bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X


From: Eli Zaretskii
Subject: bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X
Date: Mon, 29 Feb 2016 18:02:04 +0200

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: andlind@gmail.com,  22814@debbugs.gnu.org
> Date: Mon, 29 Feb 2016 11:24:11 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Michael Albinus <michael.albinus@gmx.de>
> >> Cc: andlind@gmail.com,  22814@debbugs.gnu.org
> >> Date: Sat, 27 Feb 2016 20:56:29 +0100
> >>
> >> I've improved the test case. The file-error is trapped, and the test
> >> continues. Now I get
> >>
> >> Test file-notify-test09-sufficient-ressources condition:
> >>     (error "Invalid byte code in 
> >> /usr/local/src/emacs-25/lisp/emacs-lisp/cl-seq.elc")
> >>
> >> The Lisp backtrace doesn't tell anything useful. What could I do now?
> >
> > Set a breakpoint in Fsignal, and see who signals the error, and why.
> 
> --8<---------------cut here---------------start------------->8---
> Breakpoint 5, Fsignal (error_symbol=15024, data=95357875) at eval.c:1471
> 1471        = (NILP (error_symbol) ? Fcar (data) : error_symbol);
> (gdb) pp error_symbol
> error
> (gdb) pp data
> ("Invalid byte code in /usr/local/src/emacs-25/lisp/emacs-lisp/cl-seq.elc")
> (gdb) xbacktrace
> "cl-intersection" (0xffffccc0)
> "ert--should-error-handle-error" (0xffffcd60)
> "condition-case" (0xffffcf68)
> "let" (0xffffd088)
> "let" (0xffffd1a8)
> "let" (0xffffd2c8)
> "let" (0xffffd3e8)
> "unwind-protect" (0xffffd4c8)
> 0x1b99710 Lisp type 3
> "ert--run-test-internal" (0xffffd7c0)
> "ert-run-test" (0xffffd948)
> "ert-run-or-rerun-test" (0xffffdae8)
> "ert-run-tests" (0xffffdc68)
> "ert" (0xffffdea0)
> "funcall-interactively" (0xffffde98)
> "call-interactively" (0xffffe120)
> "command-execute" (0xffffe2d8)
> "command-line-1" (0xffffe440)
> "command-line" (0xffffe608)
> "normal-top-level" (0xffffe6d0)
> "nil" (0x0)
> 0 (0x15ab400)
> 0xe04620 Lisp type 4
> 0x1ae63b0 Lisp type 3
> Error accessing memory address 0x37393832746e6588: Bad address.
> (gdb) bt
> #0  Fsignal (error_symbol=15024, data=95357875) at eval.c:1471
> #1  0x000000000050b0a9 in xsignal (error_symbol=15024, data=95357875) at 
> eval.c:1577
> #2  0x000000000050970c in xsignal1 (error_symbol=<value optimized out>, 
> arg=<value optimized out>) at eval.c:1592
> #3  0x000000000050b173 in verror (m=<value optimized out>, ap=<value 
> optimized out>) at eval.c:1770
> #4  0x0000000000509632 in error (m=0x3ab0 <Error reading address 0x3ab0: Bad 
> address>) at eval.c:1782
> #5  0x000000000050c921 in Ffetch_bytecode (object=<value optimized out>) at 
> eval.c:2949

Crystal ball says something went wrong inside read_doc_string that was
called just before the call to 'error'.  That function calls
emacs_open, and you have run out file descriptors.  Can you see what's
going on inside that call?  (That would require re-running the test
with a suitably conditioned breakpoint.)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]