erik quanstrom wrote:
it looks like you get the second trap while
you are still in your notify handler, since
i think this test
        (up->notified || up->notify==0)
is for a proc in a notify handler getting a system
trap (or a proc with no notify handler).
right, the problem is, my note handler never sees the
*real* trap. the message passed to the notehandler is the
string posted from the other process. "sig" in the case
of linuxemu. the ureg has the trap field set to 0xD. the
pc is right on the INT 0x80 instruction., but we get the
"sig", not "sys: trap: general protection ..."

(Of course! because that was the context/event that brougth
it into the kernel in the first place. But i think it picked the wrong
note for delivery, and keeps the NDebug note pending.)

If i ignore the "sig" and do a noted(NCONT); the real trap
comes in. (most of the time) But if i do any syscall in the
handler of "sig", we get killed

(maybe caused by notify() detecting the condition:
up->note[0].flag != NUser && up->notified
while we process the "sig" note)
it would be very interesting to know what the system
trap is. it would also be interesting to know if you are
seeing this randomly or if you can reliable reproduce
this condition.
I can reproduce it outside of linuxemu. I'm at work currently...
I will provide a testcase.

Many thanks for your response.
- erik

--
cinap

Reply via email to