Re: [Fwd: gtkplug commit]
- From: Owen Taylor <otaylor redhat com>
- To: gtk-devel-list redhat com
- Subject: Re: [Fwd: gtkplug commit]
- Date: 24 Nov 1999 09:10:10 -0500
Dietmar Maurer <dm@vlsivie.tuwien.ac.at> writes:
> >This looks like a real bug to me ... but it doesn't make
> >any sense to me that it would ever be triggered in
> >actual code unless the plug and socket were in the
> >same application, since a socket can only be used
> >once,
>
> I observed that the bonobo code uses the same socket window more than
> once? Why can it only be used once? Here is the putput of my program. If
> I start it multiple times it aquires the same socket window! (which
> causes the problems on the component plug which is only started once)
>
> nui# ./gshell
> set_remote_window 134798632
> nui# ./gshell
> set_remote_window 134800488
> nui# ./gshell
> set_remote_window 134798632
> nui# ./gshell
> set_remote_window 134800488
> nui# ./gshell
> set_remote_window 134798632
Well, yes, if you run a X client multiple times then the resource ID's
will be recycled. In fact, eventually they will be recycled within
the same running X client.
But, as I thought, if the above causes problems for the plug component,
then there is a bug, either in plug/socket or in Bonobo.
For gdk_window_lookup() to return the same GdkWindow for two different
X windows is simply not correct. There are two possibilities here:
- The DestroyNotify is not being caught at all.
- The CORBA transport and X event queue are out of sync so
that the new plug window is received before the DestroyNotify
is received for the old one.
The first is a memory leak, the second, worse because the
DestroyNotify would be interpreted as referring to the old
X window, not the new X window.
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]