Weird crash details.

Hi. Yesterday afternoon I experienced something very weird. A running
process would crash. ‘traceinfo’ gave me the crash address, so I
examined the map file to determine the function. I then disassembled
the object file and attempted to find the instruction that caused the
problem. I’ve done this many times, and it has always worked…until
now. The address I was given didn’t correspond to an instruction in the
disassembled file; instead, it pointed at the last byte of a move
instruction.

To illustrate, here is a snippet of the disassembled code:

02b9 8b 45 f4 mov eax,-0cH[ebp]
02bc c7 40 08 00 00 00
00 mov dword ptr
+8H[eax],00000000H
02c3 8b 45 f4 L8 mov eax,-0cH[ebp]
02c6 ff 40 08 inc dword ptr +8H[eax]

The address I was given corresponded to 02c2, and I had another person
verify this (just in case it was a math error). My question is, huh?
Under what conditions could this occur? Any insight at all, or any
method of attack, would be appreciated.

I’m pretty certain that this is a memory/stack corruption of some sort.
Unfortunately, there have been several alterations and recompiles since
then, and the problem has disappeared again; I can’t make any new tests,
at least not until the problem reappears.

Josh

Josh Hamacher <hamacher@faac.com> wrote:

To illustrate, here is a snippet of the disassembled code:

02b9 8b 45 f4 mov eax,-0cH[ebp]
02bc c7 40 08 00 00 00
00 mov dword ptr
+8H[eax],00000000H
02c3 8b 45 f4 L8 mov eax,-0cH[ebp]
02c6 ff 40 08 inc dword ptr +8H[eax]

The address I was given corresponded to 02c2, and I had another person
verify this (just in case it was a math error). My question is, huh?
Under what conditions could this occur?

The most likely is corruption of the stack, in particular, corruption
of the return address on the stack. This results in a return to
an arbitrary location – not could be anywhere in an instruction, but
that would be treated as an instruction… and chaos ensues.

-David

QNX Training Services
dagibbs@qnx.com