all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Michael Albinus <michael.albinus@gmx.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 22814@debbugs.gnu.org, andlind@gmail.com
Subject: bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X
Date: Mon, 29 Feb 2016 11:24:11 +0100	[thread overview]
Message-ID: <87lh637r1w.fsf@gmx.de> (raw)
In-Reply-To: <838u25c3z4.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 27 Feb 2016 22:06:55 +0200")

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
#6  0x000000000050c53f in funcall_lambda (fun=12117621, nargs=2, arg_vector=0x7fffffffccc0) at eval.c:2854
#7  0x000000000050bbf3 in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2742
#8  0x000000000053b8ee in exec_byte_code (bytestr=<value optimized out>, vector=22872277, maxdepth=<value optimized out>, args_template=<value optimized out>, nargs=<value optimized out>,
    args=<value optimized out>) at bytecode.c:880
#9  0x000000000050b61a in apply_lambda (fun=22872381, args=<value optimized out>, count=<value optimized out>) at eval.c:2794
#10 0x0000000000508a14 in eval_sub (form=<value optimized out>) at eval.c:2211
#11 0x000000000050a889 in internal_lisp_condition_case (var=11746680, bodyform=<value optimized out>, handlers=<value optimized out>) at eval.c:426
#12 0x0000000000508b83 in eval_sub (form=<value optimized out>) at eval.c:2119
#13 0x0000000000509ff9 in Flet (args=<value optimized out>) at eval.c:426
#14 0x0000000000508b83 in eval_sub (form=<value optimized out>) at eval.c:2119
#15 0x0000000000509ff9 in Flet (args=<value optimized out>) at eval.c:426
#16 0x0000000000508b83 in eval_sub (form=<value optimized out>) at eval.c:2119
#17 0x0000000000509ff9 in Flet (args=<value optimized out>) at eval.c:426
#18 0x0000000000508b83 in eval_sub (form=<value optimized out>) at eval.c:2119
#19 0x0000000000509ff9 in Flet (args=<value optimized out>) at eval.c:426
#20 0x0000000000508b83 in eval_sub (form=<value optimized out>) at eval.c:2119
#21 0x000000000050a64e in Funwind_protect (args=28974979) at eval.c:1170
#22 0x0000000000508b83 in eval_sub (form=<value optimized out>) at eval.c:2119
#23 0x000000000050c7c9 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=<value optimized out>) at eval.c:426
#24 0x000000000050bbf3 in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2742
#25 0x000000000053b8ee in exec_byte_code (bytestr=<value optimized out>, vector=23072773, maxdepth=<value optimized out>, args_template=<value optimized out>, nargs=<value optimized out>,
    args=<value optimized out>) at bytecode.c:880
#26 0x000000000050bbf3 in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2742
#27 0x000000000053b8ee in exec_byte_code (bytestr=<value optimized out>, vector=23073197, maxdepth=<value optimized out>, args_template=<value optimized out>, nargs=<value optimized out>,
    args=<value optimized out>) at bytecode.c:880
#28 0x000000000050bbf3 in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2742
#29 0x000000000053b8ee in exec_byte_code (bytestr=<value optimized out>, vector=23488237, maxdepth=<value optimized out>, args_template=<value optimized out>, nargs=<value optimized out>,
    args=<value optimized out>) at bytecode.c:880
#30 0x000000000050bbf3 in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2742
#31 0x000000000053b8ee in exec_byte_code (bytestr=<value optimized out>, vector=23488597, maxdepth=<value optimized out>, args_template=<value optimized out>, nargs=<value optimized out>,
    args=<value optimized out>) at bytecode.c:880
#32 0x000000000050bbf3 in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2742
#33 0x000000000053b8ee in exec_byte_code (bytestr=<value optimized out>, vector=23546765, maxdepth=<value optimized out>, args_template=<value optimized out>, nargs=<value optimized out>,
    args=<value optimized out>) at bytecode.c:880
#34 0x000000000050bbf3 in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2742
#35 0x0000000000506644 in Ffuncall_interactively (nargs=15024, args=0x5af0bb3) at callint.c:248
#36 0x000000000050bc5e in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2673
#37 0x000000000050b86d in Fapply (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2321
#38 0x0000000000506b26 in Fcall_interactively (function=4839752, record_flag=<value optimized out>, keys=<value optimized out>) at callint.c:385
#39 0x000000000050bd63 in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2700
#40 0x000000000053b8ee in exec_byte_code (bytestr=<value optimized out>, vector=8926749, maxdepth=<value optimized out>, args_template=<value optimized out>, nargs=<value optimized out>,
    args=<value optimized out>) at bytecode.c:880

[...]
--8<---------------cut here---------------end--------------->8---

Emacs was compiled with "gmake bootstrap". I'll keep the gdb session open.

Best regards, Michael.





  reply	other threads:[~2016-02-29 10:24 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-26  6:18 bug#22814: 25.0.91; Emacs runs out of file descriptors on OS X David Caldwell
2016-02-26  8:34 ` Michael Albinus
2016-02-26  9:05   ` David Caldwell
2016-02-26 10:26     ` Nicolas Richard
2016-02-26  9:22   ` Eli Zaretskii
2016-02-26 20:05     ` Michael Albinus
2016-02-26  9:04 ` Eli Zaretskii
2016-02-26 20:51 ` Anders Lindgren
2016-02-27  8:00   ` Michael Albinus
2016-02-27  9:19     ` Eli Zaretskii
2016-02-27 13:26       ` Michael Albinus
2016-02-27 19:00         ` Anders Lindgren
2016-02-27 19:12           ` Michael Albinus
2016-02-27 19:17             ` Eli Zaretskii
2016-02-27 19:33               ` Michael Albinus
2016-02-27 19:39                 ` Eli Zaretskii
2016-02-27 19:51                   ` Michael Albinus
2016-02-27 19:58                     ` Eli Zaretskii
2016-02-27 20:06                       ` Michael Albinus
2016-02-27 20:25                         ` Eli Zaretskii
2016-02-28  9:57                           ` Michael Albinus
2016-02-28 15:51                             ` Eli Zaretskii
2016-02-27 19:14           ` Eli Zaretskii
2016-02-27 19:26             ` Michael Albinus
2016-02-27 19:36               ` Eli Zaretskii
2016-02-27 19:39                 ` Michael Albinus
2016-02-27 19:56                 ` Michael Albinus
2016-02-27 20:06                   ` Eli Zaretskii
2016-02-29 10:24                     ` Michael Albinus [this message]
2016-02-29 16:02                       ` Eli Zaretskii
2016-03-02 15:03                         ` Michael Albinus
2016-03-02 16:01                           ` Eli Zaretskii
2016-03-04  7:53                             ` Michael Albinus
2016-03-04  8:14                               ` John Wiegley
2016-03-04  8:29                               ` Eli Zaretskii
2016-03-04 14:05                                 ` Michael Albinus
2016-03-04 14:11                             ` Michael Albinus
2016-04-10  8:21                               ` Michael Albinus
2016-04-10 20:37                                 ` Anders Lindgren
2016-04-11  6:40                                   ` Michael Albinus
2016-04-11  6:48                                     ` Anders Lindgren
2016-04-11  6:58                                       ` Michael Albinus
2016-04-11 18:59                                         ` Anders Lindgren
2016-04-12  7:44                                           ` Michael Albinus
2016-02-27  9:55     ` Anders Lindgren
2016-02-27 10:46       ` Eli Zaretskii
2016-02-27 11:38         ` Anders Lindgren
2016-02-27 12:17           ` Michael Albinus
2016-02-27 12:40             ` Eli Zaretskii
2016-02-27 12:49               ` Michael Albinus
2016-02-27 12:52                 ` Eli Zaretskii
2016-02-27 13:00                   ` Michael Albinus
2016-03-05  0:32 ` Paul Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lh637r1w.fsf@gmx.de \
    --to=michael.albinus@gmx.de \
    --cc=22814@debbugs.gnu.org \
    --cc=andlind@gmail.com \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.