unexplained cores after compiles

[Lenny Tropiano]

In article <3986 at cbnews.ATT.COM> res at cbnews.ATT.COM (Robert E. Stampfli) writes:
|>I have noticed that occasionally I will get a core dump immediately after
|>invoking a program on the Unix-PC, usually upon trying to run it after
|>it has just finished compiling.  Simply reinvoking the program without
|>any changes results in it running fine.  This can not be attributed to a
|>hardware glitch, as I have seen this on at least three machines I have access
|>to.  Each has different disks, memory configuration, etc.  They were,
|>however, all running version 3.5 of the Unix-PC operating system. 
|>
...
I have seen and experienced the same occurence.  I'm pretty sure it's not
OS release dependent.  I've seen this on 3B2's as well.  Usually it happens
after you execute something on a system that was just written out (you
explanation of compiling a executable, and then executing it).  It usually
will end up with a "Illegal Instruction or Memory Fault" and will dump core.
This happens on occasion because "writes" on UNIX machines are delayed.  
The kernel could write directly to the disk for all filesystem accesses, but
the system response time and throughput would be unacceptable.  Therefore,
to increase performance, disk access is done through internal data buffers
called the "buffer cache".  The kernel will minimize the frequence of writes
to the disk, if it determines that the data is transient, and will soon
be overwritten anyhow.   Basically the kernel will hope that someone will
change the contents of the internal buffer (ie. the data to be written to the
disk) before it is actually written.

The disadvantages to delayed write is that the user issuing the "write" system
call is never sure when the data finally is written to the disk/media.
Issuing a "sync" system call or using the "sync" command will assure that
all dirty buffers are written to disk.

|>Let me stress that this is a rare occurence -- I have only seen it about
|>six times, and I do a lot of compiling and testing on the Unix-PC.
...
It's very rare.  I would have trouble producing the error.  I had to stick
"sync" system calls into my B-tree routines at work at strategic points to
assure that the data is written out to the disk, hopefully not destroying
the performance of the B-tree routines.

|>I am curious: has anyone else experienced this?  If so, what version of
|>Unix were you running?  How often does it bite you?  I have a few pet
|>hypotheses but really no way to verify them.  Anyway, I am mainly curious if
|>others have observed this, too.
|>
...
You are not alone.  I've experienced it!  It's happened on 3B1's running
3.0, 3.5, and 3.51[ac].  I've also experienced it with the 3B2 running 3.1,
but there I was able to tweek the NAUTOUP tunable parameter to decrease
the time between the system will automatically update the dirty buffers.

Hope this cleared up your "weird" happenings ...
-Lenny
-- 
Lenny Tropiano             ICUS Software Systems         [w] +1 (516) 582-5525
lenny at icus.islp.ny.us      Telex; 154232428 ICUS         [h] +1 (516) 968-8576
{talcott,decuac,boulder,hombre,pacbell,sbcs}!icus!lenny  attmail!icus!lenny
        ICUS Software Systems -- PO Box 1; Islip Terrace, NY  11752