On Thursday, November 18, 2004, at 09:50 AM, Tim Kelly wrote:

> I want to bring this up again. I only got one confirmation from a 
> macppc
> user, and one deny from a i386 user.
>
> The procedure is to make a mfs partition 600M or larger by mounting it,
> and then copying something to it that is definately going to overfill
> it. I reproduced this again this morning.
>
I noticed in the thread large images with gimp was mentioned   I know a 
fair  number of programs will use mmap to read and write large files 
for speed.  I imagine that gimp may.
I wondered if the problem might be more mmap to file on mfs on mac, 
than size related.
Rather that just post, I decided to write a test program.

I'm not current: I'm running 2.0G generic on an ibook g3 with 384 meg 
ram in a 702m
ufs root.  (I tried 1.6 a while back, and when I put OSX back on, I 
gave myself 2 partitions,
1 big hfs+, and 1 cd sized ufs root,  I installed from a disk image a 
few weeks ago )
Anyway, just so I had /some/ swap  I swap to a 32meg file.

Anyway, I wrote a quick and dirty file copy program that used mmap for 
io.   Mounted a 31 meg mfs on /tmp (swapping only to a 32meg file ) ,  
overflowed /tmp a few times,  experienced only the expected outcome:  
diskfull messages.   Afterwards I umounted /tmp, and did a shutdown -p 
now,  after typical shutdown banter I got:
  shutdown: can't exec /sbin/halt:  Exec format error.
File on /sbin/halt says its a 'core file' of mmdup, my test program.
Ok. now this is weird: I cp  file,  in order to run gdb on the core 
file, and gdb reports its not a core file, file on the copy says its an 
executable.   I try gdb using /sbin/halt directly and it
nominally works,  but I can' examing anything.   Looking at the file 
with a hex editor it looks like its only been partially overwritten 
with the core file.   I think it has to be a result of overflowing the 
mfs.   (as  I did no error checking, so running out of space would 
result in a core dump, and the current directory was /tmp, which was 
mfs. )
I going to be reboot, fsck and see if halt fixes itself.     How can 
the copy be ok,
and the original be corrupt?  Is it a memory map gone awry?

I don't know -- I'm just taking a wild guess, that it could be related, 
unless of course it isn't, and its something else ;-].