Date: Thu, 20 Nov 2014 21:32:19 +0300 From: Eygene Ryabinkin <rea@freebsd.org> To: freebsd-threads@FreeBSD.org Cc: kib@FreeBSD.org, davidxu@FreeBSD.org Subject: [CFR][PATCH] Call proper signal handler from libthr for non-SA_SIGINFO case Message-ID: <KBP9w7ztz0PP7uy58G1ODYb/voI@1d%2BaJAniZP50FCDdGj54nd51%2Bks>
next in thread | raw e-mail | index | archive | help
--3D7yMlnunRPwJqC7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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-invocati= on.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=3D211= 737&r2=3D212076&view=3Dpatch Thanks. PS: I am not subscribed to the list, so, please, keep me CC'ed. --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --3D7yMlnunRPwJqC7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iL4EABEKAGYFAlRuM7NfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDgyRkUwNkJDRDQ5N0MwREU0OUVDNEZGMDE2 QUY5RUFFODE1MkVDRkIACgkQFq+eroFS7PvMKwD+M1RGSFvorQD2H+GGSPSVr7Fo 4A3B8LzBRiEVcCv83AEBAIKsbLuoEPwoAjFNLu9DB+4TW+DC3o2S0sjsdiZhRbPg =85DT -----END PGP SIGNATURE----- --3D7yMlnunRPwJqC7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?KBP9w7ztz0PP7uy58G1ODYb/voI>