[lkml]   [2009]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Signal delivery order
Oleg Nesterov wrote:
> On 03/16, Gábor Melis wrote:
>> In a nutshell, the context argument is wrong.
> I strongly disagree. This all is correct and works as expected.
> Yes, it doesn't match your expectations/needs, but this doesn't
> mean it is wrong.

It would appear that standard may allow this, depending on interpretation.

From SUSv3, regarding sigaction():

"...the third argument can be cast to a pointer to an object of type
ucontext_t to refer to the receiving thread's context that was
interrupted when the signal was delivered."

From the "signal concepts" section, "A signal is said to be
``delivered'' to a process when the appropriate action for the process
and signal is taken."

Given that the SIGSEGV isn't "delivered" until it's handler runs, it
could possibly be valid for the instruction pointer in the SIGSEGV
handler to reference test_handler, if the system was set up in such a
way that the context was set to test_handler() at the time the SIGSEGV
handler was run.

However, there are quality-of-implementation issues here--being able to
handle SIGSEGV is pretty useless if the instruction pointer being passed
to the handler doesn't actually match the instruction that caused the

> I dunno. I am not sure your problem is common enough to do these
> changes, but I can't judge.

What he's trying to do isn't all that unusual. Certainly any
application wanting to do something smart (log the instruction pointer,
for instance) on a segfault could run into the same problem.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-03-16 23:59    [W:0.067 / U:4.944 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site