|
From: Ed S. <ES...@fe...> - 2010-06-07 17:04:12
|
It will help a lot if you specify the byte values (say, 8 of them) in the instruction stream at address 0x9ceb615. How would I do this? $ gdb valgrind (gdb) run arguments-to-valgrind my-app arguments-to-my-app [snip] ==1460== valgrind: Unrecognised instruction at address 0x9ceb615. [snip] ==1460== Process terminating with default action of signal 4 (SIGILL) ==1460== Illegal opcode at address 0x9CEB615 ==1460== at 0x9CEB615: ??? [snip] (gdb) x/4x 0x9ceb615 Thanks. I had trouble with the above. Hopefully the below is the equivalent using valgringd 3.5.0 : 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 0x8b515756 0x15e3104d 0x8b0c758b 6. 0x9ceb625: 0xc18b087d 0xfc02e9c1 0xc88ba5f3 0xf303e183 I suspect the decoder may contain AMD specific opcodes as well. What tool is used to determine if these are valid opcodes, perhaps not for Intel 32-bit but perhaps valid 64-bit or AMD 32/64? Or maybe just some random data that a bad jump arrived at? The app runs without core dumping when run without Valgrind. Memory usage is steady. The problem I see is that reported memory usage increase each time I destroy and create new objects which is why started to investigate with Valgrind. >The only important change in this case is whether it still crashes or not. Ok. I saw no change it stills raises signal when it encounters unrecognized opcodes so I guess the decoder is not generating code dynamically. -Ed -- ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users -Ed |