[CFR][PATCH] Call proper signal handler from libthr for non-SA_SIGINFO case

[Eygene Ryabinkin]

Good day.

Was hacking on Squid that used to dump core when signal 15 was
delivered to it via 'squid -k shutdown' and found out that the reason
for core dumps is that thr_sighandler() is _sometimes_ passed 0x10001
as the value of "info" argument despite that _sigaction() always arms
flags for __sys_sigaction() with SA_SIGINFO.

But looking at handle_signal() I had discovered that if libthr client
wants no SA_SIGINFO, then actp->sa_sigaction() will be called, though
specs,
  http://pubs.opengroup.org/onlinepubs/009695399/functions/sigaction.html
say that in this case sa_handler should be used.  And this is consistent
with the non-threaded case.

Moreover, the called handler is passed 4 extra arguments,
{{{
  info->si_code, (struct sigcontext *)ucp, info->si_addr, (__sighandler_t *)sigfunc);
}}}
and for my poor Squid this is the root of the problem, because 0x10001
gets dereferenced (as info->SOMETHING), so SIGSEGV gets delivered
immediately.  By the way, the issue with seamonkey (but not Python) at
  https://lists.freebsd.org/pipermail/freebsd-current/2013-June/042199.html
  https://lists.freebsd.org/pipermail/freebsd-current/2013-June/042210.html
has the same pattern: inside one invocation of signal handler we see
SIGSEGV that can be triggered by this very problem: frame #5 handles
initial signal, while frame #4 is in-kernel stuff for SIGSEGV and
#3 is its userspace counterpart that takes us into libthr once again,
but this time for the different signal, I guess.  And this one goes
with proper "info", so no more harm is inflicted by libthr's code.


The origin of 0x10001 as info isn't yet clear to me, though I have
a feeling that it is SI_USER that is slipping somewhere to the wrong
place.  Will dig further.


Anyway, it seems like that the currend code inside handle_signal()
should be modified with the patch like
  http://codelabs.ru/fbsd/patches/libthr/11-CURRENT-fix-sighandler-invocation.patch

Could anyone, please, review it and, probably, come up with the idea of
why the current code is such as it is.  Revision when it first appeared
is 212076,
  https://svnweb.freebsd.org/base/head/lib/libthr/thread/thr_sig.c?r1=211737&r2=212076&view=patch

Thanks.


PS: I am not subscribed to the list, so, please, keep me CC'ed.
-- 
Eygene Ryabinkin                                        ,,,^..^,,,
[ Life's unfair - but root password helps!           | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC  4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 343 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20141120/1ebfb194/attachment.sig>