Author Topic: Watching std::string in debugger causes segfault?!?  (Read 25477 times)

Offline ascholer

  • Single posting newcomer
  • *
  • Posts: 6
Watching std::string in debugger causes segfault?!?
« on: February 27, 2013, 05:04:54 am »
In a super simple file, I put a breakpoint at the cout line and then try to add a watch for s. Instant segmentation fault every time. Tried on multiple machines with multiple fresh downloads of codeblocks 12.11 + mingw package.

Here is test file:
Code: [Select]
#include <iostream>
#include <string>

using namespace std;

int main()
{
    string s = "asdfasdf";

    cout << "Ouch!" << endl;
    return 0;
}


Here is debugger log:
Code: [Select]
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: C:\Users\Andrew\Desktop\asdfewrwe\
Adding source dir: C:\Users\Andrew\Desktop\asdfewrwe\
Adding file: C:\Users\Andrew\Desktop\asdfewrwe\asdfewrwe.exe
Changing directory to: C:/Users/Andrew/Desktop/asdfewrwe/.
Set variable: PATH=.;C:\Users\Andrew\Desktop\CodeBlocks\MinGW\bin;C:\Users\Andrew\Desktop\CodeBlocks\MinGW;C:\Program Files (x86)\Google\Chrome\Application;C:\CodeBlocks\MinGW\bin;C:\MinGW\msys\1.0\bin;C:\Program Files (x86)\AMD APP\bin\x86_64;C:\Program Files (x86)\AMD APP\bin\x86;C:\MinGW\bin;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Java\jdk1.7.0_07\bin;C:\Program Files (x86)\Haskell\bin;C:\Program Files (x86)\Haskell Platform\2011.4.0.0\lib\extralibs\bin;C:\Program Files (x86)\Haskell Platform\2011.4.0.0\bin;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static;c:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn;c:\Program Files\Microsoft SQL Server\100\Tools\Binn;c:\Program Files\Microsoft SQL Server\100\DTS\Binn;C:\Program Files\TIEDUC~1\TI-83P~1\UTILS;c:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE;c:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn;C:\Program Files\Perforce;C:\Program Files (x86)\Cppcheck;C:\Program Files\doxygen\bin;C:\Program Files (x86)\Google\Google Apps Sync;C:\Program Files (x86)\Google\Google Apps Migration;C:\Program Files\TortoiseHg;C:\Program Files (x86)\Subversion\bin;C:\apache-ant-1.8.4\bin;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files (x86)\QuickTime\QTSystem;C:\Program Files (x86)\AtomicParsley-win32-0.9.0;C:\Program Files (x86)\CodeSourcery\Sourcery_CodeBench_Lite_for_MIPS_ELF\bin;C:\Ruby193\bin;C:\Users\Andrew\AppData\Roaming\cabal\bin

[debug]Command-line: C:\Users\Andrew\Desktop\CodeBlocks\MINGW\bin\gdb.exe -nx -fullname  -quiet  -args C:/Users/Andrew/Desktop/asdfewrwe/asdfewrwe.exe
[debug]Working dir : C:\Users\Andrew\Desktop\asdfewrwe

Starting debugger: C:\Users\Andrew\Desktop\CodeBlocks\MINGW\bin\gdb.exe -nx -fullname  -quiet  -args C:/Users/Andrew/Desktop/asdfewrwe/asdfewrwe.exe
done

[debug]> set prompt >>>>>>cb_gdb:

Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints

[debug]Reading symbols from C:\Users\Andrew\Desktop\asdfewrwe\asdfewrwe.exe...done.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.5
[debug]Copyright (C) 2012 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "i686-pc-mingw32".
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]>>>>>>cb_gdb:
[debug]> set confirm off

Debugger name and version: GNU gdb (GDB) 7.5

[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set new-console on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> source C:\Users\Andrew\Desktop\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory C:/Users/Andrew/Desktop/asdfewrwe/
[debug]Source directories searched: C:/Users/Andrew/Desktop/asdfewrwe;$cdir;$cwd
[debug]>>>>>>cb_gdb:
[debug]> break "C:/Users/Andrew/Desktop/asdfewrwe/main.cpp:10"
[debug]Breakpoint 1 at 0x4013af: file C:\Users\Andrew\Desktop\asdfewrwe\main.cpp, line 10.
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]Starting program: C:\Users\Andrew\Desktop\asdfewrwe\asdfewrwe.exe

Child process PID: 9860

[debug][New Thread 9860.0x17c4]
[debug]Breakpoint 1, main () at C:\Users\Andrew\Desktop\asdfewrwe\main.cpp:10
[debug]C:\Users\Andrew\Desktop\asdfewrwe\main.cpp:10:111:beg:0x4013af
[debug]>>>>>>cb_gdb:

At C:\Users\Andrew\Desktop\asdfewrwe\main.cpp:10

[debug]> whatis s
[debug]type = std::string
[debug]>>>>>>cb_gdb:
[debug]> output s.c_str()[0]@s.size()
[debug]The program being debugged was signaled while in a function called from GDB.
[debug]GDB has restored the context to what it was before the call.
[debug]To change this behavior use "set unwindonsignal off".
[debug]Evaluation of the expression containing the function
[debug](std::string::size() const) will be abandoned.
[debug]Program received signal SIGSEGV, Segmentation fault.
[debug]0x004228ba in std::string::size() const ()
[debug]>>>>>>cb_gdb:

Program received signal SIGSEGV, Segmentation fault.
In std::string::size() const () ()

[debug]> whatis s
[debug]type = std::string
[debug]>>>>>>cb_gdb:
[debug]> output s.c_str()[0]@s.size()
[debug]The program being debugged was signaled while in a function called from GDB.
[debug]GDB has restored the context to what it was before the call.
[debug]To change this behavior use "set unwindonsignal off".
[debug]Evaluation of the expression containing the function
[debug](std::string::size() const) will be abandoned.
[debug]Program received signal SIGSEGV, Segmentation fault.
[debug]0x004228ba in std::string::size() const ()
[debug]>>>>>>cb_gdb:
[debug]> bt 30

Program received signal SIGSEGV, Segmentation fault.

[debug]> bt 30
[debug]#0  main () at C:\Users\Andrew\Desktop\asdfewrwe\main.cpp:10
[debug]>>>>>>cb_gdb:#0  main () at C:\Users\Andrew\Desktop\asdfewrwe\main.cpp:10
[debug]>>>>>>cb_gdb:

I know I used to be able to watch strings, not sure what is going on. Anyone else noticed this issue? Can anyone replicate it? Any GDB guru's see anything weird in the log? Basically, should I submit a bug or is this user error?

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5251
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Watching std::string in debugger causes segfault?!?
« Reply #1 on: February 27, 2013, 08:28:20 am »
I don't have this issue (GCC 4.6.3, GDB CVS with python enabled).
But I remember this post Why gdb fails to print std::string is definitely related to your issue, this is because the newer gcc 4.7.x (I guess C::B release 12.11 contains a 4.7.x gcc) can optimize the std::string, so the size() function is optimized out. You can see how GDB developer said in that post.

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ascholer

  • Single posting newcomer
  • *
  • Posts: 6
Re: Watching std::string in debugger causes segfault?!?
« Reply #2 on: February 27, 2013, 10:53:27 pm »
Ahh - thanks for the tip, led me to figure out that unchecking "Enable watch scripts" in the Debugger Settings prevents it from blowing up.

Any idea if there is a way to disable that optimization - any flags I've tried have not seemed to help. Would like to keep using the scripts.




Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5251
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Watching std::string in debugger causes segfault?!?
« Reply #3 on: March 01, 2013, 08:06:10 am »
Any idea if there is a way to disable that optimization - any flags I've tried have not seemed to help. Would like to keep using the scripts.
No such GCC option as I can see.
If you stick on using the C::B built-in scripts, you should at least explicitly use some functions of std::string, so that those functions will not be optimized out.
Looks like:
Code: [Select]
#include <iostream>
#include <string>

using namespace std;

int main()
{
    string s = "asdfasdf";

    // add those dummy function calls below, so that gcc 4.7.x does not remove them in final executable files.
   // as they will be used in C::B debugger scripts.
    s.c_str();
    s.size();

    cout << "Ouch!" << endl;
    return 0;
}

I do not tested yet, but please note that all the member functions involved in "s.c_str()[0]@s.size()" should be explicitly called in your source code.

« Last Edit: March 25, 2013, 03:33:31 pm by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ascholer

  • Single posting newcomer
  • *
  • Posts: 6
Re: Watching std::string in debugger causes segfault?!?
« Reply #4 on: March 03, 2013, 12:49:53 am »
Thanks - that's what I was afraid of.

Use Codeblocks as the preferred platform for a programming class. Would like to have a solution that works "out of the box" so new students don't have to remember to put random extra code in just to avoid problems debugging.

May just have to downgrade GCC version I provide.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9529
Re: Watching std::string in debugger causes segfault?!?
« Reply #5 on: March 03, 2013, 06:23:08 am »
May just have to downgrade GCC version I provide.
Or look what GCC switch turn off such optimisations.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: Watching std::string in debugger causes segfault?!?
« Reply #6 on: March 03, 2013, 12:49:25 pm »
The funny thing is, that it does not crash (with watch scripts) on fedora 64-bit with gcc 4.7.2.
I don't know if it is gcc 4.7.2 or fedora/linux specific.

And on windows it also works fine with ollydbg's gdb with pretty printer enabled and TDM's gcc 4.7.1 shipped with C::B 12.11.

Offline Folco

  • Regular
  • ***
  • Posts: 343
    • Folco's blog (68k lover)
Re: Watching std::string in debugger causes segfault?!?
« Reply #7 on: March 03, 2013, 08:17:59 pm »
I use gcc 4.7.2 too, from Linux Mint (from Ubuntu). It seems to work, if I did correctly the test case :

Kernel Extremist - PedroM power

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5251
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Watching std::string in debugger causes segfault?!?
« Reply #8 on: March 04, 2013, 04:06:08 pm »
And on windows it also works fine with ollydbg's gdb with pretty printer enabled and TDM's gcc 4.7.1 shipped with C::B 12.11.
Well, I have different result. Today, I tried with my GDB and tdm's gcc 4.7.1sjlj. But I receive the segfault like:
Code: [Select]
Selecting target:
Debug
Adding source dir: E:\code\cb\test_code\mortenr2012-01-15\
Adding source dir: E:\code\cb\test_code\mortenr2012-01-15\
Adding file: E:\code\cb\test_code\mortenr2012-01-15\bin\Debug\mortenr2012-01-15.exe
Changing directory to: E:/code/cb/test_code/mortenr2012-01-15/.
Set variable: PATH=.;E:\code\gcc\tdm471sjlj\bin;E:\code\gcc\tdm471sjlj;E:\code\gcc\PCXMinGW463\bin;E:\code\gcc\PCXMinGW463;E:\code\common_bin;D:\Program Files\TortoiseSVN\bin;C:\Program Files\SlikSvn\bin;E:\code\opencv\2.4.3\mingw\bin

[debug]Command-line: E:\code\gcc\PCXMinGW463\bin\gdb.exe -nx -fullname  -quiet  -args E:/code/cb/test_code/mortenr2012-01-15/bin/Debug/mortenr2012-01-15.exe
[debug]Working dir : E:\code\cb\test_code\mortenr2012-01-15

Starting debugger: E:\code\gcc\PCXMinGW463\bin\gdb.exe -nx -fullname  -quiet  -args E:/code/cb/test_code/mortenr2012-01-15/bin/Debug/mortenr2012-01-15.exe
done

[debug]> set prompt >>>>>>cb_gdb:

Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints

[debug]Reading symbols from E:\code\cb\test_code\mortenr2012-01-15\bin\Debug\mortenr2012-01-15.exe...
[debug]done.
[debug](gdb)
[debug]>>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.5.50.20130204-cvs
[debug]Copyright (C) 2013 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "mingw32".
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]>>>>>>cb_gdb:
[debug]> set confirm off

Debugger name and version: GNU gdb (GDB) 7.5.50.20130204-cvs

[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set new-console on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source E:\code\cb\CodeBlocksUnofficial\share\codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> source E:\code\gcc\PCXMinGW463\bin\my.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory E:/code/cb/test_code/mortenr2012-01-15/
[debug]Source directories searched: E:/code/cb/test_code/mortenr2012-01-15;$cdir;$cwd
[debug]>>>>>>cb_gdb:
[debug]> break "E:/code/cb/test_code/mortenr2012-01-15/main.cpp:10"
[debug]Breakpoint 2 at 0x4013af: file E:\code\cb\test_code\mortenr2012-01-15\main.cpp, line 10.
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]Starting program: E:\code\cb\test_code\mortenr2012-01-15\bin\Debug\mortenr2012-01-15.exe

Child process PID: 1964

[debug][New Thread 1964.0x94c]
[debug]Breakpoint 2, main () at E:\code\cb\test_code\mortenr2012-01-15\main.cpp:10
[debug]E:\code\cb\test_code\mortenr2012-01-15\main.cpp:10:111:beg:0x4013af
[debug]>>>>>>cb_gdb:

At E:\code\cb\test_code\mortenr2012-01-15\main.cpp:10

[debug]> whatis s
[debug]type = std::string
[debug]>>>>>>cb_gdb:
[debug]> output s.c_str()[0]@s.size()
[debug]The program being debugged was signaled while in a function called from GDB.
[debug]GDB has restored the context to what it was before the call.
[debug]To change this behavior use "set unwindonsignal off".
[debug]Evaluation of the expression containing the function
[debug](std::string::size() const) will be abandoned.
[debug]Program received signal SIGSEGV, Segmentation fault.
[debug]0x004228da in std::string::size() const ()
[debug]>>>>>>cb_gdb:
[debug]> bt 30

Program received signal SIGSEGV, Segmentation fault.
In std::string::size() const () ()

[debug]> bt 30
[debug]#0  main () at E:\code\cb\test_code\mortenr2012-01-15\main.cpp:10
[debug]>>>>>>cb_gdb:#0  main () at E:\code\cb\test_code\mortenr2012-01-15\main.cpp:10
[debug]> whatis s
[debug]>>>>>>cb_gdb:
[debug]> output s
[debug]type = std::string
[debug]>>>>>>cb_gdb:
[debug]> bt 30
[debug]"asdfasdf">>>>>>cb_gdb:#0  main () at E:\code\cb\test_code\mortenr2012-01-15\main.cpp:10
[debug]>>>>>>cb_gdb:
.
I try another newer build on GDB CVS 2013-03-02, but same segfault.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: Watching std::string in debugger causes segfault?!?
« Reply #9 on: March 04, 2013, 05:53:03 pm »
And on windows it also works fine with ollydbg's gdb with pretty printer enabled and TDM's gcc 4.7.1 shipped with C::B 12.11.

What I meant, was that I have used the pretty printer (watch-scripts disabled).
With the watch-scripts I get the segfault also.

With gdb from TDM and watch-scripts disabled I don't get the segfault, and the value is visible, but hidden in the deep of the string-structure.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5251
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Watching std::string in debugger causes segfault?!?
« Reply #10 on: March 05, 2013, 12:41:59 am »
And on windows it also works fine with ollydbg's gdb with pretty printer enabled and TDM's gcc 4.7.1 shipped with C::B 12.11.

What I meant, was that I have used the pretty printer (watch-scripts disabled).
With the watch-scripts I get the segfault also.

With gdb from TDM and watch-scripts disabled I don't get the segfault, and the value is visible, but hidden in the deep of the string-structure.
Oh, sorry, I was wrong. Your testing result is the same as mine.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ascholer

  • Single posting newcomer
  • *
  • Posts: 6
Re: Watching std::string in debugger causes segfault?!?
« Reply #11 on: March 07, 2013, 10:08:53 pm »
Agree - with python pretty printer and disabled watch scripts, everything is fine.

But my goal is to provide students a self-contained, reasonable size .zip that they can unpack and run. Don't really want to try to shoehorn Python into that (haven't researched to see how big a package would be needed, but guessing it won't be trivial sized). Hence the desire to stick with the old school watch scripts - also since we are talking about a package targeted at relatively inexperienced students, why I don't want to say "just add a random call to foo.c_str() if you need to debug it".

Spent a while trying every lead I could find to disable the optimizations in gcc 4.7.1 and nothing seemed to work. If anyone knows the magic words to disable, please let me know.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5251
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Watching std::string in debugger causes segfault?!?
« Reply #12 on: March 13, 2013, 01:21:03 am »
@ascholer
For python enabled GDB, I think you can just put the python installed files in the <YourMinGWGCC>/bin folder, then distribute them. This is a portable way that you don't need to install python in the target PCs.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ascholer

  • Single posting newcomer
  • *
  • Posts: 6
Re: Watching std::string in debugger causes segfault?!?
« Reply #13 on: March 13, 2013, 04:48:30 pm »
@ollydbg Thanks for the tip - I'll experiment with that.

Hacked up a version of the gdb_types.script file that doesn't set up any function calls in Evaluate_StlString but instead does work in Parse_StlString to strip things down to the "string" part of the std:string.

But I'll explore a portable pretty print solution, if for no other reason than it looks like you are the main "debugger dev" and you are focused on that.


Offline elimcodmartinez

  • Single posting newcomer
  • *
  • Posts: 4
Re: Watching std::string in debugger causes segfault?!?
« Reply #14 on: February 06, 2014, 10:10:01 am »
I'm afraid it still (nearly) happens for long strings. Seen in 13.12 for Windows using Cygwin 32bits debugger.
Sometimes it regains control but may stay unresponsive for several seconds.