0

I've not used C++ in ages, Maybe something changed. I have a large program I did not write but need to use and it seems to randomly segfault, So I re-build with "-g" option and run in gdb. (I'm using Ubuntu 20 in Intel 64-bit)

When the fault happens, I get gdb output that if I were smarter would tell be something. My question is "What are those 0x777777 and 0x555555 values?" They do not seem like random values. Where could they come from? It is obvious that these points point to memory outside my process.

Here is an example of this from "gdb's backtrace"

12 0x000055555579392a in main (argc=2, argv=0x7fffffffde38) at mainSystem.cpp:3676

Here is what I see at the breakpoint. When I see "0x7fffffff75b8" All the ffffff and 555555 seem hard to explain.

Program received signal SIGSEGV, Segmentation fault.
0x00005555556c01d1 in UnpackHeapval (
    linkval=0xffffffffffffffff <error: Cannot access memory at address 0xffffffffffffffff>, 
    val1=@0x7fffffff75b8: 18446744073709551615, val2=@0x7fffffff75c0: 18446744073709551615, 
    val3=@0x555555aa8218: 18446744073709551615) at os.cpp:706
706     val1 = data[1];
user3150208
  • 194
  • 5
  • It means that there's a bug in the code that results in memory corruption. These values are random garbage. – Sam Varshavchik Mar 02 '22 at 21:29
  • 1
    Some tools fill memory with recognizeable data to check if the program reads uninitialized memory or writes to memory out of bounds. `0x5555...` or `0x7777...` might be something like that. – mch Mar 02 '22 at 21:31
  • SIGSEGV implies Undefined Behavior. You are trying to make sense of this Undefined behavior, which may not provide meaningful results. Also, there is no `0x777777` in your output. If you mean `0x7fffffff`, take a look at [Why does Linux favor 0x7f mappings?](https://stackoverflow.com/questions/61561331/why-does-linux-favor-0x7f-mappings) – Drew Dormann Mar 02 '22 at 21:32
  • I do not recognize these numbers as [common debugger magic values](https://en.wikipedia.org/wiki/Magic_number_(programming)#Debug_values). If it's your tools trying to tell you something, I don't know what. – user4581301 Mar 02 '22 at 21:33
  • It looks to me like dereferencing a garbage pointer. – Joseph Larson Mar 02 '22 at 21:34
  • FWIW, `18446744073709551615` is `0xFFFFFFFFFFFFFFFF` – Vlad Feinstein Mar 02 '22 at 21:46
  • `0xffffffffffffffff` is a code I see every once and a while when debugging my Qt code in Visual Studio. For me it tends to be caused by freeing a object then iterating over a container in that object that was freed. Yes I know that is UB and there was a bug in my code.. – drescherjm Mar 02 '22 at 21:49

1 Answers1

1

What are those 0x777777

I don't see any of those in the quoted output.

and 0x555555 values?

A place where I see 555555 is in the middle of the second column of the stack trace. That column contains the return address of the function.

All the ffffff and 555555 seem hard to explain.

They are just values of parts of the addresses in question. It's unclear why you think they are harder to explain than for example 79392a.

It is obvious that these points point to memory outside my process.

I disagree, except for this case:

linkval=0xffffffffffffffff <error: Cannot access memory at address 0xffffffffffffffff>,

0xffffffffffffffff wasn't mapped for your process. It's in kernel-space of virtual memory. User space addresses use only the lower 48 bits in x86-64. And reading from that address is what triggered the segfault.

eerorika
  • 232,697
  • 12
  • 197
  • 326