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 13:12:29 -0800 Message-ID: <56898EBD.2000000@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> <568950C5.2030306@dancol.org> <56896359.4020309@cs.ucla.edu> <568966D4.5080707@dancol.org> <56898C6F.4010303@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="UfrrkVu0UDE6RAoCIS0kHMu6hJXQA3oLG" X-Trace: ger.gmane.org 1451855577 11941 80.91.229.3 (3 Jan 2016 21:12:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2016 21:12:57 +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 22:12:55 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 1aFpxP-0002dP-6k for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 22:12:55 +0100 Original-Received: from localhost ([::1]:42948 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFpxO-0003P0-Fy for ged-emacs-devel@m.gmane.org; Sun, 03 Jan 2016 16:12:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43197) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFpx8-0003Lp-2g for Emacs-devel@gnu.org; Sun, 03 Jan 2016 16:12:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFpx6-0007eq-Rb for Emacs-devel@gnu.org; Sun, 03 Jan 2016 16:12:38 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:39872) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFpx6-0007em-GY; Sun, 03 Jan 2016 16:12:36 -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=xVVsveIzZH90GM1T9CH68bt0eFs44OFfdadjx6m8+Z4=; b=hD7xx1ckp0rVqrqPZUQx5Og4QkOMaidRnt7GxTFq8RJ5eXc8if8vWK+95tvM86Z8d+MiGFGy6Cq7s04n5sdCkwCRAVsymsKLR17we3Zokk7iVstJ3e/oCHRD//mME7DPn5xr62Kn/BGYc5ossJ6uHjBFtAOyAFcoiH7HRZINNDjcDYGIAmAULGdy6aFn/a5NzRn8+AFZnI/sPfs91HXKYgh/z39lNpR0dGAEOaBmki2csFiSgd8orJ/lWQ2F1nab4BWR8S+VZSAKGBO2j10eiR3BIsvLIA4wi++k1GYzI0PbXpWEDgPvulWMCBzkn5UKeGf4W6Ge9ylltIyv7S3oyw==; Original-Received: from [2620:10d:c090:180::1:692e] (helo=[IPv6:2620:10d:c081:1103:2ab2:bdff:fe1c:db58]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1aFpx5-0007HD-TH; Sun, 03 Jan 2016 13:12:36 -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: <56898C6F.4010303@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:197505 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UfrrkVu0UDE6RAoCIS0kHMu6hJXQA3oLG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/03/2016 01:02 PM, Paul Eggert wrote: > Daniel Colascione wrote: >=20 >> neither you nor Eli have demonstrated in any way that all this >> complexity is necessary, that we actually have a C stack overflow >> problem, >=20 > I mentioned (1) stack overflow in the regexp code, and (2) stack > overflow in C modules; did you miss that? The counterargument for (2) > that C modules can crash Emacs in countless ways so let's not worry > about stack overflow is not all that convincing. I think it's very convincing, and it's even less defensible to try to fix overflows in modules. It's *critical* not to violate the invariants of code. You have no idea what might happen when you do. It's not the job of the Emacs core to try to fix the bugs in modules that happen to be loaded into the process. > It can be useful for > the suspenders of stack-overflow checking to go along with the belt of > must-be-perfect modules. As I've previously written, I don't believe in trying to paper over bugs. Just crash. Loading native code in Emacs is a dangerous operation; trying to hide that danger by attempting to fix certain classes of module bugs will just make all problems harder to find. >> handle_interrupt can call quit_throw_to_read_char only >> when waiting_for_input is true, which it is only when, well, we're >> waiting for input, not at arbitrary points in the program. >=20 > Ah, good point, so that part of the code should be OK. Still, a few > lines earlier we see things like Fdo_auto_save () and fflush (stdout) > that can be executed from a Unix signal handler while quit-flag is > non-nil. Although this has undefined behavior too, this code has been > around for quite some time and I use it more often than I like to admit= =2E I don't like this either. It should be possible to replace the printfs in this instance with calls to write(1, "message") (which will bypass any output buffering) and restore async-signal-safety. If a user elects to attempt auto-save in this situation, that's on him. Ideally, we'd make autosave async-signal-safe, which will help in this handler and in the segfault hander. >> Or can we use a stack guard region [1], and in the signal handler, >> unprotect the set a global variable in the signal handler, and check t= he >> variable on QUIT, and at toplevel, reprotect the guard region. If we >> segfault again without having reached toplevel, just die. Would that >> make you happy? >=20 > I think something along that lines would suffice, yes. Admittedly I > didn't quite follow what you wrote (perhaps some text got elided?). But= > the main point, as I understand it, is that we needn't worry about > having a stack-overflow check inside the stack-overflow handler, becaus= e > we can insist that the stack-overflow handler be tightly-enough > controlled so that it won't recurse indefinitely. Yes: do as little as possible in the segfault handler and signal an error the normal way at the next safe opportunity, if one arises before we fully exhaust the stack. --UfrrkVu0UDE6RAoCIS0kHMu6hJXQA3oLG 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 iQIcBAEBCAAGBQJWiY69AAoJEN4WImmbpWBlq6AQAKboHPcQrU8sd+lCHpeaMwka 3WI3NnJ1Bt7K1ZWKSdFYnbWhv6JIGdxSTCf21vGFCWPVhc+LDoNaxzF3P9bqdovu 5i+XkfITlbplhs4qtQ0FD85rpS5TicSqcpCwfDyDfnBILujhk38G7twE76jgr5FT 4PmW8ddoEMqX7ieiYLV3c3n0HXoa55g5mr0J/NClDMg9bmEqtTHBOsfI1OiwN2Q0 xvwKx2rVjXNTQ7Vj+1UvErxLQ9fyq3vAOgfbvGvz57xUqOJxbROH9dr3YSPVTwcZ HR+ELpZFYztu05H6/0j5Hx4/plwF6dS+SbuT3V5QZmlbmgNxqXCdBXHHbG+Ry7fp PgBRCbtPbJaq+KU+IhoyzxpMA1Fs17ZLCm8r9i4BKLuOQLiYsdsVDv6FYmMUU/uu e1PXCkejOyY5BTV5iXydgGVBq4oamGpjK763YaIlj4JiqRVgVvIX1GaOy5x52bFW RMiluFPCVmza8JR54hCCIH+1Sprtn7e6geKOfQWB7wk/QpaMI+80fTIe+9Iv/Hjp uLao+rW4w6tGqRTBECjr48tci4SqU2dh42cxyF2nO45Uycw6CZHElI0yRdbTsvdw yXtCI0BWyMI0uOpcLmqcIlKKW4r+Xdz+MoCtowMd4DCNdLP0YmftL4HEqi6hR6IW 5FLnlH2509juci0HfV42 =5dbc -----END PGP SIGNATURE----- --UfrrkVu0UDE6RAoCIS0kHMu6hJXQA3oLG--