Discussion:
tin-2.0.0 segfaults in process_mapping()
Urs Janßen
2011-09-05 05:58:28 UTC
Permalink
Hi,
'uname -rms' -> Linux 3.0.4-spott x86_64
bleeding edge kernel? also bleeding edge libc or compiler?
$ tin -V
Version: tin 2.0.0 release 20110823 ("Ardenistiel") Aug 29 2011 23:35:29
tin 2.0.0 release 20110823 ("Ardenistiel") [UNIX] (c) Copyright 1991-2011 Iain Lea.
Connecting to 127.0.0.1...
Leafnode NNTP daemon, version 2.0.0.alpha20110815a.luascript at nntp.spotteswoode.dnsalias.org
Reading keymap file...
Program received signal SIGSEGV, Segmentation fault.
0x0000000000434842 in process_mapping (keyname=
incomplete CFI data; unspecified registers (e.g., rax) at 0x4397b4...
0xffffffffffffd750 <Address 0xffffffffffffd750 out of bounds>, keys=0x7fffffffd75d "[\t]") at ./keymap.c:549
549 switch (keyname[0]) {
(gdb) w
#0 0x0000000000434842 in process_mapping (keyname=0xffffffffffffd750 <Address 0xffffffffffffd750 out of bounds>, keys=0x7fffffffd75d "[\t]") at ./keymap.c:549
#1 0x00000000004345a5 in read_keymap_file () at ./keymap.c:414
#2 0x00000000004411f8 in main (argc=2, argv=0x7fffffffdcb8) at ./main.c:238
(gdb) l
544 static t_bool
545 process_mapping(
546 char *keyname, /* Keyname we're searching for */
547 char *keys) /* Key to assign to keyname if found */
548 {
549 switch (keyname[0]) {
551 if (strcmp(keyname, "AttachPipe") == 0) {
552 process_keys(ATTACHMENT_PIPE, keys, &attachment_keys);
553
(gdb) bt full
#0 0x0000000000434842 in process_mapping (
keyname=0xffffffffffffd750 <Address 0xffffffffffffd750 out of bounds>, keys=0x7fffffffd75d "[\t]")
at ./keymap.c:549
No locals.
#1 0x00000000004345a5 in read_keymap_file () at ./keymap.c:414
fp = 0x7f0fa0
line = 0x7fffffffd75d "[\t]"
keydef = 0x7fffffffd75d "[\t]"
kname = 0xffffffffffffd750 <Address 0xffffffffffffd750 out of bounds>
map = 0x7ec580 "/root/.tin/keymap"
ptr = 0x7ec2e5 ""
buf = "GroupListThd\000[\t]\000\000eynames is bound to NULL it is unassigned.\n\000and their\n\000 $\n\000\177\000\000\240\325\377\377\377\177\000\000\247\325\377\377\377\177\000\000\370\001\000\000\000\000\000\000\377\001\000\000\000\000\000\000\001\000\000\000\000\000\000\000p\000\000\000\000\000\000\000`v|\000\000\000\000\000\200\n\000\000\000\000\000\000\240lz\000\000\000\000\000\360\331\335\367\377\177\000\000\240lz\000\000\000\000\000\264??\367\377\177\000\000\000\000\000\000\377\177\000\000\020\330\377\377.\000\000\000\000\002\000\000\000\000\000\000\245r0\367\377\177\000\000\240lz", '\000' <repeats 13 times>"\240, lz\000\000\000\000\000\340k|\000\000\000\000\000\374"...
buff = "keymap.en_US\000\177\000\000\350\331\335\367\377\177\000\000\000\000\000\000\000\000\000\000`Sx\000\000\000\000\000\020\327\377\377\377\177\000\000\260\270\273\367\377\177\000\000\360\331\335\367\377\177\000\000\000\000\000\000\000\000\000\000/\000\000\000\000\000\000\000\020", '\000' <repeats 15 times>"\377, \377\377\377\000\000\000\000T\037\272\367\377\177\000\000\bwz\000\000\000\000\000\255??\367\377\177\000\000aSx\000\377\377\377\377\000\000\000\000\000\000\000\000\033[48;1H\000\000\001\000\000\000\000\000\000\000\273~\000p\000\000\000\000u/\367\377\177\000\000`Sx\000\000\000\000\000\200\273~", '\000' <repeats 68 times>
filename = "/root/.tin/keymap", '\000' <repeats 4078 times>
upgrade = RC_IGNORE
ret = 1
#2 0x00000000004411f8 in main (argc=2, argv=0x7fffffffdcb8) at ./main.c:238
count = 4213344
num_cmd_line_groups = 0
start_groupnum = 0
tmp_no_write = 0
GroupListThd [ ]
NB: the mapping is "[", "TAB", "]" to map both "[" and "]". The
GroupListThd [
GroupListThd ]
bombs out the same way.
I can't reproduce this (i686-pc-linux-gnu; linux 3.0.0; gcc 4.6.1;
eglibc 2.13) and I don't see any obvious errors in keymap.c.
I'll check some other systems/compilers over the week

urs
Urs Janßen
2011-09-05 18:01:22 UTC
Permalink
CPPFLAGS = "-D_XOPEN_SOURCE=500"
looks strange for a linux system, I would expect -D_GNU_SOURCE.
When I set CPPFLAGS to -D_XOPEN_SOURCE=500 before doing configure I can
reproduce the error:

Program received signal SIGSEGV, Segmentation fault.
read_keymap_file () at ./keymap.c:414

as long as include/autoconf.h also has HAVE_STRSEP. As soon as I
undefine HAVE_STRSEP in include/autoconf.h it no longer crashes.

just a guess:

configure somehow defines _XOPEN_SOURCE=500 but doesn't honor it
when looking for strsep(3) which AFAIK is only available if _BSD_SOURCE
is defined (which is the case when _GNU_SOURCE is defined). I'd expect
it to fail at linking, but ...

Clemens, at a quick fix: after configure you could use something like
sed 's,define HAVE_STRSEP 1,undef HAVE_STRSEP,' -i include/autoconf.h

But the more interresting part is, why didn't you get _GNU_SOURCE defined
(did you manually set CPPFLAGS to -D_XOPEN_SOURCE=500?) and why did the
configure check still finds strsep...
Can you provide us your config.log?

Thomas would you mind looking into this?

urs
--
"Only whimps use tape backup: _real_ men just upload their important stuff
on ftp, and let the rest of the world mirror it ;)" - Linus
Thomas Dickey
2011-09-05 18:03:13 UTC
Permalink
Post by Urs Janßen
CPPFLAGS = "-D_XOPEN_SOURCE=500"
looks strange for a linux system, I would expect -D_GNU_SOURCE.
I would expect _GNU_SOURCE to be set, since that's a long-standing
configure check.
Post by Urs Janßen
But the more interresting part is, why didn't you get _GNU_SOURCE defined
(did you manually set CPPFLAGS to -D_XOPEN_SOURCE=500?) and why did the
configure check still finds strsep...
Can you provide us your config.log?
that would help
Post by Urs Janßen
Thomas would you mind looking into this?
ok
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Urs Janßen
2011-09-05 18:48:12 UTC
Permalink
Post by Urs Janßen
CPPFLAGS = "-D_XOPEN_SOURCE=500"
looks strange for a linux system, I would expect -D_GNU_SOURCE.
When I set CPPFLAGS to -D_XOPEN_SOURCE=500 before doing configure I can
on x86_64 linux but not on a 32bit system so I might be that the
strsep(3) implementation for _XOPEN_SOURCE=500 on x86_64 is broken.

crash: x86_64-unknown-linux-gnu; linux 2.6.24; glibc 2.7; gcc 4.2.4
crash: x86_64-unknown-linux-gnu; linux 2.6.24; glibc 2.7; icc 12.0.5
crash: x86_64-unknown-linux-gnu; linux 2.6.38; eglibc 2.13; gcc 4.5.2
ok : i686-pc-linux-gnu; linux 3.0.0; eglibc 2.13; gcc 4.6.1
Thomas Dickey
2011-09-05 20:50:39 UTC
Permalink
Post by Urs Janßen
Post by Urs Janßen
CPPFLAGS = "-D_XOPEN_SOURCE=500"
looks strange for a linux system, I would expect -D_GNU_SOURCE.
When I set CPPFLAGS to -D_XOPEN_SOURCE=500 before doing configure I can
on x86_64 linux but not on a 32bit system so I might be that the
strsep(3) implementation for _XOPEN_SOURCE=500 on x86_64 is broken.
crash: x86_64-unknown-linux-gnu; linux 2.6.24; glibc 2.7; gcc 4.2.4
crash: x86_64-unknown-linux-gnu; linux 2.6.24; glibc 2.7; icc 12.0.5
crash: x86_64-unknown-linux-gnu; linux 2.6.38; eglibc 2.13; gcc 4.5.2
ok : i686-pc-linux-gnu; linux 3.0.0; eglibc 2.13; gcc 4.6.1
I suppose that's possible, since it's implemented via inlining on Linux
(looking at /usr/include/bits/string2.h on my local machine).
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Urs Janßen
2011-09-06 08:16:59 UTC
Permalink
Post by Urs Janßen
Clemens, at a quick fix: after configure you could use something like
sed 's,define HAVE_STRSEP 1,undef HAVE_STRSEP,' -i include/autoconf.h
Bingo! Now tin doesn't crash anymore, but I cannot use the arrow-keys
for cursor movement. I'm certain the problem can be fixed.
shouldn't be strsep(3) related, but might be caused by defining
_XOPEN_SOURCE=500 instead of _GNU_SOURCE. To find out why that happens
on your side your config.log would be helpfull.
I wonder if it has to do with usr/include/sys/param.h versus
usr/include/sys/params.h. Note the trailing plural 's'. Arch-linux has
param.h, but no params.h
that's ok

Loading...