Bugzilla Bug 203389

When attempting to close filezilla by either menu option or the "x" window
decoration, filezilla crashes unexpectedly instead of closing cleanly.

Reproducible: Always

Steps to Reproduce:
1.Open Filezilla
2.operating in filezilla is optional
3.close filezilla

Actual Results:  
It crashes every time.  Attached is collected info from bugbuddy

Expected Results:  
It should have closed cleanly.

Fully updated gentoo linux.  Filezilla does require some updated dependencies
such as gnutls and wxGTK, not sure if that makes a difference.

Created an attachment (id=139365) [details]
Bugbuddy crash info collection

I am unable to reproduce, can you paste `emerge --info` please?

Created an attachment (id=139527) [details]
emerge --info

emerge --info from problematic box, as requested.

Same problem here...
emerge --info: http://tallica.pl/linux/emerge_info

I've compiled wxGTK and filezilla with C(XX)FLAGS -O0 -ggdb, FEATURES=nostrip,
USE=debug

Ran it inside gdb and got this trace:

#0  0xb66baa50 in ?? ()
#1  0xb71c6d9c in exit () from /lib/libc.so.6
#2  0xb71b0fe4 in __libc_start_main () from /lib/libc.so.6
#3  0x08073171 in _start ()

Valgrind reported the following:

==27539== 
==27539== Jump to the invalid address stated on the next line
==27539==    at 0x59EBA50: ???
==27539==    by 0x4CF7FE3: (below main) (in /lib/libc-2.6.1.so)
==27539==  Address 0x59EBA50 is not stack'd, malloc'd or (recently) free'd
==27539== 
==27539== Process terminating with default action of signal 11 (SIGSEGV)
==27539==  Access not within mapped region at address 0x59EBA50
==27539==    at 0x59EBA50: ???
==27539==    by 0x4CF7FE3: (below main) (in /lib/libc-2.6.1.so)
==27539== 


This problem does not happen with self-compiled wxWidgets and FileZilla using
the most recent reversions from the upstream SVN repositories.

Update: Problem does still happen with wxGTK from portage and a self-compiled
filezilla from the upstream SVN sources.

Update: Manually compiling wxWidgets with the same flags passed to configure as
the ebuild would do it will trigger the bug as well.

Trying to find out which flag is responsible.

Note: The segfault also happens with the wxWidgets samples, indicating that
this is a problem with wxGTK (or its deps) and not FileZilla.

Good news: The responsible configure flag is --with-gnomevfs

This is not Gentoo-specific as I've just reproduced the bug under Debian too.
We'll try to fix it in the upstream, for now it might make sense to not use
--with-gnomevfs option for building wx.

we can take this one ;)

I've "fixed" the bug in the latest wx version by not unloading
libgnomevfs-2.so.0 at all (apparently this library installs some hooks into
other GTK libraries to which we link explicitly which are not uninstalled when
it's unloaded resulting in a crash because a call to already unloaded code is
done) but the code enabled by --with-gnomevfs doesn't seem to do anything
useful currently anyhow so I repeat my recommendation that you don't use this
option at all for now. But if you do, at least it shouldn't crash any more...

Fixed in wxGTK-2.8.7.1-r1 by passing --without-gnomevfs unconditionally. 
Thanks everyone.