Re: Segfault when reading group

[fullqote due to list change to tin-dev]

On Thu, Feb 17, 2005 at 10:39:08PM +0100, Philip Paeps wrote:
> Recently, while trying to load comp.unix.bsd.freebsd.misc, Tin segfaults
> around 98%.  I'm seeing this with the last couple of snaps (can't remember
> exactly when it started, but I can try to narrow it down) on FreeBSD-current
> running on x86.
> 
> Running Tin in a debugger, gives me this stack trace:
> 
> Group comp.unix.bsd.freebsd.misc ('q' to quit)...  98% (0:00 remaining)
> Program received signal SIGSEGV, Segmentation fault.
> 0x0809716d in rfc1522_do_encode (what=0x9668a20 '.' <repeats 200 times>..., where=0x3d45323d, 
>     charset=0x323d4532 <Error reading address 0x323d4532: Bad address>, break_long_line=1160920389) at ././rfc2047.c:620
> 620                                             if (ewsize >= 70 - strlen(charset) && (contains_nonprintables(what, isstruct_head) || isbroken_within)) {
> (gdb) bt
> #0  0x0809716d in rfc1522_do_encode (what=0x9668a20 '.' <repeats 200 times>..., where=0x3d45323d, 
>     charset=0x323d4532 <Error reading address 0x323d4532: Bad address>, break_long_line=1160920389) at ././rfc2047.c:620
> #1  0x323d4532 in ?? ()
> #2  0x45323d45 in ?? ()
> #3  0x3d45323d in ?? ()
> #4  0x323d4532 in ?? ()
> #5  0x45323d45 in ?? ()
> #6  0x3d45323d in ?? ()
> #7  0x323d4532 in ?? ()
> #8  0x45323d45 in ?? ()
> #9  0x3d45323d in ?? ()
> #10 0x323d4532 in ?? ()
> #11 0x083d3f45 in ?? ()
> #12 0x00000000 in ?? ()
> #13 0x0966f788 in ?? ()
> #14 0x080cf3c0 in date.2 ()
> #15 0x080cf3a4 in once_only.1 ()
> #16 0x09672740 in ?? ()
> #17 0x095b9380 in ?? ()
> #18 0x00000000 in ?? ()
> #19 0x00000024 in ?? ()
> #20 0xbfbfe0f8 in ?? ()
> #21 0x080cf3a4 in once_only.1 ()
> #22 0x00000000 in ?? ()
> #23 0x096bd000 in ?? ()
> #24 0x283267d0 in __isthreaded () from /lib/libc.so.6
> #25 0x00000b9a in ?? ()
> #26 0x00000000 in ?? ()
> #27 0x00000000 in ?? ()
> #28 0xbfbfe128 in ?? ()
> #29 0x0804ce57 in index_group (group=Error accessing memory address 0x3d453245: Bad address.
> ) at ././art.c:463
> Previous frame inner to this frame (corrupt stack?)
> (gdb)
> 
> Frame 29 looks interesting, it appears to be the start of the problem, but I
> can't seem to get that narrowed down.  When I break on art.c:463, I get gdb to
> hang on me after I step through the function a few times.  That's probably gdb
> broken, rather than tin.
> 
> As for frame 0, not very exciting:
> 
> (gdb) l   
> 463                     write_overview(group);
> 464
> 465             /*
> 466              * Create the reference tree. The msgid and ref ptrs will
> 467              * be free()d now that the NovFile has been written.
> 468              */
> 469             build_references(group);
> 470
> 471             /*
> 472              * Needs access to the reference tree
> 
> (gdb) l rfc2047.c:620
> 615     /*
> 616      * if a word with 8bit chars is broken in the middle, whatever follows
> 617      * after the point where it's split should be encoded (i.e. even if
> 618      * they are made of only 7bit chars)
> 619      */
> 620                                             if (ewsize >= 70 - strlen(charset) && (contains_nonprintables(what, isstruct_head) || isbroken_within)) {
> 621                                                     *t++ = ' ';
> 622                                                     ewsize++;
> 623                                             }
> 624                                             quoting = FALSE;
> 
> 
> Does anyone have any ideas on how to hunt this down a bit further?  I've been
> reading through the bits of art.c and rfc2047.c that look interesting, but I
> can't see anything immediately fishy there.  I guess something might be
> confusing the strlen(), but I fail to see how...
> 
> Any hints welcome :-)

here is what I would do,
manually obtain a copy of the overview data from the group and
examine all the From and Subject fields which are RFC2047 encoded,
and see if something looks strange, then feed the crashing function
with that strange data only  and see if it causes the crash.

e.g.:
~ > script cubfm.log
Script started, file is cubfm.log
~ > telnet news nntp
> trying 127.0.0.1
> Connected to news.
< 200 posting ok
> GROUP comp.unix.bsd.freebsd.misc
< 211 1 1 2 comp.unix.bsd.freebsd.misc
> XOVER -
< 224 data follows
[...]
< .
> QUIT
< 205 .
< Connection closed by foreign host.
~ > exit
Script done, file is cubfm.log
~ > awk -F'	' '/=\?/{print "N:#"$1"# S:#"$2"# F:#"$3"#"}' < cubfm.log
[fieldseperator is tab]

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