User forums > Help

Segmentation fault during debugging when wxFileName close to breakpoint

(1/2) > >>

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.

--- End code ---

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);
}

--- End code ---

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
--- End code ---

or


--- Code: ---b TestFrame::OnButton51Click
--- End code ---

(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
--- End code ---

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.
--- End code ---

--
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.

Navigation

[0] Message Index

[#] Next page