app-editors/emacs-cvs-23.0.90: daemon crash if I run client under X twice. Reproducible: Always Steps to Reproduce: 1. run "emacs --daemon" to start the emacs daemon server. 2. run "emacsclient -c" twice under X. Actual Results: the emacs daemon automatically quit, it seems it was crash. Expected Results: emacs daemon should be always there. $ eix emacs-cvs [U] app-editors/emacs-cvs Available versions: (23) (~)23.0.60_pre20090125!s (~)23.0.90!s [M](~)23.0.9999!s {M}(~)23.0.9999-r1!s {X Xaw3d alsa dbus gif gpm gtk gzip-el hesiod jpeg kerberos m17n-lib motif png sound source spell svg tiff toolkit-scroll-bars xft xpm} Installed versions: 23.0.90(23)!s(05:25:42 AM 02/22/2009)(X alsa dbus gif gpm gtk jpeg png tiff toolkit-scroll-bars xft xpm -Xaw3d -gzip-el -hesiod -kerberos -m17n-lib -motif -sound -source -spell -svg) Homepage: http://www.gnu.org/software/emacs/ Description: The extensible, customizable, self-documenting real-time display editor
> Steps to Reproduce: > 1. run "emacs --daemon" to start the emacs daemon server. > 2. run "emacsclient -c" twice under X. Does this also happen if you start Emacs with "emacs -Q --daemon"?
Created attachment 185099 [details] log (In reply to comment #1) > > Steps to Reproduce: > > 1. run "emacs --daemon" to start the emacs daemon server. > > 2. run "emacsclient -c" twice under X. > > Does this also happen if you start Emacs with "emacs -Q --daemon"? > Yes, it do crash too. I've try 23.0.91 and the latest cvs version these days. Same things happen. If a emacsclient with "-t" is running, it will crash with daemon too. Buf if a emacsclient with "-c" is running, the bug won't appear. I straced with "emacsclient -c", no exception found. I straced -p (process of daemon) again, and found something. after the first client connected to daemon, the dameon read some lib related to gtk+ If I don't close the first(keep an X client open), clients followed use same lib in memory and no exceptions found. after quit all client opened before and start a new client, the daemon crash. it seems that the dameon stat gtk+ libiary failed, there's some stace log for it. get it from "strace -p `pidof emacs` &> file"
I succeeded to reproduce it, but only under Gnome (under Xfce4 it works for me). What desktop are you using? (In reply to comment #2) > Created an attachment (id=185099) [edit] > log From your log: access("/usr/lib64/gtk-2.0/modules/libcanberra-gtk-module.so", F_OK) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- Does the bug still happen if you unmerge media-libs/libcanberra?
(In reply to comment #3) > I succeeded to reproduce it, but only under Gnome (under Xfce4 it works for > me). What desktop are you using? > > (In reply to comment #2) > > Created an attachment (id=185099) [edit] > > log > > From your log: > access("/usr/lib64/gtk-2.0/modules/libcanberra-gtk-module.so", F_OK) = 0 > --- SIGSEGV (Segmentation fault) @ 0 (0) --- > > Does the bug still happen if you unmerge media-libs/libcanberra? > I am using gnome desktop enviroment(gnome-light). thanks to your suggestion, it works! after unmerge libcanberra. I've try to rebuild emacs with or without alsa and sound USE, rebuild libcanberra changing its USE and even update to a testing version, but problem still exists. but gnome-sound-properties in gnome-control-center(with USE=sound) depends libcanberra. I almost never use gnome-sound-properties so the way unmerging libcanberra is suitable for me. but I think that's not a good attitude towards bug ^_^.
(In reply to comment #4) > thanks to your suggestion, it works! after unmerge libcanberra. > [...] > but I think that's not a good attitude towards bug ^_^. Of course unmerging libcanberra is not the final bugfix. We will investigate this problem further.
Created attachment 185188 [details] GDB backtrace The GDB backtrace shows that the segfault happens in gtk_module_init of canberra-gtk-module. Looks like gtk_settings_get_default() returns a NULL pointer.
(In reply to comment #6) > Looks like gtk_settings_get_default() returns a NULL pointer. And this happens because there is no default display for GDK at this point.
Reported upstream: <https://bugs.freedesktop.org/show_bug.cgi?id=20693>
Created attachment 186050 [details, diff] Patch from upstream Attached patch from the upstream git repository fixes the segmentation fault.
looks fine.
Fixed in libcanberra-0.11-r5. Thank you for reporting the issue.
