Impossible crashes

[Andreas Raab]

Very likely memory corruption is your problem (unless you use other FFI 
or large C libraries). If you can run this single threaded (or put the 
threads "under control" by the app) you should write-protect the Squeak 
object-memory during those primitive calls. This will make the VM crash 
at the point of failure instead of ten minutes later in a GC.

Cheers,
   - Andreas

Cees De Groot wrote:
> Hi,
> 
> We are getting reports from customers with stacktraces indicating all
> sorts of impossibilities:
> 
> - nil elements in the ScheduledDelays collection (Delay class var);
> - crashes in #becomeForward: which looks so nonsensical that it almost
> looks like two of these calls are active at the same time;
> and other stuff like that.
> 
> I was wondering - there's no way, I hope, that the wx threads can be
> messing with the VM, is there? That suddenly two native threads start
> interpreting or something like that? Because that is almost the only
> thing that can explain this (random memory corruption is hardly likely
> to cause these crashes - they've each been reported multiple times).
> 
>