Tue 17 Jul 2012 02:25:03 PM UTC, comment #8:
Ok, thank you for giving the info.
|
Tue 17 Jul 2012 02:17:13 PM UTC, comment #7:
After fiddling around for a while I found some more reports of similar issues (but not related to weechat):
http://cygwin.com/ml/cygwin/2009-12/msg00586.html
http://old.nabble.com/Strange-lock-problem-under-screen-4.00.02-03-td14248045.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609444
In one of the links the issue has been related to a bug in libevents which would make sense with the previous comment, but I'm not sure, it's not my server so I can't update the library.
I have not found a real solution, but I did find a workaround. I can unfreeze the session by forcing the it to detach in other places when I reattach, e.g.,:
tmux attach -d
screen -d -r
It's not perfect as you can only attach with only one terminal at a time. But it's better than a frozen screen I guess.
This is obviously not a weechat problem so I will stop bothering you here, just posting this workaround in case anyone encounters a similar problem. Thank you for the quick support!
|
Tue 17 Jul 2012 11:21:46 AM UTC, comment #6:
I think that it's not WeeChat fault, yes.
According to your trace (your first paste), WeeChat was in the main select(), waiting for events (on sockets or keyboard). So I think WeeChat is not frozen, but waiting for events.
|
Tue 17 Jul 2012 09:52:39 AM UTC, comment #5:
I will try that out. I have mode an interesting observation however.
Based on these links:
http://osdir.com/ml/gnu.screen.user/2007-08/msg00001.html
http://superuser.com/questions/227901/gnu-screen-unable-to-reattach-to-screen-after-lost-connection
The problem only occurs if the session is not cleanly detached! In OSX I'm used to doing it the dirty way by just closing my Terminal tab with ctrl-w. This results in the "hang" if I reattach and switch buffers. If I detach cleanly (Ctrl-a d in screen, or ctrl-b d in tmux) all is well.
I think this means this might not be weechat's fault. It might trigger something during the redrawing phase, I guess I don't have weechat to blame ?
|
Sun 15 Jul 2012 09:31:10 PM UTC, comment #4:
Very strange problem, first time I heard about such problem (I'm myself using WeeChat + screen for almost 10 years, without any problem!)
Can you try WeeChat on another machine? If possible using a binary package, from your distro (so that we are sure this is not a compilation problem). By the way, cmake is the preferred way to compile, but it should not freeze at all with ./configure anyway.
If you still have same problem on other machines, then the only solution for me would be to have an account on machine with problem, so that I can test. Let me know if it's possible (feel free to contact me on IRC).
|
Sun 15 Jul 2012 09:24:29 PM UTC, comment #3:
Even when start a vanilla weechat with just the core buffer open, it happens. I detach the sessions, when I attach it still works, but as soon as I trigger a buffer redraw (eg "/connect chat.freenode.net") the freeze occurs.
|
Sun 15 Jul 2012 09:16:42 PM UTC, comment #2:
Still happens.
Forgot to mention that on both servers where I tried it, weechat was built from source, using ./configure and make (in case it matters).
|
Sun 15 Jul 2012 08:59:55 PM UTC, comment #1:
Can you try without scripts loaded and default WeeChat config?
For example with this command:
|
Sun 15 Jul 2012 08:22:53 PM UTC, original submission:
I run weechat in linux under a screen/tmux. I am having an issue where I can make weechat freeze consistently. I start a screen session, I run weechat and detach from the session. When I attach it again weechat still works, but as soon as I switch buffers weechat freezes, becomes unresponsive and I have to kill it.
The freeze happens during the drawing phase of the next buffer. The refresh starts but somewhere in the middle of the screen it stops and hangs, showing half of the new buffer and half of the old buffer.
I have tried it on two servers, in both tmux and screen , but it happens consistently everywhere. I can easily reproduce it.
I took the debugging steps as described, and have pasted the output of gdb here:
http://pastebin.com/cXTzmxGu
Feel free to contact me if you need more info
|