stack parameters read from wrong memory address in the stack

I am trying to debug a process core dump on ARM architecture.

It is a telecom stack software written in C. The process is single-threaded.

Some debugging through gdb indicated that the stack parameters (local variables or function arguments) are being read from a memory location that is at a fixed offset (8 bytes) from the correct location.

Here is some debugging information:

(gdb) p localParam_p
$16 = (UInt8 *) 0xbe <Address 0xbe out of bounds>

(gdb) x /16wx &localParam_p
0x7ea5c774:     0x000000be      0x00000010      0x94dc788c     0x00000000

The correct (expected) value is 0x94dc788c which is stored at a memory location 0x7ea5c77c (third word in the output above)

Here is another example:

(gdb) p localParam2
$18 = 0

(gdb) x /16wx &localParam2
0x7ea5c770:     0x00000000      0x000000be      0x00000010     0x94dc788c

Expected value for addrLen is 0x10 (third word above).

I can see the same issue with other local variables across stack frames.

Kindly help!

Valgrind can not be used on this system.

The process has only crashed once in a duration of several days and the reproduction steps are as yet unknown.

My reaction to this sort of thing is to suspect a compiler debuginfo bug. It could also be a gdb bug. If I had this problem, here is what I would do:

First, make sure I had a recent version of gdb; upgrading to the latest release if not.

If that didn't work, enable DWARF location disassembly:

maint set dwarf2 always-disassemble on

Then ask for the location of the variable in question:

info addr localParm2

This will dump a DWARF expression showing where gdb thinks the variable is located. DWARF expressions use a simple stack machine language, you will have to dig into the DWARF standard and perhaps some GCC extension documentation (on the GCC wiki) to understand this.

If you are not using DWARF -- well, you should these days, and that's a good spot to start.

This is the spot where I would expect to find the bug. And, if so, the only answer is that you need to fix the compiler, either by upgrading or by debugging the problem there.

It's also possible that the compiler output is correct and that you've found a gdb bug. I think this is less likely, though, since the location expression code in gdb has been fairly well exercised.

It's also worth double-checking that the debuginfo matches the program you are debugging. And, it may worth looking to see if the compiler you're using has any known bugs in this area.