Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: I had to downgrade filezilla from filezilla-3.9.0.6-1.fc21.x86_64 to filezilla-3.8.1-3.fc21.x86_64 because the newer version put uses 50% of the cpu on startup, even when not connected to anything. Version-Release number of selected component (if applicable): filezilla-3.9.0.6-1.fc21.x86_64 How reproducible: update to filezilla-3.9.0.6-1.fc21.x86_64 Steps to Reproduce: 1. monitor top 2. start filezilla 3. watch and wonder
I can confirm this bug on 3 different HW platforms even in F21 in virtualbox
Same here, same version. I use Mate as DE, and I get dbus errors (see attachment)
Created attachment 977506 [details] filezilla output in console
Please reproduce with 3.10.0 http://koji.fedoraproject.org/koji/taskinfo?taskID=8550975 I've no issue with any of my setup (running gnome). this message: wxD-Bus: Signal: Error: The name org.gnome.SessionManager was not provided by any .service files doesn't seem from filezilla but by dependent library.
with version: filezilla-3.8.1-3.fc21.x86_64, I don't have these messages (the console reports nothing after I start filezilla), and if I just start filezilla, the CPU tells it uses about <1.0% CPU with version: filezilla-3.9.0.6-1.fc21.x86_64 or filezilla-3.10.0-1.fc21.x86_64, both reports these messages. (I do get a line I didn't copy/past with the 2 last version: Reading locale option from /home/heldwin/.filezilla/filezilla.xml, that I don't get with the 3.8.1, and this version doesn't seem to recreate the .filezilla folder if I delete it). But on my system, it isn't only filezilla that increases in %CPU, but also the Xorg.bin process (it jumps from 2% to >30% CPU with the 2 last versions)
the .filezilla/filezilla.xml is my settings... and I didn't add settings after I had deleted it, so must be why it doesn't recreate it.
For me it is busy drawing, always in pango/cairo when interrupted, even not visible. #0 0x000000337d067890 in g_slist_reverse () at /lib64/libglib-2.0.so.0 #1 0x000000338f2209e4 in pango_layout_check_lines () at /lib64/libpango-1.0.so.0 #2 0x000000338f222478 in pango_layout_get_extents_internal () at /lib64/libpango-1.0.so.0 #3 0x000000338f2228e6 in pango_layout_get_pixel_extents () at /lib64/libpango-1.0.so.0 #4 0x000000338f222926 in pango_layout_get_pixel_size () at /lib64/libpango-1.0.so.0 #5 0x0000003f7ebe79f9 in wxCairoContext::GetTextExtent(wxString const&, double*, double*, double*, double*) const () at /lib64/libwx_gtk3u_core-3.0.so.0 #6 0x0000003f7eb9eab1 in wxGCDCImpl::DoGetTextExtent(wxString const&, int*, int*, int*, int*, wxFont const*) const () at /lib64/libwx_gtk3u_core-3.0.so.0 #7 0x0000003f7eadd139 in wxListLineData::DrawTextFormatted(wxDC*, wxString const&, int, int, int, int) () at /lib64/libwx_gtk3u_core-3.0.so.0 #8 0x0000003f7eaeb914 in wxListLineData::DrawInReportMode(wxDC*, wxRect const&, wxRect const&, bool, bool) () at /lib64/libwx_gtk3u_core-3.0.so.0 #9 0x0000003f7eaec184 in wxListMainWindow::OnPaint(wxPaintEvent&) () at /lib64/libwx_gtk3u_core-3.0.so.0 #10 0x0000003397870d3e in wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const () at /lib64/libwx_baseu-3.0.so.0 #11 0x0000003397a0d348 in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () at /lib64/libwx_baseu-3.0.so.0 #12 0x0000003397a0d44b in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () at /lib64/libwx_baseu-3.0.so.0 #13 0x0000003397a0d7f8 in wxEvtHandler::TryHereOnly(wxEvent&) () at /lib64/libwx_baseu-3.0.so.0 #14 0x0000003397a0d883 in wxEvtHandler::ProcessEventLocally(wxEvent&) () at /lib64/libwx_baseu-3.0.so.0 #15 0x0000003397a0d8e5 in wxEvtHandler::ProcessEvent(wxEvent&) () at /lib64/libwx_baseu-3.0.so.0 #16 0x0000003397a0d657 in wxEvtHandler::SafelyProcessEvent(wxEvent&) () at /lib64/libwx_baseu-3.0.so.0 #17 0x0000003f7eac7ee5 in wxWindow::GTKSendPaintEvents(_cairo*) () at /lib64/libwx_gtk3u_core-3.0.so.0 #18 0x0000003f7eac83fe in draw () at /lib64/libwx_gtk3u_core-3.0.so.0 #19 0x0000003f7c7ed55d in _gtk_marshal_BOOLEAN__BOXED () at /lib64/libgtk-3.so.0 #20 0x0000003f7c91a7af in gtk_widget_draw_marshaller () at /lib64/libgtk-3.so.0 #21 0x000000337e80fd35 in g_closure_invoke () at /lib64/libgobject-2.0.so.0 #22 0x000000337e821a42 in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0 #23 0x000000337e829d58 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0 #24 0x000000337e82a3af in g_signal_emit () at /lib64/libgobject-2.0.so.0 #25 0x0000003f7c928c36 in _gtk_widget_draw_internal.part.102 () at /lib64/libgtk-3.so.0 #26 0x0000003f7c92a2af in _gtk_widget_draw_windows () at /lib64/libgtk-3.so.0 #27 0x0000003f7c92a52f in _gtk_widget_draw () at /lib64/libgtk-3.so.0 #28 0x0000003f7c741fb5 in gtk_container_propagate_draw () at /lib64/libgtk-3.so.0 #29 0x0000003f7c799f01 in gtk_fixed_draw () at /lib64/libgtk-3.so.0 #30 0x0000003f7c7ed55d in _gtk_marshal_BOOLEAN__BOXED () at /lib64/libgtk-3.so.0 #31 0x0000003f7c91a7af in gtk_widget_draw_marshaller () at /lib64/libgtk-3.so.0 #32 0x000000337e80fc8f in g_closure_invoke () at /lib64/libgobject-2.0.so.0 #33 0x000000337e82193a in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0 #34 0x000000337e829d58 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0 #35 0x000000337e82a3af in g_signal_emit () at /lib64/libgobject-2.0.so.0 #36 0x0000003f7c928c36 in _gtk_widget_draw_internal.part.102 () at /lib64/libgtk-3.so.0 #37 0x0000003f7c92a2af in _gtk_widget_draw_windows () at /lib64/libgtk-3.so.0 #38 0x0000003f7c92a52f in _gtk_widget_draw () at /lib64/libgtk-3.so.0 #39 0x0000003f7c741fb5 in gtk_container_propagate_draw () at /lib64/libgtk-3.so.0 #40 0x0000003f7c742082 in gtk_container_draw () at /lib64/libgtk-3.so.0 #41 0x0000003f7c8662a0 in gtk_scrolled_window_draw () at /lib64/libgtk-3.so.0 #42 0x0000003f7c7ed65e in _gtk_marshal_BOOLEAN__BOXEDv () at /lib64/libgtk-3.so.0 #43 0x0000003f7c91a710 in gtk_widget_draw_marshallerv () at /lib64/libgtk-3.so.0 #44 0x000000337e80feb2 in _g_closure_invoke_va () at /lib64/libgobject-2.0.so.0 #45 0x000000337e82962b in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0 #46 0x000000337e82a3af in g_signal_emit () at /lib64/libgobject-2.0.so.0 #47 0x0000003f7c928c36 in _gtk_widget_draw_internal.part.102 () at /lib64/libgtk-3.so.0 #48 0x0000003f7c92a683 in _gtk_widget_draw () at /lib64/libgtk-3.so.0 #49 0x0000003f7c741fb5 in gtk_container_propagate_draw () at /lib64/libgtk-3.so.0 #50 0x0000003f7c799f01 in gtk_fixed_draw () at /lib64/libgtk-3.so.0 #51 0x0000003f7c7ed55d in _gtk_marshal_BOOLEAN__BOXED () at /lib64/libgtk-3.so.0 #52 0x0000003f7c91a7af in gtk_widget_draw_marshaller () at /lib64/libgtk-3.so.0 #53 0x000000337e80fc8f in g_closure_invoke () at /lib64/libgobject-2.0.so.0 #54 0x000000337e82193a in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0 #55 0x000000337e829d58 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0 #56 0x000000337e82a3af in g_signal_emit () at /lib64/libgobject-2.0.so.0 #57 0x0000003f7c928c36 in _gtk_widget_draw_internal.part.102 () at /lib64/libgtk-3.so.0 #58 0x0000003f7c92a2af in _gtk_widget_draw_windows () at /lib64/libgtk-3.so.0 #59 0x0000003f7c92a52f in _gtk_widget_draw () at /lib64/libgtk-3.so.0
And it is unusable as it freezes as soon as you try to browse a directory. Solved by moving back from filezilla.x86_64 0:3.9.0.6-1.fc21 to filezilla.x86_64 0:3.8.1-3.fc21
same problem (high CPU usage) with filezilla.x86_64 0:3.10.0.2-1.fc21 from updates-testing
I'm experiencing the same thing with filezilla 3.9.0.6-1.fc21.x86_64. Just starting the application without doing anything within it causes it to consume 50% CPU on an Intel i5-3570K CPU.
Same problem with filezilla-3.10.2-0.1.fc21.x86_64.rpm (dated Feb 26) in updates-testing.
on Fedora21 update since Fedora18 by fedup, i try to compile filezilla-3.10.2_src.tar.bz2 before i'm install yum install wxGTK3-devel , wxGTK3-gl , wxGTK3-media , sqlite-devel , sqlite2-devel and ./configure --with-wx-config=wx-config-3.0 --with-tinyxml=builtin the make tell me : Options.cpp:56:30: attention : comparison between ‘enum interfaceOptions’ and ‘enum<anonymous>’ [-Wenum-compare] static_assert(OPTIONS_NUM <= changed_options_size, "OPTIONS_NUM too big for changed_options_t"); ^ In file included from updater.cpp:21:0: ../putty/sshsh512.c:205:6: attention : ‘void {anonymous}::SHA384_Init({anonymous}::SHA512_State*)’ defined but not used [-Wunused-function] void SHA384_Init(SHA512_State *s) { ^ ../putty/sshsh512.c:306:6: attention : ‘void {anonymous}::SHA384_Final({anonymous}::SHA512_State*, unsigned char*)’ defined but not used [-Wunused-function] void SHA384_Final(SHA512_State *s, unsigned char *digest) { ^ uxcons.c: In function ‘console_open’: uxcons.c:351:9: attention : unused variable ‘fd’ [-Wunused-variable] int fd; ^ ssh.c: In function ‘do_ssh2_authconn’: ssh.c:9458:55: attention : pointer targets in passing argument 3 of ‘remove_duplicate_keys’ differ in signedness [-Wpointer-sign] remove_duplicate_keys(ssh, &s->loaded_keyfile_list, s->pkblob, s->pklen); ^ ssh.c:1016:13: note: expected ‘unsigned char *’ but argument is of type ‘char *’ static void remove_duplicate_keys(Ssh ssh, Loaded_keyfile_list** list, unsigned char* blob, unsigned int bloblen) May be this help you.
Is there any progress on this? I see that the version in updates-testing is still dated 2015-02-26 20:13
bump
I still have this problem with filezilla x86_64 3.9.0.6-1.fc21 updates 3.7 M Any progress?
Doesn't seem to do that anymore on f22: filezilla-3.10.3-1.fc22.x86_64
I think 3.9.0.6-1.fc21 should be unpushed from the repositories. For me it doesn't work at all (the GUI has glitches where stuff doesn't get loaded or is not clickable, etc.). 3.8.1-3.fc21 works perfectly.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
fixed
Reappeared for me on FC23: 3.14.1-2.fc23 3.12.0.2-1.fc23 100% cpu usage idling. sftp connections almost impossible.
(In reply to Francois Cartegnie from comment #20) > Reappeared for me on FC23: > 3.14.1-2.fc23 > 3.12.0.2-1.fc23 > > 100% cpu usage idling. > sftp connections almost impossible. Since I left my comment on this issue almost one year ago, I have used Nautilus instead of Filezilla for my FTP needs. In Nautilus, choose to connect to a server, enter "ftp://your.domain", then you will be prompted for username and password, and following that you are connected. This is obviously just a workaround, and Nautilus is not as feature-rich as Filezilla; however, it has worked well-enough for my minor FTP needs, which consists of updating some PHP web sites every once in a while.
It also started again on f22 since a few updates. So I took the 3.8 from f21 and excluded it from f22 updates :) On f22, there is also this password encryption I had to reverse to be able to connect to my sftp accounts with the version 3.8. Didn't bother to try on f23 yet. But seeing the message above, I will get ready to drop the 3.8 on f23 too.
Having no problems with filezilla-3.14.1-2.fc23.x86_64
I've tried with another user, cpu normal. The difference when Cpu usage is 100% seems the layout (another wxwidget issue?) (filezilla:9301): Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'height >= -1' failed (filezilla:9301): Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'width >= -1' failed (filezilla:9301): Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'width >= -1' failed (filezilla:9301): Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'height >= -1' failed (filezilla:9301): Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'width >= -1' failed (filezilla:9301): Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'height >= -1' failed (filezilla:9301): Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'width >= -1' failed
The cpu usage is directly related to the file listing views. When headers are fully visible (modif date, size..), cpu usage goes down. When headers are partially masked by the vertical split, cpu usage goes rocket high. Probably also related to column size.
yes, for me too. If on mate, I use: GTK_DEBUG=interactive filezilla, and set: Show Graphic Updates to 1, it shows that if the local directory listing is too big to show completely in the window size, it updates all the time. If the list of the directories is smaller, it stops updating the view all the time making the cpu decrease dramatically.
Is there anyway to reopen this ticket ? On F24 Mate I have exactly the same problem, bypassed by not showing treeview of local folders. Yet I don't see why it is considered "not a bug", and even more, I quote : ---- NOTABUG : The problem described is not a bug. *An explanation of why this resolution has been chosen should be supplied as a comment*. ---- I don't see any explanation here, the problem still occurs, and is definitely killing user experience by making FileZilla unusable.
As I remember, it was solved for me by deleting the config file for the underlying toolkit. Forgot the name, but you can find it by stracing