| Issue 39: | Firefox 3 will stay in memory after closing window (KDE4) | |
| 5 people starred this issue and may be notified of changes. | Back to list |
(Issue imported from Trac - moriarty)
When the theme is used, the firefox process will stay in memory after the
window is closed, or even if File -> Quit is used. This doesn't happen if
the theme is not activated. Running firefox with strace I can see it
stopping at a waitpid() call:
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGINT, {0x807bd61, [], 0}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL}, {0x807bd61, [], 0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
read(255, "\nif [ $debugging = 1 ]\nthen\n ec"..., 3949) = 209
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [INT CHLD], 8) = 0
rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) = 0
_llseek(255, -35, [3914], SEEK_CUR) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|
SIGCHLD, child_tidptr=0xb7d76708) = 29244
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGINT, {0x807bd61, [], 0}, {SIG_DFL}, 8) = 0
waitpid(-1,
|
|
,
Jul 19, 2009
Backtrace I get for a blocking iceweasel (aka firefox on debian):
0x0000003dac4c4066 in *__GI___poll (fds=<value optimized out>, nfds=<value optimized
out>, timeout=<value optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
87 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
in ../sysdeps/unix/sysv/linux/poll.c
(gdb) by
Undefined command: "by". Try "help".
(gdb) bt
#0 0x0000003dac4c4066 in *__GI___poll (fds=<value optimized out>, nfds=<value
optimized out>, timeout=<value optimized out>) at
../sysdeps/unix/sysv/linux/poll.c:87
#1 0x0000003dae0098aa in ?? () from /usr/lib/libxcb.so.1
#2 0x0000003dae009e99 in ?? () from /usr/lib/libxcb.so.1
#3 0x0000003dae00a145 in xcb_writev () from /usr/lib/libxcb.so.1
#4 0x0000003dae44ebf6 in _XSend (dpy=<value optimized out>, data=<value optimized
out>, size=<value optimized out>) at ../../src/xcb_io.c:332
#5 0x0000003dae43c6f9 in XQueryExtension (dpy=<value optimized out>, name=<value
optimized out>, major_opcode=<value optimized out>, first_event=<value optimized
out>,
first_error=<value optimized out>) at ../../src/QuExt.c:50
#6 0x0000003dae430c3f in XInitExtension (dpy=<value optimized out>, name=<value
optimized out>) at ../../src/InitExt.c:49
#7 0x0000003db2806edc in XRenderFindDisplay () from /usr/lib/libXrender.so.1
#8 0x0000003db2804a5e in XRenderFreePicture () from /usr/lib/libXrender.so.1
#9 0x00007fdb2891d1c4 in QX11PixmapData::release (this=<value optimized out>) at
image/qpixmap_x11.cpp:1206
#10 0x00007fdb2891d8d4 in ~QX11PixmapData (this=<value optimized out>,
__in_chrg=<value optimized out>) at image/qpixmap_x11.cpp:1182
#11 0x00007fdb2890e6fe in QPixmap::deref (this=<value optimized out>) at
image/qpixmap.cpp:1322
#12 0x00007fdb2890ea44 in ~QPixmap (this=<value optimized out>, __in_chrg=<value
optimized out>) at image/qpixmap.cpp:332
#13 0x00007fdb280dacdc in ~TileSet (this=0x7fdb1b7dbe00, __in_chrg=<value optimized
out>) at ../../../kstyles/oxygen/tileset.h:61
#14 0x00007fdb280e6ca7 in OxygenStyleHelper::~OxygenStyleHelper() () from
/usr/lib/kde4/plugins/styles/oxygen.so
#15 0x0000003dac43641d in *__GI_exit (status=<value optimized out>) at exit.c:75
#16 0x0000003dac41e5ad in __libc_start_main (main=<value optimized out>, argc=<value
optimized out>, ubp_av=<value optimized out>, init=<value optimized out>,
fini=<value optimized out>,
rtld_fini=<value optimized out>, stack_end=Could not find the frame base for
"__libc_start_main".
) at libc-start.c:254
#17 0x0000000000401cc9 in ?? ()
#18 0x00007fff18c194d8 in ?? ()
#19 0x000000000000001c in ?? ()
#20 0x0000000000000003 in ?? ()
#21 0x00007fff18c1aa41 in ?? ()
#22 0x0000000000000000 in ?? ()
|
|
,
Jul 19, 2009
Downstream bug report: http://bugs.debian.org/537585 |
|
,
Aug 15, 2009
Another bug report is here: https://bugzilla.redhat.com/show_bug.cgi?id=501427 According to https://bugzilla.mozilla.org/show_bug.cgi?id=417163 this is because Qt tries to clean up after the display is closed and gets in a right tizzy (and also jemalloc may be more aggressive about freeing/recycling memory). There was a workaround in firefox but it bit-rotted as the theme name is now "Qt4" instead of "Qt". https://bugzilla.mozilla.org/show_bug.cgi?id=417163#c31 discusses why theme_exit() is never called - in particular "GTK makes no promises to notify theme engines when opening and closing displays. It is up to the theme engine to register for close display signals." I'm no expert, but this seems to be talking about this signal http://library.gnome.org/devel/gdk/stable/GdkDisplay.html#GdkDisplay-closed The wrinkle here is that, if I understand the code correctly, qt-glib eventloop integration is explicity disabled in gtk-qt-engine - see the dummy event dispatcher at http://code.google.com/p/gtk-qt-engine/source/browse/trunk/gtk-qt-engine/src/engine.cpp#140 Since the code here was imported from some other repository, it's impossible to see when these lines were introduced. Is "stealing events from GTK" still a concern? Is there a way to make gtk-qt-engine listen for the close display event, or would that cause more problems. |
|
 Sign in to add a comment
|
