Hm ... I wonder if that might be a GCC optimization issue? IIRC, then we had
problems with GCC 3+ in some areas and trying to optimize some of this C
code _might_ get you in trouble if the optimizations aren't rock-solid.

There's another possibility, though. I found on Windows that under some
circumstances (which I could never figure out completely) the FPU flags get
changed to signal exceptions instead of silently over/underflowing. There
_are_ situations in which some computations can over/underflow but checking
for this explicitly would be huge pain (given the non-existence of
cross-platform exception handling you'd have to manually put in a number of
tests on each of the operations affected). Is there any chance that the
crash is caused by a SIGNAN (or whatever it may be called)?

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Jon Hylands
> Sent: Monday, July 28, 2003 11:08 PM
> To: The general-purpose Squeak developers list
> Subject: Re: crashes with Ballon3D (was: accelerated OpenGL 
> on linux/nvidia (crash))
> 
> 
> On Mon, 28 Jul 2003 22:53:04 +0200, "Boris Gaertner"
> <Boris.Gaertner at gmx.net> wrote:
> 
> > Radek, can you perhaps prepare a change set with the scene
> > that causes the crash? I can try it on my computer.
> 
> I ran into this while doing some 3D stuff for my AUV 
> simulator. If you open
> any of the example morphs in the AdvancedB3DSceneMorph 
> viewer, you should
> then be able to open your example without crashing.
> 
> As well, I found that in my code, if I open the morph with hardware
> acceleration already turned on, it doesn't crash.
> 
> Later,
> Jon
> 
> --------------------------------------------------------------
>    Jon Hylands      Jon at huv.com      http://www.huv.com/jon
> 
>   Project: Micro Seeker (Micro Autonomous Underwater Vehicle)
>            http://www.huv.com
>