GNU bug report logs - #1107
23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 1107 in the body.
You can then email your comments to 1107 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: William Farrington <wfarr <at> gatech.edu>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X
Date: Tue, 7 Oct 2008 09:39:30 -0400

Using HEAD compiled with --with-ns, emacsclient crashes the running  
instance of emacs if it was started with the --daemon flag.


In GNU Emacs 23.0.60.1 (i386-apple-darwin9.5.0, *Step 9.0)
 of 2008-09-28 on Will-Farringtons-MacBook.local
Windowing system distributor `Apple', version 49.46.48
configured using `configure  '--with-ns''

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: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Major mode: rcirc

Minor modes in effect:
  rcirc-track-minor-mode: t
  global-hl-line-mode: t
  show-paren-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  use-hard-newlines: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r c i r c <return> C-x b t * <return> C-x b e m
<return> h m <return> m i n e SPC j u s t SPC c r a
s h e s SPC w h e n S-SPC I SPC t r y SPC t o SPC c
o n n e c t SPC o <backspace> t o SPC i t <return>
M-x b u <tab> <backspace> <backspace> s e n d - b u
<tab> C-g M-x r e p o <tab> r t <tab> <return>

Recent messages:
Starting new Ispell process [default] ...
Enabling Flyspell mode gave an error
Rcirc-Omit mode enabled
Starting new Ispell process [default] ...
Enabling Flyspell mode gave an error
Rcirc-Omit mode enabled
Making completion list...
Quit
Making completion list...
09:37:33 AM - abbe is calling your name in #emacs.

Message #8 received at 1107 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: William Farrington <wfarr <at> gatech.edu>
Cc: 1107 <at> debbugs.gnu.org
Subject: Re: bug#1107: 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X
Date: Tue, 7 Oct 2008 10:14:36 -0700 (PDT)

William Farrington <wfarr <at> gatech.edu> writes:

  > Using HEAD compiled with --with-ns, emacsclient crashes the running
  > instance of emacs if it was started with the --daemon flag.
  > 
  > 
  > In GNU Emacs 23.0.60.1 (i386-apple-darwin9.5.0, *Step 9.0)
  >  of 2008-09-28 on Will-Farringtons-MacBook.local
  > Windowing system distributor `Apple', version 49.46.48
  > configured using `configure  '--with-ns''

Can you please try to debug it?

First try:

emacs -Q --daemon

and then try to see if 

emacsclient -t

works.  If it doesn't please try to debug it.
If it does please try to debug why:

emacsclient -c 

crashes emacs. 

If nobody looks at this, I will disable the --daemon code for the
nextstep port before the release.

Message #15 received at 1107 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: 1107 <at> debbugs.gnu.org
Cc: Dan Nicolaescu <dann <at> ics.uci.edu>, William Farrington <wfarr <at> gatech.edu>
Subject: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs
Date: Mon, 24 Nov 2008 22:47:32 -0500

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.

Message #20 received at 1107 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: 1107 <at> debbugs.gnu.org
Cc: Dan Nicolaescu <dann <at> ics.uci.edu>, William Farrington <wfarr <at> gatech.edu>
Subject: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs
Date: Mon, 24 Nov 2008 23:17:42 -0500

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.

Message #23 received at 1107 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: 1107 <at> debbugs.gnu.org, William Farrington <wfarr <at> gatech.edu>
Subject: Re: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs
Date: Mon, 24 Nov 2008 22:20:53 -0800 (PST)

Adrian Robert <adrian.b.robert <at> 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?

Does that the same happen if you use

emacs -Q --daemon

?

Message #28 received at 1107 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: Dan Nicolaescu <dann <at> ics.uci.edu>
Cc: 1107 <at> debbugs.gnu.org, William Farrington <wfarr <at> gatech.edu>
Subject: Re: #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

On Nov 25, 2008, at 1:20 AM, Dan Nicolaescu wrote:

> Adrian Robert <adrian.b.robert <at> 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)

Message #31 received at 1107 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: 1107 <at> debbugs.gnu.org, William Farrington <wfarr <at> gatech.edu>
Subject: Re: #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 07:27:03 -0800 (PST)

Adrian Robert <adrian.b.robert <at> gmail.com> writes:

  > On Nov 25, 2008, at 1:20 AM, Dan Nicolaescu wrote:
  > 
  > > Adrian Robert <adrian.b.robert <at> 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.

Given that the problem also happens when NOT using --daemon, then the
problem is quite likely not caused by the --daemon changes, the changes
should not affect anything if --daemon is not used.

The daemon code was checked in on 2008-09-21, I'd recommend trying a
version before that date and see if you still have the problem.

You can also try to see if:

emacs -nw -Q --daemon

followed by:

emacsclient -t

also causes problems. 

The stack trace posted seems to be taken when using --daemon, one for
emacs -Q -f server-start  would be more helpful.

Message #36 received at 1107 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: Dan Nicolaescu <dann <at> ics.uci.edu>
Cc: 1107 <at> debbugs.gnu.org
Subject: Re: #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 15:08:31 -0500

OK, it seems that the NS GUI stuff cannot be used in a child process  
from fork():

http://developer.apple.com/ReleaseNotes/CoreFoundation/CoreFoundation.html

(search for "fork"):

> Due to the behavior of fork(), CoreFoundation cannot be used on the  
> child-side of fork(). If you fork(), you must follow that with an  
> exec*() call of some sort, and you should not use CoreFoundation  
> APIs within the child, before the exec*().

I put in a really ugly hack that calls execve() in the child after the  
fork (which then means the daemonization has to be short-circuited the  
second time), and this works in all respects except:

The emacsclient must be given "--socket-name /tmp/emacs503/server" to  
find the server.  Else it gives "No socket or alternate editor."

On the other hand, if I start emacs -Q and run 'server-start', this  
argument is NOT needed, and furthermore if it IS given it, it fails  
with "connect: Connection refused".

Any insight into what is happening here?

Message #39 received at 1107 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: 1107 <at> debbugs.gnu.org
Subject: Re: #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 12:34:51 -0800 (PST)

Adrian Robert <adrian.b.robert <at> gmail.com> writes:

  > OK, it seems that the NS GUI stuff cannot be used in a child process
  > from fork():
  > 
  > http://developer.apple.com/ReleaseNotes/CoreFoundation/CoreFoundation.html
  > 
  > (search for "fork"):
  > 
  > > Due to the behavior of fork(), CoreFoundation cannot be used on the
  > > child-side of fork(). If you fork(), you must follow that with an
  > > exec*() call of some sort, and you should not use CoreFoundation
  > > APIs within the child, before the exec*().

Bleah, how ugly.  Do you know if this is also a problem if you never use
CoreFoundation (whatever that is) before the fork() call?

  > I put in a really ugly hack that calls execve() in the child after the
  > fork (which then means the daemonization has to be short-circuited the
  > second time), and this works in all respects except:
  > 
  > The emacsclient must be given "--socket-name /tmp/emacs503/server" to
  > find the server.  Else it gives "No socket or alternate editor."
  > 
  > On the other hand, if I start emacs -Q and run 'server-start', this
  > argument is NOT needed, and furthermore if it IS given it, it fails
  > with "connect: Connection refused".
  > 
  > Any insight into what is happening here?

What is (daemonp) returning?  When using --daemon, if the value returned by
(daemonp) is a string is used to set `server-name', before calling
`server-start'. 

So does emacs -Q -f server-start  work now? (You reported problems in a
previous message...)

Message #44 received at 1107 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: Dan Nicolaescu <dann <at> ics.uci.edu>
Cc: 1107 <at> debbugs.gnu.org
Subject: Re: #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 16:15:24 -0500

On Nov 25, 2008, at 3:34 PM, Dan Nicolaescu wrote:

> Adrian Robert <adrian.b.robert <at> gmail.com> writes:
>
>> OK, it seems that the NS GUI stuff cannot be used in a child process
>> from fork():
>>
>> http://developer.apple.com/ReleaseNotes/CoreFoundation/CoreFoundation.html
>>
>> (search for "fork"):
>>
>>> Due to the behavior of fork(), CoreFoundation cannot be used on the
>>> child-side of fork(). If you fork(), you must follow that with an
>>> exec*() call of some sort, and you should not use CoreFoundation
>>> APIs within the child, before the exec*().
>
> Bleah, how ugly.  Do you know if this is also a problem if you never  
> use
> CoreFoundation (whatever that is) before the fork() call?

The problem is AFTER the fork.  CoreFoundation means any use of Cocoa  
GUI stuff.


>> The emacsclient must be given "--socket-name /tmp/emacs503/server" to
>> find the server.  Else it gives "No socket or alternate editor."
>>
>> On the other hand, if I start emacs -Q and run 'server-start', this
>> argument is NOT needed, and furthermore if it IS given it, it fails
>> with "connect: Connection refused".
>>
>> Any insight into what is happening here?
>
> What is (daemonp) returning?  When using --daemon, if the value  
> returned by
> (daemonp) is a string is used to set `server-name', before calling
> `server-start'.

If run with --daemon now, it returns "t".  If run emacs -Q then  
"server-start" it returns "nil".

server-name is "server" in both cases.

Here's some more info.  If I do 'lsof | grep <process ID>', when  
running --daemon, I get:

Emacs      6608 arobert    3u    unix 0x11bf3110       0t0           / 
tmp/emacs503/server

whereas when running normal+server-start I get:

Emacs      6600 arobert    6u    unix 0x11bf3110       0t0           / 
var/folders/90/90K8geLYFgW7CC5i5eRKmk+++TQ/-Tmp-/emacs503/server

Does this tell anything?  I'm not too knowledgeable about sockets, but  
the second one looks more "official".

Message #49 received at 1107 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: Dan Nicolaescu <dann <at> ics.uci.edu>
Cc: 1107 <at> debbugs.gnu.org
Subject: Re: #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 16:24:48 -0500

Ignore my last message, the problem was me not passing the TMPDIR env  
variable correctly to the child process.  I'll have to figure out how  
to get the full set of env variables in an array to pass to execve(),  
get the pipe info passed to the child (currently I'm ignoring that and  
just sleeping in the parent), and clean up the patch.

Message #58 received at 1107 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: 1107 <at> debbugs.gnu.org
Subject: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs
Date: Tue, 9 Dec 2008 23:18:01 -0500

[Message part 1 (text/plain, inline)]

I have not had the chance to refine my fix so I'm attaching my patch  
here in hopes that someone else can work on it.  It uses exec()  
instead of fork() to launch the child, using a daemon name argument to  
differentiate the child.  This prevents normal use of the name  
argument.  Moreover, the pipe connection does not work (not sure why),  
so it is disabled.

Index: src/emacs.c
===================================================================
RCS file: /sources/emacs/emacs/src/emacs.c,v
retrieving revision 1.456
diff -u -p -r1.456 emacs.c
--- src/emacs.c	8 Dec 2008 16:22:40 -0000	1.456
+++ src/emacs.c	10 Dec 2008 04:16:16 -0000
@@ -1102,21 +1102,26 @@ main (int argc, char **argv)
 	 use a pipe for synchronization.  The parent waits for the child
 	 to close its end of the pipe (using `daemon-initialized')
 	 before exiting.  */
+#ifndef HAVE_NS
       if (pipe (daemon_pipe) == -1)
 	{
 	  fprintf (stderr, "Cannot pipe!\n");
 	  exit (1);
 	}
-
       f = fork ();
+#else
+      if (!dname_arg || strcmp (dname_arg, "child"))
+	  f = fork ();
+      else
+	  f = 0;
+#endif
       if (f > 0)
 	{
 	  int retval;
 	  char buf[1];
-
+#ifndef HAVE_NS
 	  /* Close unused writing end of the pipe.  */
 	  close (daemon_pipe[1]);
-
 	  /* Just wait for the child to close its end of the pipe.  */
 	  do
 	    {
@@ -1131,6 +1136,9 @@ main (int argc, char **argv)
 	    }

 	  close (daemon_pipe[0]);
+#else
+	  sleep(5);
+#endif
 	  exit (0);
 	}
       if (f < 0)
@@ -1139,13 +1147,30 @@ main (int argc, char **argv)
 	  exit (1);
 	}

+#ifdef HAVE_NS
+      {
+        char *empty[1] = { NULL };
+        char *newargs[4] = {argv[0], "--daemon=child", "-Q", NULL};
+        if (!dname_arg || strcmp (dname_arg, "child")) {
+          int c = execve(argv[0], newargs, empty);
+          fprintf(stderr, "SHOULDN'T BE HERE: %d\t%d\n",c,errno);
+          exit(1);
+        }
+        daemon_pipe[1] = 1; // hack to get IS_DAEMON to work
+        if (dname_arg && !strcmp(dname_arg, "child"))
+          dname_arg = NULL;
+      }
+#endif
+
       if (dname_arg)
        	daemon_name = xstrdup (dname_arg);
+#ifndef HAVE_NS
       /* Close unused reading end of the pipe.  */
       close (daemon_pipe[0]);
       /* Make sure that the used end of the pipe is closed on exec, so
 	 that it is not accessible to programs started from .emacs.  */
       fcntl (daemon_pipe[1], F_SETFD, FD_CLOEXEC);
+#endif

 #ifdef HAVE_SETSID
       setsid();
@@ -2484,10 +2509,13 @@ from the parent process and its tty file
      Instead, we should probably close the pipe in start-process and
      call-process to make sure the pipe is never inherited by
      subprocesses.  */
+#ifndef HAVE_NS
   write (daemon_pipe[1], "\n", 1);
   close (daemon_pipe[1]);
+#endif
   /* Set it to an invalid value so we know we've already run this  
function.  */
   daemon_pipe[1] = -1;
+
   return Qt;
 }

[daemon_20081209.patch (application/octet-stream, attachment)]

[Message part 3 (text/plain, inline)]

Message #63 received at 1107 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: 1107 <at> debbugs.gnu.org
Subject: Re: 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, 9 Dec 2008 22:58:37 -0800 (PST)

Adrian Robert <adrian.b.robert <at> gmail.com> writes:

  > I have not had the chance to refine my fix so I'm attaching my patch  
  > here in hopes that someone else can work on it.  It uses exec()  
  > instead of fork() to launch the child, using a daemon name argument to  
  > differentiate the child.  This prevents normal use of the name  
  > argument.  Moreover, the pipe connection does not work (not sure why),  
  > so it is disabled.
  > 
  > Index: src/emacs.c
  > ===================================================================
  > RCS file: /sources/emacs/emacs/src/emacs.c,v
  > retrieving revision 1.456
  > diff -u -p -r1.456 emacs.c
  > --- src/emacs.c	8 Dec 2008 16:22:40 -0000	1.456
  > +++ src/emacs.c	10 Dec 2008 04:16:16 -0000
  > @@ -1102,21 +1102,26 @@ main (int argc, char **argv)
  >   	 use a pipe for synchronization.  The parent waits for the child
  >   	 to close its end of the pipe (using `daemon-initialized')
  >   	 before exiting.  */
  > +#ifndef HAVE_NS

Is this a problem just for MacOSX or also for GNUStep?
All these #ifdefs are very ugly, IMHO it would be better to separate the
NS functionality in a different function, that way only a single #ifdef
is needed here.

Message #68 received at 1107 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: Dan Nicolaescu <dann <at> ics.uci.edu>
Cc: 1107 <at> debbugs.gnu.org
Subject: Re: bug#1107: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs
Date: Wed, 10 Dec 2008 10:27:20 -0500

On Dec 10, 2008, at 1:58 AM, Dan Nicolaescu wrote:

> Is this a problem just for MacOSX or also for GNUStep?

Actually just OS X.  The ifdefs should be changed to NS_IMPL_COCOA.


> All these #ifdefs are very ugly, IMHO it would be better to  
> separate the
> NS functionality in a different function, that way only a single  
> #ifdef
> is needed here.

I agree, but did not see an easy way to do so given the way the  
daemon initialization is spread over two processes and several  
functions.  Another idea I thought of would be to simply not fork,  
and just require OS X users to run "emacs --daemon &".

Message #73 received at 1107 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: 1107 <at> debbugs.gnu.org
Subject: Re: bug#1107: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs
Date: Thu, 11 Dec 2008 11:21:34 -0500

> I have not had the chance to refine my fix so I'm attaching my patch here in
> hopes that someone else can work on it.  It uses exec()  instead of fork()
> to launch the child, using a daemon name argument to  differentiate the
> child.  This prevents normal use of the name  argument.  Moreover, the pipe
> connection does not work (not sure why),  so it is disabled.

The reason why the pipe connection doesn't work is pretty simple: the
exec'd daemon doesn't know the pipe's file descriptor number.
I.e. the --daemon arg for the child could look like
"--daemon=\nFD\nNAME" where NAME is the original daemon name, and FD is
the pipe's file descriptor.


        Stefan

Message #78 received at 1107 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: 1107 <at> debbugs.gnu.org, Dan Nicolaescu <dann <at> ics.uci.edu>
Subject: Re: bug#1107: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs
Date: Thu, 11 Dec 2008 11:22:28 -0500

> I agree, but did not see an easy way to do so given the way the daemon
> initialization is spread over two processes and several  functions.
> Another idea I thought of would be to simply not fork,  and just require OS
> X users to run "emacs --daemon &".

I thought so too, but that would probably get in the way for things like
emacsclient (once we change it to automatically start the daemon if
it's not running yet).


        Stefan

Message #85 received at 1107-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: 1107-done <at> debbugs.gnu.org
Subject: Re: 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X
Date: Fri, 23 Jan 2009 11:15:15 +0200

I have committed an improved version of the patch posted earlier.   
Conditionalized on NS_IMPL_COCOA,  use the pipe, and pass name other  
arguments properly to the child emacs process.  Closing.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.