|
From: John A. <ja...@mb...> - 2004-09-01 07:00:55
|
On Thu, 26 Aug 2004 14:13:35 +0100 (BST), Nicholas Nethercote <nj...@ca...> wrote: >On Thu, 26 Aug 2004, Dimitri Papadopoulos-Orfanos wrote: > >> For your information, I've also attempted to instrument the code with=20 >> Insure++. It didn't prove very helpful either... Something seems to be= wrong=20 >> in a timeout signal handler in distcc. > >One thing you could try: modify Valgrind so that when the assert = triggers,=20 >you print out the value of "eip". Then, use "objdump -d" to look at the= =20 >original machine code (if it's in a shared object it's a little trickier= =20 >to work out how the 'eip' maps to the code) and see if it really is a=20 >nested "enter" instruction. > >That would at least determine, with some confidence, whether it's a = nested=20 >"enter" or a jump into non-code that's troubling Valgrind. > >N > One machine I worked on had a "lagging address pointer", which was the second most recent eip value. It was great for identify what happened just before random branches. Maybe valgrind could add a prior eip stack which could be dumped after an error. [I'm just an observer here.. love to read about this interesting project.] john alvord [ |