Sun 14 Mar 2010 11:12:06 PM UTC, comment #9:
Thanks for the report, and testing the fix.
|
Tue 09 Mar 2010 10:02:20 AM UTC, comment #8:
I didn't see this any more for 4 days now, so I consider this fixed.
|
Sat 06 Mar 2010 02:20:19 PM UTC, comment #7:
No coredumps so far.
I still have to reproduce that bug again. It usually appeared at least once a day, but now hasn't appeared since two days, so it looks to me like this is fixed (probably with one of the invalid memory accesses).
The hanging pause() call was before pulling your memory fixes.
|
Fri 05 Mar 2010 11:31:56 PM UTC, comment #6:
That looks like a 'client' waiting to connect to a server. But it should stop pausing after ~15 seconds. Does it not?
The server probably died underneath ... is there a coredump for that? You can also build with debug (-DDEBUG), and see if there's something interesting in /tmp/debug/screen. (or SCREEN.) files.
The valgrind log looks pretty clean. Screen can't do much about the leaks listed since they are not controlled by screen.
|
Wed 03 Mar 2010 08:41:22 PM UTC, comment #5:
Here's a backtrace from a hanging screen:
|
Wed 03 Mar 2010 05:24:47 PM UTC, comment #4:
Next valgrind logfile, with current git.
I see no errors any more, just leaks. And valgrind reports error counts, but doesn't list any errors.
Again no hang, valgrind seems to prevent screen from hanging.
(file #19843)
|
Wed 03 Mar 2010 04:53:21 PM UTC, comment #3:
Yes, I have a habit of always setting ulimit -c unlimited.
I've just pulled master and merged with my patched branch. (If you want me to test without the %E patch, I can do that, but I really prefer to use it.)
Running valgrind with valgrind --log-file=valgrind.screen.%p.log --leak-check=full --track-origins=yes screen
Last time I dropped the --leak-check=full, because I just wanted to see the memory errors.
|
Wed 03 Mar 2010 04:21:23 PM UTC, comment #2:
Thanks. The valgrind log is very useful. One of the invalid memory reads was fixed earlier (in 4f28ba8c8f). I have committed a fix for the remaining invalid reads (da8e87d6505). If you run screen in valgrind again, if you could use the latest version, that would be great. Thanks again!
To get a coredump, do you have 'ulimit -c' set appropriately? (I set 'ulimit -c unlimited' myself).
|
Wed 03 Mar 2010 12:14:24 PM UTC, comment #1:
Attaching valgrind output from yesterday. But I didn't see a freeze/crash while valgrind was supervising screen. I'll try again now.
(file #19842)
|
Wed 03 Mar 2010 12:12:30 PM UTC, original submission:
Hi!
I recently pulled b6dd7d868756eccc06aa4b9ef6c2098d41ceaa86 from git and applied ben love's patch from https://savannah.gnu.org/bugs/?27713 to try out the %E string escape. I'm using the hardstatus given in https://savannah.gnu.org/bugs/?27713#comment3
Sometimes after I terminate a shell or program in screen, my screen session will hang, and when I start a new shell I see a dead screen session, but no coredump.
I can't reproduce this behaviour, but one or all of the following factors coincide with it:
- running mutt, reading all my new mails
- running screen via ssh on another host, possibly also starting mutt
- running rtorrent or another application that has some involved text ui
Since I have no coredump, I thought running valgrind might be a good idea and I see some invalid reads there, which might be related to this behaviour.
|