2

I have a core file from a linux c++ program, and it crashed with a segmentation fault. Looking at the backtrace and code, I find one pointer/object that could be garbage. The pointer address is this=0x62900000f200, so is there a way I can determine if that could possibly be a valid address using GDB?

What I'm hoping for is a way to get GDB to tell me what allocated memory regions are, or what memory the core dump contains. I know accuracy will be low because its somewhat likely that a slightly mangled pointer could still point to "valid" memory, but hopefully there is a way to identify pointers that can't possibly be valid.

I have seen questions asking if a pointer "is valid" and I know the complexity of determining if a pointer as been free'd already, or if its point to the wrong object, etc, but that is not what I'm asking. I just want a test that would say, "This core contains all memory from address 0x01 to 0x50, and your pointer is 0x70, so its obviously not valid."

JPhi1618
  • 783
  • 1
  • 11
  • 21
  • 1
    Do you always have a full core dump? If so, there's an easy way. `x/b 0x62900000f200` or `p *(char *)0x62900000f200` will print the byte at that address iff it's a valid address and the data is present in the core dump, otherwise GDB will output the error message `Cannot access memory at address 0x62900000f200`. – Mark Plotnick Apr 20 '21 at 15:45
  • @MarkPlotnick, yes, we always have the full dump. I'll give that a shot. I didn't think about "manually" trying to access that memory. I still wonder if there is a "what memory does this dump contain" table or something. – JPhi1618 Apr 20 '21 at 15:47

1 Answers1

1

I found what seems to help in this answer. It suggests the command maint info sections to show all the loaded "sections" of the core file.

It produces a lot of output for a large core file, but in my case the output included this:

...
0x627000000000->0x627001030000 at 0x273c6000: load146 ALLOC LOAD HAS_CONTENTS
0x627001030000->0x627001030000 at 0x283f6000: load147 ALLOC READONLY
0x627e00000000->0x627e00010000 at 0x283f6000: load148 ALLOC LOAD HAS_CONTENTS
0x627e00010000->0x627e00010000 at 0x28406000: load149 ALLOC READONLY
0x628000000000->0x628000030000 at 0x28406000: load150 ALLOC LOAD HAS_CONTENTS
0x628000030000->0x628000030000 at 0x28436000: load151 ALLOC READONLY
0x628e00000000->0x628e00010000 at 0x28436000: load152 ALLOC LOAD HAS_CONTENTS
0x628e00010000->0x628e00010000 at 0x28446000: load153 ALLOC READONLY
0x629000000000->0x6290010b0000 at 0x28446000: load154 ALLOC LOAD HAS_CONTENTS
0x6290010b0000->0x6290010b0000 at 0x294f6000: load155 ALLOC READONLY
0x629e00000000->0x629e00010000 at 0x294f6000: load156 ALLOC LOAD HAS_CONTENTS
0x629e00010000->0x629e00010000 at 0x29506000: load157 ALLOC READONLY
0x62a000000000->0x62a0000c0000 at 0x29506000: load158 ALLOC LOAD HAS_CONTENTS
0x62a0000c0000->0x62a0000c0000 at 0x295c6000: load159 ALLOC READONLY
0x62ae00000000->0x62ae00010000 at 0x295c6000: load160 ALLOC LOAD HAS_CONTENTS
0x62ae00010000->0x62ae00010000 at 0x295d6000: load161 ALLOC READONLY
0x62b000000000->0x62b000070000 at 0x295d6000: load162 ALLOC LOAD HAS_CONTENTS
0x62b000070000->0x62b000070000 at 0x29646000: load163 ALLOC READONLY
0x62be00000000->0x62be00010000 at 0x29646000: load164 ALLOC LOAD HAS_CONTENTS
...

Since the region of 0x629000000000->0x6290010b0000 is present, and my pointer value falls between those, I can tell my pointer is valid. For a quicker search, you would need a script to check all the ranges, but the output does seem to be in numerical order (in my one case) so manually searching for the range was easy.

JPhi1618
  • 783
  • 1
  • 11
  • 21