Crash on layout switch
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 10/10/2006 at 22:02, xxxxxxxx wrote:
User Information:
Cinema 4D Version: 9.102
Platform: Windows ; Mac ; Mac OSX ;
Language(s) : C++ ;---------
I've been alerted to a crash situation with my plugin's dialog when switching layouts.Thing is that it's very specific. The conditions are:
1. The dialog must be saved with the layout being reselected (say, from Startup->Standard->Startup layouts).
2. The dialog must be docked.
3. The dialog has no thumbnails being shown or no Runtimes (and thus no thumbnails) - as best as can be found.
If the dialog is not docked, no crash. (???) 'xplain that one please. If docked, but thumbnails are visible (any thumbnails), no crash.
I cannot find a debug breakpoint that corresponds with the crash - i.e.: this is crashing while making a Cinema 4D call and not one of my plugin's. But it is definitely instigated by my plugin. As best as I can tell, it is crashing before it reaches RestoreLayout() (?). As far as I am aware, there are no other plugin calls prior to this - any you can submit?
It is always crashing at the same instruction:
mov ecx,dword ptr [edx+4]
Lot of help that is. The error is "Access Violation" and obviously there is an invalid/NULL pointer involved.
Since Cinema 4D is in the middle of switching layouts, finding the root cause here is more than frustrating. No way to GePrint. No way to raise an error dialog. And little I can do to find the entry point to this crash (!!!!).
Tell me what to do.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 11/10/2006 at 02:01, xxxxxxxx wrote:
A common pitfall that leads to those types of crashes is not to reset the pointers to customgui elements in DestroyWindow!
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 11/10/2006 at 02:26, xxxxxxxx wrote:
You mean like this:
// GeDialog.DestroyWindow //*---------------------------------------------------------------------------* void IPPDialog::DestroyWindow() //*---------------------------------------------------------------------------* { searchResultsList = NULL; tree = NULL; if (baseFile && settings) { settings->SaveAutoPrefs(baseFile, root.GetSelected()); baseFile->Close(); } }These are also reset at the top of CreateLayout() and are set to NULL in the dialog constructor.
As I said - this ONLY occurs if the dialog is docked in the saved layout. If I undock it...save the layout... and do the same exact thing that crashes it when docked... no crash! Works perfectly. That isn't a pointer problem (of my making).
So far, I've managed to fix this for R8.2, R8.5, and R9.1. R9.5 and R9.6 still exhibit the crashes. I can't find the cause in these. I've checked every class that is associated with the dialog (for the TreeViews and so on) several times.
Any other leads?
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 11/10/2006 at 08:57, xxxxxxxx wrote:
Additional information (from the user who alerted me) :
If the dialog is docked in both the layouts being switched, it works. If only docked in one, it will possibly crash.
Seems like something isn't jiving when the dialog gets killed by a layout switch and then restored by another - and it's docked. This is insanity!
Again, I reiterate, that I can't debug this - if I put a breakpoint on the first line of my CommandData::RestoreLayout(), it never reaches it before the Access Violation. I cannot find a breakpoint further back (not too many places to go and they don't get called). This makes it nearly impossible to determine the cause.
Thanks,