* 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 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
* Re: Emacs-24.3 crash when browse-url
2012-12-04 21:21 ` Stefan Monnier
@ 2012-12-05 10:23 ` Paul Eggert
0 siblings, 0 replies; 16+ messages in thread
From: Paul Eggert @ 2012-12-05 10:23 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel, Andreas Schwab, Thierry Volpiatto
On 12/04/2012 01:21 PM, Stefan Monnier wrote:
> Paul, can you take a look at this?
Andreas fixed the bug already. His fix suggests some
relatively minor cleanups (a file descriptor can be
closed twice in some rare error conditions) which I'll
look into adding soon.
Thanks, Andreas!
^ 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
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 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.