Hi, ALL,
I have a following scenario.
I am trying to upgrade our codebase from 2.8 to 3.0. The application is MT and it has many different binaries and many different so/a libraries (we are on RHEL6ATM).
What happen is when the machine is going to reboot we see the assertion dialog. The first 5 frames of the dialog points to the wxGrid destructor and the reference counting. However I am not able to see past the 5 frame of the backtrace and therefore don't have slightest idea of what is happening.
I tried to slow down the process of reboot, but the assertion dialog shows up and because the binary will die that didn't work. All I have time to do is click the backtrace button in the dialog, see the first 5 frames and that's it.
Does anyone have an idea of what I can try to do to see where the assert is coming from? Presumably the assert is coming from the binary being shutting down and destroying the grid, but I don't know which one.
On top of that the program has very weird design - some frames are created, but never showed to the user until needed/required, and so this left me completely blind as to the where the assertion comes from.
Thank you.
Assertion during the 3.0 upgrade
Re: Assertion during the 3.0 upgrade
I assume the crash happens when the PC is shutting down?
Do you handle the wxEVT_QUERY_END_SESSION/wxEVT_END_SESSION events? And if yes, are they fired?
A few years ago i had a similar problem under Windows and the problem was that some destructors were called in a different order when shutting down compared to a "normal" termination of the application. In particular, the wxApp dtor was executed before the one from the main frame, which lead to several classes being destroyed already that i relied on in the frame dtor. But that was a bug in wx and was fixed later.
But maybe it's a similar problem in your case. I'd try to write some logging data in a file, so you can check it after the reboot.
Do you handle the wxEVT_QUERY_END_SESSION/wxEVT_END_SESSION events? And if yes, are they fired?
A few years ago i had a similar problem under Windows and the problem was that some destructors were called in a different order when shutting down compared to a "normal" termination of the application. In particular, the wxApp dtor was executed before the one from the main frame, which lead to several classes being destroyed already that i relied on in the frame dtor. But that was a bug in wx and was fixed later.
But maybe it's a similar problem in your case. I'd try to write some logging data in a file, so you can check it after the reboot.
Use the source, Luke!
Re: Assertion during the 3.0 upgrade
doublemax,
The problem is that this particular assert when it shows the assert dialog has only 5 frames visible initially and all of those are from wx and not our code.
And unfortunately this assert does not generate core file. When I try to click "Save to File" it shows the file saving dialog for a quick second and then normal shutdown kicks in which destroys everything.
I presume the assert dialog stays for the time the application is active and as soon as the dialog dies, the binary dies with it and the shutdown process keeps going on.
And saving everything to clipboard doesn't make much sense either - the content of clipboard will be gone after the application dies and system will go to the shutdown process.
Thank you.
You presumption is correct, aside from the fact that it is an assertion and not a crash.doublemax wrote: I assume the crash happens when the PC is shutting down?
No, I don't handle them in any of the binaries/so's.doublemax wrote: Do you handle the wxEVT_QUERY_END_SESSION/wxEVT_END_SESSION events? And if yes, are they fired?
I'd love to.doublemax wrote: A few years ago i had a similar problem under Windows and the problem was that some destructors were called in a different order when shutting down compared to a "normal" termination of the application. In particular, the wxApp dtor was executed before the one from the main frame, which lead to several classes being destroyed already that i relied on in the frame dtor. But that was a bug in wx and was fixed later.
But maybe it's a similar problem in your case. I'd try to write some logging data in a file, so you can check it after the reboot.
The problem is that this particular assert when it shows the assert dialog has only 5 frames visible initially and all of those are from wx and not our code.
And unfortunately this assert does not generate core file. When I try to click "Save to File" it shows the file saving dialog for a quick second and then normal shutdown kicks in which destroys everything.
I presume the assert dialog stays for the time the application is active and as soon as the dialog dies, the binary dies with it and the shutdown process keeps going on.
And saving everything to clipboard doesn't make much sense either - the content of clipboard will be gone after the application dies and system will go to the shutdown process.
Thank you.
Re: Assertion during the 3.0 upgrade
I was thinking about some custom logging function that writes something into a logfile. Just outputting a line in the dtors of crucial classes (wxApp, Main wxFrame, etc) could at least tell you if they are called in a different order on shutdown. But as this is under Linux, i can't imagine that's the problem.
I would also try to catch the wxEVT_QUERY_END_SESSION/wxEVT_END_SESSION events and close the application when they're received. Maybe it makes a difference.
I would also try to catch the wxEVT_QUERY_END_SESSION/wxEVT_END_SESSION events and close the application when they're received. Maybe it makes a difference.
Use the source, Luke!
Re: Assertion during the 3.0 upgrade
doublemax,
I had to go over couple of my binaries to find where the grid is referenced and find which binary is crashing.
Now I will have to do some investigation of what is going on.
Thank you.
I had to go over couple of my binaries to find where the grid is referenced and find which binary is crashing.
Now I will have to do some investigation of what is going on.
Thank you.