From: Adrian Robert <adrian.b.robert@gmail.com>
To: Dan Nicolaescu <dann@ics.uci.edu>
Cc: 1107@emacsbugs.donarmstrong.com, William Farrington <wfarr@gatech.edu>
Subject: bug#1107: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs
Date: Tue, 25 Nov 2008 09:47:03 -0500 [thread overview]
Message-ID: <C9836674-C9AD-44D1-89BF-3E34DBA177DB@gmail.com> (raw)
In-Reply-To: <200811250620.mAP6KrBx009202@mothra.ics.uci.edu>
On Nov 25, 2008, at 1:20 AM, Dan Nicolaescu wrote:
> Adrian Robert <adrian.b.robert@gmail.com> writes:
>
>> I just tried to replicate this locally and failed. No crash.
>> However, it also doesn't work -- emacsclient just always says "can't
>> find socket; have you started the server?".
>>
>> This is new. Emacsclient always worked before, up to and including
>> multi-tty. Could something in the new daemon support have affected
>> this? Was there anything in particular that changed as far as how
>> the
>> client and server communicate?
>>
>> gnuserv, which I use, still works.
>
> Can you please clarify, if you are doing
>
> emacs --daemon
>
> then you can connect with gnuclient, but cannot with emacsclient?
I'm trying emacs -Q/-q/normal --daemon, or "run emacs -Q/-q/normal [no
opts] + M-x server-start". All give the same result of no socket
found for emacsclient. If I start emacs (-q/-Q/normal) and do "M-x
gnuserv-start", then gnuclient works.
Now I just tried on X11 on Mac, and it works, although there is a
delay of seconds the first time emacsclient is run before the file
shows up in emacs.
And, I tried under --enable-cocoa-experimenal-ctrl-g and got the same
behavior, with these exceptions:
- if there is an emacs window active (no --daemon) the mouse must be
moved over emacs to get it to pick up the file -- the first time, but
not subsequent times
- if there is no window active, a crash ensues, sometimes after a
pause (stack trace below)
Some of this difference must have something to do with how the socket
event works its way into the input loop, maybe only for the first
event. If you can summarize what changed in this area with the new
impl it would help me look into it.
thanks,
Adrian
---------------------
#0 0x9210837c in __CFRunLoopFindMode ()
#1 0x92109f78 in CFRunLoopAddSource ()
#2 0x9211132c in CFSetApplyFunction ()
#3 0x92109f5c in CFRunLoopAddSource ()
#4 0x920eabf4 in CFMachPortCreateWithPort ()
#5 0x920eacc8 in CFMachPortCreate ()
#6 0x920edb64 in _CFXNotificationCenterCreate ()
#7 0x920edc60 in _CFXNotificationGetHostCenter ()
#8 0x91ba71c4 in +[NSDistributedNotificationCenter
notificationCenterForType:] ()
#9 0x952095f8 in +[NSDynamicSystemColor initialize] ()
#10 0x932a9ab4 in _class_initialize ()
#11 0x932a8010 in _class_lookupMethodAndLoadCache ()
#12 0x932ba0c8 in objc_msgSend ()
#13 0x95208f10 in +[NSApplication initialize] ()
#14 0x932a9ab4 in _class_initialize ()
#15 0x932a9934 in _class_initialize ()
#16 0x932a8010 in _class_lookupMethodAndLoadCache ()
#17 0x932ba0c8 in objc_msgSend ()
#18 0x0016a760 in ns_term_init (display_name=33765435) at nsterm.m:3736
#19 0x0017a0cc in Fx_open_connection (display=33765435,
resource_string=<value temporarily unavailable, due to optimizations>,
must_succeed=25165881) at nsfns.m:1762
#20 0x00107fc8 in Ffuncall (nargs=<value temporarily unavailable, due
to optimizations>, args=<value temporarily unavailable, due to
optimizations>) at eval.c:3050
#21 0x00142c9c in Fbyte_code (bytestr=<value temporarily unavailable,
due to optimizations>, vector=<value temporarily unavailable, due to
optimizations>, maxdepth=48) at bytecode.c:678
#22 0x00107a1c in funcall_lambda (fun=2495124, nargs=0,
arg_vector=0xbfffb604) at eval.c:3231
#23 0x0010813c in Ffuncall (nargs=<value temporarily unavailable, due
to optimizations>, args=<value temporarily unavailable, due to
optimizations>) at eval.c:3101
#24 0x00142c9c in Fbyte_code (bytestr=<value temporarily unavailable,
due to optimizations>, vector=<value temporarily unavailable, due to
optimizations>, maxdepth=32) at bytecode.c:678
#25 0x00107a1c in funcall_lambda (fun=2284540, nargs=2,
arg_vector=0xbfffb7e4) at eval.c:3231
#26 0x0010813c in Ffuncall (nargs=<value temporarily unavailable, due
to optimizations>, args=<value temporarily unavailable, due to
optimizations>) at eval.c:3101
#27 0x00142c9c in Fbyte_code (bytestr=<value temporarily unavailable,
due to optimizations>, vector=<value temporarily unavailable, due to
optimizations>, maxdepth=40) at bytecode.c:678
#28 0x00107a1c in funcall_lambda (fun=8747220, nargs=3,
arg_vector=0xbfffb9d4) at eval.c:3231
#29 0x0010813c in Ffuncall (nargs=<value temporarily unavailable, due
to optimizations>, args=<value temporarily unavailable, due to
optimizations>) at eval.c:3101
#30 0x00142c9c in Fbyte_code (bytestr=<value temporarily unavailable,
due to optimizations>, vector=<value temporarily unavailable, due to
optimizations>, maxdepth=136) at bytecode.c:678
#31 0x001071fc in Feval (form=<value temporarily unavailable, due to
optimizations>) at eval.c:2381
#32 0x0010a1f4 in internal_lisp_condition_case (var=25503185,
bodyform=8098837, handlers=8098077) at eval.c:1456
#33 0x00143690 in Fbyte_code (bytestr=<value temporarily unavailable,
due to optimizations>, vector=<value temporarily unavailable, due to
optimizations>, maxdepth=48) at bytecode.c:868
#34 0x001071fc in Feval (form=<value temporarily unavailable, due to
optimizations>) at eval.c:2381
#35 0x00105820 in internal_catch (tag=<value temporarily unavailable,
due to optimizations>, func=0x106d60 <Feval>, arg=8100637) at eval.c:
1247
#36 0x00143648 in Fbyte_code (bytestr=<value temporarily unavailable,
due to optimizations>, vector=<value temporarily unavailable, due to
optimizations>, maxdepth=16) at bytecode.c:853
#37 0x00107a1c in funcall_lambda (fun=8749588, nargs=2,
arg_vector=0xbfffc604) at eval.c:3231
#38 0x0010813c in Ffuncall (nargs=<value temporarily unavailable, due
to optimizations>, args=<value temporarily unavailable, due to
optimizations>) at eval.c:3101
#39 0x00109d3c in Fapply (nargs=2, args=0xbfffc688) at eval.c:2532
#40 0x00109db4 in apply1 (fn=51659257, arg=<value temporarily
unavailable, due to optimizations>) at eval.c:2793
#41 0x0010553c in internal_condition_case_1 (bfun=0x1483a0
<read_process_output_call>, arg=7822085, handlers=25205497,
hfun=0x1483b0 <read_process_output_error_handler>) at eval.c:1559
#42 0x00148a94 in read_process_output (proc=8574004, channel=<value
temporarily unavailable, due to optimizations>) at process.c:5341
#43 0x0014ef18 in wait_reading_process_output (time_limit=0,
microsecs=0, read_kbd=<value temporarily unavailable, due to
optimizations>, do_display=1, wait_for_cell=25165833, wait_proc=0x0,
just_wait_proc=0) at process.c:4994
#44 0x0009c5bc in read_char (commandflag=1, nmaps=2, maps=0xbfffe520,
prev_event=25165833, used_mouse_menu=0xbfffe58c, end_time=0x0) at
keyboard.c:4038
#45 0x0009f4fc in read_key_sequence (keybuf=0xbfffe698, bufsize=30,
prompt=25165833, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at keyboard.c:9344
#46 0x000a16a8 in command_loop_1 () at keyboard.c:1621
#47 0x00105998 in internal_condition_case (bfun=0xa1260
<command_loop_1>, handlers=25205497, hfun=0x98820 <cmd_error>) at
eval.c:1511
#48 0x00091de0 in command_loop_2 () at keyboard.c:1338
#49 0x00105820 in internal_catch (tag=<value temporarily unavailable,
due to optimizations>, func=0x91da0 <command_loop_2>, arg=25165833) at
eval.c:1247
#50 0x00091a90 in command_loop () at keyboard.c:1317
#51 0x00091bb8 in recursive_edit_1 () at keyboard.c:942
#52 0x00091d44 in Frecursive_edit () at keyboard.c:1004
#53 0x00091390 in main (argc=<value temporarily unavailable, due to
optimizations>, argv=0xbffff148) at emacs.c:1777
Lisp Backtrace:
Unsafe to call functions on thread 1: function:
_class_lookupMethodAndLoadCache on stack
"x-open-connection" (0xbfffb414)
"ns-initialize-window-system" (0xbfffb604)
"make-frame-on-display" (0xbfffb7e4)
"server-create-window-system-frame" (0xbfffb9d4)
"byte-code" (0xbfffbae4)
"byte-code" (0xbfffbff4)
"server-process-filter" (0xbfffc604)
next prev parent reply other threads:[~2008-11-25 14:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-25 4:17 bug#1107: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs Adrian Robert
2008-11-25 6:20 ` Dan Nicolaescu
2008-11-25 14:47 ` Adrian Robert [this message]
2008-11-25 15:27 ` Dan Nicolaescu
2008-11-25 20:08 ` Adrian Robert
2008-11-25 20:34 ` Dan Nicolaescu
2008-11-25 21:15 ` Adrian Robert
2008-11-25 21:24 ` Adrian Robert
-- strict thread matches above, loose matches on Subject: below --
2008-12-10 4:18 Adrian Robert
2008-12-10 6:58 ` Dan Nicolaescu
2008-12-10 15:27 ` Adrian Robert
2008-12-11 16:22 ` Stefan Monnier
2008-12-11 16:21 ` Stefan Monnier
2008-11-25 3:47 Adrian Robert
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C9836674-C9AD-44D1-89BF-3E34DBA177DB@gmail.com \
--to=adrian.b.robert@gmail.com \
--cc=1107@emacsbugs.donarmstrong.com \
--cc=dann@ics.uci.edu \
--cc=wfarr@gatech.edu \
/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 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.