* Emacs-24.3 crash when browse-url
@ 2012-12-04 13:26 Thierry Volpiatto
2012-12-04 13:40 ` Andreas Schwab
0 siblings, 1 reply; 16+ messages in thread
From: Thierry Volpiatto @ 2012-12-04 13:26 UTC (permalink / raw)
To: emacs-devel
Hi,
emacs crash when using M-x browse-url
I think the function that crash is `browse-url-xdg-open'
or its predicate `browse-url-can-use-xdg-open'.
There is no crash when using something else than
`browse-url-default-browser' for `browse-url-browser-function'
e.g:
(setq browse-url-browser-function 'browse-url-firefox)
This happen with this revision from trunk:
--8<---------------cut here---------------start------------->8---
changeset: 123958:5c920c28f35c
tag: tip
user: Katsumi Yamaoka <yamaoka@jpl.org>
date: Tue Dec 04 08:22:12 2012 +0000
summary: gmm-utils.el (gmm-flet, gmm-labels): New macros.
--8<---------------cut here---------------end--------------->8---
Here the BT.
--8<---------------cut here---------------start------------->8---
(gdb) run -Q
Starting program: /home/thierry/tmp/emacs-hg/src/emacs -Q
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=10) at emacs.c:313
313 {
(gdb) bt
#0 terminate_due_to_signal (sig=6, backtrace_limit=10) at emacs.c:313
#1 0x00000000004ed393 in emacs_abort () at sysdep.c:2132
#2 0x00000000005804f4 in exec_byte_code (bytestr=6, vector=140737488341064, maxdepth=20,
args_template=4611686019484352512, nargs=4611686018662268928, args=0x14) at bytecode.c:1955
#3 0x000000000054750f in funcall_lambda (fun=18195317, nargs=<optimized out>, arg_vector=0x7fffffffcb68) at eval.c:2903
#4 0x000000000054785d in Ffuncall (nargs=<optimized out>, args=0x7fffffffcb60) at eval.c:2732
#5 0x0000000000548a77 in Fapply (nargs=3, args=0x7fffffffcb60) at eval.c:2152
#6 0x0000000000547a9f in Ffuncall (nargs=<optimized out>, args=0x7fffffffcb58) at eval.c:2652
#7 0x000000000057db83 in exec_byte_code (bytestr=6, vector=140737488341848, maxdepth=20,
args_template=4611686019484352512, nargs=4611686018662268928, args=0x14) at bytecode.c:897
#8 0x000000000054750f in funcall_lambda (fun=18203597, nargs=<optimized out>, arg_vector=0x7fffffffce68) at eval.c:2903
#9 0x000000000054785d in Ffuncall (nargs=<optimized out>, args=0x7fffffffce60) at eval.c:2732
#10 0x0000000000548a77 in Fapply (nargs=3, args=0x7fffffffce60) at eval.c:2152
#11 0x0000000000547a9f in Ffuncall (nargs=<optimized out>, args=0x7fffffffce58) at eval.c:2652
#12 0x000000000057db83 in exec_byte_code (bytestr=6, vector=140737488342616, maxdepth=20,
args_template=4611686019484352512, nargs=4611686018662268928, args=0x14) at bytecode.c:897
#13 0x000000000054750f in funcall_lambda (fun=17204357, nargs=<optimized out>, arg_vector=0x7fffffffd038) at eval.c:2903
#14 0x000000000054785d in Ffuncall (nargs=<optimized out>, args=0x7fffffffd030) at eval.c:2732
#15 0x000000000054889d in Fapply (nargs=<optimized out>, args=0x7fffffffd0f0) at eval.c:2205
#16 0x0000000000547dc0 in apply1 (fn=16197490, arg=<optimized out>) at eval.c:2439
#17 0x0000000000543a15 in Fcall_interactively (function=16197490, record_flag=16716530, keys=19146278) at callint.c:377
#18 0x0000000000547a15 in Ffuncall (nargs=<optimized out>, args=0x7fffffffd2b0) at eval.c:2678
#19 0x0000000000547c84 in call3 (fn=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>)
at eval.c:2496
#20 0x00000000005479fe in Ffuncall (nargs=<optimized out>, args=0x7fffffffd3b8) at eval.c:2682
#21 0x000000000057db83 in exec_byte_code (bytestr=6, vector=140737488343992, maxdepth=20,
args_template=4611686019484352512, nargs=4611686018662268928, args=0x14) at bytecode.c:897
#22 0x000000000054750f in funcall_lambda (fun=9454405, nargs=<optimized out>, arg_vector=0x7fffffffd5a8) at eval.c:2903
#23 0x000000000054785d in Ffuncall (nargs=<optimized out>, args=0x7fffffffd5a0) at eval.c:2732
#24 0x000000000054889d in Fapply (nargs=<optimized out>, args=0x7fffffffd660) at eval.c:2205
#25 0x0000000000547dc0 in apply1 (fn=12309266, arg=<optimized out>) at eval.c:2439
#26 0x0000000000543a15 in Fcall_interactively (function=12309266, record_flag=12002370, keys=19138230) at callint.c:377
#27 0x0000000000547a15 in Ffuncall (nargs=<optimized out>, args=0x7fffffffd820) at eval.c:2678
#28 0x0000000000547c84 in call3 (fn=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>)
at eval.c:2496
#29 0x00000000004e14c3 in command_loop_1 () at keyboard.c:1576
#30 0x0000000000545dc8 in internal_condition_case (bfun=0x4e1140 <command_loop_1>, handlers=12053730,
---Type <return> to continue, or q <return> to quit---
hfun=0x4d6880 <cmd_error>) at eval.c:1192
#31 0x00000000004d4a2e in command_loop_2 (ignore=<optimized out>) at keyboard.c:1163
#32 0x0000000000545c8d in internal_catch (
tag=<error reading variable: Cannot access memory at address 0xffffffffffffffe6>, func=0x4d4a10 <command_loop_2>,
arg=12002370) at eval.c:963
#33 0x00000000004d6367 in command_loop () at keyboard.c:1142
#34 recursive_edit_1 () at keyboard.c:774
#35 0x00000000004d6694 in Frecursive_edit () at keyboard.c:838
#36 0x0000000000410865 in main (argc=2, argv=<optimized out>) at emacs.c:1560
Lisp Backtrace:
"browse-url-xdg-open" (0xffffcb68)
"apply" (0xffffcb60)
"browse-url-default-browser" (0xffffce68)
"apply" (0xffffce60)
"browse-url" (0xffffd038)
"call-interactively" (0xffffd2b8)
"command-execute" (0xffffd3c0)
"execute-extended-command" (0xffffd5a8)
"call-interactively" (0xffffd828)
(gdb)
--8<---------------cut here---------------end--------------->8---
--
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Emacs-24.3 crash when browse-url
2012-12-04 13:26 Emacs-24.3 crash when browse-url Thierry Volpiatto
@ 2012-12-04 13:40 ` Andreas Schwab
2012-12-04 14:29 ` Thierry Volpiatto
2012-12-04 14:57 ` Thierry Volpiatto
0 siblings, 2 replies; 16+ messages in thread
From: Andreas Schwab @ 2012-12-04 13:40 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: emacs-devel
Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
> #2 0x00000000005804f4 in exec_byte_code (bytestr=6, vector=140737488341064, maxdepth=20,
> args_template=4611686019484352512, nargs=4611686018662268928, args=0x14) at bytecode.c:1955
Looks like you are having invalid byte code. How did you compile this?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Emacs-24.3 crash when browse-url
2012-12-04 13:40 ` Andreas Schwab
@ 2012-12-04 14:29 ` Thierry Volpiatto
2012-12-04 14:57 ` Thierry Volpiatto
1 sibling, 0 replies; 16+ messages in thread
From: Thierry Volpiatto @ 2012-12-04 14:29 UTC (permalink / raw)
To: Andreas Schwab; +Cc: emacs-devel
Andreas Schwab <schwab@linux-m68k.org> writes:
> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> #2 0x00000000005804f4 in exec_byte_code (bytestr=6, vector=140737488341064, maxdepth=20,
>> args_template=4611686019484352512, nargs=4611686018662268928, args=0x14) at bytecode.c:1955
>
> Looks like you are having invalid byte code. How did you compile this?
With make, probably I have to bootstrap?
will try, thanks.
--
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Emacs-24.3 crash when browse-url
2012-12-04 13:40 ` Andreas Schwab
2012-12-04 14:29 ` Thierry Volpiatto
@ 2012-12-04 14:57 ` Thierry Volpiatto
2012-12-04 15:01 ` Andreas Schwab
1 sibling, 1 reply; 16+ messages in thread
From: Thierry Volpiatto @ 2012-12-04 14:57 UTC (permalink / raw)
To: emacs-devel
Andreas Schwab <schwab@linux-m68k.org> writes:
> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> #2 0x00000000005804f4 in exec_byte_code (bytestr=6, vector=140737488341064, maxdepth=20,
>> args_template=4611686019484352512, nargs=4611686018662268928, args=0x14) at bytecode.c:1955
>
> Looks like you are having invalid byte code. How did you compile this?
Same crash happen after 'make bootstrap'.
--
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Emacs-24.3 crash when browse-url
2012-12-04 14:57 ` Thierry Volpiatto
@ 2012-12-04 15:01 ` Andreas Schwab
2012-12-04 15:13 ` Thierry Volpiatto
0 siblings, 1 reply; 16+ messages in thread
From: Andreas Schwab @ 2012-12-04 15:01 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: emacs-devel
Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
> Same crash happen after 'make bootstrap'.
Then you seem to have a bug in the byte compiler. Try compiling with
-DBYTE_CODE_SAFE.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Emacs-24.3 crash when browse-url
2012-12-04 15:01 ` Andreas Schwab
@ 2012-12-04 15:13 ` Thierry Volpiatto
2012-12-04 16:16 ` Andreas Schwab
0 siblings, 1 reply; 16+ messages in thread
From: Thierry Volpiatto @ 2012-12-04 15:13 UTC (permalink / raw)
To: Andreas Schwab; +Cc: emacs-devel
Andreas Schwab <schwab@linux-m68k.org> writes:
> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> Same crash happen after 'make bootstrap'.
>
> Then you seem to have a bug in the byte compiler. Try compiling with
> -DBYTE_CODE_SAFE.
Thanks, but can you provide more info on how to compile with this option?
--
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Emacs-24.3 crash when browse-url
2012-12-04 15:13 ` Thierry Volpiatto
@ 2012-12-04 16:16 ` Andreas Schwab
2012-12-04 16:40 ` Thierry Volpiatto
0 siblings, 1 reply; 16+ messages in thread
From: Andreas Schwab @ 2012-12-04 16:16 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: emacs-devel
Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>>
>>> Same crash happen after 'make bootstrap'.
>>
>> Then you seem to have a bug in the byte compiler. Try compiling with
>> -DBYTE_CODE_SAFE.
> Thanks, but can you provide more info on how to compile with this option?
Just like any other compiler flag, via CFLAGS.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Emacs-24.3 crash when browse-url
2012-12-04 16:16 ` Andreas Schwab
@ 2012-12-04 16:40 ` Thierry Volpiatto
2012-12-04 17:21 ` Stefan Monnier
0 siblings, 1 reply; 16+ messages in thread
From: Thierry Volpiatto @ 2012-12-04 16:40 UTC (permalink / raw)
To: Andreas Schwab; +Cc: emacs-devel
Andreas Schwab <schwab@linux-m68k.org> writes:
> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>
>>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>>>
>>>> Same crash happen after 'make bootstrap'.
>>>
>>> Then you seem to have a bug in the byte compiler. Try compiling with
>>> -DBYTE_CODE_SAFE.
>> Thanks, but can you provide more info on how to compile with this option?
>
> Just like any other compiler flag, via CFLAGS.
Ok thanks, it didn't crash but I have now an error:
--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (error "binding stack not balanced (serious byte compiler bug)")
browse-url-xdg-open("http://www.google.fr" nil)
apply(browse-url-xdg-open "http://www.google.fr" nil)
browse-url-default-browser("http://www.google.fr" nil)
apply(browse-url-default-browser "http://www.google.fr" nil)
browse-url("http://www.google.fr" nil)
call-interactively(browse-url record nil)
command-execute(browse-url record)
execute-extended-command(nil "browse-url")
call-interactively(execute-extended-command nil nil)
--8<---------------cut here---------------end--------------->8---
--
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Emacs-24.3 crash when browse-url
2012-12-04 16:40 ` Thierry Volpiatto
@ 2012-12-04 17:21 ` Stefan Monnier
2012-12-04 18:01 ` Thierry Volpiatto
0 siblings, 1 reply; 16+ messages in thread
From: Stefan Monnier @ 2012-12-04 17:21 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: Andreas Schwab, emacs-devel
> Debugger entered--Lisp error: (error "binding stack not balanced (serious byte compiler bug)")
> browse-url-xdg-open("http://www.google.fr" nil)
Hmm... Can you show us the result of
M-x disassemble RET browse-url-xdg-open RET
I suspect that your browse-url.elc file is somehow corrupted because
this function is very small and simple, so there's not much opportunity
for the byte-compiler to mess it up.
Stefan
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Emacs-24.3 crash when browse-url
2012-12-04 17:21 ` Stefan Monnier
@ 2012-12-04 18:01 ` Thierry Volpiatto
2012-12-04 18:45 ` Stefan Monnier
0 siblings, 1 reply; 16+ messages in thread
From: Thierry Volpiatto @ 2012-12-04 18:01 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Andreas Schwab, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Debugger entered--Lisp error: (error "binding stack not balanced (serious byte compiler bug)")
>> browse-url-xdg-open("http://www.google.fr" nil)
>
> Hmm... Can you show us the result of
>
> M-x disassemble RET browse-url-xdg-open RET
--8<---------------cut here---------------start------------->8---
byte code for browse-url-xdg-open:
doc: Pass the specified URL to the "xdg-open" command. ...
args: (url &optional ignored)
interactive: (browse-url-interactive-arg "URL: ")
0 constant call-process
1 constant "xdg-open"
2 constant nil
3 constant 0
4 constant nil
5 varref url
6 call 5
7 return
--8<---------------cut here---------------end--------------->8---
And while I am at it:
--8<---------------cut here---------------start------------->8---
byte code for browse-url-can-use-xdg-open:
doc: Return non-nil if the "xdg-open" program can be used. ...
args: nil
0 constant getenv
1 constant "DISPLAY"
2 call 1
3 goto-if-nil-else-pop 1
6 constant executable-find
7 constant "xdg-open"
8 call 1
9 goto-if-nil-else-pop 1
12 constant executable-find
13 constant "nohup"
14 call 1
15 goto-if-nil-else-pop 1
18 constant getenv
19 constant "GNOME_DESKTOP_SESSION_ID"
20 call 1
21 goto-if-not-nil-else-pop 1
24 constant nil
25 constant <byte code>
0 constant call-process
1 constant "dbus-send"
2 constant nil
3 dup
4 dup
5 constant "--dest=org.gnome.SessionManager"
6 constant "--print-reply"
7 constant "/org/gnome/SessionManager"
8 constant "org.gnome.SessionManager.CanShutdown"
9 call 8
11 constant 0
12 eq
13 return
26 constant ((error))
27 condition-case
28 goto-if-not-nil-else-pop 1
31 constant getenv
32 constant "KDE_FULL_SESSION"
33 call 1
34 constant "true"
35 equal
36 goto-if-not-nil-else-pop 1
39 constant nil
40 constant <byte code>
0 constant call-process
1 constant "/bin/sh"
2 constant nil
3 dup
4 dup
5 constant "-c"
6 constant "xprop -root _DT_SAVE_MODE|grep xfce4"
7 call 6
9 constant 0
10 eq
11 return
41 constant ((error))
42 condition-case
43 goto-if-not-nil-else-pop 1
46 constant getenv
47 constant "DESKTOP_SESSION"
48 call 1
49 constant ("LXDE" "Lubuntu")
50 member
51 goto-if-not-nil-else-pop 1
54 constant getenv
55 constant "XDG_CURRENT_DESKTOP"
56 call 1
57 constant "LXDE"
58 equal
59:1 return
--8<---------------cut here---------------end--------------->8---
> I suspect that your browse-url.elc file is somehow corrupted because
> this function is very small and simple, so there's not much opportunity
> for the byte-compiler to mess it up.
Why would it be corrupted ?
--
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Emacs-24.3 crash when browse-url
2012-12-04 18:01 ` Thierry Volpiatto
@ 2012-12-04 18:45 ` Stefan Monnier
2012-12-04 20:31 ` Thierry Volpiatto
0 siblings, 1 reply; 16+ messages in thread
From: Stefan Monnier @ 2012-12-04 18:45 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: Andreas Schwab, emacs-devel
>>> Debugger entered--Lisp error: (error "binding stack not balanced (serious byte compiler bug)")
>>> browse-url-xdg-open("http://www.google.fr" nil)
>> M-x disassemble RET browse-url-xdg-open RET
> --8<---------------cut here---------------start------------->8---
> byte code for browse-url-xdg-open:
> doc: Pass the specified URL to the "xdg-open" command. ...
> args: (url &optional ignored)
> interactive: (browse-url-interactive-arg "URL: ")
> 0 constant call-process
> 1 constant "xdg-open"
> 2 constant nil
> 3 constant 0
> 4 constant nil
> 5 varref url
> 6 call 5
> 7 return
> --8<---------------cut here---------------end--------------->8---
Hmm... "binding stack not balanced (serious byte compiler bug)" means
that the specpdl stack (the stack of things that need to be unwound,
such as unwind-protects and dynamic let bindings) does not have the same
height at the end of (presumably) browse-url-xdg-open as it had at
the beginning. But as we see above, browse-url-xdg-open does not push
nor pop anything to/from that stack (it does push constants onto the
bytecode's execution stack, but that's a completely different stack).
So, the specpdl stack was somehow messed up, presumably during the
execution of browse-url-xdg-open but apparently not by the byte code of
browse-url-xdg-open. It could be a problem in `call-process'.
>> I suspect that your browse-url.elc file is somehow corrupted because
>> this function is very small and simple, so there's not much opportunity
>> for the byte-compiler to mess it up.
> Why would it be corrupted ?
No idea, it was just a shot in the dark, but the disassembly seems to
indicate it's not corrupted.
Stefan
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Emacs-24.3 crash when browse-url
2012-12-04 18:45 ` Stefan Monnier
@ 2012-12-04 20:31 ` Thierry Volpiatto
2012-12-04 21:19 ` Andreas Schwab
2012-12-04 21:21 ` Stefan Monnier
0 siblings, 2 replies; 16+ messages in thread
From: Thierry Volpiatto @ 2012-12-04 20:31 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Andreas Schwab, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>> Debugger entered--Lisp error: (error "binding stack not balanced (serious byte compiler bug)")
>>>> browse-url-xdg-open("http://www.google.fr" nil)
>>> M-x disassemble RET browse-url-xdg-open RET
>> --8<---------------cut here---------------start------------->8---
>> byte code for browse-url-xdg-open:
>> doc: Pass the specified URL to the "xdg-open" command. ...
>> args: (url &optional ignored)
>> interactive: (browse-url-interactive-arg "URL: ")
>> 0 constant call-process
>> 1 constant "xdg-open"
>> 2 constant nil
>> 3 constant 0
>> 4 constant nil
>> 5 varref url
>> 6 call 5
>> 7 return
>> --8<---------------cut here---------------end--------------->8---
>
> Hmm... "binding stack not balanced (serious byte compiler bug)" means
> that the specpdl stack (the stack of things that need to be unwound,
> such as unwind-protects and dynamic let bindings) does not have the same
> height at the end of (presumably) browse-url-xdg-open as it had at
> the beginning. But as we see above, browse-url-xdg-open does not push
> nor pop anything to/from that stack (it does push constants onto the
> bytecode's execution stack, but that's a completely different stack).
Thanks for explanation.
> So, the specpdl stack was somehow messed up, presumably during the
> execution of browse-url-xdg-open but apparently not by the byte code of
> browse-url-xdg-open. It could be a problem in `call-process'.
Ok, here the last working revision:
--8<---------------cut here---------------start------------->8---
changeset: 123952:4d87702c495a
user: Paul Eggert <eggert@cs.ucla.edu>
date: Mon Dec 03 13:07:47 2012 -0800
summary: * bytecode.c, lisp.h (Qbytecode): Remove.
--8<---------------cut here---------------end--------------->8---
And the crash reappear when I compile from here:
--8<---------------cut here---------------start------------->8---
changeset: 123953:342630a53fea
user: Paul Eggert <eggert@cs.ucla.edu>
date: Mon Dec 03 13:42:12 2012 -0800
summary: Don't let call-process be a zombie factory.
--8<---------------cut here---------------end--------------->8---
Hope that help.
--
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Emacs-24.3 crash when browse-url
2012-12-04 20:31 ` Thierry Volpiatto
@ 2012-12-04 21:19 ` Andreas Schwab
2012-12-05 19:44 ` Thierry Volpiatto
2012-12-04 21:21 ` Stefan Monnier
1 sibling, 1 reply; 16+ messages in thread
From: Andreas Schwab @ 2012-12-04 21:19 UTC (permalink / raw)
To: Thierry Volpiatto; +Cc: Stefan Monnier, emacs-devel
Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
> And the crash reappear when I compile from here:
>
> changeset: 123953:342630a53fea
> user: Paul Eggert <eggert@cs.ucla.edu>
> date: Mon Dec 03 13:42:12 2012 -0800
> summary: Don't let call-process be a zombie factory.
Thanks, should be fixed now.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Emacs-24.3 crash when browse-url
2012-12-04 21:19 ` Andreas Schwab
@ 2012-12-05 19:44 ` Thierry Volpiatto
0 siblings, 0 replies; 16+ messages in thread
From: Thierry Volpiatto @ 2012-12-05 19:44 UTC (permalink / raw)
To: emacs-devel
Andreas Schwab <schwab@linux-m68k.org> writes:
> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> And the crash reappear when I compile from here:
>>
>> changeset: 123953:342630a53fea
>> user: Paul Eggert <eggert@cs.ucla.edu>
>> date: Mon Dec 03 13:42:12 2012 -0800
>> summary: Don't let call-process be a zombie factory.
>
> Thanks, should be fixed now.
Indeed fixed, thanks for your quick fix.
--
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Emacs-24.3 crash when browse-url
2012-12-04 20:31 ` Thierry Volpiatto
2012-12-04 21:19 ` Andreas Schwab
@ 2012-12-04 21:21 ` Stefan Monnier
2012-12-05 10:23 ` Paul Eggert
1 sibling, 1 reply; 16+ messages in thread
From: Stefan Monnier @ 2012-12-04 21:21 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel, Andreas Schwab, Thierry Volpiatto
Paul, can you take a look at this?
>>>>> Debugger entered--Lisp error: (error "binding stack not balanced (serious byte compiler bug)")
>>>>> browse-url-xdg-open("http://www.google.fr" nil)
>>>> M-x disassemble RET browse-url-xdg-open RET
>>> --8<---------------cut here---------------start------------->8---
>>> byte code for browse-url-xdg-open:
>>> doc: Pass the specified URL to the "xdg-open" command. ...
>>> args: (url &optional ignored)
>>> interactive: (browse-url-interactive-arg "URL: ")
>>> 0 constant call-process
>>> 1 constant "xdg-open"
>>> 2 constant nil
>>> 3 constant 0
>>> 4 constant nil
>>> 5 varref url
>>> 6 call 5
>>> 7 return
>>> --8<---------------cut here---------------end--------------->8---
>>
>> Hmm... "binding stack not balanced (serious byte compiler bug)" means
>> that the specpdl stack (the stack of things that need to be unwound,
>> such as unwind-protects and dynamic let bindings) does not have the same
>> height at the end of (presumably) browse-url-xdg-open as it had at
>> the beginning. But as we see above, browse-url-xdg-open does not push
>> nor pop anything to/from that stack (it does push constants onto the
>> bytecode's execution stack, but that's a completely different stack).
> Thanks for explanation.
My pleasure.
>> So, the specpdl stack was somehow messed up, presumably during the
>> execution of browse-url-xdg-open but apparently not by the byte code of
>> browse-url-xdg-open. It could be a problem in `call-process'.
> Ok, here the last working revision:
> --8<---------------cut here---------------start------------->8---
> changeset: 123952:4d87702c495a
> user: Paul Eggert <eggert@cs.ucla.edu>
> date: Mon Dec 03 13:07:47 2012 -0800
> summary: * bytecode.c, lisp.h (Qbytecode): Remove.
> --8<---------------cut here---------------end--------------->8---
> And the crash reappear when I compile from here:
> --8<---------------cut here---------------start------------->8---
> changeset: 123953:342630a53fea
> user: Paul Eggert <eggert@cs.ucla.edu>
> date: Mon Dec 03 13:42:12 2012 -0800
> summary: Don't let call-process be a zombie factory.
> --8<---------------cut here---------------end--------------->8---
Aha!
Stefan
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2012-12-05 19:44 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-12-04 13:26 Emacs-24.3 crash when browse-url Thierry Volpiatto
2012-12-04 13:40 ` Andreas Schwab
2012-12-04 14:29 ` Thierry Volpiatto
2012-12-04 14:57 ` Thierry Volpiatto
2012-12-04 15:01 ` Andreas Schwab
2012-12-04 15:13 ` Thierry Volpiatto
2012-12-04 16:16 ` Andreas Schwab
2012-12-04 16:40 ` Thierry Volpiatto
2012-12-04 17:21 ` Stefan Monnier
2012-12-04 18:01 ` Thierry Volpiatto
2012-12-04 18:45 ` Stefan Monnier
2012-12-04 20:31 ` Thierry Volpiatto
2012-12-04 21:19 ` Andreas Schwab
2012-12-05 19:44 ` Thierry Volpiatto
2012-12-04 21:21 ` Stefan Monnier
2012-12-05 10:23 ` Paul Eggert
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).