* 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 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
* 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-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
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 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).