2

I have a class named Sample which contains a parameter value which is of type std::string. There is a public member function setValue(std::string tempdata) which is used to set the value of this member.

void Sample::setValue( std::string tempdata ) { this->value= tempdata; }

From the application I have to set the value of this parameter. I do something like:

std::string tempvalue = "Hello";
Sample s;
s.setValue( tempvalue );

when I run the application the program crashes and on debugging it through gdb I get:

#0  0x049da761 in __gnu_cxx::__exchange_and_add () from /usr/lib/libstdc++.so.6
#1  0x049c0e6e in std::string::assign () from /usr/lib/libstdc++.so.6
#2  0x049c0ed1 in std::string::operator= () from /usr/lib/libstdc++.so.6
#3  0x08075e9b in Sample::setValue (this=0x83779a8, tempdata=Cannot access memory at address 0xffffffff )

Can anyone please suggest how should I go about debugging this issue?

R. Martinho Fernandes
  • 228,013
  • 71
  • 433
  • 510
Amit
  • 21
  • 1
  • 2
  • 1
    the code looks ok. Did you modify the header file without recompiling the files which include it ? (e.g. do a `make clean` and then `make` if you're working with a Makefile and these targets are defined in it) – Andre Holzner Sep 17 '11 at 15:44
  • 1
    This looks like an internal problem of gcc, see http://stackoverflow.com/questions/7038124/weird-sigsegv-segmentation-fault-in-stdstringassign-method-from-libstdc . – Yaroslav Nikitenko May 13 '12 at 18:09

1 Answers1

2

The code you've shown is correct. So the error is somehere else. It could, for example be stack or heap corruption at some earlier point, which just isn't noticed until these lines of code are executed.

jalf
  • 243,077
  • 51
  • 345
  • 550
  • 2
    Of note is that `tempdata` is `0xffffffff` in the stack trace. That is very...unusual, at least for the code pasted above. – C. K. Young Sep 17 '11 at 16:47
  • This code is a part of a bigger application which I am trying to run. It is just that the code crashes at this point when I try to assign a value to class member. I agree this might be a heap or stack corruption but how to look for it in such a large application and does 0xffffffff indicate something significant? - Amit – Amit Sep 17 '11 at 18:26
  • 1
    Well, it indicates that someone wrote the value `0xffffffff` to this part of memory at some point. ;) I think @Chris's point is that it's not a commonly-seen value. You more commonly see pointers values that were *once* valid (pointing to a block of memory that has since been freed), or in debug builds, you might see special values like `0xcdcdcdcd` or `0xdeadbeef` or other recognizable patterns for uninitialized or freed memory. `0xffffffff` is only significant in that it is not the a pointer to either data or code. So someone wrote some non-pointer data over your `tempdata` pointer. – jalf Sep 17 '11 at 18:29
  • You could try setting a data breakpoint on the pointer so the debugger will break when the contents of that address are changed. – jalf Sep 17 '11 at 18:30
  • I had no idea we could set breakpoints on memory addresses. I will try this out. – Amit Sep 17 '11 at 18:56
  • @Amit: It depends on your debugger, of course, but the VS debugger and GDB can do it, at least – jalf Sep 17 '11 at 19:28