|
From: | Adrian Robert |
Subject: | bug#1107: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs |
Date: | Tue, 25 Nov 2008 16:15:24 -0500 |
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 useCoreFoundation (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".
[Prev in Thread] | Current Thread | [Next in Thread] |