From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc. Date: Sun, 3 Jan 2016 08:48:05 -0800 Message-ID: <568950C5.2030306@dancol.org> References: <83mvu1x6t3.fsf@gnu.org> <56772054.8010401@cs.ucla.edu> <83zix4scgf.fsf@gnu.org> <5677DBC9.6030307@cs.ucla.edu> <83io3rst2r.fsf@gnu.org> <567841A6.4090408@cs.ucla.edu> <567844B9.2050308@dancol.org> <5678CD07.8080209@cs.ucla.edu> <5678D3AF.7030101@dancol.org> <5678D620.6070000@cs.ucla.edu> <83mvt2qxm1.fsf@gnu.org> <56797CD9.8010706@cs.ucla.edu> <8337uuqsux.fsf@gnu.org> <5679DC83.70405@cs.ucla.edu> <83oadhp2mj.fsf@gnu.org> <567AD556.6020202@cs.ucla.edu> <567AD766.3060608@dancol.org> <567B5DAB.2000900@cs.ucla.edu> <83fuyromig.fsf@gnu.org> <567C25B1.3020101@dancol.org> <56892FD6.8040708@dancol.org> <56894CE7.7090301@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="T81W0qcxNSVGAC3swBh09OgjA555fGcwk" X-Trace: ger.gmane.org 1451839720 8891 80.91.229.3 (3 Jan 2016 16:48:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 16:48:40 +0000 (UTC) To: Paul Eggert , Eli Zaretskii , Emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 03 17:48:32 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aFlpX-00083F-AF for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 17:48:31 +0100 Original-Received: from localhost ([::1]:42185 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFlpW-0000je-8Y for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 11:48:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41630) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFlpI-0000jX-DF for Emacs-devel@gnu.org; Sun, 03 Jan 2016 11:48:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFlpD-0002vZ-Fi for Emacs-devel@gnu.org; Sun, 03 Jan 2016 11:48:16 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:38426) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFlpD-0002vT-48; Sun, 03 Jan 2016 11:48:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=APhNAUGTZ3SNtx8ScDfpL33deVXudDtmMGPXZoeNCjk=; b=TuCuiVdlea/hwJop4R+bir+wBV6oUk7fmxA9TUwTEC0/KHb+tMvhAFICfMQPjjZeh1Z9rIE1IsAPou6Va3HWXV5GjhYpqJkjs3BaPAFeHA2xJifJ9LeVxO/qKSJAWB2Y+eEqC3kBgR/1XnpAG5L5Ks13ckUP/Jml2VeoNgr4H2HGEvgjRAh53L/wEgS2+7gkwz9mZEUETzmhzLyrUP2Z/K+4dQZComYwssQ2tGFk2ygrBTXrmu7KyPXOSABVmAboxISLHP8w8+DKNe4KdMvele+FML9KY9VENWSTLwQoSTcY64169U66/G/nWbBIU71q2Q2IsCd5tPvaehfhbLAE2A==; Original-Received: from c-67-161-115-4.hsd1.wa.comcast.net ([67.161.115.4] helo=[192.168.1.210]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1aFlpC-0005uc-4a; Sun, 03 Jan 2016 08:48:10 -0800 X-Enigmail-Draft-Status: N1110 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <56894CE7.7090301@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:197465 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --T81W0qcxNSVGAC3swBh09OgjA555fGcwk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/03/2016 08:31 AM, Paul Eggert wrote: > Daniel Colascione wrote: >> In 2014, Emacs gained a new path in the SIGSEGV handler that attempts = to >> detect C stack oerflow and longjmp back to toplevel. It's important to= >> note that we don't just longjmp when we're in a safe position: we >> longjmp from *anywhere*, even if we're, say, in the middle of malloc. >=20 > Although that particular code path may have been introduced recently, > for decades Emacs has longjmped from arbitrary locations due to other > signals, so adding a longjmp for SIGSEGV does not introduce new issues.= What do you mean? We can lisp-signal from lots of places (but not arbitrary values of the program counter), but we don't respond to *unix* signals by longjmping. When I added the SIGUSR2 debug-break support, I made handle_user_signal set Vquit_flag instead of longjmping in order to avoid exactly the problem I'm highlighting here. We don't longjmp from SIGIO either, by the way: we set a flag that we inspect later, at a safe place. >> The code is fundamentally flawed and cannot be made to work >> properly on any platform. >=20 > The code is part of Emacs 24.5 and does not appear to be causing > problems; at least, I don't recall any bug reports from the field. The > other longjmps, which are fundamentally flawed in the same way, have > been in Emacs for decades, and also seem to work well enough in practic= e. >=20 >> No other program attempts to recover from >> stack overflow this way. >=20 > True, not *exactly* in this way, but Emacs is pretty special. Not in this respect. In particular, Emacs has no special magic that makes it safe to longjmp out of arbitrary C program sequences. >> In practice, the Lisp stack depth limits provide enough protection >=20 > That won't be true once once people link in dynamic modules, since the > modules may not use Lisp and may exhaust the C stack. And even without > modules, I recall people running into stack-overflow issues in the > regular-expression code. Did that ever get fixed? Even if so, most > likely other such issues are still lurking in the regexp code. >=20 >> The existing auto-save logic >> is good enough for data recovery, especially if we run the sigsegv >> handler on the alternate signal stack (which we can make as large as w= e >> want) when possible. >=20 > Something like that could help, yes. But the existing auto-save logic > can longjmp out, so I don't see how this would address your concern > about longjmp. It can Fsignal. That's not the same thing. Fsignal is a supported, controlled mechanism with defined semantics, not a free-for-all like the SIGSEGV handler. > One possible way forward here is the approach recommended by GNU > libsigsegv. See "About stack= > overflow handlers". In the past we've avoided libsigsegv's approach > because it was considered to be too heavyweight, but it would be safer > to do something along the lines that it suggests, or perhaps even to us= e > libsigsegv if available. The libsigsegv approach is a problem too: pthread cancellation in practice is unsupported on some platforms, does not execute C++ destructors on some platforms even where it's supported, is lightly tested, and conflicts with other uses of sigsegv. In the case of Emacs, pthread cancellation is additionally risky because we don't even try to PTHREAD_CANCEL_DISABLE around critical code sequences. Neither you nor Eli have provided any evidence that we need to worry about C stack overflow at all and that any of the proposed recovery schemes is worth the technical complexity and risk. We should treat C stack overflow exactly like we treat a NULL dereference. I've previously proposed alternate, safe, ways we can recover from C stack overflow, but I don't think we should use any of these, because I don't think it's worth attempting to recover from this bad state at all. >> If we keep this code in Emacs, it sets a precedent for other terrible >> forms of crash recovery, like silently ignoring writes to NULL ... >=20 > Naah. We're pragmatic, not stupid. People who call themselves pragmatic have had worse ideas. --T81W0qcxNSVGAC3swBh09OgjA555fGcwk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWiVDFAAoJEN4WImmbpWBlXFIP/2Dm3eCnERGOZObBgmby4ovs 6hI5ejXxCvT1ZyfZUFJYc4d9w3gIR+ZAWGkgMAvuN2Mj4lUwEPL0i5Pcqn7SjIZS 1ElOhe3rkFAL/uB1alyGvtSiAoxnpkKsqiJ45He6b/dpXKcYkfQ/JFVKaPyS76kY P1fHKdZiJIP43zhThlDQlVZI4jvm6hPX2HLDScnsvc0O/T0KQcLDfKP/uz+XpzwX TgVVRqdyB8MzY3VaWQeFk7czs5iMXItnbKQSHS/D7+/i4V3C8qmfnTU2+AzmXNDW MO5A1UTP+mK/580NyEPVDmW2KArt0G9fo6OtMkdBXGSp8s4q683HOX35uEGFGjDS zqGF6Wsqg/HZ2wEy9ChGd+cbIg0noAWBlIgBG9Qb8h6+L3nUDwhzdJs4g63pJfXa Hyt8tWK9eWnoRZAO9D+uTSiDJ+hm/OtfdhhSICAewUh7WAvMH0jPDNSb3yw/2CXi IZLbdbgLWd5HJYS/WoYH2bYT2XDtaGMRkAffAdIuDmu9Ib4DYkqoqq1T7Nl5Y12j YQ7DkEU6oJ7C4dCNhJRRpcXZBUzA0fTYbJtYA66DkDoN6rjPcnG4DeZdtMaKyfgP irov6UPbnRuiBUWdiKWbbmlvaJa0IrDUeD1UrTBRU8U4uWz80Hz7NKXEksGqFdRm 1Z9uaPa3znrXHq96B9mV =0EKj -----END PGP SIGNATURE----- --T81W0qcxNSVGAC3swBh09OgjA555fGcwk--