|
From: Tom H. <to...@co...> - 2006-01-16 16:47:42
|
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...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|