Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

App: fix undo/redo of dynamic property add/remove/change #3625

Merged
merged 1 commit into from Feb 21, 2022

Conversation

realthunder
Copy link
Collaborator

In an transaction where dynamic property is removed, it is copied and stored. However, if there is new dynamic property added in the same transaction, it is possible for the memory allocator to reuse the just deleted memory block. This will cause hard to debug problem, because Transaction uses a map with the property pointer as key. This commit changed the key to an integer ID.

Copy link
Member

@chennes chennes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a straightforward change. It doesn't appear to break anything, the code is compact and understandable, and based on @realthunder's description it sounds like it fixes a potentially serious problem. There is no test case given to demonstrate the issue, but changing to a monotonically increasing thread-safe integer key for this map seems like a good idea.

@@ -48,11 +50,12 @@ TYPESYSTEM_SOURCE_ABSTRACT(App::Property , Base::Persistence)
//**************************************************************************
// Construction/Destruction

static std::atomic<long> _PropID;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we define this to be an uint64_t instead?
On some configurations long can be 32bits.
If someone would use such a system and this static variable would get updated 60 times a second it would only take about a year before it wraps around and becomes negative. Give it another year and the uniqueness aren't guaranteed anymore.

I do know that this is an edge case, but better safe than sorry when it comes to uniqueness. Edge cases has happened before :)

@berndhahnebach berndhahnebach added Core Issue or PR touches core sections (App, Gui, Base) of FreeCAD and removed For 0.20 labels Sep 17, 2021
@berndhahnebach
Copy link
Contributor

berndhahnebach commented Sep 24, 2021

Following a link to the branch on the CI-repository:

https://gitlab.com/freecad/FreeCAD-CI/-/commits/PR_3625

The CI-status is available on the latest commit of the branch.
If there is no status available the PR should be rebased on latest master.
Check pipeline branches to see if your PR has been run by the CI.

https://gitlab.com/freecad/FreeCAD-CI/-/pipelines?scope=branches

@donovaly
Copy link
Member

donovaly commented Jan 6, 2022

Can you please rebase that it can be merged?

@wwmayer, this is a small PR but was never merged, are there concerns from your side?
@chennes, you once gave your OK, so OK with you to merge it?

@chennes
Copy link
Member

chennes commented Jan 7, 2022

Yes, my current self agrees with my past self (for once!) 😃 I think this is a good idea.

@donovaly
Copy link
Member

@realthunder , please rebase this to be merged

@donovaly
Copy link
Member

Thanks for rebasing

@donovaly donovaly merged commit 0a0bdf6 into FreeCAD:master Feb 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Core Issue or PR touches core sections (App, Gui, Base) of FreeCAD
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants