gnu@hoptoad.uucp (John Gilmore) (05/13/88)
This news article showed up today on hoptoad, causing a failure when C
news tried to mail a reply to the address in the Path: line (because
mail uses uux, and Sun's uux can't handle long command lines due to
statically allocated buffers):
Path: hoptoad!pacbell!ames!ncar!oddjob!nosuch!sitesas!these!madeup!namesin!hereexist!ijust!addedthem!tomakethe!pathline!aslongas!theonein!theother!testmessage!thatisent!atthesame!timeas!thisone!iamsure!youseewhy!oddjob.uchicago.edu!bbtest1
From: bbtest1@oddjob.uchicago.edu (Matt Crawford)
Newsgroups: news.admin.ctl
Subject: version
Message-ID: <test-2@oddjob.uchicago.edu>
Date: 12 May 88 18:22:47 GMT
Control: version
Reply-To: bbtest2@oddjob.uchicago.edu (Matt Crawford)
Distribution: usa
Organization: University of Chicago
Lines: 0
Approved: Matt
Later, reply mail came through from one of the sites that we forwarded
the article to (their uux has been fixed, I guess). But this caused
our uuxqt to coredump as long as the X.file for the message was in the
execute queue. Another statically allocated buffer! When uuxqt
coredumps, it leaves around the /usr/spool/uucp/LCK.XQT file, so no
uuxqt's will run again until someone manually removes this file (at
which point the next uuxqt will coredump again). You have to move the
bad X. file out of the spool directory before you can process the rest
of the incoming news and mail. Here's what it looked like on hoptoad:
U daemon utzoo
F D.hoptoadB5d75
I D.hoptoadB5d75
C rmail pacbell!ames!ncar!oddjob!nosuch!sitesas!these!madeup!namesin!hereexist!ijust!addedthem!tomakethe!pathline!aslongas!theonein!theother!testmessage!thatisent!atthesame!timeas!thisone!iamsure!youseewhy!oddjob.uchicago.edu!bbtest1
Looks like a fun terrorist trick, it will certainly stop uucp execution
on all the Suns on the net...
Maybe Matt can explain the point of this; iamsure!idont!seewhy.
John Gilmore
--
John Gilmore {sun,pacbell,uunet,pyramid,ihnp4}!hoptoad!gnu gnu@toad.com
"Use the Source, Luke...."csg@pyramid.pyramid.com (Carl S. Gutekunst) (05/14/88)
If it's any consolation, Sun is switching to BNU (aka HoneyDanBer) in SunOS 4.0. So you can all stop groaning and moaning about Sun's UUCP.... Of course, that doesn't help any with the problem you have *now*. :-( <csg>
honey@umix.cc.umich.edu (Peter Honeyman) (05/14/88)
4.1, not 4.0 peter
darylm@Zaephod.gwd.tek.com (Daryl V. McDaniel) (05/17/88)
In article <4578@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >This news article showed up today on hoptoad, causing a failure when C >news tried to mail a reply to the address in the Path: line (because >mail uses uux, and Sun's uux can't handle long command lines due to >statically allocated buffers): ... deleted stuff ... >... Here's what it looked like on hoptoad: > > U daemon utzoo > F D.hoptoadB5d75 > I D.hoptoadB5d75 > C rmail pacbell!ames!ncar!oddjob!nosuch!sitesas!these!madeup!namesin!hereexist!ijust!addedthem!tomakethe!pathline!aslongas!theonein!theother!testmessage!thatisent!atthesame!timeas!thisone!iamsure!youseewhy!oddjob.uchicago.edu!bbtest1 ... deleted stuff ... > John Gilmore >-- >John Gilmore {sun,pacbell,uunet,pyramid,ihnp4}!hoptoad!gnu gnu@toad.com >"Use the Source, Luke...." While I still worked for Tektronix I discovered a similar problem receiving mail from mailing lists. Whenever I would receive mail originating from certain sites, there would be a core dump in XTMP. Further analysis showed that rmail was failing with a "segmentation violation". I looked at the rmail sources (thank goodness they are quite small) and noticed that almost all temporary variables are statically allocated arrays. The array that the path was reconstructed in was char[64]. There was another array that would never contain a value other than "From:" or ">From:" what was allocated as char[1024]. The RCS logs indicated that this had not been changed from the way it was received from Berkeley. After I changed the char[64] to a char[1024] (I also changed the other array to char[8]) I have had no further problems. -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Daryl V. McDaniel (503) 224-7056 Micronetics, Aloha Research Group 4730 S.W. 182nd Ave. ...tektronix!nosun!illian!darylm Aloha, Oregon 97007 WUI Telex: 6972206
mike@ists (Mike Clarkson) (05/18/88)
In article <23121@pyramid.pyramid.com>, csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: > If it's any consolation, Sun is switching to BNU (aka HoneyDanBer) in SunOS > 4.0. So you can all stop groaning and moaning about Sun's UUCP.... > > Of course, that doesn't help any with the problem you have *now*. :-( My understanding is that the new UUCP will not be in 4.0, but is planned for 4.1. Sun's UUCP is a disgrace. I heard once that Rick Salz gave them a fully ported 4.3 UUCP a long time ago but that they didn't do anything with it. Is there any way source licenced sites can get this code. I'm not sure I can live another day without it. -- Mike Clarkson mike@ists.UUCP Institute for Space and Terrestrial Science mike@ists.yorku.ca York University, North York, Ontario, uunet!mnetor!yunexus!ists!mike CANADA M3J 1P3 +1 (416) 736-5611
rsalz@bbn.com (Rich Salz) (05/19/88)
>I heard once that Rick Salz gave [Sun] a fully ported 4.3 UUCP a long time ago >but that they didn't do anything with it. Is there any way source licenced >sites can get this code. I'm not sure I can live another day without it. Some is giving me credit for work I never did! Sounds like something Rick Adams might have done, tho... /Rich $alz -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
csg@pyramid.pyramid.com (Carl S. Gutekunst) (05/19/88)
In article <23121@pyramid.pyramid.com>, I said: >If it's any consolation, Sun is switching to BNU (aka HoneyDanBer) in SunOS >4.0. So you can all stop groaning and moaning about Sun's UUCP.... In article <127@ists> mike@ists (Mike Clarkson) writes: >My understanding is that the new UUCP will not be in 4.0, but is planned for >4.1. Mea Culpa! I misunderstood Bill Shannon's note. Yes, it will not be in 4.0. Bill is working on the BNU port now, and he's going to do it *right*. As it comes right off the tape, SVR3 BNU is lacking a few important features, and has some appalling bugs. (You can tell at a glance which code was from the original HDB, and which was hacked in later. Love 'em or damn 'em, but Peter, Dave, and Brian write beautiful code.) >I heard once that Rick Salz... Try Rick Adams. C'mon folks, Ric_k Adams, Ric_h Salz. They're not inter- changable. :-) >... gave them a fully ported 4.3 UUCP a long time ago but that they didn't do >anything with it. Plain ol' 4.3BSD UUCP runs just dandy on SunOS 3.x; seismo is a Sun 3/180, remember. So if you've got the source license, go for it. Make sure you have all of Rick's latest fixes. What you fail to understand is that a computer vendor cannot take a 500K hunk of source code -- no matter how well it works -- and simply drop it into their release. It took me three months to add 4.3BSD UUCP to Pyramid's OSx, excluding local enhancements. That included: - Learning the new code. If I don't understand it, I'm not shipping it; I don't care who ported or how much I respect them. As a *vendor*, I cannot trust anyone else to support my machine. Vendors cannot supply software they cannot support. - Querying sample customers. We had to determine how much it would disrupt existing customer's operations to drop a radically new UUCP on them. (As it happens, I did a less than adaquate job, and got some rude flames as a con- sequence.) - Beta testing, and fixing bugs. Nothing's perfect, and I have an obligation to the customers to make sure the software works. - Writing the release notes. Lots of changes between the old and new versions. A README file in the source directory will not do. - Training field service, and providing materials to the education department. This included preparing a course on UUCP adminstration, making lecture notes and transparencies, and lecturing to a VCR so we could distribute tapes to the field offices. We got a lot of calls about UUCP. The people who answer the phones have to be able to answer the questions. - Man pages. (At the time, the 4.3BSD UUCP man pages hadn't been written.) - Administrator's manual. I wasn't happy with the 4.3BSD SMM:9, so I rewrote it. Sun probably wouldn't like my document either (it doesn't fit their for- mat, and I'm not exactly a professional writer), so they'd have to rewrite it again. Sure, Sun had a working 4.3BSD that they did nothing with. In their place, I would have done the same thing. Sun's management decided that there were a lot more important things to do than supporting a new UUCP -- only a tiny fraction of their installed base uses it. Pyramid, on the other hand, sells to a diff- erent customer base, one for whom UUCP was much more important; so we took the necessary time. <csg>