GNU bug report logs - #11884
24.1.50; a regression with pselect(2) on FreeBSD after r108687

Previous Next

Package: emacs;

Reported by: Jan Beich <jbeich <at> tormail.org>

Date: Mon, 9 Jul 2012 06:53:02 UTC

Severity: normal

Found in version 24.1.50

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Jan Beich <jbeich <at> tormail.org>
Subject: bug#11884: closed (Re: 24.1.50; a regression with pselect(2) on
 FreeBSD after r108687)
Date: Tue, 17 Jul 2012 02:28:02 +0000
[Message part 1 (text/plain, inline)]
Your bug report

#11884: 24.1.50; a regression with pselect(2) on FreeBSD after r108687

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 11884 <at> debbugs.gnu.org.

-- 
11884: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11884
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jan Beich <jbeich <at> tormail.org>
Cc: "Herbert J. Skuhra" <hskuhra <at> eumx.net>, 11884-done <at> debbugs.gnu.org
Subject: Re: 24.1.50; a regression with pselect(2) on FreeBSD after r108687
Date: Mon, 16 Jul 2012 19:20:42 -0700
Thanks for that bug report.  Herbert J. Skuhra also
privately reported the same bug, and was gracious enough to
give me a login on a FreeBSD host where I could reproduce
your test case and debug the problem.

I found two related bugs.  First, Emacs's 'configure' script
incorrectly assumed that pthread_sigmask wasn't working on
FreeBSD; this is fixed in Emacs trunk bzr 109107.

Second, the gnulib fallback code for pthread_sigmask
incorrectly assumed that FreeBSD's pthread_sigmask (1729,
NULL, NULL) returns a nonzero error number, which it does
not -- it returns 0.  This is arguably a POSIX-compliance
bug in FreeBSD, but a bug like this is something that should
not make Emacs hang.  This is fixed by Emacs trunk bzr
109099.

I'm marking the bug as done; please feel free to reopen it if
this fix does not work for you.

Here's some URLs if you want to see diffs:

http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/109099

http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/109107

[Message part 3 (message/rfc822, inline)]
From: Jan Beich <jbeich <at> tormail.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.1.50; a regression with pselect(2) on FreeBSD after r108687
Date: Sun, 08 Jul 2012 16:04:08 -1100
Trying to use anything that waits for a process turns emacs into a cpu
hog, e.g. browse-url or vc-annotate. A simple test case is:

  $ emacs -Q
  (start-process "dummy" "*dummy*" "/usr/bin/true")

It does nothing on r108686 but degrades on r108707 (intermediate
revisions do not compile). list-processes still shows `true' despite the
process is long gone:

  Process [v]     Status  Buffer          TTY          Command
  dummy           run     *dummy*         /dev/pts/8   /usr/bin/true

in ktrace(1) it looks like this (repeatedly)

   911 emacs    CALL  ioctl(0x3,FIONREAD,0x7fffffffb47c)
   911 emacs    RET   ioctl 0
   911 emacs    CALL  pselect(0x5,0x7fffffffc850,0x7fffffffc7d0,0,0x7fffffffc7c0,0)
   911 emacs    RET   pselect 1
   911 emacs    CALL  ioctl(0x3,FIONREAD,0x7fffffffb46c)
   911 emacs    RET   ioctl 0
   911 emacs    CALL  read(0x4,0x7fffffffb550,0x1000)
   911 emacs    GIO   fd 4 read 0 bytes
       ""
   911 emacs    RET   read 0

--
FreeBSD 10.0-CURRENT r237800 amd64



This bug report was last modified 13 years and 28 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.