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 attachment 139365 [details] Bugbuddy crash info collection
I am unable to reproduce, can you paste `emerge --info` please?
Created attachment 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.
In case anyone else happens across this, this issue also affected Cygwin back in the day, but I can confirm that the issue seems to have gone away as of wxWidgets 3.0.5.1, at least on Cygwin - building with GNOMEVFS now works just fine. I imagine most packages elsewhere are more up to date so this probably isn't of much interest, but worth noting anyway.
