Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Debugger (gdb) crash: Reproducable?

(1/2) > >>

MortenMacFly:
Dear all,
I've had crashes of the debugger in recent times which I think I narrowed down to a reproducable example:
- Create a console application
- Compile the following code:

--- Code: ---#include <iostream>
#include <string>

std::string Manipulate(const std::string &str)
{
  std::string new_str(str);
  unsigned int loc;

  loc = new_str.find("World");
  if (loc != std::string::npos)
    new_str.insert(loc, "to the whole ");

  return new_str;
}

int main()
{
  std::string s = "Hello World";
  std::cout << Manipulate(s) << std::endl;
  return 0;
}

--- End code ---
- Place a breakpoint at the return new_str;
- Run the debugger - it will break at that line
- Place the cursor over the new_str variable in this line (having the debugger's option enabled to "Evaluate expressions under the cursor")
-> GDB crashes! (not C::B, only GDB!)
The debugger's debug log is as following:

--- Code: ---Command-line: D:\Devel\GCC345\bin\gdb.exe -nx -fullname  -quiet -args Debug/huhu.exe
Working dir : C:\Dokumente und Einstellungen\Morten\Desktop\huhu\
> set prompt >>>>>>cb_gdb:
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
>>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set new-console on
>>>>>>cb_gdb:
> set disassembly-flavor intel
>>>>>>cb_gdb:
> directory C:/DOKUME~1/Morten/Desktop/huhu/
>>>>>>cb_gdb:
> delete breakpoints
>>>>>>cb_gdb:
> break C:/DOKUME~1/Morten/Desktop/huhu/main.cpp:13
Breakpoint 1 at 0x401471: file main.cpp, line 13.
>>>>>>cb_gdb:
> run
Breakpoint 1, Manipulate (str=@0x22ff50) at main.cpp:13
C:/DOKUME~1/Morten/Desktop/huhu/main.cpp:13:243:beg:0x401471
>>>>>>cb_gdb:
> info locals
new_str = (string *) 0x22ff40
loc = 6
>>>>>>cb_gdb:
> info args
str = (const string &) @0x22ff50: {static npos = 4294967295, _M_dataplus = {<allocator<char>> = {<new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x3e3c94 "Hello World"}}
>>>>>>cb_gdb:
> whatis new_str
type = string *
>>>>>>cb_gdb:
> output new_str.c_str()[0]@new_str.size()

--- End code ---
Now I wonder if I'm the only one that experiences these crashes. It would be nice if soneone could confirm this issue. Unfortunately I've no clue how I should start tracking down this bastard - any hints in that direction are welcome, too...?!

With regards, Morten.

Edit: I forgot: C::B Version 1.0 revision 2514 ()   gcc 3.4.5 Windows/unicode

MortenMacFly:
...I've gotten one step further:
The issue is wwith the debugger's command output new_str.c_str()[0]@new_str.size().
Since new_str is a string pointer (notice the output whatis new_str) of it should be: output new_str->c_str()[0]@new_str->size() (notice the pointer).
It seems the script for how C::B handles std::string does not cover this case... right?
With regards, Morten.

mandrav:

--- Quote from: MortenMacFly on June 01, 2006, 08:59:46 am ---...I've gotten one step further:
The issue is wwith the debugger's command output new_str.c_str()[0]@new_str.size().

--- End quote ---

It's not it. GDB is smart enough to work it out no matter if you use . or -> (try it out, it still crashes).

Well, something 's wrong with gdb here. You 're right, if you use -> it works fine. But the point is that gdb sees new_str as "string *" where in fact it's a "string"  :shock:

mandrav:
I 've updated the script that does the evaluation to look for * in the type name, although this solution is far from perfect...

MortenMacFly:

--- Quote from: mandrav on June 01, 2006, 10:00:42 am ---But the point is that gdb sees new_str as "string *" where in fact it's a "string"  :shock:

--- End quote ---
I'ts nice you say that because I acually thought the same but was afraid to mention my thoughts in presence of C++ guru's (for the case I'm wrong... :oops: ;-))...
Anyway, I've updated to SVN and can confirm it no more crashes! :P I'll post a bug report (or a request for clarification) to the GDB mailing list in a minute...
With best regards, Morten.

Navigation

[0] Message Index

[#] Next page