|
From: | David De La Harpe Golden |
Subject: | bug#9874: Fixes for several integer overflow and width issues |
Date: | Wed, 26 Oct 2011 18:02:22 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Icedove/3.1.15 |
On 26/10/11 15:26, Juanma Barranquero wrote:
Thank you very much, but we're too far in the release process for such large patches, so it will have to wait for 24.2.These bugs seem serious enough: - On my Fedora 14 x86-64 host, (signal-process 4294967295 1) crashes my entire login session, Emacs included, and leaves my workstation in a corrupted state in which the screen continually flashes a nonsense pattern and I cannot log in. This bug occurs because Emacs incorrectly assumes that fixnums fit into pid_t values, which is not true on typical 64-bit hosts.
Hmm. The really serious/horrible part there (screen manglement and being unable to login again) sounds like some X and/or [gkx]dm bug well outside emacs' responsibility. Given the current state of the emacs code, it should "just" kill (hup) all the processes you can kill*. It shouldn't be any worse than if you just opened up an xterm and typed "kill -HUP -1".
Yes, that probably includes suddenly ending your entire desktop session, but unless you're running as a privileged user that should "just" leave you staring in annoyance at the [gkx]dm login dialog, there shouldn't be any lingering corruption, just like there shouldn't be any lingering corruption with a "kill -HUP -1".
Emacs bug that 4294967295 silently/surprisingly becomes -1 in signal-process? Well, probably. Emacs bug that your computer's state somehow gets corrupted to the point you can't log in again? No.
* pid_t 32-bit, 4294967295 => 32-bit -1, and kill(-1,...) signals everything you're allowed signal.
[Prev in Thread] | Current Thread | [Next in Thread] |