Problem with history - cant fgets after article

Steve Youngs sryoungs at bigpond.net.au
Fri Jan 2 14:40:12 UTC 2004 

|--==> "RA" == Russ Allbery <rra at stanford.edu> writes:
  RA> Try upgrading to a current STABLE snapshot from INN 2.4.0.
  RA> There was a bug in INN that caused it to die when processing
  RA> certain malformed messages, and I'm wondering if you're running
  RA> into that.

Hi Russ!

I, too, have had the "can't fgets after article" problem for ages
now.  Today I built/installed inn-STABLE-20040101, and yes, it _still_
has the problem.

I can trigger it every time without fail with `rnews -U'.

Here's a backtrace from rnews:

GNU gdb 5.2
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-slackware-linux"...
(gdb) run -U
Starting program: /usr/local/news/bin/rnews -U

Program received signal SIGPIPE, Broken pipe.
0x40101708 in write () from /lib/libc.so.6
(gdb) bt
#0  0x40101708 in write () from /lib/libc.so.6
#1  0x40160d24 in __DTOR_END__ () from /lib/libc.so.6
#2  0x4009dd2e in new_do_write () from /lib/libc.so.6
#3  0x4009dcc6 in _IO_new_do_write () from /lib/libc.so.6
#4  0x4009e969 in _IO_new_file_sync () from /lib/libc.so.6
#5  0x4009318a in fflush () from /lib/libc.so.6
#6  0x0804baba in main (ac=0, av=0xbffff81c) at rnews.c:926
#7  0x40043d06 in __libc_start_main () from /lib/libc.so.6
(gdb) quit


And here's one from innd (attaching gdb to the running innd and then
doing `rnews -U' from another console):

GNU gdb 5.2
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-slackware-linux".
(gdb) attach 22516
Attaching to process 22516
Reading symbols from /usr/local/news/bin/innd...done.
Reading symbols from /usr/lib/libtcl.so...done.
Loaded symbols for /usr/lib/libtcl.so
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libpthread.so.0...done.
[New Thread 16384 (LWP 22516)]
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libutil.so.1...done.
Loaded symbols for /lib/libutil.so.1
Reading symbols from /usr/local/lib/perl5/5.8.0/i586-linux-thread-multi/CORE/libperl.so...done.
Loaded symbols for /usr/local/lib/perl5/5.8.0/i586-linux-thread-multi/CORE/libperl.so
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/python2.2/lib-dynload/strop.so...done.
Loaded symbols for /usr/lib/python2.2/lib-dynload/strop.so
0x4034f5e2 in select () from /lib/libc.so.6
(gdb) cont
Continuing.

Program received signal SIGSTOP, Stopped (signal).
[Switching to Thread 16384 (LWP 22516)]
0x4034f5e2 in select () from /lib/libc.so.6
(gdb) bt
#0  0x4034f5e2 in select () from /lib/libc.so.6
#1  0x00000000 in ?? ()
(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x402ebf8f in _int_malloc () from /lib/libc.so.6
(gdb) bt
#0  0x402ebf8f in _int_malloc () from /lib/libc.so.6
#1  0x402eaf1a in malloc () from /lib/libc.so.6
#2  0x403300b2 in re_node_set_init_2 () from /lib/libc.so.6
#3  0x40332762 in calc_epsdest () from /lib/libc.so.6
#4  0x40332590 in analyze_tree () from /lib/libc.so.6
#5  0x4033257e in analyze_tree () from /lib/libc.so.6
#6  0x4033257e in analyze_tree () from /lib/libc.so.6
#7  0x4033257e in analyze_tree () from /lib/libc.so.6
#8  0x4033257e in analyze_tree () from /lib/libc.so.6
#9  0x4033257e in analyze_tree () from /lib/libc.so.6
#10 0x4033257e in analyze_tree () from /lib/libc.so.6
#11 0x4033257e in analyze_tree () from /lib/libc.so.6
#12 0x4033257e in analyze_tree () from /lib/libc.so.6
#13 0x4033257e in analyze_tree () from /lib/libc.so.6
#14 0x4033257e in analyze_tree () from /lib/libc.so.6
#15 0x4033257e in analyze_tree () from /lib/libc.so.6
#16 0x4033257e in analyze_tree () from /lib/libc.so.6
#17 0x4033257e in analyze_tree () from /lib/libc.so.6
#18 0x4033257e in analyze_tree () from /lib/libc.so.6
#19 0x4033257e in analyze_tree () from /lib/libc.so.6
#20 0x4033257e in analyze_tree () from /lib/libc.so.6
#21 0x4033257e in analyze_tree () from /lib/libc.so.6
#22 0x4033257e in analyze_tree () from /lib/libc.so.6
#23 0x4033257e in analyze_tree () from /lib/libc.so.6
#24 0x4033257e in analyze_tree () from /lib/libc.so.6
#25 0x4033257e in analyze_tree () from /lib/libc.so.6
#26 0x4033256c in analyze_tree () from /lib/libc.so.6
#27 0x4033256c in analyze_tree () from /lib/libc.so.6
#28 0x4033257e in analyze_tree () from /lib/libc.so.6
#29 0x4033257e in analyze_tree () from /lib/libc.so.6
#30 0x403324e8 in analyze () from /lib/libc.so.6
#31 0x40331f19 in re_compile_internal () from /lib/libc.so.6
#32 0x4033196c in regcomp () from /lib/libc.so.6
#33 0x080697d2 in KEYgenerate (hc=0x403ddf64, 
    body=0x822f233 "In article <slrnbv9t3p.3qs.usenet at dustpuppy.no-dns-yet.org.uk>,\r\n  Simon wrote:\r\n> I thought most of those sorts of systems had a CD writer or CD-RW.  If\r\n> there was one, I might have used that, sinc"..., v=0x0, 
    l=0) at keywords.c:127
#34 0x0805e88a in ARTmakeoverview (cp=0x403dd938) at art.c:1714
#35 0x080607ba in ARTpost (cp=0x403dd938) at art.c:2307
#36 0x0806a42b in NCpostit (cp=0x403dd938) at nc.c:196
#37 0x0806c30f in NCproc (cp=0x403dd938) at nc.c:985
#38 0x0806ccfb in NCreader (cp=0x403dd938) at nc.c:1188
#39 0x08066f0d in CHANreadloop () at chan.c:1062
#40 0x0806968e in main (ac=0, av=0xbffffe54) at innd.c:666
#41 0x40289d06 in __libc_start_main () from /lib/libc.so.6
(gdb) quit

My suspicion is that glibc is the culprit.  I've got this horrible
nagging feeling that I first saw this after a libc upgrade (I'm
currently running glibc 2.3.2).

Let me know if there is anything more that I could do to help get to
the bottom of this.

HTH

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|              Ashes to ashes, dust to dust.               |
|      The proof of the pudding, is under the crust.       |
|------------------------------<sryoungs at bigpond.net.au>---|


-- Attached file included as plaintext by Ecartis --

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Eicq - The XEmacs ICQ Client <http://eicq.sf.net/>

iEYEABECAAYFAj/1gtIACgkQHSfbS6lLMAMFAwCdGj+GNmipOxJ+SHrmd/Z0nwsw
y5wAn18Ogx7TTRb7HyMqJIap5GEecHJF
=cggv
-----END PGP SIGNATURE-----

More information about the inn-workers mailing list