unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Markus Triska <markus.triska@gmx.at>
To: emacs-pretest-bug@gnu.org
Subject: bug#1812: 23.0.60; OSX: server crashes on client quit when built without X toolkit
Date: Tue,  6 Jan 2009 22:27:04 +0100 (CET)	[thread overview]
Message-ID: <20090106212704.00398C2A6E7@mt-computer.local> (raw)


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








             reply	other threads:[~2009-01-06 21:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <wlhbzi9bf7.wl%mituharu@math.s.chiba-u.ac.jp>
2009-01-06 21:27 ` Markus Triska [this message]
2009-01-07 18:45   ` bug#1812: 23.0.60; OSX: server crashes on client quit when built without X toolkit Dan Nicolaescu
2009-05-19  0:40   ` bug#1812: marked as done (23.0.60; OSX: server crashes on client quit when built without X toolkit) Emacs bug Tracking System

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=20090106212704.00398C2A6E7@mt-computer.local \
    --to=markus.triska@gmx.at \
    --cc=1812@emacsbugs.donarmstrong.com \
    --cc=emacs-pretest-bug@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 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).