Note: There are a few cases of duplicates in user autocompletion which are being worked on.

gtk2xtbin leaks client windows

RESOLVED FIXED in mozilla22



7 years ago
5 years ago


(Reporter: karlt, Assigned: karlt)



Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)



(1 attachment)



7 years ago
xt_client_create creates a window for xtclient->child_widget through XtRealizeWidget().

xt_client_unrealize changes the window on the parent widget
xtclient->top_widget to old_window which is None.

When the parent widget is destroyed, the child_widget gets destroyed, but the
child_widget's window is not a descendant of the parent widget's window and so
the child widget's window does not get destroyed when the parent widget's
window is destroyed.

Comment 1

7 years ago
When the window is destroyed during xt_client_unrealize, the acroread process started by the plugin spits out "unexpectedly destroyed" warnings and glib object type assertions and sometimes crashes.  Once the acroread process dies does not re-establish a connection, so the plugin fails to work.

These same errors already happen on shutdown while a plugin instance exists, but it would be more inconvenient to have the plugin fail while the application is still running.

XFixesChangeSaveSet can arrange for windows created by other clients to be automatically unmapped and reparented when the parent is destroyed.  This generates a BadMatch error when the child window has been created by the same client.

Comment 2

5 years ago
Created attachment 696657 [details] [diff] [review]
destroy XtClient child window on unrealize

I still get warnings and assertions when destroying the child window, but I
haven't had an acroread crash yet with the latest version.

Other plugins such as vlc don't destroy their own windows but expect them to
be destroyed with the child window, leading to more windows leaked.

acroread is now not used by default for pdf documents (Preferences ->
Applications -> PDF needs to be changed to "Use Adobe Reader" "(in Nightly)").
Assignee: nobody → karlt
Attachment #696657 - Flags: review?(stransky)

Comment 3

5 years ago
Comment on attachment 696657 [details] [diff] [review]
destroy XtClient child window on unrealize

Makes sense to me and I don't see any unexpected behaviour with this patch.
Attachment #696657 - Flags: review?(stransky) → review+

Comment 4

5 years ago


5 years ago
Flags: in-testsuite-

Comment 5

5 years ago
I've just retested this patch (see Bug 814200 comment 26) and it causes a regression. crashes when more documents are open sequentially.

Comment 6

5 years ago
I managed to reproduce with the build from Bug 814200 comment 26 by loading the same page again and again, but it took about a dozen attempts.  I ended up with a SIGSEGV in the acroread process at
XCreatePixmap (dpy=0x0, d=0, width=1, height=1, depth=195033592) at CrPixmap.c:50

acroread 8.5.1; gtk+ 2.20.1; libX11 1.4.0

That's a shame.  I guess I should back this out until bug 748923 is fixed.
Depends on: 748923

Comment 7

5 years ago
backed out:
Whiteboard: [leave open]

Comment 8

5 years ago
Firefox 19 uses pdf.js, so we don't need to support the acroread plugin now and I relanded.
Whiteboard: [leave open]
Sorry, I backed out this fix and several others on inbound because it looks like one of them broke B2G tests:
Relanded in
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
You need to log in before you can comment on or make changes to this bug.