Hi win32 folks,

coincidentally I found a huge bug with external primitives on win32
Spur VMs. The bug was the VM code generator not using the EXPORT macro to
export primitive accessor depths. This macro does nothing on unix & macos
(hence I didn't notice the bug), but is required on win32. The transparent
forwarding mechanism for primitives is broken by this bug. Hence any
external primitive that needs to retry to follow a forwarder (e.g. after a
pin operation or a become to grow something, etc) won't retry on win32. I
fon't know if this will fix the SSL issue on win32. But it is certainly a
smoking gun.

The bug is fixed in my most recent commit.

On Fri, Apr 9, 2021 at 12:45 AM Marcel Taeumel ***@***.***>

> Well, I wouldn't immediately celebrate "Got it!" 😄 but yes, I can
> reproduce this in Squeak 5.3 (64-bit) with the VM 202003021730. So, what
> does this behavior tell us? At least, it is releated to some kind of memory
> management. Renaming "Squeak.exe" to something else or using
> "SqueakConsole.exe" or changing the VM to 202011120327 ... all options
> still show that bug in that "broken" image.
> There is something wrong with module loading. Is there some interference
> between Squeak's object memory and how modules are loaded? Maybe take a
> look at how primitive 571 is implemented. (SmalltalkImage >>
> #unloadModule:)
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/554#issuecomment-816486966>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ADY5VUE6HYN67FMHCWUIMQTTH2WA5ANCNFSM4ZCQMSXA>
> .

best, Eliot

You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.