Fri 18 Jul 2008 09:24:37 PM UTC, comment #13:
No, not really.
This is what I did yesterday:
cat <<EOF > /tmp/xx
chdir /foo/bar
chdir /foojlkjhlkjhljkhkjhlkjhlkjhlkjhlkjhlkjhlkjhlkjhlkjhhlkjhlkj/bar
EOF
ltrace -f -o x -s500 ./screen -c /tmp/xx
But as soon as tried to approach this with gdb or valgrind, everything was okay.
|
Fri 18 Jul 2008 08:07:04 PM UTC, comment #12:
Sounds like it's not just a FreeBSD thing, then.
Juergen, I don't suppose you can craft a script that reproduces this reliably for you?
|
Fri 18 Jul 2008 09:47:17 AM UTC, comment #11:
I was testing on latest SUSE linux with latest git checkout.
Have no FreebSD here, sorry.
My concern is, that his resolution is just no longer triggering the bug, although it is still there.
|
Thu 17 Jul 2008 10:34:29 PM UTC, comment #10:
Hm, Juergen, were you also testing on FreeBSD? The OP apparently resolved the issue simply by an updated ports tree; it seems that either the issue was originally with the package, or else the packager found the problem and fixed it (in which case, it'd have been better if they'd notified us...).
Perhaps looking at the last couple versions of the FreeBSD screen package will be informative.
Reopening so we don't forget to check it out, to be sure.
|
Thu 17 Jul 2008 12:59:04 PM UTC, comment #9:
I'd suspect this is the strncpy() in screen.c:Msg().
Is it possible that strerror() returns NULL in FreeBSD?
Still I doubt, this is the cause.
I tried to reproduce, and had a crash, while running under ltrace, but no crash while under gdb.
the crash with ltrace happened at different locations.
once in execve(), once in unlockpt() and once in strcmp_chk().
This indicates memory corruption.
|
Thu 17 Jul 2008 03:52:58 AM UTC, comment #8:
Hm. Wonder if it was a FreeBSD packager's patch, then. Thanks for the update!
|
Thu 17 Jul 2008 02:41:45 AM UTC, comment #7:
I've updated to the latest ports version and now the non-debug version works too so this really can be closed (I don't seem to have permissions to do it myself though).
|
Wed 16 Jul 2008 08:59:52 PM UTC, comment #6:
Does "make WITH_DEBUG=1" do anything besides adding a -g flag to compilation? If so, you might hack the sources or makefile (or possibly just set your own CFLAGS) so that -g is added, without making any other changes from what a normal make would do.
As it is, it's somewhat instructive to at least see that it segfaults in a string-copying function. But yeah, not enough information.
|
Wed 16 Jul 2008 08:29:58 PM UTC, comment #5:
Unfortunately this bug is nastier than I thought -- it doesn't manifest itself when screen is built with debug ("make WITH_DEBUG=1" in /usr/ports/sysutils/screen). And while I can still it reproduce it 100% reliably with the packaged version it doesn't have any symbols and so doesn't provide any useful information:
Program terminated with signal 11, Segmentation fault.
(gdb) bt
#0 0x0000000800aaf858 in strncpy () from /lib/libc.so.6
#1 0x000000000040398b in ?? ()
#2 0x000000000042f1fb in ?? ()
#3 0x0000000000430c12 in ?? ()
#4 0x000000000040f1be in ?? ()
#5 0x000000000040fdd5 in ?? ()
#6 0x0000000000407af0 in ?? ()
#7 0x0000000000402f2e in ?? ()
#8 0x000000080056f000 in ?? ()
#9 0x0000000000000000 in ?? ()
... and so on and so forth but the last frame is obviously invalid so it doesn't matter ...
I guess this bug should be forwarded to screen port maintainer in FreeBSD but unfortunately I don't even know how to do it.
Anyhow, I don't see what you can do about it if you can't reproduce it so I guess it should be just closed.
Thanks,
VZ
|
Fri 11 Jul 2008 01:59:47 AM UTC, comment #4:
I cannot seem to reproduce this in Linux, either in 4.0.03 or in the git version. A backtrace would indeed be helpful.
|
Mon 16 Jun 2008 01:40:14 AM UTC, comment #3:
Mostly, it just means I'll look into it when I can (and I need to verify that it's still a problem, look into appropriate solutions, etc).
|
Sun 15 Jun 2008 11:36:25 AM UTC, comment #2:
Is there anything I can do in order to confirm this bug?
Thanks!
|
Sun 28 Jan 2007 02:46:45 PM UTC, comment #1:
Oops, sorry, I forgot to mention that this is for amd64 version.
|
Sun 28 Jan 2007 02:42:36 PM UTC, original submission:
Reproduced in a freshly installed (in a VmWare 6 virtual machine but it really shouldn't matter) FreeBSD 6.2 system:
1. Install screen version 4.00.03 (FAU) 23-Oct-06 from the ports collection in the usual way (i.e. "make" without any special options)
2. screen works
3. echo "chdir /bloordyblop > ~/.screenrc"
4. now screen core dumps (can recompile with stack available if needed, i.e. if there is any problem with reproducing this)
FWIW chdir without argument and chdir to an existing directory work just fine.
|