Re: Signal delivery order

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.

On Lunes 16 Marzo 2009, Oleg Nesterov wrote:
On 03/15, Gábor Melis wrote:

The revised signal-delivery-order.c (also attached) outputs:

test_handler=8048727
sigsegv_handler=804872c
eip: 8048727
esp: b7d94cb8

which shows that sigsegv_handler also has incorrect eip in the
context.

Why do you think it is not correct?

I didn't try your test-case, but I can't see where "esp: b7d94cb8"
comes from. But "eip: 8048727" looks exactly right, this is the
address of test_handler.

Sorry, I removed the printing of esp from the code as it was not
relevant to my point but pasted the output of a previous run.

Anyway, I think eip is incorrect in sigsegv because it's not pointing to
the instruction that caused the sigsegv. In general the ucontext is
wrong, because it's as if sigsegv_handler were invoked within
test_handler.

This is problematic if the sigsegv handler wants to do something with
the context. The real life sigsegv handler that's been failing does
this:
- skip the offending instruction by incrementing eip

I don't know how to solve your problem cleanly. Please let me now
if you find the solution ;)

As a workaround, perhaps sigsegv_handler() can just return if
uc_mcontext->ip points to another signal handler (assuming that
the first instruction of the signal handler can't cause the fault).
In this case the task will repeat the faulting instruction, and
sigsegv_handler() will be called again.

Agreed, this is not nice and the task should track sigaction()
calls, or sigsegv_handler() can do sigaction(signr, NULL, &oldact)
in a loop to see which handler we have.


Can the kernel help?

Perhaps we can add si_ip to _sigfault, in this case we could just
check uc_mcontext->ip != info->si_ip and return. Or we can unwind
the stack and find the "correct" rt_sigframe which matches the
page fault.

Or, we can change force_sig_info_fault() to block all signals
except si_signo and use set_restore_sigmask() logic. This means
no other signal can be dequeued until sigsegv_handler() returns.

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

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Windows XP hangs when I right click
    ... Windows displays the context menu. ... * When you click "Play All" in the Music or Videos folder Common Tasks, ... These problems are caused by a poorly coded context menu handler. ... Using ShellExView to determine the Context-menu handler causing the ...
    (microsoft.public.windowsxp.general)
  • Re: Windows Explorer crashes on launch and more, though not for al
    ... [[These problems are caused by a bad context menu handler. ... > uninstalling the imageconverter, and lo and behold... ... > somewhat disconcerting) I thank you both for your help and my wife thanks ...
    (microsoft.public.windowsxp.perform_maintain)
  • Re: Dynamic ToolStripMenuItem + No Event being triggered
    ... We use a standard ContextMenuStrip control along with a subclassed ... ToolbarMenuItem control that carries some application specific information ... associated ItemClicked Handler. ... handler for the new context menu and that handler works fine for each of the ...
    (microsoft.public.dotnet.framework.windowsforms.controls)
  • Re: Signal delivery order
    ... which shows that sigsegv_handler also has incorrect eip in the ... The real life sigsegv handler that's been failing does ... "some function" cannot be called with SIGUSR1 blocked because that ...
    (Linux-Kernel)
  • Re: Treeview Context Menu
    ... From the tree node, you can traverse up the node path to ... context menu services. ... Now, still in the mouse down event handler, store in a private instance ...
    (microsoft.public.vsnet.general)
Loading