|
From: Jeroen N. W. <jn...@xs...> - 2004-08-26 08:45:42
|
> In message <207...@we...> > "Jeroen N. Witmond" <jn...@xs...> wrote: > >> It looks as if I have stumbled across a bug in the way valgrind (CVS) >> handles signal SIGFPE. To demonstrate this problem, I have created and >> attached file SIGFPEc.c. >> >> The problem: When I run this program stand-alone [output in attached >> file >> SIGFPEc.check.txt], it shows that that siginfo->si_addr points somewhere >> in my executable. But when I run the very same executable under valgrind >> --tool=memcheck [output in attached file SIGFPEc.valgrind.txt], >> siginfo->si_addr points somewhere in valgrind's stage2. > > With SIGFPE si_addr is the address of the faulting instruction. When > running under valgrind all instructions in your program are simulated > by valgrind which does a just in time translation of your code. > > As a result the faulting instruction will always be in a different > place when running under valgrind. In particular in this case the > fault is probably occurring in one of the helper routines which is > used to handle division operations, hence the reason why the address > is inside stage2 as that is where the helper routines are. > Hmm? I would have expected that the simulated environment created by Valgrind (CPU and parts of Linux/libc) behaves the same as the environment being simulated. Any deviation may (and hence one day will) make the program being tested behave differently when run with or without Valgrind, reducing its effectiveness. Also, in the case of a SIGSEGV, Valgrind is quite capable to set the user's EIP in fields: - ((ucontext_t*)context)->uc_mcontext.gregs[REG_EIP], where 'void* context' is the third argument to the sa_sigaction in struct sigaction. 'ucontext_t' is declared by '#include <ucontext.h>'. Just now I have verified that this field is also set correctly by Valgrind in the case of a SIGFPE. - ctx.eip, where 'struct sigcontext ctx' is the undocumented second argument to the sa_handler in struct sigaction. [In the case of a SIGSEGV, siginfo->si_addr contains the address of the memory that cannot be accessed, not the address of the instruction doing the accessing. Not verified under Valgrind.] Should I create a bug report for this problem? Jeroen. |