User forums > Help

Segmentation fault during debugging when wxFileName close to breakpoint

<< < (2/2)

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  :D

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

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

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

Navigation

[0] Message Index

[*] Previous page