|
From: Richard Frith-M. <ri...@br...> - 2006-01-16 17:01:11
|
On 16 Jan 2006, at 16:47, Tom Hughes wrote: > In message <861...@br...> > Richard Frith-Macdonald <ri...@br...> wrote: > >> On 16 Jan 2006, at 11:44, Tom Hughes wrote: >> >>> Looks like a signal handling issue then - add --trace-signals=yes >>> and see what that gets you. >> >> OK ... segmentation violation ... but I don't know where/why. >> Does the following (the last six lines are the ones that repeat >> forever) make any sense? > > OK. I can reproduce this. I think the problem is that the JVM is > installing a SEGV handler which tries to resume at a different > address by updating the value of RIP in the signal context. > > Now valgrind doesn't handle that - it copies most of the register > values back but not the RIP value. I've just tried making it copy > the RIP value back but it didn't seem to help and it was still > looping. > > I presume the reason for that is that although the RIP for the > simulated CPU has been updated when the signal handler returns > the real CPU will restart execution from in the JITed code that > valgrind has generated and then fault again. > > The signal handler probably needs to jump back to the scheduler > if RIP has changed so that the scheduler can restart execution > from the right address but Julian may have a better idea how to > fix this... That's getting into the internals of valgrind and beyond my current knowhow ... but I understand the gist of your reply. I guess this is to be taken as a valgrind bug then ... would you like me to file a bug report? |