unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: owner@emacsbugs.donarmstrong.com (Emacs bug Tracking System)
To: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
Subject: bug#1812: marked as done (23.0.60; OSX: server crashes on client  quit when built without X toolkit)
Date: Tue, 19 May 2009 00:40:06 +0000	[thread overview]
Message-ID: <handler.1812.D1812.124269336121425.ackdone@emacsbugs.donarmstrong.com> (raw)
In-Reply-To: 20090106212704.00398C2A6E7@mt-computer.local

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]


Your message dated Tue, 19 May 2009 09:35:56 +0900
with message-id <wlhbzi9bf7.wl%mituharu@math.s.chiba-u.ac.jp>
and subject line Re: bug#1812: 23.0.60;	OSX: server crashes on client quit when built without X toolkit
has caused the Emacs bug report #1812,
regarding 23.0.60; OSX: server crashes on client quit when built without X toolkit
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
1812: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1812
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 11109 bytes --]

From: Markus Triska <markus.triska@gmx.at>
To: emacs-pretest-bug@gnu.org
Subject: 23.0.60; OSX: server crashes on client quit when built without X toolkit
Date: Tue,  6 Jan 2009 22:27:04 +0100 (CET)
Message-ID: <20090106212704.00398C2A6E7@mt-computer.local>


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





[-- Attachment #3: Type: message/rfc822, Size: 1974 bytes --]

From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
To: 1812-done@emacsbugs.donarmstrong.com
Subject: Re: bug#1812: 23.0.60;	OSX: server crashes on client quit when built without X toolkit
Date: Tue, 19 May 2009 09:35:56 +0900
Message-ID: <wlhbzi9bf7.wl%mituharu@math.s.chiba-u.ac.jp>

Fixed with the following change.

2009-05-19  YAMAMOTO Mitsuharu  <mituharu@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


      parent reply	other threads:[~2009-05-19  0:40 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 ` bug#1812: 23.0.60; OSX: server crashes on client quit when built without X toolkit Markus Triska
2009-01-07 18:45   ` Dan Nicolaescu
2009-05-19  0:40   ` Emacs bug Tracking System [this message]

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=handler.1812.D1812.124269336121425.ackdone@emacsbugs.donarmstrong.com \
    --to=owner@emacsbugs.donarmstrong.com \
    --cc=mituharu@math.s.chiba-u.ac.jp \
    /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).