Oversight in NN(6.3.5) causes coredump

[Todd Day]

I recently stumbled upon an oversight in nnmaster that causes a coredump.

I couldn't get nnmaster to run in the background, so I kept doing a
complete rebuild of the database for nn.  But, nnmaster would never
finish.  I finally found out it was getting stuck in rec.music.synth.
Yep, I found a core file in there.  So, I recompiled nnmaster with the
-g switch so I could find the problem.  Turns out it was quitting with
IOT (signal 6).  (BTW, I am running on a 68010.  I thought IOT was only
for PDP machines...)  It was getting stuck in the pack_name routine in
pack_name.c.  I figured out what article it was processing, which is
posted below.  Look at the length of the From: line.  Looks like some
garbage crept in there.

Path: ivucsb!anise.acc.com!apple!usc!bbn!rochester!daemon
From: miller at CS.ROCHESTER.EDU, , bet at orion writes: >I got the PF-85 >	 TAKING A GOOD PAIR OF HEADPHONES WITH ME! If you care about >	 the sound, this step is crucial. Amp, spea (Brad Miller)
Newsgroups: rec.music.synth
Subject: Re: Shopping for a digitally synth. electronic piano
Message-ID: <1989Sep7.205538.10037 at cs.rochester.edu>
Date: 7 Sep 89 20:55:38 GMT
Sender: daemon at cs.rochester.edu (Old Scratch)
Organization: University of Rochester Computer Science Department
Lines: 5

[msg deleted]

Anyway, the problem is in pack_name.c.  On line 174, we get a 129 character
namebuf.  Unfortunately, it looks like pack_name never checks to see if
the incoming name is longer than 128 characters!

Unfortunately, I can't make out exactly what the code is doing, so my
"bugfix" is simply to edit the message to make it more reasonable.  I'll
let someone who knows what they're doing come up with a fix.

-- 

Todd Day  |  todd at ivucsb.sba.ca.us  |  ivucsb!todd at anise.acc.com
"We live in an age where pizza gets to our house faster than the police."