TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2

User forums > General (but related to Code::Blocks)

TDM-GCC 4.8 series (Latest: 4.8.1-tdm-2 - 2013-10-06)

<< < (5/9) > >>

ollydbg:

--- Quote from: TDragon on September 30, 2013, 05:53:14 pm ---
--- Quote from: ollydbg on September 30, 2013, 04:56:26 pm ---Bug report about TDM-GCC 4.8.1 32bit dw2 version.

As you can see that I have report that wxWidgets's sample "excep" get crashed under TDM-GCC-dw2, to reproduce this bug, I create a minimal simple project.

--- End quote ---

I can confirm that this bug is specific to TDM-GCC. No ETA for a fix yet.

-John E. / TDM

--- End quote ---
@John, I found a strange thing, today I use mingw-builds x32-4.8.1-posix-dwarf-rev5 to build wx2.8.12, and I see that Except sample still crash, call stack below:

--- Code: ---[debug]> bt 30
[debug]#0 0x7c90e514 in ntdll!KiFastSystemCallRet () from C:\WINDOWS\system32\ntdll.dll
[debug]#1 0x7e419418 in WaitMessage () from C:\WINDOWS\system32\user32.dll
[debug]#2 0x7e42770a in USER32!CallMsgFilterW () from C:\WINDOWS\system32\user32.dll
[debug]#3 0x7e4249c4 in USER32!GetCursorFrameInfo () from C:\WINDOWS\system32\user32.dll
[debug]#4 0x7e43a956 in USER32!SoftModalMessageBox () from C:\WINDOWS\system32\user32.dll
[debug]#5 0x7e43a2bc in USER32!MessageBoxIndirectA () from C:\WINDOWS\system32\user32.dll
[debug]#6 0x7e4663fd in USER32!MessageBoxTimeoutW () from C:\WINDOWS\system32\user32.dll
[debug]#7 0x7e4664a2 in USER32!MessageBoxTimeoutA () from C:\WINDOWS\system32\user32.dll
[debug]#8 0x7e450877 in USER32!MessageBoxExA () from C:\WINDOWS\system32\user32.dll
[debug]#9 0x7e45082f in USER32!MessageBoxA () from C:\WINDOWS\system32\user32.dll
[debug]#10 0x77c39300 in strerror () from C:\WINDOWS\system32\msvcrt.dll
[debug]#11 0x77c3b127 in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll
[debug]#12 0x77c36bba in msvcrt!abort () from C:\WINDOWS\system32\msvcrt.dll
[debug]#13 0x0000000a in ?? ()
[debug]#14 0x6fc5a09d in libstdc++-6!_ZN9__gnu_cxx27__verbose_terminate_handlerEv () from D:\mingw-builds\x32-4.8.1-posix-dwarf-rev5\mingw32\bin\libstdc++-6.dll
[debug]#15 0x6fc54fe9 in libstdc++-6!_ZN10__cxxabiv111__terminateEPFvvE () from D:\mingw-builds\x32-4.8.1-posix-dwarf-rev5\mingw32\bin\libstdc++-6.dll
[debug]#16 0x6fca82f0 in libstdc++-6!_ZSt9terminatev () from D:\mingw-builds\x32-4.8.1-posix-dwarf-rev5\mingw32\bin\libstdc++-6.dll
[debug]#17 0x6fcadc1c in libstdc++-6!__cxa_throw () from D:\mingw-builds\x32-4.8.1-posix-dwarf-rev5\mingw32\bin\libstdc++-6.dll
[debug]#18 0x0040233b in MyFrame::OnThrowInt (this=0xb25cd0) at D:\exception\aaa\aaaMain.cpp:417
[debug]#19 0x627015f1 in wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#20 0x6276a07e in wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#21 0x6276a14a in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#22 0x6276a545 in wxEvtHandler::ProcessEvent(wxEvent&) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#23 0x004021dc in MyFrame::ProcessEvent (this=0xb25cd0, event=...) at D:\exception\aaa\aaaMain.cpp:382
[debug]#24 0x62804dc7 in wxFrameBase::ProcessCommand(int) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#25 0x627b9d64 in wxFrame::HandleCommand(unsigned short, unsigned short, void*) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#26 0x627ba173 in wxFrame::MSWWindowProc(unsigned int, unsigned int, long) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#27 0x627a0cee in wxWndProc(HWND__*, unsigned int, unsigned int, long)@16 () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#28 0x7e418734 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
[debug]#29 0x000a0528 in ?? ()
[debug](More stack frames follow...)

--- End code ---

The exception was throw from #18 0x0040233b in MyFrame::OnThrowInt (this=0xb25cd0) at D:\exception\aaa\aaaMain.cpp:417.

But mingw-builds x32-4.8.1-posix-dwarf-rev5 can successfully run my Test Case2.

EDIT:
I just test the official MinGW GCC 4.8.1 which is dw2 by default, I also successfully pass the Case2 program, but crash happens when I run except sample code. BTW, to build the wxWidgets 2.8.12 by official MinGW 4.8.1, you need to change the header file:

--- Quote ---edit line 2217 of /mingw/include/commctrl.h to read

#define TV_DISPINFO NMTVDISPINFO

instead of

#define TV_DISPINFO __AW(NMTVDISPINFO)
--- End quote ---
See: [Mingw-users] win32api version 4

TDragon:
The wxWidgets sample crashes because it tries to throw the exception through the Windows runtime from a callback to the wxWidgets event handler. This is not supported with DW2 exception unwinding. Your test case doesn't throw through a Windows callback, which is why it works as it should under mingw-builds and MinGW.org; it exhibits a bug specific to TDM-GCC.

-John E. / TDM

ollydbg:

--- Quote from: TDragon on October 01, 2013, 02:16:44 pm ---The wxWidgets sample crashes because it tries to throw the exception through the Windows runtime from a callback to the wxWidgets event handler. This is not supported with DW2 exception unwinding. Your test case doesn't throw through a Windows callback, which is why it works as it should under mingw-builds and MinGW.org; it exhibits a bug specific to TDM-GCC.

-John E. / TDM

--- End quote ---
Thanks, I know that exception can not propagate through a non-mingw build frame, but what the wxWidgets' except sample do is:
1, write a overload function the MyFrame::ProcessEvent, and write a try block there:

--- Code: ---bool MyFrame::ProcessEvent(wxEvent& event)
{
   try
   {
   return wxFrame::ProcessEvent(event);
   }
   catch ( const wxChar *msg )
   {
   wxLogMessage(_T("Caught a string \"%s\" in MyFrame"), msg);

   return true;
   }
}

--- End code ---

2, I think all the function up to the MyFrame::ProcessEvent is all build from the same MinGW compiler, see the call stack:

--- Code: ---[debug]#18 0x0040233b in MyFrame::OnThrowInt (this=0xb25cd0) at D:\exception\aaa\aaaMain.cpp:417
[debug]#19 0x627015f1 in wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#20 0x6276a07e in wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#21 0x6276a14a in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#22 0x6276a545 in wxEvtHandler::ProcessEvent(wxEvent&) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#23 0x004021dc in MyFrame::ProcessEvent (this=0xb25cd0, event=...) at D:\exception\aaa\aaaMain.cpp:382
[debug]#24 0x62804dc7 in wxFrameBase::ProcessCommand(int) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#25 0x627b9d64 in wxFrame::HandleCommand(unsigned short, unsigned short, void*) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#26 0x627ba173 in wxFrame::MSWWindowProc(unsigned int, unsigned int, long) () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#27 0x627a0cee in wxWndProc(HWND__*, unsigned int, unsigned int, long)@16 () from E:\code\wx\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#28 0x7e418734 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
[debug]#29 0x000a0528 in ?? ()

--- End code ---

You see, the call back is infact the function wxWndProc (#27), and in #23 0x004021dc in MyFrame::ProcessEvent, there is a try catch block. So, I think there is not chance that the exception will go up to the Windows call back function, which is #27 0x627a0cee in wxWndProc.

Am I right?

EDIT: the code below works correctly, my question is: it looks like exception can not propagate up cross the event handler function.

--- Code: ---void f()
{
   throw 1;
}

void MyFrame::OnThrowInt(wxCommandEvent& WXUNUSED(event))
{
   //throw -17;
   try
   {
   f();
   }
   catch ( int i )
   {
   wxLogWarning(_T("Caught an int %d in MyApp."), i);
   }
}
--- End code ---

EDIT2
@John, you are right. I have a mistake, because the original try catch block can not catch int type.

--- Code: ---bool MyFrame::ProcessEvent(wxEvent& event)
{
   try
   {
   return wxFrame::ProcessEvent(event);
   }
   catch ( const wxChar *msg )
   {
   wxLogMessage(_T("Caught a string \"%s\" in MyFrame"), msg);

   return true;
   }
}

--- End code ---
If I add one catch clause (catch ( int i )) here

--- Code: ---bool MyFrame::ProcessEvent(wxEvent& event)
{
   try
   {
   return wxFrame::ProcessEvent(event);
   }
   catch ( int i )
   {
   wxLogWarning(_T("Caught an int %d in MyFrame."), i);
   return true;
   }
   catch ( const wxChar *msg )
   {
   wxLogMessage(_T("Caught a string \"%s\" in MyFrame"), msg);

   return true;
   }
}
--- End code ---
then I can correctly catch this int type exception.

I see that the except sample code do have another level of try/catch block in the app level.

--- Code: ---bool MyApp::OnExceptionInMainLoop()
{
   try
   {
   throw;
   }
   catch ( int i )
   {
   wxLogWarning(_T("Caught an int %d in MyApp."), i);
   }
   catch ( MyException& e )
   {
   wxLogWarning(_T("Caught MyException(%s) in MyApp."), e.what());
   }
   catch ( ... )
   {
   throw;
   }

   return true;
}

--- End code ---
This try block is far up in the call stack train (cross the Windows call back function call), so exception(build with gcc-dw2) can not go there.

Sorry about the noise.

gd_on:
Hi,
finally, concerning the problem described in http://forums.codeblocks.org/index.php/topic,18383.msg125671.html#msg125671, I have found a workaround:
On my PC, this harddisk DR4 corresponds the letter H: and physically to a place where I can put some memory cards (from a camera, phone, ...). The one which makes problem is for a memory type that I don't have (MS/Pro Usb).
I simply desactivated the driver for this specific memory card and the problem disappeared ;). If necessary, I can reactivate it.

Concerning the other problem with gfortran and if it's possible to use preprocessing to be able to know if it has been compiled in 32bits ou 64bits, I tried the command you suggested :
gcc -dM -E - <nul
It works with gcc and gfortran 4.71 and 4.81, 32 bits or 64 bits version and gives exactly the same results.
So the #define are there. They are correctly interpreted and used by gcc (the same program already given but rewritten in C works!), but gfortran, even if i use the preprocessing -cpp option, does not seem to transmit them, so my #idfef WIN32 or _WIN32 or _WIN64 ... are ignored apparently!

Thanks for your work

gd_on

Edit:
It works if I add in gfortran compilation options -D_WIN32=1 for 32 bits and add -D_WIN64=1 for 64 bits compiling. But I thought this should be automatic as it is made in gcc.
More, if in the compiler option, #define Tab, I put _WIN32=1 for example, I obtain a compilation error : error unrecognized command line option '-fversion=_WIN32=1' . Is that normal ?

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version