Segmentation fault during debugging when wxFileName close to breakpoint

[eranon]

Hello,

I'm experiencing a weird behavior during debugging. When I put a breakpoint in a block of code containing a wxFileName, I receive any kind of segmentation fault (ie. SEGFAULT, SIGSEGV, SIGFPE, etc). The fault can happen when the debugger reach the breakpoint or just after running step by step.

Also, I observed unrelated side effects, like a wxString in the same block which is magically emptied... Well, I don't see the relationship.

Apparently the things I see in the debug log has no more sense (knowing this one is just a sample from a test project and another block of code could give a totally different result - for example, in my real project I receive a SIGSEGV) :

Code

Setting breakpoints
Debugger name and version: GNU gdb (GDB) 7.2.50.20101213
Child process PID: 808
At D:\eranon\dev\sandbox\test22\TestMain.cpp:1795
Program received signal SIGFPE, Arithmetic exception.
At C:\devlibs\wxWidgets-3.0.0\build\msw/../../src/richtext/richtextliststylepage.cpp:288
Program received signal SIGTRAP, Trace/breakpoint trap.
In KERNELBASE!DeleteAce () (C:\Windows\syswow64\KernelBase.dll)
Program received signal SIGTRAP, Trace/breakpoint trap.

A simple code like this (here the minimal command handler giving the debug log above) generates the SEGFAULT. And if I comment the wxFileName line, all is OK !

Code

void TestFrame::OnButton51Click(wxCommandEvent& event)
{
    wxString strFile = "C:/base/test.dat";    // I put the breakpoint on this line
    wxFileName fn(strFile);
}

Also, I'm under CodeBlocks SVN r.9609 with MinGW64 (aka. TDM64-GCC 4.7.1), using gdb 7.2 coming from MinGW32 (aka. TDM32-GCC) to be right with my 32-bit project build. Also, CodeBlocks is configured with pretty printer Python script against gdb. All of this under Windows 7 64-bit.

So, I posted here, but I really don't know if it comes from C::B, gdb or wxWidgets (recently updated to 3.0.0). So, I'll cross-post in the wxWidgets forum too...

Do you have an idea ? Is it a known issue ?

--
EDIT : related thread in wxWidgets forum is here : http://forums.wxwidgets.org/viewtopic.php?f=19&t=39050

[oBFusCATed]

Try running in a command line gdb and if it crashes, then it is not C::B's fault.
If it doesn't. Enable full long and execute the same commands printed in the debuggers log in the command line instance of gdb.
If it doesn't crash again then its C::B's fault.

[eranon]

Well, thanks for the guideline, Obfuscated.

I just tried with gdb (ie. C:\MinGW32\bin>gdb since I've another one under the MinGW64 directory), but I fall in another issue : indicating a breakpoint as

Code

b TestMain.cpp:1795

or

Code

b TestFrame::OnButton51Click

(which match the same code line), then running until this point, I get an error message saying

Code

Line number 1795 out of range [...] TestMain.cpp has 1789 lines

that being wrong since TestMain.cpp has 1797 lines.

Thinking about the things I did recently, I can list :
- some Windows Update
- update from wxWidgets 3.0.0 RC2 to Finale release
- update of my C::B SVN working copy
- and continuation of the OSX porting of my project (which was in stand by since some month).

So, just an idea : thinking about the last point and this wrong gdb lines count, do you think it could be simply something because of different files encoding between Windows and OS X ? Or no homogeneous end of lines ?

Well, I'll see tommorow.

[oBFusCATed]

I guess you're source and binaries are out of sync. Recompile everything and should fix itself magically. (probably)

[eranon]

Unfortunately not I rebuilded in full and same result. I doublechecked erasing the obj and exe on disk by hand before to rebuild and same result.

But searching, it sounds that this kind of gdb issue already happened to some. For example, this : http://stackoverflow.com/questions/8200419/stepping-into-template-classes-with-gdb (even if not completely my case since gdb doesn't reports 1 line only).

Is it possible that C::B be troubled by this error (out of range about line number of breakpoint) at a level it does anything ?

I updated my C::B SVN to HEAD and same code give a different debug output. This time (with the same two lines of code expressed in my previous post), I get a SIGSEGV :

Code

Setting breakpoints
Debugger name and version: GNU gdb (GDB) 7.2.50.20101213
Child process PID: 6404
At D:\eranon\dev\sandbox\test22\TestMain.cpp:1795
Program received signal SIGSEGV, Segmentation fault.
In ?? () ()
Program received signal SIGTRAP, Trace/breakpoint trap.
In KERNELBASE!DeleteAce () (C:\Windows\syswow64\KernelBase.dll)
Program received signal SIGTRAP, Trace/breakpoint trap.

--
EDIT : just downloaded the last gdb release (7.6.1 for Windows) and from command line it doesn't seem to fall in the issue (ie. breakpoint is honored and stepping proceeded w/o SEGFAULT)... Prematured to say it's solved, but a good news. I'll tell you after integration in C::B with the Python script, then attempt with my own real project's code.

[eranon]

SOLVED. It was what I express above in my EDIT : updating gdb from 7.2 to 7.6 solved the issue. Now, it's OK both from command line and from C::B.

[oBFusCATed]

Good to know 

[eranon]

Yep, good it was... Until I fall in other weird situations with gdb 7.6... But, since I had no time to digg (and more from the point these issues with gdb 7.6 sounded more difficult to track than the clear one with 7.2), I prefered to go back to gdb 7.2 (the one shipped with the TDM-GCC package)... And I finally found the reason why of this "line number out of range". Here is the story :

To avoid to break something in my regular dev station, I'm used to do my tests in a virtual machine (VirtualBox or VMware, depending of the OS). So, this time, I copied my test project and the mingw32 + python tree towards a Win7 x64 machine. Then, I renewed my typical gdb session, trying to set and reach the same breakpoint I talked about in my previous post (above)... And got the same result : "out of range". So, perfect (since it meant it was disconnected to my current system and the issue was really between my test project and gdb only) : Then, knowing I had neither CodeBlocks nor Notepad++ in this virtual machine, I started to take a look at my source files in the standard Notepad... And, yes ! Just seen the problem like an obviousness : the incriminated file (TestMain.cpp) shown mixed EOL (sometimes CRLF and sometimes CR) and, more weird, some lines were not ended at all (e.g. some functions started on the same line as the closing "}" of the previous function) - really don't know why since it doesn't appeared like this neither under CodeBlocks nor under Notepad++. Then, I simply checked my Codeblocks's editor settings about EOL under both MSW and OSX to do it forces CRLF everywhere (since I'm more often under Windows rather than under OS X), then I re-saved all my projects file before to re-build in full... And now, the breakpoint is well taken by gdb 7.2 as shown below :

Code

C:\>C:\MinGW32\bin\gdb.exe F:/dev/misc/bin/GCCX86~2/Test.exe
GNU gdb (GDB) 7.2.50.20101213
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from F:/dev/misc/bin/GCCX86~2/Test.exe...done.
(gdb) b TestFrame::OnButton51Click
Breakpoint 1 at 0x4188f5: file F:\dev\misc\TestMain.cpp, line 1778.
(gdb) r
Starting program: F:/dev/misc/bin/GCCX86~2/Test.exe
[New Thread 5004.0x2304]
[New Thread 5004.0x26e0]
[New Thread 5004.0x2200]
[New Thread 5004.0x2580]
[New Thread 5004.0x1204]

Breakpoint 1, TestFrame::OnButton51Click (this=0x5fab4c0, event=...)
    at F:\dev\misc\TestMain.cpp:1778
1778        wxString path("c:/test.png");
(gdb) n
1779        wxFileName fn(path);
(gdb) n
1780    }
(gdb) q
A debugging session is active.

        Inferior 1 [process 5004] will be killed.

Quit anyway? (y or n) y

error return ../../gdb-7.2.50.20101213/gdb/windows-nat.c:1243 was 5

C:\>

Thus, now, I think it's really SOLVED and not worked around only

--
PS : not time to re-read but hoping (ven with eventual typo) it will help someone a day... Ensure EOL consistency when you go cross-platform ^^