bugWeeChat - Bugs: bug #36851, weechat freeze on detach/attach of...

 
 

bug #36851: weechat freeze on detach/attach of screen or tmux

Submitter:  None
Submitted:  Sun 15 Jul 2012 08:22:53 PM UTC
   
 
Category:  display Severity:  3 - Normal
Item Group:  display Status:  Invalid
Privacy:  Public Assigned to:  flashcode
Originator Name:  rroels Originator Email:  * -email is unavailable-
Open/Closed:  Closed Release:  * 0.3.8
IRC nick: 
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 17 Jul 2012 02:25:03 PM UTC, comment #8: 

Ok, thank you for giving the info.

Sebastien Helleu <flashcode>
Group administrator
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!

Reinout Roels <rroels>
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.

Sebastien Helleu <flashcode>
Group administrator
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 ?

Reinout Roels <rroels>
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).

Sebastien Helleu <flashcode>
Group administrator
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.

Reinout Roels <rroels>
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).

Reinout Roels <rroels>
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:

weechat-curses --dir /tmp/weechat


Sebastien Helleu <flashcode>
Group administrator
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

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rroels (Posted a comment)
  • -email is unavailable- added by flashcode (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-09-29 flashcode Open/ClosedOpen Closed
    2012-07-17 flashcode StatusNeed Info Invalid
    2012-07-15 flashcode StatusNone Need Info
        Assigned toNone flashcode

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code