🚀 go-pugleaf

In article <1992Dec23.011833.10963@vax.oxford.ac.uk>, leep@vax.oxford.ac.uk writes:
|> 
|> IsosurfaceLat and IsosurfaceLat2 both crash
|> on large data sets.  The size is not
|> always the ssame for the lattice, but instead seems
|> to be a function of the complexity of the surfaces
|> generated.  The limit for a lattice of char variables
|> is about 1.5M, at which point the helpful error
|> "segmentation fault" is generated and all other
|> modules hang.  Is this a known bug?  Is there a fix?
|> The isosurflat2 was pulled from swedishchief on Dec.22.
|> 
|> Is there any pd source available for the marching cubes
|> algorithm so that I can try and generate the iso-surfaces
|> external to explorer?
|> 
|> Cheers,
|> Peter Lee

Something to check for - does your arenasize exceed the available disk space
on the disk specified by tempdir (default is /usr/tmp).  The shared memory
arena used by explorer is mapped to a file under the tempdir directory.
This mapped file acts as the VM swapfile for the arena (not your swap
partition).

The mapped arena file does not start out attempting to use all of the
disk space specified by arenasize.  As memory is needed, the arena file
will grow.  If it grows past the available memory, weird execution
behavior will occur and no errors that the arena has grown larger than
the available disk space will be displayed.  I've encountered the kind of
weird behavior like you are seeing in the circumstances that I had specified
an arena larger than the disk space that I had.   I don't know if this is
the problem that you are encountering.

						--- Dave

-- 

    __   * __   _  __  ___			
   /  \ / / /  / \/  \/   \ 	He was a man like any other man, however, not
  /    /  \/  /  /\  /    /	quite like any other man.
  \___/\__/\_/  /_/ / \__/	
	           *