Impossible crashes

[Rob Gayvert]

That sounds like a great idea. It looks like this can be accomplished in 
the Windows VM using a couple of simple calls to VirtualProtect(). Is 
that right? If so, I could slip this in as a debugging option.

.. Rob

Andreas Raab wrote:

> 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).
>>
>>
>