gui becomes unresponsive

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

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.

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

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?

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

this log looks more verbose (ran from build dir)

btw it did not recover after some 70 minutes

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

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)...

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+....

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

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

@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

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

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

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

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

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());

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

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.

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

:)

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

what were the reasons for choosing GTK over Qt ?

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.

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().

@Steven:

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

@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

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

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.