[Vm-dev] VM Crash LocaleTest>> beginning with Cog Spur 16.13 on Windows

Levente Uzonyi leves at caesar.elte.hu
Fri May 20 10:16:28 UTC 2016


Hi Dave,

On Thu, 19 May 2016, David T. Lewis wrote:

>
> On Thu, May 19, 2016 at 04:40:17AM -0700, Patrick R. wrote:
>>
>> Hi everyone,
>>
>> just wanted to let you know that the LocaleTest crashes the VM for builds
>> after and including Cog with Spur on Windows version number 16.13. The crash
>> dump does neither contain a Smalltalk nor a C trace and the VM crashes at
>> the primitive 117. It is somewhat unclear what the issue might be. Are there
>> any more information that could help you on that?
>>
>
> Background information on the UUID bug is here:
>
> http://bugs.squeak.org/view.php?id=7358
>
> In that bug report, we were treating this as a "Linux issue". But presumably
> it is a Gnu library problem, and if the Windows VM uses the same libraries,
> then it may be subject to the same bug.

The Windows platform code uses Windows's built-in UUID generator[1].
Since this bug hasn't happened before the recent rewrite of the UUID 
plugin, I'm fairly sure this is an entirely different issue with similar 
symptoms.

My guess is that the UUID generation fails on the machine (the underlying 
UuidCreate[2] function returns RPC_S_UUID_LOCAL_ONLY instead of RPC_S_OK), 
and the forthcoming interpreterProxy->primitiveFail() crashes, because 
interpreterProxy is not set.
But this is just a wild guess, and someone with a Windows machine 
and a debugger could easily find out what's going on, since we have an 
easy-to-reproduce case.

>
> Key points from Mantis 7358:
>
> - The bug exists in some, but not all, versions of the runtime library.
>
> - Compiling the plugin as an internal plugin makes the problem go away.
>
> - If you compile the plugin as an internal plugin, but the user does not
>  have the uuid runtime installed, then the VM will crash.
>
> - Therefore: No matter what you do, you are screwed.
>
> This is the reason that I was very happy when recent improvements in
> Squeak trunk made UUID generation so fast that the plugin is really not
> needed any more.

Unfortunately, those improvements do not worth much without a good source 
of randomness available to the image. The problem is that the image side 
random number generator is currently initialized with less than 32-bits of 
entropy, and that makes it way too likely for UUIDs to not be unique.

Levente

>
> Dave
>
>

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms688568%28v=vs.85%29.aspx
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa379205%28v=vs.85%29.aspx


More information about the Vm-dev mailing list