* emacs --daemon and GDK default display
@ 2009-03-17 11:14 Ulrich Mueller
2009-03-17 11:47 ` Jason Rumney
0 siblings, 1 reply; 9+ messages in thread
From: Ulrich Mueller @ 2009-03-17 11:14 UTC (permalink / raw
To: emacs-devel
Hi, at Gentoo we've got a report on a segmentation fault with 23.0.91:
<http://bugs.gentoo.org/259891>
1. install libcanberra and emacs (--with-x-toolkit=gtk)
2. run "emacs -Q --daemon"
3. under GNOME, run "emacsclient -c" (exit with C-x 5 0)
4. run "emacsclient -c" again, and emacs will segfault
It happens because there is no GDK default display when the display
for the second client frame is opened (xg_display_open), and
libcanberra fails to check for that case.
While I think that the blame is with libcanberra, I'm confused about
the fact that the segfault only happens during the second request from
a client. Does it mean that there is a GDK default display at the time
of the first request, but not for the second one? Why?
Could somebody shed some light on the issue?
Ulrich
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: emacs --daemon and GDK default display
2009-03-17 11:14 emacs --daemon and GDK default display Ulrich Mueller
@ 2009-03-17 11:47 ` Jason Rumney
2009-03-23 9:28 ` Ulrich Mueller
0 siblings, 1 reply; 9+ messages in thread
From: Jason Rumney @ 2009-03-17 11:47 UTC (permalink / raw
To: Ulrich Mueller; +Cc: emacs-devel
Ulrich Mueller wrote:
> While I think that the blame is with libcanberra, I'm confused about
> the fact that the segfault only happens during the second request from
> a client. Does it mean that there is a GDK default display at the time
> of the first request, but not for the second one? Why?
>
Just a guess without looking at libcanberra, but could the bug be that
libcanberra remembers the default display created during the first
request and tries to reuse it after it is closed?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: emacs --daemon and GDK default display
2009-03-17 11:47 ` Jason Rumney
@ 2009-03-23 9:28 ` Ulrich Mueller
2009-03-23 17:09 ` Jan Djärv
0 siblings, 1 reply; 9+ messages in thread
From: Ulrich Mueller @ 2009-03-23 9:28 UTC (permalink / raw
To: Jason Rumney; +Cc: emacs-devel
>>>>> On Tue, 17 Mar 2009, Jason Rumney wrote:
>> While I think that the blame is with libcanberra, I'm confused
>> about the fact that the segfault only happens during the second
>> request from a client. Does it mean that there is a GDK default
>> display at the time of the first request, but not for the second
>> one? Why?
> Just a guess without looking at libcanberra, but could the bug be
> that libcanberra remembers the default display created during the
> first request and tries to reuse it after it is closed?
It doesn't remember it. libcanberra just calls a GTK function, which
in turn asks the GDK display manager for the default display. And that
returns a valid display for the first request, but a null pointer for
the second one.
Ulrich
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: emacs --daemon and GDK default display
2009-03-23 9:28 ` Ulrich Mueller
@ 2009-03-23 17:09 ` Jan Djärv
2009-03-23 21:33 ` Ulrich Mueller
2009-03-24 1:11 ` Austin
0 siblings, 2 replies; 9+ messages in thread
From: Jan Djärv @ 2009-03-23 17:09 UTC (permalink / raw
To: Ulrich Mueller; +Cc: emacs-devel, Jason Rumney
Ulrich Mueller skrev:
>>>>>> On Tue, 17 Mar 2009, Jason Rumney wrote:
>>> While I think that the blame is with libcanberra, I'm confused
>>> about the fact that the segfault only happens during the second
>>> request from a client. Does it mean that there is a GDK default
>>> display at the time of the first request, but not for the second
>>> one? Why?
>
>> Just a guess without looking at libcanberra, but could the bug be
>> that libcanberra remembers the default display created during the
>> first request and tries to reuse it after it is closed?
>
> It doesn't remember it. libcanberra just calls a GTK function, which
> in turn asks the GDK display manager for the default display. And that
> returns a valid display for the first request, but a null pointer for
> the second one.
>
If I remember correctly, the display manager does not set a new default
display when the old is closed. There is some code for that case i gtkutil.c.
But there was a bug in it. I don't know if that fixes anything, but please
try again. Note that closing displays under Gtk+ is generally buggy in
itself. If you can capture a stack trace in the debugger we should be able to
tell if it is Gtk+ or Emacs that is doing the wrong thing.
Jan D.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: emacs --daemon and GDK default display
2009-03-23 17:09 ` Jan Djärv
@ 2009-03-23 21:33 ` Ulrich Mueller
2009-03-25 19:21 ` Jan Djärv
2009-03-24 1:11 ` Austin
1 sibling, 1 reply; 9+ messages in thread
From: Ulrich Mueller @ 2009-03-23 21:33 UTC (permalink / raw
To: Jan Djärv; +Cc: emacs-devel, Jason Rumney
>>>>> On Mon, 23 Mar 2009, Jan Djärv wrote:
> If I remember correctly, the display manager does not set a new
> default display when the old is closed. There is some code for that
> case i gtkutil.c.
> But there was a bug in it. I don't know if that fixes anything, but
> please try again.
This wouldn't help, since the segmentation fault already happens in
gdk_display_open, so it doesn't reach the code affected by your
change of today.
> Note that closing displays under Gtk+ is generally buggy in itself.
> If you can capture a stack trace in the debugger
A GDB backtrace is attached to our downstream bug at
<http://bugs.gentoo.org/attachment.cgi?id=185188>. Unfortunately,
without symbols in Emacs. ;-) But I think that there's enough
information to see what is going on.
> we should be able to tell if it is Gtk+ or Emacs that is doing the
> wrong thing.
There's definitely a problem in libcanberra which fails to check for a
null pointer (already reported to its upstream).
The question is if Emacs could do anything to work around the problem?
I suppose you can't set a default display before calling
gdk_display_open?
Ulrich
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: emacs --daemon and GDK default display
2009-03-23 17:09 ` Jan Djärv
2009-03-23 21:33 ` Ulrich Mueller
@ 2009-03-24 1:11 ` Austin
1 sibling, 0 replies; 9+ messages in thread
From: Austin @ 2009-03-24 1:11 UTC (permalink / raw
To: emacs-devel
Jan Djärv <jan.h.d@swipnet.se> writes:
> Ulrich Mueller skrev:
>>>>>>> On Tue, 17 Mar 2009, Jason Rumney wrote:
>>>> While I think that the blame is with libcanberra, I'm confused
>>>> about the fact that the segfault only happens during the second
>>>> request from a client. Does it mean that there is a GDK default
>>>> display at the time of the first request, but not for the second
>>>> one? Why?
>>
>>> Just a guess without looking at libcanberra, but could the bug be
>>> that libcanberra remembers the default display created during the
>>> first request and tries to reuse it after it is closed?
>>
>> It doesn't remember it. libcanberra just calls a GTK function, which
>> in turn asks the GDK display manager for the default display. And that
>> returns a valid display for the first request, but a null pointer for
>> the second one.
>>
>
> If I remember correctly, the display manager does not set a new
> default display when the old is closed. There is some code for that
> case i gtkutil.c.
>
> But there was a bug in it. I don't know if that fixes anything, but
> please try again. Note that closing displays under Gtk+ is generally
> buggy in itself. If you can capture a stack trace in the debugger we
> should be able to tell if it is Gtk+ or Emacs that is doing the wrong
> thing.
>
> Jan D.
This is the stack trace that I got when following Ulrich's procedure.
Program received signal SIGSEGV, Segmentation fault.
0x0000000006a10e8a in gtk_module_init () from
/usr/lib64/gtk-2.0/modules/libcanberra-gtk-module.so
(gdb) bt
#0 0x0000000006a10e8a in gtk_module_init () from
/usr/lib64/gtk-2.0/modules/libcanberra-gtk-module.so
#1 0x000000357e93c36f in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#2 0x000000357e93c428 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#3 0x000000357e93c4f7 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0
#4 0x000000357f20b7dd in g_closure_invoke () from
/lib64/libgobject-2.0.so.0
#5 0x000000357f2214bd in ?? () from /lib64/libgobject-2.0.so.0
#6 0x000000357f222b68 in g_signal_emit_valist () from
/lib64/libgobject-2.0.so.0
#7 0x000000357f222ee7 in g_signal_emit_by_name () from
/lib64/libgobject-2.0.so.0
#8 0x000000357cc41906 in gdk_display_open () from
/usr/lib64/libgdk-x11-2.0.so.0
#9 0x00000000004d24eb in xg_display_open (display_name=0x0,
dpy=0x6a12897) at emacs/src/gtkutil.c:121
#10 0x00000000004a10ac in x_term_init (display_name=15258819,
xrm_option=0x0, resource_name=0x10a51c0 "emacs") at
emacs/src/xterm.c:10018
#11 0x00000000004adbcc in x_display_info_for_name (name=15258819) at
emacs/src/xfns.c:4108
#12 0x00000000004b305d in Fx_create_frame (parms=12003973) at
emacs/src/xfns.c:3155
#13 0x000000000055f31c in Ffuncall (nargs=2, args=<value optimized out>)
at emacs/src/eval.c:3044
#14 0x0000000000595f85 in Fbyte_code (bytestr=<value optimized out>,
vector=11655313, maxdepth=<value optimized out>)
at emacs/src/bytecode.c:678
...
It is the latest CVS code and the system is FC10 x86_64, kernel
2.6.27.19, with NVidia dual-head. My observation is that this seg fault
won't happen if the first frame is not closed when creating the second
one.
Hope this helps,
Austin
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: emacs --daemon and GDK default display
2009-03-23 21:33 ` Ulrich Mueller
@ 2009-03-25 19:21 ` Jan Djärv
2009-03-28 15:49 ` Jan Djärv
0 siblings, 1 reply; 9+ messages in thread
From: Jan Djärv @ 2009-03-25 19:21 UTC (permalink / raw
To: Ulrich Mueller; +Cc: Jason Rumney, emacs-devel
Ulrich Mueller skrev:
>>>>>> On Mon, 23 Mar 2009, Jan Djärv wrote:
>
>> If I remember correctly, the display manager does not set a new
>> default display when the old is closed. There is some code for that
>> case i gtkutil.c.
>
>> But there was a bug in it. I don't know if that fixes anything, but
>> please try again.
>
> This wouldn't help, since the segmentation fault already happens in
> gdk_display_open, so it doesn't reach the code affected by your
> change of today.
>
>> Note that closing displays under Gtk+ is generally buggy in itself.
>> If you can capture a stack trace in the debugger
>
> A GDB backtrace is attached to our downstream bug at
> <http://bugs.gentoo.org/attachment.cgi?id=185188>. Unfortunately,
> without symbols in Emacs. ;-) But I think that there's enough
> information to see what is going on.
>
>> we should be able to tell if it is Gtk+ or Emacs that is doing the
>> wrong thing.
>
> There's definitely a problem in libcanberra which fails to check for a
> null pointer (already reported to its upstream).
Okay, now I see it in the stack trace Austin posted, thanks.
Emacs opens the first display, and that becomes the
default display. Then that display is closed, and there is no default
display. When a new display is opened, it does not become the default
display. The gdk_display_open function calls libcanberra before Emacs has a
chance to set the default display. Maybe this could be seen as a bug in Gtk+.
I see that the code in Gtk+ kind of assumes that once the default display is
open, it is never closed.
The module initialization, of which libcanberra is part, is triggered by the
display_opened signal. It should be possible to manipulate that signal so
it is either delayed or intercepted. However, I don't have libcanberra here
where I am currently. I'll be back at home in a couple of days, I'll try
something then.
>
> The question is if Emacs could do anything to work around the problem?
> I suppose you can't set a default display before calling
> gdk_display_open?
>
No, but if Emacs can catch the display_opened signal first it can set the
default display before libcanberra is called.
I am thinking of filing an Gtk+ bug on this, but I have to have the proper
setup myself first.
Jan D.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: emacs --daemon and GDK default display
2009-03-25 19:21 ` Jan Djärv
@ 2009-03-28 15:49 ` Jan Djärv
2009-03-28 18:09 ` Ulrich Mueller
0 siblings, 1 reply; 9+ messages in thread
From: Jan Djärv @ 2009-03-28 15:49 UTC (permalink / raw
To: Ulrich Mueller; +Cc: emacs-devel, Jason Rumney
Jan Djärv skrev:
>
>
> Ulrich Mueller skrev:
>
>>
>> The question is if Emacs could do anything to work around the problem?
>> I suppose you can't set a default display before calling
>> gdk_display_open?
>>
>
> No, but if Emacs can catch the display_opened signal first it can set
> the default display before libcanberra is called.
>
> I am thinking of filing an Gtk+ bug on this, but I have to have the proper
> setup myself first.
>
I can not reproduce this, I think the libcanberra here is too old. Anyway, I
don't think we should do anything about this in Emacs. It will just be a
workaround for one version of libcanberra. And they have since fixed the
problem, no?
Jan D.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: emacs --daemon and GDK default display
2009-03-28 15:49 ` Jan Djärv
@ 2009-03-28 18:09 ` Ulrich Mueller
0 siblings, 0 replies; 9+ messages in thread
From: Ulrich Mueller @ 2009-03-28 18:09 UTC (permalink / raw
To: Jan Djärv; +Cc: emacs-devel, Jason Rumney
>>>>> On Sat, 28 Mar 2009, Jan Djärv wrote:
> I can not reproduce this, I think the libcanberra here is too old.
> Anyway, I don't think we should do anything about this in Emacs.
> It will just be a workaround for one version of libcanberra.
I could reproduce the bug with libcanberra-0.11. From looking at their
source I conclude that the problem should exist in all versions from
0.4 to 0.11.
> And they have since fixed the problem, no?
Yes, it's been fixed in their git repository.
Ulrich
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-03-28 18:09 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-17 11:14 emacs --daemon and GDK default display Ulrich Mueller
2009-03-17 11:47 ` Jason Rumney
2009-03-23 9:28 ` Ulrich Mueller
2009-03-23 17:09 ` Jan Djärv
2009-03-23 21:33 ` Ulrich Mueller
2009-03-25 19:21 ` Jan Djärv
2009-03-28 15:49 ` Jan Djärv
2009-03-28 18:09 ` Ulrich Mueller
2009-03-24 1:11 ` Austin
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.