Corruption of some binary articles?

Joe St Sauver JOE at OREGON.UOREGON.EDU
Fri May 25 19:53:38 UTC 2001


Hi,

I had a report from a user who was reading alt.binaries.pictures.scenic
about apparent intermittent and small scale (but annoying) binary article
payload corruption exhibiting itself on one of our reader boxes ... but
which was not exhibiting itself on another reader box of ours he tried. 

The article we ended up looking at as a demonstration of the phenomena
was <tgt3tnc3q2as1e at corp.supernews.co.uk> -- a picture of a lighthouse. 

Looking at just at the uuencoded binary itself, it was clear that there
WAS in fact a difference in the encoded article payload between the two 
boxes:

% diff lighthouse.article.a lighthouse.article.b
30,31c30,31
< M>U*!0`WMS13\8-&.`&8HIV.:,4!8;2$4[%&*+A8;BDIQI*`$I*=BDQ0(2DQ
< M3\>U``#<<4`4\@48H`S]+.;)CK/,?_`"*U7":I:.2^C6KG[SIO/U//]:N$
---
> M>U*!0`WMS13\8-&.*`&8HIV.:,4!8;2$4[%&*+A8;BDIQI*`$I*=BDQ0(2DQ
> M3\>U`%`#<<4`4\@48H`S]+.;)CCK/,?_`"*U7":I:.2^C6KG[SIO/U//]:N$

You will notice a missing asterisk in line one, and a missing %
sign and a missing C on line two of the copy of the article from
server a (versus b). 

Specifics:

-- Reader box "A" (with the apparent corruption problem): 

   - RedHat Linux running 2.4.3-pre4 SMP

   - INN 2.4.0 (20010502 prerelease)
   - CNFS
   - tradindexed 

   - built with 

     #!/bin/sh -x
     CC="gcc -D_XOPEN_SOURCE=500 -D_BSD_SOURCE"; export CC
     ./configure \
     --with-perl \
     --with-python=no \
     --with-tcl=no \
     --enable-tagged-hash=no \
     --enable-largefiles \
     --with-syslog-facility=LOG_NEWS \
     --with-sendmail=/usr/sbin/sendmail \
     --with-berkeleydb=no \
     --with-openssl=/usr/local/ssl

Reader Box "B" (withOUT the apparent corruption problem):

   - RedHat Linux running 2.2.10

   - INN 2.3.0 (20000809 prerelease)
   - CNFS
   - buffindexed

Has anyone else noticed this phenomena?

Potential corruption of encoded article body contents is obviously something
which would be Not Good.

Can anyone confirm this problem exists? Will roling to the latest snap help
eliminate this issue? (The user believes the problem began about the time we
rolled to the currently installed snap on reader box A). 

Thanks,

Joe


More information about the inn-workers mailing list