help: wired crash issue which only happens in Windows XP system with release build of wx 3.0.2

[asmwarrior]

Hi, as a developer of Codeblocks(www.codeblocks.org), I try to migrate my wxWidgets library from 2.8.12 to 3.0.2.
I can build and wxWidgets 3.0.2 and Codeblocks(which link to wx library) successfully, but I get a crash if I try to close C::B or sometimes disable or enable some core plugins.

The crash happens in the condition that:

Condition A:
1, wxWidgets 3.0.2 is build as release mode(mingw32-make.exe ...BUILD=release)
2, OS: windows XP
result: C::B random crash!

Condition B:
1, wxWidgets 3.0.2 is build as release mode(mingw32-make.exe ...BUILD=release)
2, OS: windows 7 32bit or 64 bit
result: C::B no crash.

Condition C:
1, build wxWidgets 3.0.2 in debug mode (mingw32-make.exe ...BUILD=debug)
2, OS: windows XP
result: C::B no crash.

This is quite wired, since only the release version of wx library on winXP system cause the crash.
To hunt the crash bug, I even build a release version of wx which has "-g" option:

mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 USE_OPENGL=1 VENDOR=cb CXXFLAGS=" -g -fno-keep-inline-dllexport -Wno-unused-local-typedefs -Wno-deprecated-declarations" >log-release-g.txt 2>&1

Thus, I can get a detailed crash call stack in the GDB, the call stack are:

#0 0x6474c5e5 in wxClassInfo::IsKindOf (info=<optimized out>, this=<optimized out>) at D:\wx3\include\wx\rtti.h:91
#1 wxCheckDynamicCast (classInfo=<optimized out>, obj=<optimized out>) at D:\wx3\include\wx\object.h:450
#2 wxWindow::FindItemByHWND (this=<optimized out>, hWnd=hWnd@entry=0x208a4, controlOnly=controlOnly@entry=true) at D:\wx3\src\msw\window.cpp:408
#3 0x6474dc28 in wxWindow::HandleCtlColor (this=<optimized out>, brush=brush@entry=0x22cff0, hDC=hDC@entry=0xa50116c3, hWnd=hWnd@entry=0x208a4) at D:\wx3\src\msw\window.cpp:4537
#4 0x6475911b in wxWindow::MSWHandleMessage (this=0x5a0a5e0, result=0x22d100, message=307, wParam=2768312003, lParam=133284) at D:\wx3\src\msw\window.cpp:3286
#5 0x647497a0 in wxWindow::MSWWindowProc (this=this@entry=0x5a0a5e0, message=message@entry=307, wParam=wParam@entry=2768312003, lParam=lParam@entry=133284) at D:\wx3\src\msw\window.cpp:3645
#6 0x64741f96 in wxTopLevelWindowMSW::MSWWindowProc (this=this@entry=0x5a0a5e0, message=message@entry=307, wParam=wParam@entry=2768312003, lParam=lParam@entry=133284) at D:\wx3\src\msw\toplevel.cpp:467
#7 0x647a8046 in wxFrame::MSWWindowProc (this=0x5a0a5e0, message=307, wParam=2768312003, lParam=133284) at D:\wx3\src\msw\frame.cpp:887
#8 0x64751223 in wxWndProc(HWND__*, unsigned int, unsigned int, long)@16 (hWnd=0x20678, message=307, wParam=2768312003, lParam=133284) at D:\wx3\src\msw\window.cpp:2711
#9 0x7e418734 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
#10 0x00020678 in ?? ()
#11 0x7e418816 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
#12 0x647511b0 in wxWindow::SubclassWin(HWND__*) () at D:\wx3\include\wx\object.h:361
#13 0x7e42927b in USER32!GetParent () from C:\WINDOWS\system32\user32.dll
#14 0x00000000 in ?? ()

Which point to the line:

// Climb upwards through inheritance hierarchy.
// Dual inheritance is catered for.

bool IsKindOf(const wxClassInfo *info) const
{
return info != 0 &&
( info == this ||
( m_baseInfo1 && m_baseInfo1->IsKindOf(info) ) ||
( m_baseInfo2 && m_baseInfo2->IsKindOf(info) ) ); //**********HERE********
}

Since the release of wx is build with "-O2" option, I can't figure out what cause the issue.
It looks like some function are in-lined.
Here is the disas of the crash(the result of the command "disas /rs" under GDB),
0x6474c5e5 is the crash program address.

...
90 ( m_baseInfo1 && m_baseInfo1->IsKindOf(info) ) ||
0x6474c5b0 <+544>: c7 04 24 00 60 46 65 mov DWORD PTR [esp],0x65466000
0x6474c5b7 <+551>: e8 74 51 91 00 call 0x65061730 <wxClassInfo::IsKindOf(wxClassInfo const*) const>
0x6474c5bc <+556>: 83 ec 04 sub esp,0x4
0x6474c5bf <+559>: 84 c0 test al,al
0x6474c5c1 <+561>: 0f 85 e9 fd ff ff jne 0x6474c3b0 <wxWindow::FindItemByHWND(HWND__*, bool) const+32>
91 ( m_baseInfo2 && m_baseInfo2->IsKindOf(info) ) );
0x6474c5c7 <+567>: 8b 4b 10 mov ecx,DWORD PTR [ebx+0x10]
90 ( m_baseInfo1 && m_baseInfo1->IsKindOf(info) ) ||
0x6474c5ca <+570>: 85 c9 test ecx,ecx
0x6474c5cc <+572>: 74 17 je 0x6474c5e5 <wxWindow::FindItemByHWND(HWND__*, bool) const+597>
91 ( m_baseInfo2 && m_baseInfo2->IsKindOf(info) ) );
0x6474c5ce <+574>: c7 04 24 00 60 46 65 mov DWORD PTR [esp],0x65466000
0x6474c5d5 <+581>: e8 56 51 91 00 call 0x65061730 <wxClassInfo::IsKindOf(wxClassInfo const*) const>
0x6474c5da <+586>: 83 ec 04 sub esp,0x4
0x6474c5dd <+589>: 84 c0 test al,al
0x6474c5df <+591>: 0f 85 cb fd ff ff jne 0x6474c3b0 <wxWindow::FindItemByHWND(HWND__*, bool) const+32>
=> 0x6474c5e5 <+597>: 8b 52 10 mov edx,DWORD PTR [edx+0x10]
90 ( m_baseInfo1 && m_baseInfo1->IsKindOf(info) ) ||
0x6474c5e8 <+600>: 85 d2 test edx,edx
0x6474c5ea <+602>: 0f 84 e7 fd ff ff je 0x6474c3d7 <wxWindow::FindItemByHWND(HWND__*, bool) const+71>
88 return info != 0 &&
0x6474c5f0 <+608>: 81 fa 00 60 46 65 cmp edx,0x65466000
0x6474c5f6 <+614>: 0f 84 b4 fd ff ff je 0x6474c3b0 <wxWindow::FindItemByHWND(HWND__*, bool) const+32>
90 ( m_baseInfo1 && m_baseInfo1->IsKindOf(info) ) ||
0x6474c5fc <+620>: 8b 5a 0c mov ebx,DWORD PTR [edx+0xc]
89 ( info == this ||
0x6474c5ff <+623>: 85 db test ebx,ebx
0x6474c601 <+625>: 0f 84 aa 00 00 00 je 0x6474c6b1 <wxWindow::FindItemByHWND(HWND__*, bool) const+801>
88 return info != 0 &&
0x6474c607 <+631>: 81 fb 00 60 46 65 cmp ebx,0x65466000
0x6474c60d <+637>: 0f 84 9d fd ff ff je 0x6474c3b0 <wxWindow::FindItemByHWND(HWND__*, bool) const+32>
90 ( m_baseInfo1 && m_baseInfo1->IsKindOf(info) ) ||
0x6474c613 <+643>: 8b 73 0c mov esi,DWORD PTR [ebx+0xc]
...


Here, the edx is 0, so it try to access a memory address of 0x00000010.

Does this cause by a GCC bug, if this is true, why the same app(which crash on winXP) works fine under Win7 system?
Does this cause by a wxWidgets bug only related to winXP, if so, why the debug version of wx library don't cause the crash on winXP?

Any one can give me a hint? Thanks.

The original discussion are here in Codeblocks' forum:
All - http://forums.codeblocks.org/index.php/topic,20607.0/all.html

Asmwarrior

[Rossano Paris]

Hallo

Basing on my experience such kind of random problems often are due to different compilation parameters among main application and its plugin

In other words, could you verify if others CB plugins you are using have been built using the same wx version and compiler parameters ?

Hope it helps

Regards

Rossano

[AsmWarrior]

On Friday, October 2, 2015 at 2:58:39 PM UTC+8, Rossano Paris wrote:

Hallo

Basing on my experience such kind of random problems often are due to different compilation parameters among main application and its plugin

In other words, could you verify if others CB plugins you are using have been built using the same wx version and compiler parameters ?

Hope it helps

Regards

Rossano

Hi, Rossano, thanks for the suggest.
I have carefully check the compilation parameters, I don't see they have differences, except that the dllimport/dllexport are different for the dll and exe files.
The compiler option are not changed for several years since we link C::B to the wx2.x library.

The wx library are built with -O2 option, and the C::B is built with -O0, does those mixed binary cause some issue?(From my research, it should not cause issues).

Asmwarrior

[Rossano Paris]

I'm sorry, I can't give you a sure answer about those options.

After having faced in the past such kind of problems you described, I've decided to adopt exactly the same compilation parameters among applications, static or dynamic linked libraries and "plugins" components. That's my kind of approach in order to avoid strange behaviours. Even the compiler version, to follow the rules I've decided to keep developing applications, must be the same among components.

Another approach to discover the origin of your problems could be to investigate along the way the application uses to update values in its controls.

As you certainly know, controls values must be updated always from the main application thread.

Some times developers to process an event in an EventHandler object, instead of using the QueueEvent() function they use ProcessEvent() even from another thread.

This modality might create issues which they appear randomly.

Regards

Rossano

On Thursday, 1 October 2015 17:19:49 UTC+2, AsmWarrior wrote:

[AsmWarrior]

On Monday, October 5, 2015 at 8:26:58 PM UTC+8, Rossano Paris wrote:

I'm sorry, I can't give you a sure answer about those options.

After having faced in the past such kind of problems you described, I've decided to adopt exactly the same compilation parameters among applications, static or dynamic linked libraries and "plugins" components. That's my kind of approach in order to avoid strange behaviours. Even the compiler version, to follow the rules I've decided to keep developing applications, must be the same among components.

Hi, Rossano, thanks for the replay again, I know the rule you mentioned, and in-fact, I built a debug version of wx 3.0.2 library and C::B, all were built with -O0 option, and I didn't see the crash on my Windows XP any more, that's the workaround I currently use.

 

Another approach to discover the origin of your problems could be to investigate along the way the application uses to update values in its controls.

As you certainly know, controls values must be updated always from the main application thread.

Some times developers to process an event in an EventHandler object, instead of using the QueueEvent() function they use ProcessEvent() even from another thread.

This modality might create issues which they appear randomly.

OK, I understand this, but my crash is not quite related. Further analysis shows that if a plugin create a wxWindow, but do not add the window to the wxAui windows system, then the main application(codeblocks.exe) won't crash on exits(after its call the Destroy() function in the main frame), so I guess it is either a gcc bug or wxAui bug.

Any way, thanks for the constructive help.

Asmwarrior

[Rossano Paris]

Hi, AsmWarrior

I thank you for your effort to maintain C::B

I hope to hear news from C::B about a new release.

Happy coding ! ;)

Rossano

On Thursday, 1 October 2015 17:19:49 UTC+2, AsmWarrior wrote:

[AsmWarrior]

On Wednesday, October 7, 2015 at 4:01:39 AM UTC+8, Rossano Paris wrote:

Hi, AsmWarrior

I thank you for your effort to maintain C::B

I hope to hear news from C::B about a new release.

Happy coding ! ;)

Rossano

Some news about this bug, it looks like this is a GCC optimization error, see our recent discussion here:

#17483 (wxDynamicCast segfault with mingw64 5.3.0 release build) – wxWidgets

ollydbg from Code::Blocks forum