|
From: John R. <jr...@bi...> - 2010-06-07 17:26:07
|
> 1. ulimit -c unlimited ( I did not have core dump enabled ) > 2. valgrind --leak-check=yes ./debugmemoryleak > 3. gdb ./debugmemoryleak vgcore.6491 > 4. (gdb) x/8x 0x9ceb615 > 5. 0x9ceb615: 0xec8b55cb Assuming that we are looking in the same place as the CPU was: Opcode 0xcb (the low-order byte in 0xec8b55cb) is 'lret' (RET far) which expects a 48-bit segmented return address (which was pushed onto the stack as two 32-bit words). Valgrind assumes that code is written for a flat, non-segmented, addressing model; all return addresses are 32-bits only [on a 32-bit machine.] So that library contains (or is generating) code that valgrind won't understand. Ask the purveyor of the library about this. If you are truly desperate, then get a wizard to patch the code so that '0xcb' becomes '0xc2 0x04 0x00' (RET near $4). This will discard the segment register information, and might work. -- |