Path: utzoo!mnetor!uunet!husc6!rutgers!ames!sdcsvax!ucsdhub!jack!crash!bblue
From: bblue@crash.cts.com (Bill Blue)
Newsgroups: news.software.b
Subject: Strange Core Dumps
Message-ID: <2122@crash.cts.com>
Date: 9 Dec 87 17:44:14 GMT
Organization: Crash TS, San Diego, CA
Lines: 108


Perhaps someone can help me with a very strange problem I've been having
for some time now.  I'm running 2.11 at patchlevel 12 on a Symmetric
machine with 4.2 BSD.  inews is set for spooling in and out using the
.rnews directory.  I'm receiving a full feed, batched and compressed.

Several months ago I began having strange panics on the system
(noswapspace) and resulting reboots.  Nothing had been changed, it just
started happening. After watching for patterns for a time, I found that
this panic only occurred during times of uncompressing and unbatching
for posting locally.  I began watching the unbatching/posting operations
with a process monitor (a program called 'top' which displays processes,
priorities, memory usage, etc) and found that every so often one of the
inews processes would start consuming huge amounts of memory.  From a
typical of 150-180k it would start creeping up to several megabytes.
Once it exceeded my disk swap space (7mb) the system would die as
described above.  Occasionally it would dump core at the 5mb point and
continue, but not often.  I found that if I killed the process before it
got to that point everything would clean up nicely and I'd still be up.
Then, if I restarted the unbatching process on the *same* batch file, it
would process normally.  In other words, the problem does not replicate
given the same sets of articles. It somehow appears to be cumulative in
nature.

It appears as though I'm not alone in this behavior, either.  In talking
to two neighboring sites (my feed and another that I full-feed to) I
found that they have noticed very large core files laying around from
time to time, but have just deleted them since nothing serious appeared
to have happened.  This problem is obviously affecting different
machines differently, having the most profound effect on my smaller
machine.

Anyway, I've continued watching for patterns -- anything that would help
me localize what the trigger is.  And I think I've found something.
In my last five runaways (core dumps or panics), all of which happened
while inews was unbatching, after examining the .ar* and .in* files that
were being processed at the time of the runaway, I find that in EVERY
case they are BITNET articles posted to comp.lang.modula2!  Dum da dum dum....

Now, hopefully, someone will be given a clue from this behavior that
will result in a patch that will fix this obnoxious problem once and for
all. I have compared the articles being processed to others from the
same source that did post correctly, and don't notice anything peculiar
between them.  I suppose the most peculiar thing about those articles in
the first place is the Message-ID number, but I don't see anything in
the source code that suggests any problem there.

I've enclosed three of the comp.lang.modula2 articles (with shortened
text).

Please help!

--Bill


>Path: crash!ncr-sd!hp-sdd!hplabs!ucbvax!GWUVM.BITNET!MFELDMAN
>From: MFELDMAN@GWUVM.BITNET (Mike Feldman)
>Newsgroups: comp.lang.modula2
>Subject: Re: Modula-2 Texts
>Message-ID: 
>Date: 8 Dec 87 03:52:00 GMT
>Sender: daemon@ucbvax.BERKELEY.EDU
>Reply-To: Info-Modula2 Distribution List 
>Organization: The ARPA Internet
>Lines: 2
>
>As a general M2 book with an _excellent_ discussion of PROCESSES,
>try Ford and Wiener, "Software Engineering with Modula-2". Wiley.
>
>
>Path: crash!ncr-sd!hp-sdd!hplabs!ucbvax!UOGUELPH.BITNET!BOTCHAIR
>From: BOTCHAIR@UOGUELPH.BITNET (Alex Bewley)
>Newsgroups: comp.lang.modula2
>Subject: Re: Modula II on IBM PC with HALO graphics
>Message-ID: 
>Date: 8 Dec 87 23:10:49 GMT
>References: 
>Sender: daemon@ucbvax.BERKELEY.EDU
>Reply-To: Info-Modula2 Distribution List 
>Organization: The ARPA Internet
>Lines: 13
>
>
>  As far as your concurrency question about async ports goes...
>
>   The communication libraries supplied with LogiTech are quite good.  The
>async routine is run off the IOTRANSFER command.  So it will interrupt your
>[stuff deleted]
>
>
>Path: crash!ncr-sd!hp-sdd!hplabs!ucbvax!NMSUVM1.BITNET!MCSMAL
>From: MCSMAL@NMSUVM1.BITNET
>Newsgroups: comp.lang.modula2
>Subject: (none)
>Message-ID: 
>Date: 8 Dec 87 00:54:26 GMT
>Sender: usenet@ucbvax.BERKELEY.EDU
>Reply-To: Info-Modula2 Distribution List 
>Organization: The ARPA Internet
>Lines: 14
>
>I have the Microbotics Multifunction module and the 68881 coprocessor
>for my Amiga.  I have been trying to access the 2 IEEE libraries
>(supplied by Microbotics) from Benchmark Modula-2. I have written
>modules in both Modula-2 and Assembly that attempt to call these library
>[stuff deleted]
>
>