View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002317 | NoesisGUI | C++ SDK | public | 2022-03-31 20:22 | 2022-05-03 19:15 |
| Reporter | steveh | Assigned To | sfernandez | ||
| Priority | normal | Severity | crash | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.1.4 | ||||
| Target Version | 3.1.5 | Fixed in Version | 3.1.5 | ||
| Summary | 0002317: Crash when applying animation values in TimeManager::Tick | ||||
| Description | Hi guys, I've spent quite a bit of time tracking down a crash. I've tracked it down to attempting to apply an animation value on a destroyed dependency object. I've created a reproducible sample that I've attached as a ZIP to this bug report. So what has happened?
So just to clarify, it's this bit of code in TimeManager::Tick which is broken:
So if dependency objects that currently reside in the animationValues map are removed during ApplyAnimationValues it can crash. In my case this was caused by changing the Content from a DependencyPropertyChangedEvent which cleared out the ContentTemplate which destroyed the DependencyObjects created by that DataTemplate. Since this happened instantly, it ended up invalidating the AnimationValue map which had already taken a raw pointer to the DependencyObjects. I've fixed this locally by adding all targets in the AnimationValue map to the "aliveTargets" vector:
I'm not sure if this is the best fix, but I've not been able to crash it after this change. Cheers! | ||||
| Steps To Reproduce |
Note: This does not seem to be 100% for some reason. If it doesn't break, just restart the sample. It'll break eventually. | ||||
| Attached Files | |||||
| Platform | Any | ||||
|
Thanks for the report Steve, giving high-priority to this |
|
|
Hi guys, so in addition to the above change, one of our tech directors is investigating other stomps with other tools and has identified the following stomp (I've attached an image). The change is the P4 diff. Unfortunately I didn't investigate this stomp so I don't have any more info on it. It looks like erasing the clock pointer inside RemoveMasterClock, and then we try to write mTarget to 0 on a now-erased clock. The fix is to zero out the target on the clock before it's erased from the mMasterClocks vector. |
|
|
That change is not correct because there is another use of the RemoveMasterClock (in the method OnClockFinished) that requires later use of clock->mTarget. void TimeManager::RemoveUnusedMasterClocks(const ClocksSet& clocks) Could you try that? |
|
|
Hi Sergio, your suggestion works great. We've submitted that to our local branch, much appreciated. |
|
|
Both issues solved in changeset r11317. |
|
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-03-31 20:22 | steveh | New Issue | |
| 2022-03-31 20:22 | steveh | File Added: AnimationCrashBug.zip | |
| 2022-04-04 07:53 | jsantos | Assigned To | => sfernandez |
| 2022-04-04 07:53 | jsantos | Status | new => assigned |
| 2022-04-04 07:53 | jsantos | Product Version | => 3.1.4 |
| 2022-04-04 07:53 | jsantos | Target Version | => 3.1.5 |
| 2022-04-04 07:54 | jsantos | Note Added: 0007884 | |
| 2022-04-22 14:37 | steveh | Note Added: 0007906 | |
| 2022-04-22 14:37 | steveh | File Added: image.png | |
| 2022-04-22 16:18 | sfernandez | Status | assigned => feedback |
| 2022-04-22 16:18 | sfernandez | Note Added: 0007907 | |
| 2022-04-22 18:30 | steveh | Note Added: 0007909 | |
| 2022-04-22 18:30 | steveh | Status | feedback => assigned |
| 2022-05-03 19:15 | sfernandez | Status | assigned => resolved |
| 2022-05-03 19:15 | sfernandez | Resolution | open => fixed |
| 2022-05-03 19:15 | sfernandez | Fixed in Version | => 3.1.5 |
| 2022-05-03 19:15 | sfernandez | Note Added: 0007916 |