Crash on close if ANY window undocked?!

[MortenMacFly]

Dear all,
I'm having a strange problem which I cannot pinpoint:
If I undock any window inside C::B (I first tried the debugger's watch window but it also appears with others, e.g. management...) and close C::B I get a segfault immediatly after C::B asks to "save the changed layout". By Undocking I mean to put the window completely besides the C::B main window. Is this only me? If not: Is this a bug in C::B or the docking lib? I've attached a report file in case this will help if someone cannot reproduce this thing.
With regards, Morten.
Ps.: Version 1.0 revision 2160 (gcc 3.4.4 Windows/unicode, build: Mar  6 2006 10:07:48)
Pps.: I cannot upload the report file because the folder is full so I've attached it here:

Error occured on Thursday, March 9, 2006 at 08:05:18.

D:\Devel\CodeBlocks_Devel\src\devel\codeblocks.exe caused an Access Violation at location 00000000 Reading from location 00000000.

Registers:
eax=017634e8 ebx=014c60f8 ecx=00000000 edx=02167720 esi=004b5b08 edi=0022f804
eip=00000000 esp=0022f4a0 ebp=0022f4ac iopl=0         nv up ei pl zr na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246

Call stack:
00000000
101F2A2E  C:\WINDOWS\system32\wxmsw26u_gcc_cb.dll:101F2A2E  _ZNK11wxSizerItem7IsShownEv
0044ECBF  D:\Devel\CodeBlocks_Devel\src\devel\codeblocks.exe:0044ECBF  wxFrameManager::Render(wxDC*)  D:/Devel/CodeBlocks_Devel/src/src/wxAUI/manager.cpp:3335
0044EFCB  D:\Devel\CodeBlocks_Devel\src\devel\codeblocks.exe:0044EFCB  wxFrameManager::Repaint(wxDC*)  D:/Devel/CodeBlocks_Devel/src/src/wxAUI/manager.cpp:3391
0044F083  D:\Devel\CodeBlocks_Devel\src\devel\codeblocks.exe:0044F083  wxFrameManager::OnPaint(wxPaintEvent&)  D:/Devel/CodeBlocks_Devel/src/src/wxAUI/manager.cpp:3398
100AA0E8  C:\WINDOWS\system32\wxmsw26u_gcc_cb.dll:100AA0E8  _ZN12wxEvtHandler21ProcessEventIfMatchesERK21wxEventTableEntryBasePS_R7wxEvent
100AA4AC  C:\WINDOWS\system32\wxmsw26u_gcc_cb.dll:100AA4AC  _ZN16wxEventHashTable11HandleEventER7wxEventP12wxEvtHandler
100AB489  C:\WINDOWS\system32\wxmsw26u_gcc_cb.dll:100AB489  _ZN12wxEvtHandler12ProcessEventER7wxEvent
1010F95F  C:\WINDOWS\system32\wxmsw26u_gcc_cb.dll:1010F95F  _ZN8wxWindow11HandlePaintEv
10138958  C:\WINDOWS\system32\wxmsw26u_gcc_cb.dll:10138958  _ZN7wxFrame11HandlePaintEv
1013923A  C:\WINDOWS\system32\wxmsw26u_gcc_cb.dll:1013923A  _ZN7wxFrame13MSWWindowProcEjjl
1010C750  C:\WINDOWS\system32\wxmsw26u_gcc_cb.dll:1010C750  _Z9wxWndProcP6HWND__jjl@16
77D18734  C:\WINDOWS\system32\USER32.dll:77D18734  GetDC
77D18816  C:\WINDOWS\system32\USER32.dll:77D18816  GetDC
77D1B4C0  C:\WINDOWS\system32\USER32.dll:77D1B4C0  DefWindowProcW
77D1B50C  C:\WINDOWS\system32\USER32.dll:77D1B50C  DefWindowProcW
7C91EAE3  C:\WINDOWS\system32\ntdll.dll:7C91EAE3  KiUserCallbackDispatcher
77D18A10  C:\WINDOWS\system32\USER32.dll:77D18A10  DispatchMessageW
100EC1B5  C:\WINDOWS\system32\wxmsw26u_gcc_cb.dll:100EC1B5  _ZN11wxEventLoop14ProcessMessageEP6tagMSG
100EC7F4  C:\WINDOWS\system32\wxmsw26u_gcc_cb.dll:100EC7F4  _ZN11wxEventLoop8DispatchEv
100EC590  C:\WINDOWS\system32\wxmsw26u_gcc_cb.dll:100EC590  _ZN11wxEventLoop3RunEv
10183E8E  C:\WINDOWS\system32\wxmsw26u_gcc_cb.dll:10183E8E  _ZN9wxAppBase8MainLoopEv
00404C28  D:\Devel\CodeBlocks_Devel\src\devel\codeblocks.exe:00404C28  CodeBlocksApp::OnRun()  D:/Devel/CodeBlocks_Devel/src/src/app.cpp:461
10043817  C:\WINDOWS\system32\wxmsw26u_gcc_cb.dll:10043817  _Z14wxUninitializev
100B33BA  C:\WINDOWS\system32\wxmsw26u_gcc_cb.dll:100B33BA  _Z7wxEntryP11HINSTANCE__S0_Pci
0040148A  D:\Devel\CodeBlocks_Devel\src\devel\codeblocks.exe:0040148A  WinMain  D:/Devel/CodeBlocks_Devel/src/src/app.cpp:297
0045FAAA  D:\Devel\CodeBlocks_Devel\src\devel\codeblocks.exe:0045FAAA
004011E7  D:\Devel\CodeBlocks_Devel\src\devel\codeblocks.exe:004011E7
00401238  D:\Devel\CodeBlocks_Devel\src\devel\codeblocks.exe:00401238
7C816D4F  C:\WINDOWS\system32\kernel32.dll:7C816D4F  RegisterWaitForInputIdle

[MortenMacFly]

Update: Meanwhile I'm pretty sure the bug is caused by wxAUI... but I would still welcome confirmations.
By the way: I found this interesting site about wxAUI: http://www.alex.org.uk/wxAUI/index.html. There are a few patches and hints about wxAUI an (e.g. wxAUI on the MAC!).
With regards, Morten.

[thomas]

Looks like an uninitialized pointer in wxAUI, will be hard to find.

EDIT: Don't waste your time stepping through it in the debugger, it will work fine...

[MortenMacFly]

EDIT: Don't waste your time stepping through it in the debugger, it will work fine...

You're right. But this issue is pretty weird. I placed a fprintf nearly everywhere in the wxAUI code to pinpoint where it got's crashed but so far I can see all my fprintf's. It seems it's not the wxAUI or some deep-level wxWidgets stuff... I also applied some of the "null pointer" patches from the patches on the web page listed in my previous post. This does'nt fix the issue, too. BTW: I believe some of the patches should be applied anyway. Any hints I could use for further investigation?
With regards, Morten.

[thomas]

Narrowed the location:  debugger plugin, inside OnRelease().

[thomas]

The good news: I fixed the problem in the debugger plugin.
Naively speaking, is as easy as that:

Code

-    if (m_pExamineMemoryDlg)
+    if (!appShutDown && m_pExamineMemoryDlg)
    {
        CodeBlocksDockEvent evt(cbEVT_REMOVE_DOCK_WINDOW);
        evt.pWindow = m_pExamineMemoryDlg;
        Manager::Get()->GetAppWindow()->ProcessEvent(evt);
        m_pExamineMemoryDlg->Destroy();
    }

The bad news: This is a symptom, not the cause. As the debugger plugin works fine, the TODO plugin will crash for the same reason, and as that one is fixed, another one...

The crash happens inside MainFrame::OnApplicationClose when Manager::Shutdown() is called (during OnRelease of certain plugins).

The debugger plugin, the todo plugin, and some others post cbEVT_REMOVE_DOCK_WINDOW events during their shutdown functions.

This should actually be fine, but for some reason it is not OK if a dock window is undocked. Apparently, these events are only processed after the main frame has been destroyed...

[MortenMacFly]

I was away until today so I read the new just by now. Sorry for the delayed answer.
It is valuable information at least in the way that I didn't get that far... ;-)
Anyway... I agree: This is strange. Didn't mandrav know the author of the wxAUI plugin? Maybe he has another hint. Because if this error is really something related to wxAUI (which still could be if I understand what you've written). He should receive a lot of support requests because of that. Also interesting to know is if this also happens if one uses wxWidgets in another version - e.g. 2.6.1 or 2.6.3 (RC somehwat). This would show up if it's a problem with wxWidets itself... Anyone out there not using version 2.6.2???
With regards, Morten.

[MortenMacFly]

Anyone out there not using version 2.6.2???

Thomas, I've got good news!
I've compiled wxWidgets version 2.6.1 and then re-build Code::Blocks from scratch using this version of wxWidgets (2.6.1). And guess what? You CAN undock and close C::B without any crashes. So I guess it's really a bug with wxWidgets. Maybe C::B should stick with wxWidgets 2.6.1? I remember other issues that maybe releated to 2.6.2, too.
Now, why is this good news? Because it may be an issue that'll be fixed in 2.6.3... ;-)
With regards, Morten.

[MortenMacFly]

Anyone out there not using version 2.6.2???

Well, by now I've compiled wxWidgets 2.6.3-RC1. And guess what: It works there, too. I would say that this is proof enough to say that this issue is wxWidgets 2.6.2 related. Furthermore I suggest not putting too much effort into this anymore - sooner or later C::B will work with wxWidgets 2.6.3 (release) anyway...
With regards, Morten.

[MortenMacFly]

This will be my last post to this topic, but it has to be said:
By now I've completely removed all *.o;*.a;*.gch files and removed the "devel" and "output" directory completely. Then I made a rebuild using wxWidgets 2.6.2 (that's exactly the same way I did it with the other versions of wxWidgets) and now it works. The bug suddenly has "disappeard" allthough I'm really doing the same: Undocking a debug-related window outside C::B. Now that's absolutely strange and to be honest: I have no glue what happens here. At least you (Thomas) experienced the same issue so I'm not alone. ;-)
Anyway: Anybody else experiencing such strange crashes should maybe follow my instructions before complaining.
With regards, Morten.

[sethjackson]

Well that stinks rebuilding now.

[sethjackson]

Didn't fix. 

[MortenMacFly]

Didn't fix. 

Which version of wxWidgets you are using? Unicode?! And what are exactly the steps that still cause the crash for you? E.g.: What windo do you undock to where - left/right; besides C::B; completely ouutside / overlapping... maybe you could post a screenshot? Could you try to do the same using wxWidgets 2.6.1?
With regards, Morten.

[sethjackson]

Yep Unicode. wx 2.6.2.

C::B Version 1.0 revision 2202 (gcc 3.4.4 Windows/unicode, build: Mar 14 2006 20:30:30)



1. Undock Messages pane (leave Messages pane inside C::B window area).
2. Close C::B
3. C::B crash.

[MortenMacFly]

1. Undock Messages pane (leave Messages pane inside C::B window area).
2. Close C::B
3. C::B crash.

Here at work I did the same steps as yesterday at home and it's still crashing, too. Unfortunately I cannot give a try what happens if I change the lib version here. All I can say is that at home it was crashing, then I compiled C::B from scratch using 2.6.1, then 2.6.3-RC1 and finally 2.6.2 again and there it doesn't crash anymore. Now how strange is that?!
Could you (maybe) try to compile "your" C::B from scratch against wxWidgets 2.6.1?
With regards, Morten.
Ps.: Isn't that what developers really like?! :?