* bug#1107: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs
@ 2008-11-25 3:47 Adrian Robert
0 siblings, 0 replies; 14+ messages in thread
From: Adrian Robert @ 2008-11-25 3:47 UTC (permalink / raw
To: 1107; +Cc: Dan Nicolaescu, William Farrington
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#1107: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs
@ 2008-11-25 4:17 Adrian Robert
2008-11-25 6:20 ` Dan Nicolaescu
0 siblings, 1 reply; 14+ messages in thread
From: Adrian Robert @ 2008-11-25 4:17 UTC (permalink / raw
To: 1107; +Cc: Dan Nicolaescu, William Farrington
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#1107: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs
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
0 siblings, 1 reply; 14+ messages in thread
From: Dan Nicolaescu @ 2008-11-25 6:20 UTC (permalink / raw
To: Adrian Robert; +Cc: 1107, William Farrington
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?
Does that the same happen if you use
emacs -Q --daemon
?
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#1107: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs
2008-11-25 6:20 ` Dan Nicolaescu
@ 2008-11-25 14:47 ` Adrian Robert
2008-11-25 15:27 ` Dan Nicolaescu
0 siblings, 1 reply; 14+ messages in thread
From: Adrian Robert @ 2008-11-25 14:47 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: 1107, William Farrington
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)
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#1107: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs
2008-11-25 14:47 ` Adrian Robert
@ 2008-11-25 15:27 ` Dan Nicolaescu
2008-11-25 20:08 ` Adrian Robert
0 siblings, 1 reply; 14+ messages in thread
From: Dan Nicolaescu @ 2008-11-25 15:27 UTC (permalink / raw
To: Adrian Robert; +Cc: 1107, William Farrington
Adrian Robert <adrian.b.robert@gmail.com> writes:
> 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.
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#1107: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs
2008-11-25 15:27 ` Dan Nicolaescu
@ 2008-11-25 20:08 ` Adrian Robert
2008-11-25 20:34 ` Dan Nicolaescu
0 siblings, 1 reply; 14+ messages in thread
From: Adrian Robert @ 2008-11-25 20:08 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: 1107
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?
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#1107: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs
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
0 siblings, 2 replies; 14+ messages in thread
From: Dan Nicolaescu @ 2008-11-25 20:34 UTC (permalink / raw
To: Adrian Robert; +Cc: 1107
Adrian Robert <adrian.b.robert@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...)
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#1107: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs
2008-11-25 20:34 ` Dan Nicolaescu
@ 2008-11-25 21:15 ` Adrian Robert
2008-11-25 21:24 ` Adrian Robert
1 sibling, 0 replies; 14+ messages in thread
From: Adrian Robert @ 2008-11-25 21:15 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: 1107
On Nov 25, 2008, at 3:34 PM, Dan Nicolaescu wrote:
> Adrian Robert <adrian.b.robert@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".
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#1107: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs
2008-11-25 20:34 ` Dan Nicolaescu
2008-11-25 21:15 ` Adrian Robert
@ 2008-11-25 21:24 ` Adrian Robert
1 sibling, 0 replies; 14+ messages in thread
From: Adrian Robert @ 2008-11-25 21:24 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: 1107
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#1107: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs
@ 2008-12-10 4:18 Adrian Robert
2008-12-10 6:58 ` Dan Nicolaescu
2008-12-11 16:21 ` Stefan Monnier
0 siblings, 2 replies; 14+ messages in thread
From: Adrian Robert @ 2008-12-10 4:18 UTC (permalink / raw
To: 1107
[-- Attachment #1: Type: text/plain, Size: 2940 bytes --]
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;
}
[-- Attachment #2: daemon_20081209.patch --]
[-- Type: application/octet-stream, Size: 2529 bytes --]
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;
}
[-- Attachment #3: Type: text/plain, Size: 3 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#1107: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs
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:21 ` Stefan Monnier
1 sibling, 1 reply; 14+ messages in thread
From: Dan Nicolaescu @ 2008-12-10 6:58 UTC (permalink / raw
To: Adrian Robert; +Cc: 1107
Adrian Robert <adrian.b.robert@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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#1107: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs
2008-12-10 6:58 ` Dan Nicolaescu
@ 2008-12-10 15:27 ` Adrian Robert
2008-12-11 16:22 ` Stefan Monnier
0 siblings, 1 reply; 14+ messages in thread
From: Adrian Robert @ 2008-12-10 15:27 UTC (permalink / raw
To: Dan Nicolaescu; +Cc: 1107
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 &".
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#1107: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs
2008-12-10 4:18 Adrian Robert
2008-12-10 6:58 ` Dan Nicolaescu
@ 2008-12-11 16:21 ` Stefan Monnier
1 sibling, 0 replies; 14+ messages in thread
From: Stefan Monnier @ 2008-12-11 16:21 UTC (permalink / raw
To: Adrian Robert; +Cc: 1107
> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#1107: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs
2008-12-10 15:27 ` Adrian Robert
@ 2008-12-11 16:22 ` Stefan Monnier
0 siblings, 0 replies; 14+ messages in thread
From: Stefan Monnier @ 2008-12-11 16:22 UTC (permalink / raw
To: Adrian Robert; +Cc: Dan Nicolaescu, 1107
> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2008-12-11 16:22 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
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.