gui becomes unresponsive

[Jose Riha]

on a random occasion (i've been able to reproduce it several times by right-clicking directories and selecting ,,download whole directory'' in a loop) the gui of linuxdcpp becomes unresponsive. if i switch desktop and turn back the whole window is grey and nothing can be done. however program continues operation - if there's something in the queue it just continue downloading. console log does not seem to be helpful either. process responds to sigterm.

os: arch linux (current) but also ubuntu (my friend is seeing the same issue)
compiled from sources (bzr as of january 3rd 2010 with scons debug=1)

[Razzloss (razzloss)]

Does it recover if left alone for a while, maybe 15-30 minutes?

Also a backtrace from a frozen linuxdcpp could be useful (compiled with scons debug=1).
1) Start linuxdcpp normally
2) Cause it to freeze
3) start gdb in another terminal
4) type in gdb: attach PID_of_Linuxdcpp (check pid with ps -A | grep linuxdcpp)
5) Paste the output of 'thread apply all bt full' to a text file and attach here.

Another thing to check is if this can be reproduced with bzr revision before 339 (if you can't provide a backtrace).
1) bzr branch lp:linuxdcpp -r 338
2) compile and run
3) see if this can be reproduced with that version.

--RZ

[Jose Riha (jose1711)]

it seems it does not ever recover but i'll let it run for an hour and see. i attached the gdb output. first i experienced this problem with current stable (in fact that is the reason i'm on bzr now). hope the log will help.

[Razzloss (razzloss)]

That backtrace doesn't seem to be from a debug version? Or at least the symbol information is missing. So please compile the debug version with scons debug=1 (and run scons install, if you've done it before). And repeat the steps to get the backtrace with debugging information.

If the stable version was also freezing then trying the older bzr versions probably won't help.

--RZ

[Jose Riha (jose1711)]

i compiled the package in the following manner:

..
  scons debug=1 PREFIX=/usr LIBDIR=/usr/share || return 1
  scons install FAKE_ROOT=$startdir/pkg || return 1
..
is that wrong? am i missing something?

[Razzloss (razzloss)]

Compilation is fine.

Not so sure about the install. If $startdir contains something reasonable then it shouldn't be a problem, if you're actually running the binary installed. Or are you building a package which you install? (I have no idea what kind of package manager arch linux has).

You could try to start the linuxdcpp from the builddir with cd yourbuilddirectory and ./linuxdcpp (assuming that you don't have older datafiles in $PREFIX/share/linuxdcpp (in that case it probably will crash instantly))

 --RZ

[Jose Riha (jose1711)]

this log looks more verbose (ran from build dir)

[Jose Riha (jose1711)]

btw it did not recover after some 70 minutes

[Razzloss (razzloss)]

yup, the backtrace looks better... sort of.. I was expecting to see some manager critical sections in a dead lock, but apparently that isn't the case. Steven any thoughts?

I'll have to see if I can reproduce this at home, wasn't able to do it here (with a slow link and a passive connection)

--RZ

[taresus (grip2die)]

Hello,

I'm a newby and, unfortunatly, subscribe to this bug.

distribution: openSUSE 11.2 32 bit
linux kernel: 2.6.31.5-0.1-desktop #1 SMP PREEMPT 2009-10-26 15:49:03 +0100 i686 i686 i386 GNU/Linux
linuxdcpp version: stable 1.0.3

Steps to reproduce this bug:
1. launched for the first time linuxdcpp
2. opened public hubs list
3. double click on the country separator (that column was to thin)
4. it froze (had to terminate the process)...

[Steven Sheehy (steven-sheehy)]

taresus: I am unable to reproduce your issue. Interacting with the column separator doesn't even touch linuxdcpp code, it would be internal to gtk+. You can try disabling accessibility as mentioned in bug #437426.

As for the other issue, it appears to be a deadlock between thread 1 & 10. A call to gdk_flush() seems to be waiting indefinitely while the main thread is waiting for the gdk lock to be returned by thread 10. As for why gdk_flush() is not returning, I've no idea. Gdk explicitly recommends calling gdk_flush in such situations (http://library.gnome.org/devel/gdk/unstable/gdk-Threads.html):

"Before calling gdk_threads_leave() from a thread other than your main thread, you probably want to call gdk_flush() to send all pending commands to the windowing system."

So, in summary: I hate you GTK+....

[Jose Riha (jose1711)]

is there anything more one could do? recompiling gtk+ with debugging enabled maybe?

[Razzloss (razzloss)]

That's an option.

Another is trying different GTK versions and see if it is reproducable. What version are you using btw? You could try to change GTK theme engine also (wouldn't be the first problem to be solved by theme engine change).

-RZ

[Jose Riha (jose1711)]

@razzloss: i'm using gtk2 2.18.5. could you tell me which one are you using? i'll try to install the version you have and see if anything changes. if not i'll proceed to debug-enabled recompilation

[Razzloss (razzloss)]

2.16.6 seems to be installed. Before the debug compilation I'd suggest to try with a different GTK theme, it's faster and easier to rule out than the gtk debug build.

--RZ

[Jose Riha (jose1711)]

i changed the theme to simple. it took a while but i was able to reproduce the bug. installing 2.16.5 does not seem to be a viable option as too many packages depends on gtk2>=2.18.5 :-( i'll check if i am able to recompile it with debugging symbols enabled at least

[Jose Riha (jose1711)]

ok, don't know if the attached log is any better. if there's more needed to be recompiled, i'll do it.

[Razzloss (razzloss)]

Marking this confirmed for now as I was actually able to reproduce this, the bad thing is I have no idea if it was because I did it 'right' or was it because I upgraded my gtk to 2.18.5. The backtrace I got had blown it's ProcessGuiQueue threads stack to hell.

The guilty party still (us or gtk) needs to be figured out.

--RZ

[Steven Sheehy (steven-sheehy)]

It's actually blocking in X waiting on more events, so not sure if Gtk+ would be at fault. Can someone try to comment out gdk_flush in linux/wulformanager.cc to see if it resolves it for them? Another alternative is to call X directly using XFlush() since the XSync() in gdk_flush() is a more expensive round-trip operation that is not necessary for our purposes (kind of nasty though).

#include <gdk/gdkx.h>

XFlush(GDK_DISPLAY_XDISPLAY(gdk_display_get_default());

[Jose Riha (jose1711)]

it's an hour now that i've been testing with changed wulformanager.cc and still cannot reproduce the bug (and i'm talking about quite intensive testing).

@razzloss: would you please mind recompiling too and checking if this fixed it for you? anyway, i'll keep it running and see what happens

[Kristoffer Grundström (umeaman)]

I've noticed this TO & my problem starts when you rightclick on a file in the Qeue to "search for alternates".
Linuxdc++ stops to respond & there's nothing else you can do beside force it to exit by clicking on the X in the top right corener.

[taresus (grip2die)]

http://en.wikipedia.org/wiki/Qt_%28toolkit%29

:)

[taresus (grip2die)]

PS: http://en.wikipedia.org/wiki/Qt_%28toolkit%29#Applications_built_using_Qt

[taresus (grip2die)]

what were the reasons for choosing GTK over Qt ?

[Jose Riha (jose1711)]

i don't think bug report is a good place for starting a discussion like this but anyway. i just wanted to say that i can no more reproduce the problem after that change in wulformanager.cc. i could be lucky or it really solved the issue. others having issues with gui: you might want to try that too.

[Steven Sheehy (steven-sheehy)]

taresus: Please don't troll.

Jose: Can you please try the XFlush as well? It should stop it from freezing plus it may offer some performance improvements from the old gdk_flush().

[Jose Riha (jose1711)]

@Steven:

XFlush(GDK_DISPLAY_XDISPLAY(gdk_display_get_default()); to be put to the same line where gdk_flush was?

[Razzloss (razzloss)]

@Jose:

Yes, (well add one ) before the ; so the parentheses match) and #include <gdk/gdkx.h> at the top of the file with the other includes. Then recompile and test. I cannot reproduce this reliably enough to say whether the change has any effect or not.

--RZ

[Jose Riha (jose1711)]

i recompiled with gdk_flush replaced by XFlush and could not see the issue anymore.

[YBatuto (yan-batuto)]

I had exactly the same issue under FreeBSD-8 (gtk-2.18.6)
After gdk_flush was replaced to XFlush I can't reproduce GUI freezing.
Thanks for patch.