App crashes on closing Topic is solved

[damnitmat]

Hello,

My app started to crash upon closing. In practical, it isn't really disturbing or annoying to the end user, since the app just closes and everything is saved. But as a developer it isn't really satisfying, and I suppose that it's not really good for my computer either.
The exception thrown is a sizer exception, but I don't know how to interpret it, here is the call stack :



Here is the exception :
Exception thrown: read access violation.
this->m_window-> was 0xDDDDDDDD.

and at this exact line of the Free() method :

Code: Select all

	case Item_Sizer:
            delete m_sizer;   // THIS LINE
            break;

Here are my thoughts, as I would like to get yours :

- The excepion is thrown from a sizer that is deleted "manually" and that wxWidgets can't delete no more since it doesn't exist (I say manually between quotes because I checked and I don't delete sizers by myself in the entire project)
- The exception is thrown from a sizer that I declarated but didn't initialize, so the pointed value is not valid, and wxWidgets can't delete it when the time comes.

The « External Code » bit prevents me from tracing the source of the problem; does someone have a way to know what is this external code talked about ? I'm using VS 2019 on Windows 10.

Thanks in advance,
Mat

[doublemax]

Most likely you put a sizer item (either a window or another sizer) into two (or more) different sizers. Go through your sizer code line by line and check.

This happens quite often when writing sizer code by hand.

[PB]

Most likely you put a sizer item (either a window or another sizer) into two (or more) different sizers.

I believe that unlike wxSizers, wxWindows are guarded (with an assert) against being put in more than sizer so the culprit is most likely a sizer.

The posted code with wxSizerItem's m_kind being Item_Sizer corroborates this.

As for External Code, right click the list in Call Stack window and in the menu that pops up check "Show External Code". I am afraid it will not be very helpful in this case though, the difference you will see will be the gray text:

[damnitmat]

Most likely you put a sizer item (either a window or another sizer) into two (or more) different sizers. Go through your sizer code line by line and check.

This happens quite often when writing sizer code by hand.

Ok that's what I did, and I found the problem, at those lines :

Code: Select all

	image_scroll = new wxScrolledWindow(page1_panel);
	image_scroll->SetSizer(middle_pane);
	image_scroll->SetScrollRate(15, 15);

It was a 5th or 6th level sizer that I forgot inside my code, now that it is simplified, it works fine !
But why can't you embed that much sizers ? Is this a bug or is this a voluntary thing ? I guess it could cause performance issues...

Also, PB you indeed said that the code that threw an error was designed to delete a sizer, but the problematic item is a wxScrolledWindow, which is a heir of wxPanel and wxWindow, could this be a bug ?

Thanks for the help, guys

[doublemax]

It was a 5th or 6th level sizer that I forgot inside my code, now that it is simplified, it works fine !
But why can't you embed that much sizers ? Is this a bug or is this a voluntary thing ? I guess it could cause performance issues...

It doesn't have to do with the number or level of sizers. You just have to avoid "illegal" relationships, like one sizer being inside multiple sizers or one sizer being assigned to multiple windows.

The code you posted doesn't say much. It won't cause any problem unless you used middle_pane for another window already.

[damnitmat]

Ah yes, middle_pane was indeed set as sizer for two objects at the same time, I get it now. That's why it couldn't be accessed the second time.

Thanks for all !