|
From: Ed S. <ES...@fe...> - 2010-06-07 18:22:51
|
On Jun 7, 2010, at 12:25 PM, John Reiser wrote: >> 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. So as I understand it the 48-bit segmented addressing opcode is valid but Valgrind 3.5.0 does not recognize it and raises an exception. I assume it is not worth submitting a bug report, especially for my own personal benefit, as it may never be supported. > > 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. Good suggestion and might be worth it if it helps me uncover any real memory leaks. Thank you for your and everyone's help, -Ed |