Question

Suppose I have these functions

void foo(int a, int b, int c);
void bar(int d);
void start();

And I get a core dump which looks something like this

foo(<value of a>, <value of b>, <value of c>, <three garbage values>)
bar(<value of d>, <five garbage values>)
start(<six garbage values>)
.... [other functions]

So start called bar, which called foo and we crashed in foo. Question is, are those values in the stack trace the values of the %o1, .., %o5 registers at the time each function was called, or are they the values of the %i0, .., %i5 registers at the time of the crash (meaning if the function changed one of these input registers, the value in the stack trace would be different)?

The reason I ask is because I thought it was the values of the out registers, but a customer recently upgraded their hardware and has a core dump where one of the arguments in the stack trace looks faulty. The disassembly for the caller looks correct, even the registers which were used to set that specific argument, and I've checked for the usual type mismatch, signed/unsigned, etc.

Was it helpful?

Solution

Stack traces usually show dumps of stack frames for every call (pardon the tautology). Function parameters are followed by return address, pointer to the previous stack frame etc. Those are your garbage values. For exact details on stack layout you may google something like "AIX call conventions". When core dump is generated it is impossible to tell what the values on stack were at the time when function was called. You see the values at the time of crash. So if function assigns a new value to formal parameter or parameters were overwritten due to a bug (like overflowing on-stack buffer) values will be different from the ones at the time of the call.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top