GNU bug report logs -
#1812
23.0.60; OSX: server crashes on client quit when built without X toolkit
Previous Next
Reported by: Markus Triska <markus.triska <at> gmx.at>
Date: Tue, 6 Jan 2009 21:35:05 UTC
Severity: normal
Done: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 1812 in the body.
You can then email your comments to 1812 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#1812
; Package
emacs
.
(Tue, 06 Jan 2009 21:35:05 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Markus Triska <markus.triska <at> gmx.at>
:
New bug report received and forwarded. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Tue, 06 Jan 2009 21:35:05 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
After building Emacs without X toolkit, when I do:
$ emacs -nw -Q -f server-start
$ emacsclient -c -e "(save-buffers-kill-terminal)"
the server crashes with the backtrace below. As previously in #581, I
cannot reproduce the problem when I comment out the call of
XrmDestroyDatabase in xterm.c. If I do that, I occasionally get:
*ERROR*: X protocol error: BadLength (poly request too large or
internal Xlib length error) on protocol request 7
when starting emacsclient -c, and on the next try it works again.
The full backtrace is available from:
http://www.logic.at/prolog/btfull20090106.txt
and the regular version is:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x85003389
0x0122a7ad in DestroyNTable ()
(gdb) bt
#0 0x0122a7ad in DestroyNTable ()
#1 0x0122a7c1 in DestroyNTable ()
#2 0x0122a7c1 in DestroyNTable ()
#3 0x0122a7c1 in DestroyNTable ()
#4 0x0122a873 in XrmDestroyDatabase ()
#5 0x0009629b in x_delete_display (dpyinfo=0x2066ed0) at xterm.c:10521
#6 0x0009641c in x_delete_terminal (terminal=0x2067080) at xterm.c:10656
#7 0x00080725 in Fdelete_terminal (terminal=33976452, force=50332729) at terminal.c:334
#8 0x00010357 in delete_frame (frame=34031764, force=50332729) at frame.c:1505
#9 0x00149e5c in Ffuncall (nargs=2, args=0xbfffc110) at eval.c:3054
#10 0x0018339f in Fbyte_code (bytestr=68101411, vector=33867188, maxdepth=6) at bytecode.c:678
#11 0x0014973f in funcall_lambda (fun=33843028, nargs=1, arg_vector=0xbfffc2a4) at eval.c:3231
#12 0x00149c22 in Ffuncall (nargs=2, args=0xbfffc2a0) at eval.c:3101
#13 0x0018339f in Fbyte_code (bytestr=50981563, vector=33914500, maxdepth=3) at bytecode.c:678
#14 0x0014973f in funcall_lambda (fun=33915444, nargs=2, arg_vector=0xbfffc424) at eval.c:3231
#15 0x00149c22 in Ffuncall (nargs=3, args=0xbfffc420) at eval.c:3101
#16 0x0018339f in Fbyte_code (bytestr=2069731, vector=2069748, maxdepth=4) at bytecode.c:678
#17 0x0014973f in funcall_lambda (fun=2069684, nargs=0, arg_vector=0xbfffc530) at eval.c:3231
#18 0x001499aa in apply_lambda (fun=2069684, args=50332681, eval_flag=1) at eval.c:3155
#19 0x001490f4 in Feval (form=30668741) at eval.c:2435
#20 0x00149e35 in Ffuncall (nargs=2, args=0xbfffc690) at eval.c:3050
#21 0x0018339f in Fbyte_code (bytestr=67908323, vector=33919252, maxdepth=7) at bytecode.c:678
#22 0x0014973f in funcall_lambda (fun=33913204, nargs=2, arg_vector=0xbfffc824) at eval.c:3231
#23 0x00149c22 in Ffuncall (nargs=3, args=0xbfffc820) at eval.c:3101
#24 0x0018339f in Fbyte_code (bytestr=67758419, vector=33925812, maxdepth=3) at bytecode.c:678
#25 0x0014973f in funcall_lambda (fun=33926756, nargs=1, arg_vector=0xbfffca14) at eval.c:3231
#26 0x00149c22 in Ffuncall (nargs=2, args=0xbfffca10) at eval.c:3101
#27 0x0014b45f in Fapply (nargs=3, args=0xbfffca10) at eval.c:2473
#28 0x00149424 in Feval (form=30622269) at eval.c:2348
#29 0x00149648 in Fprogn (args=30622277) at eval.c:449
#30 0x001498e6 in funcall_lambda (fun=30622288, nargs=0, arg_vector=0xbfffcc28) at eval.c:3224
#31 0x00149c22 in Ffuncall (nargs=1, args=0xbfffcc24) at eval.c:3101
#32 0x00149dc7 in Ffuncall (nargs=2, args=0xbfffcc20) at eval.c:3025
#33 0x0014b037 in call1 (fn=50422177, arg1=30622293) at eval.c:2829
#34 0x0015330b in mapcar1 (leni=1, vals=0x0, fn=50422177, seq=30622301) at fns.c:2496
#35 0x001536be in Fmapc (function=50422177, sequence=30622301) at fns.c:2588
#36 0x00149e5c in Ffuncall (nargs=3, args=0xbfffcd30) at eval.c:3054
#37 0x0018339f in Fbyte_code (bytestr=67734947, vector=33910004, maxdepth=4) at bytecode.c:678
#38 0x0014930a in Feval (form=30543925) at eval.c:2385
#39 0x0014b8f3 in internal_lisp_condition_case (var=50365641, bodyform=30543925, handlers=30565269) at eval.c:1456
#40 0x001822d5 in Fbyte_code (bytestr=67735107, vector=33820420, maxdepth=3) at bytecode.c:868
#41 0x0014973f in funcall_lambda (fun=33854500, nargs=7, arg_vector=0xbfffd0d4) at eval.c:3231
#42 0x00149c22 in Ffuncall (nargs=8, args=0xbfffd0d0) at eval.c:3101
#43 0x0018339f in Fbyte_code (bytestr=67744291, vector=33811876, maxdepth=8) at bytecode.c:678
#44 0x0014973f in funcall_lambda (fun=33945108, nargs=8, arg_vector=0xbfffd2d4) at eval.c:3231
#45 0x00149c22 in Ffuncall (nargs=9, args=0xbfffd2d0) at eval.c:3101
#46 0x0014b45f in Fapply (nargs=10, args=0xbfffd2d0) at eval.c:2473
#47 0x00149424 in Feval (form=30668613) at eval.c:2348
#48 0x00149648 in Fprogn (args=30668621) at eval.c:449
#49 0x001498e6 in funcall_lambda (fun=30668632, nargs=0, arg_vector=0xbfffd494) at eval.c:3224
#50 0x00149c22 in Ffuncall (nargs=1, args=0xbfffd490) at eval.c:3101
#51 0x00149424 in Feval (form=30550437) at eval.c:2348
#52 0x0014b8f3 in internal_lisp_condition_case (var=50332681, bodyform=30550437, handlers=30546301) at eval.c:1456
#53 0x001822d5 in Fbyte_code (bytestr=67814611, vector=33883060, maxdepth=4) at bytecode.c:868
#54 0x0014973f in funcall_lambda (fun=33922004, nargs=1, arg_vector=0xbfffd784) at eval.c:3231
#55 0x00149c22 in Ffuncall (nargs=2, args=0xbfffd780) at eval.c:3101
#56 0x0018339f in Fbyte_code (bytestr=67775219, vector=33702836, maxdepth=17) at bytecode.c:678
#57 0x0014930a in Feval (form=30542469) at eval.c:2385
#58 0x0014b8f3 in internal_lisp_condition_case (var=50365641, bodyform=30542469, handlers=30564237) at eval.c:1456
#59 0x001822d5 in Fbyte_code (bytestr=67812819, vector=33904660, maxdepth=6) at bytecode.c:868
#60 0x0014930a in Feval (form=30544421) at eval.c:2385
#61 0x00147bfe in internal_catch (tag=68243913, func=0x148efa <Feval>, arg=30544421) at eval.c:1247
#62 0x00182185 in Fbyte_code (bytestr=67812883, vector=33883108, maxdepth=2) at bytecode.c:853
#63 0x0014973f in funcall_lambda (fun=33904820, nargs=2, arg_vector=0xbfffdd74) at eval.c:3231
#64 0x00149c22 in Ffuncall (nargs=3, args=0xbfffdd70) at eval.c:3101
#65 0x0014b442 in Fapply (nargs=2, args=0xbfffde00) at eval.c:2532
#66 0x0014b59d in apply1 (fn=68250369, arg=30624237) at eval.c:2796
#67 0x001866da in read_process_output_call (fun_and_args=30624245) at process.c:5154
#68 0x00147d20 in internal_condition_case_1 (bfun=0x1866bd <read_process_output_call>, arg=30624245, handlers=50372345, hfun=0x1866dc <read_process_output_error_handler>) at eval.c:1559
#69 0x00186bdf in read_process_output (proc=33931380, channel=50372345) at process.c:5343
#70 0x0018cb26 in wait_reading_process_output (time_limit=0, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=50332681, wait_proc=0x0, just_wait_proc=0) at process.c:4996
#71 0x000e40c9 in read_char (commandflag=1, nmaps=4, maps=0xbffff4a0, prev_event=50332681, used_mouse_menu=0xbffff598, end_time=0x0) at keyboard.c:4052
#72 0x000e606a in read_key_sequence (keybuf=0xbffff658, bufsize=30, prompt=50332681, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9359
#73 0x000e848b in command_loop_1 () at keyboard.c:1632
#74 0x00147fac in internal_condition_case (bfun=0xe826d <command_loop_1>, handlers=50372345, hfun=0xe1080 <cmd_error>) at eval.c:1511
#75 0x000da3d4 in command_loop_2 () at keyboard.c:1349
#76 0x00147bfe in internal_catch (tag=50368417, func=0xda390 <command_loop_2>, arg=50332681) at eval.c:1247
#77 0x000da176 in command_loop () at keyboard.c:1328
#78 0x000da22f in recursive_edit_1 () at keyboard.c:942
#79 0x000da377 in Frecursive_edit () at keyboard.c:1004
#80 0x000d918c in main (argc=2, argv=0xbffffa94) at emacs.c:1786
Lisp Backtrace:
"delete-frame" (0xbfffc114)
"server-delete-client" (0xbfffc2a4)
"server-save-buffers-kill-terminal" (0xbfffc424)
"save-buffers-kill-terminal" (0xbfffc530)
"eval" (0xbfffc694)
"server-eval-and-print" (0xbfffc824)
0x205ae64 PVEC_COMPILED
"apply" (0xbfffca10)
0x1d34255 Lisp type 5
"funcall" (0xbfffcc24)
"mapc" (0xbfffcd34)
"byte-code" (0xbfffce24)
"server-execute" (0xbfffd0d4)
0x205f614 PVEC_COMPILED
"apply" (0xbfffd2d0)
0x1d3f75d Lisp type 5
"funcall" (0xbfffd490)
"server-execute-continuation" (0xbfffd784)
"byte-code" (0xbfffd8b4)
"byte-code" (0xbfffdae4)
"server-process-filter" (0xbfffdd74)
In GNU Emacs 23.0.60.1 (i386-apple-darwin8.11.1)
of 2009-01-06 on v254-051.vps.tuwien.ac.at
Windowing system distributor `The XFree86 Project, Inc', version 11.0.40400000
configured using `configure '--with-x-toolkit=no''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_GB.UTF-8
value of $XMODIFIERS: nil
locale-coding-system: nil
default-enable-multibyte-characters: t
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#1812
; Package
emacs
.
(Wed, 07 Jan 2009 18:55:04 GMT)
Full text and
rfc822 format available.
Message #8 received at 1812 <at> emacsbugs.donarmstrong.com (full text, mbox):
Markus Triska <markus.triska <at> gmx.at> writes:
> After building Emacs without X toolkit, when I do:
>
> $ emacs -nw -Q -f server-start
>
> $ emacsclient -c -e "(save-buffers-kill-terminal)"
>
> the server crashes with the backtrace below. As previously in #581, I
> cannot reproduce the problem when I comment out the call of
> XrmDestroyDatabase in xterm.c. If I do that, I occasionally get:
>
> *ERROR*: X protocol error: BadLength (poly request too large or
> internal Xlib length error) on protocol request 7
>
> when starting emacsclient -c, and on the next try it works again.
>
> The full backtrace is available from:
>
> http://www.logic.at/prolog/btfull20090106.txt
>
> and the regular version is:
I can't reproduce this on a Fedora10 machine...
Reply sent
to
YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
:
You have taken responsibility.
(Tue, 19 May 2009 00:40:06 GMT)
Full text and
rfc822 format available.
Notification sent
to
Markus Triska <markus.triska <at> gmx.at>
:
bug acknowledged by developer.
(Tue, 19 May 2009 00:40:06 GMT)
Full text and
rfc822 format available.
Message #13 received at 1812-done <at> emacsbugs.donarmstrong.com (full text, mbox):
Fixed with the following change.
2009-05-19 YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
* xterm.c (x_delete_display): Don't call XrmDestroyDatabase here.
(x_delete_terminal): Dissociate resource database from display and
then call XrmDestroyDatabase before closing display.
Cf. http://lists.gnu.org/archive/html/emacs-devel/2009-05/msg00263.html
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> emacsbugs.donarmstrong.com
.
(Tue, 16 Jun 2009 14:24:13 GMT)
Full text and
rfc822 format available.
This bug report was last modified 16 years and 8 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.