Hi all --
Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Thank you!
Best, Marcel
Hi Marcel,
On 11/21/2023 2:02 PM, Taeumel, Marcel wrote:
Hi all --
Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Thank you!
Best, Marcel
Thank you very much for this! We'll be testing them with Cuis.
Cheers,
Hi,
I've done light testing on Linux x86-64, Arm64, and Arm32.
With the exception of removing
--enable-fast-bitblt
in
opensmalltalk-vm/building/linux32ARMv6/squeak.cog.spur/build [http://squeak.cog.spur/build]
/mvm
all seems fine.
The --enable-fast-bitblt is getting the wrong code because on my Arm32 system it is running Raspberry Pi OS from November. And this is a 64 bit kernel so both the arch command and uname -m return aarch64, but it is a 32 bit userland.
So the logic as to which fast bitblt to pick is wrong and it tries to build the 64 bit one. Chaos ensues.
I don't see this as a big deal since building on an older Arm32 Raspberry pi will do the right thing.
cheers
bruce
On 2023-11-21T19:15:53.000+01:00, Juan Vuletich juan@cuis.st wrote:
------------------------- Hi Marcel, On 11/21/2023 2:02 PM, Taeumel, Marcel wrote:
Hi all -- Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431] Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines. Thank you! Best, Marcel
Thank you very much for this! We'll be testing them with Cuis. Cheers, -- Juan Vuletich cuis.st [http://cuis.st] github.com/jvuletich [http://github.com/jvuletich] researchgate.net/profile/Juan-Vuletich [http://researchgate.net/profile/Juan-Vuletich] independent.academia.edu/JuanVuletich [http://independent.academia.edu/JuanVuletich] patents.justia.com/inventor/juan-manuel-vuletich [http://patents.justia.com/inventor/juan-manuel-vuletich] linkedin.com/in/juan-vuletich-75611b3 [http://linkedin.com/in/juan-vuletich-75611b3] twitter.com/JuanVuletich [http://twitter.com/JuanVuletich]
Hi Marcel,
When running on an Intel Mac with latest OS, the command shell window where I start the VM + Cuis shows this message: "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."
This has been so for some time, after some MacOS update. I guess this is a harmless annoyance from Apple, and not a bug in the VM at all. Still, it would be nice if there was a way to avoid it.
Thanks!
On 11/21/2023 2:02 PM, Taeumel, Marcel wrote:
Hi all --
Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Thank you!
Best, Marcel
On 11/21/2023 3:25 PM, Juan Vuletich wrote:
Hi Marcel,
When running on an Intel Mac with latest OS, the command shell window where I start the VM + Cuis shows this message: "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."
This has been so for some time, after some MacOS update. I guess this is a harmless annoyance from Apple, and not a bug in the VM at all. Still, it would be nice if there was a way to avoid it.
Thanks!
On 11/21/2023 2:02 PM, Taeumel, Marcel wrote:
Hi all --
Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Thank you!
Best, Marcel
-- Juan Vuletich cuis.st github.com/jvuletich researchgate.net/profile/Juan-Vuletich independent.academia.edu/JuanVuletich patents.justia.com/inventor/juan-manuel-vuletich linkedin.com/in/juan-vuletich-75611b3 twitter.com/JuanVuletich
It should be enough to implement NSApplicationDelegate.applicationSupportsSecureRestorableState: returning NO, right?
Thanks,
Hi Juan --
The binaries we build and share are for macOS 10.9+ (Intel) or macOS 11+ (ARM).
Yes, I can implement applicationSupportsSecureRestorableState, returning YES because we do not do custom save/restore and thus can let macOS handle it.
However, I cannot test the binary as I have no macOS12+Intel combination at my service. I am pretty sure that such backwards compatible binaries will not expose this API for newer OS versions... even if technically there in the binary.
Do you know how this mechanism works? Can I build for a pre-12 macOS and still provide an answer to that check in a 12+ macOS? Does it scan the binary for symbols? Does modern xcode used in an old macOS have some special measures for this?
Hmm...
Best, Marcel
Am 21.11.2023 20:19:39 schrieb Juan Vuletich juan@cuis.st:
On 11/21/2023 3:25 PM, Juan Vuletich wrote: Hi Marcel,
When running on an Intel Mac with latest OS, the command shell window where I start the VM + Cuis shows this message: "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."
This has been so for some time, after some MacOS update. I guess this is a harmless annoyance from Apple, and not a bug in the VM at all. Still, it would be nice if there was a way to avoid it.
Thanks!
On 11/21/2023 2:02 PM, Taeumel, Marcel wrote:
Hi all --
Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Thank you!
Best, Marcel
-- Juan Vuletich cuis.st github.com/jvuletich researchgate.net/profile/Juan-Vuletich independent.academia.edu/JuanVuletich patents.justia.com/inventor/juan-manuel-vuletich linkedin.com/in/juan-vuletich-75611b3 twitter.com/JuanVuletich
It should be enough to implement NSApplicationDelegate.applicationSupportsSecureRestorableState: returning NO, right?
Thanks,
-- Juan Vuletich cuis.st github.com/jvuletich researchgate.net/profile/Juan-Vuletich independent.academia.edu/JuanVuletich patents.justia.com/inventor/juan-manuel-vuletich linkedin.com/in/juan-vuletich-75611b3 twitter.com/JuanVuletich
Aha!
I am pretty sure that such backwards compatible binaries will not expose this API for newer OS versions... even if technically there in the binary.
It is Objective-C, not C. Tobias reminded me. :-) It's kind of message sending. So this should work, even if compiled on an older (pre-12) macOS. I will not touch the .h to avoid compilation issues on newer macOS platforms. That particular interface might be private anyway.
Best, Marcel
Am 11.12.2023 11:43:38 schrieb Marcel marcel.taeumel@hpi.uni-potsdam.de:
Hi Juan --
The binaries we build and share are for macOS 10.9+ (Intel) or macOS 11+ (ARM).
Yes, I can implement applicationSupportsSecureRestorableState, returning YES because we do not do custom save/restore and thus can let macOS handle it.
However, I cannot test the binary as I have no macOS12+Intel combination at my service. I am pretty sure that such backwards compatible binaries will not expose this API for newer OS versions... even if technically there in the binary.
Do you know how this mechanism works? Can I build for a pre-12 macOS and still provide an answer to that check in a 12+ macOS? Does it scan the binary for symbols? Does modern xcode used in an old macOS have some special measures for this?
Hmm...
Best, Marcel
Am 21.11.2023 20:19:39 schrieb Juan Vuletich juan@cuis.st:
On 11/21/2023 3:25 PM, Juan Vuletich wrote: Hi Marcel,
When running on an Intel Mac with latest OS, the command shell window where I start the VM + Cuis shows this message: "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."
This has been so for some time, after some MacOS update. I guess this is a harmless annoyance from Apple, and not a bug in the VM at all. Still, it would be nice if there was a way to avoid it.
Thanks!
On 11/21/2023 2:02 PM, Taeumel, Marcel wrote:
Hi all --
Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Thank you!
Best, Marcel
-- Juan Vuletich cuis.st github.com/jvuletich researchgate.net/profile/Juan-Vuletich independent.academia.edu/JuanVuletich patents.justia.com/inventor/juan-manuel-vuletich linkedin.com/in/juan-vuletich-75611b3 twitter.com/JuanVuletich
It should be enough to implement NSApplicationDelegate.applicationSupportsSecureRestorableState: returning NO, right?
Thanks,
-- Juan Vuletich cuis.st github.com/jvuletich researchgate.net/profile/Juan-Vuletich independent.academia.edu/JuanVuletich patents.justia.com/inventor/juan-manuel-vuletich linkedin.com/in/juan-vuletich-75611b3 twitter.com/JuanVuletich
Thanks!
Cheers,
On 12/11/2023 9:20 AM, Taeumel, Marcel wrote:
Aha!
I am pretty sure that such backwards compatible binaries will not
expose this API for newer OS versions... even if technically there in the binary.
It is Objective-C, not C. Tobias reminded me. :-) It's kind of message sending. So this should work, even if compiled on an older (pre-12) macOS. I will not touch the .h to avoid compilation issues on newer macOS platforms. That particular interface might be private anyway.
Best, Marcel
Am 11.12.2023 11:43:38 schrieb Marcel marcel.taeumel@hpi.uni-potsdam.de:
Hi Juan --
The binaries we build and share are for macOS 10.9+ (Intel) or macOS 11+ (ARM).
Yes, I can implement applicationSupportsSecureRestorableState, returning YES because we do not do custom save/restore and thus can let macOS handle it.
However, I cannot test the binary as I have no macOS12+Intel combination at my service. I am pretty sure that such backwards compatible binaries will not expose this API for newer OS versions... even if technically there in the binary.
Do you know how this mechanism works? Can I build for a pre-12 macOS and still provide an answer to that check in a 12+ macOS? Does it scan the binary for symbols? Does modern xcode used in an old macOS have some special measures for this?
Hmm...
Best, Marcel
Am 21.11.2023 20:19:39 schrieb Juan Vuletich juan@cuis.st:
On 11/21/2023 3:25 PM, Juan Vuletich wrote:
Hi Marcel,
When running on an Intel Mac with latest OS, the command shell window where I start the VM + Cuis shows this message: "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."
This has been so for some time, after some MacOS update. I guess this is a harmless annoyance from Apple, and not a bug in the VM at all. Still, it would be nice if there was a way to avoid it.
Thanks!
On 11/21/2023 2:02 PM, Taeumel, Marcel wrote:
Hi all --
Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Thank you!
Best, Marcel
-- Juan Vuletich cuis.st github.com/jvuletich researchgate.net/profile/Juan-Vuletich independent.academia.edu/JuanVuletich patents.justia.com/inventor/juan-manuel-vuletich linkedin.com/in/juan-vuletich-75611b3 twitter.com/JuanVuletich
It should be enough to implement NSApplicationDelegate.applicationSupportsSecureRestorableState: returning NO, right?
Thanks,
Juan Vuletich cuis.st github.com/jvuletich researchgate.net/profile/Juan-Vuletich independent.academia.edu/JuanVuletich patents.justia.com/inventor/juan-manuel-vuletich linkedin.com/in/juan-vuletich-75611b3 twitter.com/JuanVuletich
Hi Marcel,
Thank you for building the release candidate. I just used the squeak.cog.spur_macos64x64 VM with the latest Cuis image for several hours. When I tried to save and quit the VM it crashed, see attachment. It seems to have saved the image correctly before the crash.
I used OSProcess extensively to call md5 to calculate file hashes. I ran into a lot of OSProcess errors. Maybe the crash has something to do with this.
Cheers, Bernhard
Am 21.11.2023 um 18:02 schrieb Taeumel, Marcel Marcel.Taeumel@hpi.de:
Hi all --
Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Thank you!
Best, Marcel
Hi Bernhard, Hi All,
On Sun, Nov 26, 2023 at 1:51 PM Bernhard Pieber bernhard@pieber.com wrote:
Hi Marcel,
Thank you for building the release candidate. I just used the squeak.cog.spur_macos64x64 VM with the latest Cuis image for several hours. When I tried to save and quit the VM it crashed, see attachment. It seems to have saved the image correctly before the crash.
The crash is in the Metal specific graphics backend:
5 AMDRadeonX6000MTLDriver 0x00007ffb0ab12d95 _ZL27GFX10_GenerateTileAddressesPK18CpuTexInterfaceRecPK21ATIMipmapBufferHeaderPKjjjjjjjjjjPFvyjjPvES7_ + 2730 6 AMDRadeonX6000MTLDriver 0x00007ffb0ab116c9 _ZL25GFX10_TextureReplaceTilesPK18CpuTexInterfaceRecPK21ATIMipmapBufferHeaderPKjPK21amd_gfx10_format_infojjmjmmjjjjj + 296 7 AMDRadeonX6000MTLDriver 0x00007ffb0ab111af _ZL25GFX10_TextureAccessRegionPK18CpuTexInterfaceRecPFvS1_PK21ATIMipmapBufferHeaderPKjPK21amd_gfx10_format_infojjmjmmjjjjjESB_S4_S6_S9_jjmjmmjjjjj + 546 8 AMDRadeonX6000MTLDriver 0x00007ffb0ab10f24 _Z31amdMtl_HWL_TextureReplaceRegionPK18CpuTexInterfaceRecPK21ATIMipmapBufferHeaderPKjPK21amd_gfx10_format_infojjPvjmmjjjjj + 400 9 AMDRadeonX6000MTLDriver 0x00007ffb0abdf85c -[GFXAAMD_MtlTexture replaceRegion:mipmapLevel:withBytes:bytesPerRow:] + 510 10 Squeak 0x00000001005120de -[*sqSqueakOSXMetalView loadTexturesSubRectangle:*] + 616 11 Squeak 0x0000000100511c39 -[*sqSqueakOSXMetalView drawRect:*] + 144 12 MetalKit 0x00007ff81ce68a06 -[MTKView draw] + 159
Without looking at this in a debugger we don't know whether the issue is the rectangle passed to loadTexturesSubRectangle: (derived from clippy, a global variable which might be wrongly initialized) or to do with the texture itself. Since a compaction is done during snapshot the display bitmap and the texture machinery might have got out of sync. I've cc'ed Ronie, the author, and hopefully he'll be able to take a look. Bernhard, is this reproducible?
I used OSProcess extensively to call md5 to calculate file hashes. I ran into a lot of OSProcess errors. Maybe the crash has something to do with this.
Cheers, Bernhard
Am 21.11.2023 um 18:02 schrieb Taeumel, Marcel Marcel.Taeumel@hpi.de:
Hi all --
Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Thank you!
Best, Marcel
Aha!
If this was in a Cuis image, that image probably did not get the fix we did in DisplayScreen >> restore
restore | priorBits | priorBits := bits. "Must avoid to be GC'ed!" self setExtent: self class actualScreenSize depth: self nativeDepth. self beDisplay. priorBits := nil. "Documentation only." Project current ifNotNil: [:p| p displaySizeChanged].
For Cuis 5.0 and Cuis 6.0, this fix should probably be in DisplayScreen >> setExtent:depth:, where bits is cleared and thus can be GC'ed .
No, this cannot be fixed only in the VM platform code. The image allocates memory for the bits and communicates a pointer to that to the platform code via #beDisplay. Whenever those bits change, new bits must be communicated via #beDisplay *before* the GC collects the old bits. Image code must ensure that with a strong reference.
Well, this is no new behavior. The issue can also occur with the 2022-06 OSVM. But it is (still) rare. Probably related to how much old space the image uses. Definitely GC-related.
Best, Marcel
Am 06.12.2023 21:12:16 schrieb Eliot Miranda eliot.miranda@gmail.com:
If I remember correctly, the change to the macOS Metal support in OSVM (2022-06) was like this: - use event mechanism (i.e. paint events) instead of raw Metal pipeline to avoid locking image performance to 60 FPS max - OSVM does a lot of "event pumping" at unexpected places, probably in support of an input-event semaphore and thus a reactive in-image GUI framework (instead of cyclic Morphic, which polls events on its own)
Now the issue is with resizing DisplayScreen, which happens on snapshotting. There, bits get minimized to not have, e.g., 4K forms (8 meg?) in the file but only a smaller representative. And this is where the GC might collect those 8 meg, the VM does not know about the new bits yet, but unexpected "event pumping" triggers a repaint event via metal and thus a dangling "bits" pointer is processed in our metal backend. The VM crashes.
See the wording "does not slow down VM interpreter loop" here: - https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/620
Those bits in DisplayScreen must be protected whenever screen-extent is changed from within the image such as on snapshotting.
Best, Marcel
Am 07.12.2023 13:10:22 schrieb Marcel marcel.taeumel@hpi.uni-potsdam.de:
Aha!
If this was in a Cuis image, that image probably did not get the fix we did in DisplayScreen >> restore
restore | priorBits | priorBits := bits. "Must avoid to be GC'ed!" self setExtent: self class actualScreenSize depth: self nativeDepth. self beDisplay. priorBits := nil. "Documentation only." Project current ifNotNil: [:p| p displaySizeChanged].
For Cuis 5.0 and Cuis 6.0, this fix should probably be in DisplayScreen >> setExtent:depth:, where bits is cleared and thus can be GC'ed .
No, this cannot be fixed only in the VM platform code. The image allocates memory for the bits and communicates a pointer to that to the platform code via #beDisplay. Whenever those bits change, new bits must be communicated via #beDisplay *before* the GC collects the old bits. Image code must ensure that with a strong reference.
Well, this is no new behavior. The issue can also occur with the 2022-06 OSVM. But it is (still) rare. Probably related to how much old space the image uses. Definitely GC-related.
Best, Marcel
Am 06.12.2023 21:12:16 schrieb Eliot Miranda eliot.miranda@gmail.com:
Hi Marcel,
Thank you very much for making us aware of this!
Indeed I was not aware of the "new" requirement to call #beDisplay whenever Display bits change, and to keep the old instance around until this is done.
I'll do the appropriate changes to Cuis soon, hopefully tomorrow.
BTW, I guess this means that the Display bits are also pinned by the VM upon calling #beDisplay, right? Otherwise the GC would move them, and the crash would happen all the time.
Thanks a lot!
Cheers,
On 12/9/2023 4:29 AM, Taeumel, Marcel wrote:
If I remember correctly, the change to the macOS Metal support in OSVM (2022-06) was like this:
- use event mechanism (i.e. paint events) instead of raw Metal
pipeline to avoid locking image performance to 60 FPS max
- OSVM does a lot of "event pumping" at unexpected places, probably in
support of an input-event semaphore and thus a reactive in-image GUI framework (instead of cyclic Morphic, which polls events on its own)
Now the issue is with resizing DisplayScreen, which happens on snapshotting. There, bits get minimized to not have, e.g., 4K forms (8 meg?) in the file but only a smaller representative. And this is where the GC might collect those 8 meg, the VM does not know about the new bits yet, but unexpected "event pumping" triggers a repaint event via metal and thus a dangling "bits" pointer is processed in our metal backend. The VM crashes.
See the wording "does not slow down VM interpreter loop" here:
Those bits in DisplayScreen must be protected whenever screen-extent is changed from within the image such as on snapshotting.
Best, Marcel
Am 07.12.2023 13:10:22 schrieb Marcel marcel.taeumel@hpi.uni-potsdam.de:
Aha!
If this was in a Cuis image, that image probably did not get the fix we did in DisplayScreen >> restore
*restore* |priorBits| priorBits*:=*bits./"Must avoid to be GC'ed!"/ selfsetExtent:selfclassactualScreenSizedepth:selfnativeDepth. selfbeDisplay. priorBits*:=*nil./"Documentation only."/ ProjectcurrentifNotNil:[:p|pdisplaySizeChanged].
For Cuis 5.0 and Cuis 6.0, this fix should probably be in DisplayScreen >> setExtent:depth:, where bits is cleared and thus can be GC'ed .
No, this cannot be fixed only in the VM platform code. The image allocates memory for the bits and communicates a pointer to that to the platform code via #beDisplay. Whenever those bits change, new bits must be communicated via #beDisplay *before* the GC collects the old bits. Image code must ensure that with a strong reference.
Well, this is no new behavior. The issue can also occur with the 2022-06 OSVM. But it is (still) rare. Probably related to how much old space the image uses. Definitely GC-related.
Best, Marcel
Am 06.12.2023 21:12:16 schrieb Eliot Miranda eliot.miranda@gmail.com:
On 2023-12-10, at 5:45 AM, Juan Vuletich juan@cuis.st wrote:
BTW, I guess this means that the Display bits are also pinned by the VM upon calling #beDisplay, right? Otherwise the GC would move them, and the crash would happen all the time.
That depends. If you use the Display bits by starting from an oop that the GC pays attention to then you're safe unless the relevant code tries to run in the middle of a gc that affects the display bits. That's a danger of multithreaded systems and then we get into putting locks on things and failing to release the lock at the right time and then nasty creatures from the dungeon dimensions leak out and eat you.
I used to copy bits from the squeak Display object to an OS sprite (yes, RISC OS kept ancient terminology) so that the OS code could do anything it liked at any time. It's wasteful of memory, obviously. It used to seem like a lot of waste in the days of 4Mb ram machines. Now with vast 32bpp screens it seems like a lot to me still! Then again, when even a Pi can have 8Gb, who really cares? I mean have you seen what other applications use to do a tiny fraction of what smalltalk does?
In other older systems I used to allocate fixed memory outside of object space and set the bitmap instvar in the Display from, and modified the GC to ignore the relevant bits. In another old system we could actually just set the hardware pointer for the physical display to point anywhere and the gc could update that if needed.
I'm not huge fan of pinning objects because they can make for nasty logjams in compaction. Maybe it would be practical to pin the display bits intermittently, ie only when it really needs to be locked? That might have the same issues as a thread lock though.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Overdue for deincarnation.
Yes, bits get pinned via beDisplay. We just have to ensure strong references from within the image.
Best, Marcel
________________________________ From: Juan Vuletich juan@cuis.st Sent: Sunday, December 10, 2023 2:45:47 PM To: Open Smalltalk Virtual Machine Development Discussion vm-dev@lists.squeakfoundation.org Cc: Taeumel, Marcel Marcel.Taeumel@hpi.de Subject: Re: [Vm-dev] Re: Please test | Relase candidate for OSVM 2023
Hi Marcel,
Thank you very much for making us aware of this!
Indeed I was not aware of the "new" requirement to call #beDisplay whenever Display bits change, and to keep the old instance around until this is done.
I'll do the appropriate changes to Cuis soon, hopefully tomorrow.
BTW, I guess this means that the Display bits are also pinned by the VM upon calling #beDisplay, right? Otherwise the GC would move them, and the crash would happen all the time.
Thanks a lot!
Cheers,
On 12/9/2023 4:29 AM, Taeumel, Marcel wrote:
If I remember correctly, the change to the macOS Metal support in OSVM (2022-06) was like this: - use event mechanism (i.e. paint events) instead of raw Metal pipeline to avoid locking image performance to 60 FPS max - OSVM does a lot of "event pumping" at unexpected places, probably in support of an input-event semaphore and thus a reactive in-image GUI framework (instead of cyclic Morphic, which polls events on its own)
Now the issue is with resizing DisplayScreen, which happens on snapshotting. There, bits get minimized to not have, e.g., 4K forms (8 meg?) in the file but only a smaller representative. And this is where the GC might collect those 8 meg, the VM does not know about the new bits yet, but unexpected "event pumping" triggers a repaint event via metal and thus a dangling "bits" pointer is processed in our metal backend. The VM crashes.
See the wording "does not slow down VM interpreter loop" here: - https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/620
Those bits in DisplayScreen must be protected whenever screen-extent is changed from within the image such as on snapshotting.
Best, Marcel
Am 07.12.2023 13:10:22 schrieb Marcel marcel.taeumel@hpi.uni-potsdam.demailto:marcel.taeumel@hpi.uni-potsdam.de:
Aha!
If this was in a Cuis image, that image probably did not get the fix we did in DisplayScreen >> restore
restore | priorBits | priorBits := bits. "Must avoid to be GC'ed!" self setExtent: self class actualScreenSize depth: self nativeDepth. self beDisplay. priorBits := nil. "Documentation only." Project current ifNotNil: [:p| p displaySizeChanged].
For Cuis 5.0 and Cuis 6.0, this fix should probably be in DisplayScreen >> setExtent:depth:, where bits is cleared and thus can be GC'ed .
No, this cannot be fixed only in the VM platform code. The image allocates memory for the bits and communicates a pointer to that to the platform code via #beDisplay. Whenever those bits change, new bits must be communicated via #beDisplay *before* the GC collects the old bits. Image code must ensure that with a strong reference.
Well, this is no new behavior. The issue can also occur with the 2022-06 OSVM. But it is (still) rare. Probably related to how much old space the image uses. Definitely GC-related.
Best, Marcel
Am 06.12.2023 21:12:16 schrieb Eliot Miranda eliot.miranda@gmail.commailto:eliot.miranda@gmail.com:
-- Juan Vuletich cuis.st github.com/jvuletich researchgate.net/profile/Juan-Vuletich independent.academia.edu/JuanVuletich patents.justia.com/inventor/juan-manuel-vuletich linkedin.com/in/juan-vuletich-75611b3 twitter.com/JuanVuletich
Thanks Marcel.
I've just pushed to Cuis GitHub repo the relevant changes.
Cheers,
On 12/11/2023 3:36 AM, Taeumel, Marcel wrote:
Yes, bits get pinned via beDisplay. We just have to ensure strong references from within the image.
Best, Marcel
*From:* Juan Vuletich juan@cuis.st *Sent:* Sunday, December 10, 2023 2:45:47 PM *To:* Open Smalltalk Virtual Machine Development Discussion vm-dev@lists.squeakfoundation.org *Cc:* Taeumel, Marcel Marcel.Taeumel@hpi.de *Subject:* Re: [Vm-dev] Re: Please test | Relase candidate for OSVM 2023 Hi Marcel,
Thank you very much for making us aware of this!
Indeed I was not aware of the "new" requirement to call #beDisplay whenever Display bits change, and to keep the old instance around until this is done.
I'll do the appropriate changes to Cuis soon, hopefully tomorrow.
BTW, I guess this means that the Display bits are also pinned by the VM upon calling #beDisplay, right? Otherwise the GC would move them, and the crash would happen all the time.
Thanks a lot!
Cheers,
On 12/9/2023 4:29 AM, Taeumel, Marcel wrote:
If I remember correctly, the change to the macOS Metal support in OSVM (2022-06) was like this:
- use event mechanism (i.e. paint events) instead of raw Metal
pipeline to avoid locking image performance to 60 FPS max
- OSVM does a lot of "event pumping" at unexpected places, probably
in support of an input-event semaphore and thus a reactive in-image GUI framework (instead of cyclic Morphic, which polls events on its own)
Now the issue is with resizing DisplayScreen, which happens on snapshotting. There, bits get minimized to not have, e.g., 4K forms (8 meg?) in the file but only a smaller representative. And this is where the GC might collect those 8 meg, the VM does not know about the new bits yet, but unexpected "event pumping" triggers a repaint event via metal and thus a dangling "bits" pointer is processed in our metal backend. The VM crashes.
See the wording "does not slow down VM interpreter loop" here:
Those bits in DisplayScreen must be protected whenever screen-extent is changed from within the image such as on snapshotting.
Best, Marcel
Am 07.12.2023 13:10:22 schrieb Marcel marcel.taeumel@hpi.uni-potsdam.de mailto:marcel.taeumel@hpi.uni-potsdam.de:
Aha!
If this was in a Cuis image, that image probably did not get the fix we did in DisplayScreen >> restore
*restore* |priorBits| priorBits*:=*bits./"Must avoid to be GC'ed!"/ selfsetExtent:selfclassactualScreenSizedepth:selfnativeDepth. selfbeDisplay. priorBits*:=*nil./"Documentation only."/ ProjectcurrentifNotNil:[:p|pdisplaySizeChanged].
For Cuis 5.0 and Cuis 6.0, this fix should probably be in DisplayScreen >> setExtent:depth:, where bits is cleared and thus can be GC'ed .
No, this cannot be fixed only in the VM platform code. The image allocates memory for the bits and communicates a pointer to that to the platform code via #beDisplay. Whenever those bits change, new bits must be communicated via #beDisplay *before* the GC collects the old bits. Image code must ensure that with a strong reference.
Well, this is no new behavior. The issue can also occur with the 2022-06 OSVM. But it is (still) rare. Probably related to how much old space the image uses. Definitely GC-related.
Best, Marcel
Am 06.12.2023 21:12:16 schrieb Eliot Miranda eliot.miranda@gmail.com mailto:eliot.miranda@gmail.com:
-- Juan Vuletich cuis.st github.com/jvuletich researchgate.net/profile/Juan-Vuletich independent.academia.edu/JuanVuletich patents.justia.com/inventor/juan-manuel-vuletich linkedin.com/in/juan-vuletich-75611b3 twitter.com/JuanVuletich
Hi there,
happy to report a green bar for SimulationStudio under 6.0 using the new VM on Windows 10 22H2 (squeak.cog.spur_win64x64).
However, I cannot start the VM on WSL 1/Ubuntu 18.04 (squeak.cog.spur_linux64x64):
$ squeak /path/to/squeak60.image /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak)
With the previous VM, I did not have this issue.
$ file /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=db26fa3de79c67698b6850c38f487f719f2afd9c, for GNU/Linux 3.2.0, with debug_info, not stripped $ file /usr/bin/squeak.bak20231128/lib/squeak/5.0-202204190959-64bit/squeak /usr/bin/squeak.bak20231128/lib/squeak/5.0-202204190959-64bit/squeak: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=c7e8211b70431cf23cd03d1531d6b82f16366438, with debug_info, not stripped
Should the VM work out of the box without installing extra dependencies? If yes, could there something be missing in the build process? If not, can we please make the documentation on how to install the missing dependencies very accessible (e.g., include a readme in the VM bundles)?
Best, Christoph
--- Sent from Squeak Inbox Talk
On 2023-11-21T17:02:16+00:00, marcel.taeumel@hpi.de wrote:
Hi all --
Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Thank you!
Best, Marcel
I remember some GLIBC issue with the last VM as well... hmmm....
________________________________ From: Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de Sent: Tuesday, November 28, 2023 5:38:57 PM To: vm-dev@lists.squeakfoundation.org vm-dev@lists.squeakfoundation.org Subject: [Vm-dev] Re: Please test | Relase candidate for OSVM 2023
Hi there,
happy to report a green bar for SimulationStudio under 6.0 using the new VM on Windows 10 22H2 (squeak.cog.spur_win64x64).
However, I cannot start the VM on WSL 1/Ubuntu 18.04 (squeak.cog.spur_linux64x64):
$ squeak /path/to/squeak60.image /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak)
With the previous VM, I did not have this issue.
$ file /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=db26fa3de79c67698b6850c38f487f719f2afd9c, for GNU/Linux 3.2.0, with debug_info, not stripped $ file /usr/bin/squeak.bak20231128/lib/squeak/5.0-202204190959-64bit/squeak /usr/bin/squeak.bak20231128/lib/squeak/5.0-202204190959-64bit/squeak: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=c7e8211b70431cf23cd03d1531d6b82f16366438, with debug_info, not stripped
Should the VM work out of the box without installing extra dependencies? If yes, could there something be missing in the build process? If not, can we please make the documentation on how to install the missing dependencies very accessible (e.g., include a readme in the VM bundles)?
Best, Christoph
--- Sent from Squeak Inbox Talk
On 2023-11-21T17:02:16+00:00, marcel.taeumel@hpi.de wrote:
Hi all --
Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Thank you!
Best, Marcel
Please remember Ubuntu 18 has reached "normal" EOL in April already:
https://ubuntu.com/blog/ubuntu-18-04-eol-for-devices
And it ships with Glibc 2.27 (Even debian buster has 2.28…)
If we want to support older GLIBCen, we have to do strange dances: - for example, explicitly marking symbols to use "old" versoines ones https://web.archive.org/web/20160107032111/http://www.trevorpounds.com/blog/... (this seems excessive) (but pepople seem to have managed that: https://stackoverflow.com/a/69139182 ) - link statically, but that is, imho a Very Bad Idea™ - Kill the version info and cross fingers: https://stackoverflow.com/a/73388939 - Build on ubuntu 18.04. I don't know whether github still has this for runners…
it's messy
best regards -Tobias
On 28. Nov 2023, at 17:38, christoph.thiede@student.hpi.uni-potsdam.de christoph.thiede@student.hpi.uni-potsdam.de wrote:
Hi there,
happy to report a green bar for SimulationStudio under 6.0 using the new VM on Windows 10 22H2 (squeak.cog.spur_win64x64).
However, I cannot start the VM on WSL 1/Ubuntu 18.04 (squeak.cog.spur_linux64x64):
$ squeak /path/to/squeak60.image /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak)
With the previous VM, I did not have this issue.
$ file /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=db26fa3de79c67698b6850c38f487f719f2afd9c, for GNU/Linux 3.2.0, with debug_info, not stripped $ file /usr/bin/squeak.bak20231128/lib/squeak/5.0-202204190959-64bit/squeak /usr/bin/squeak.bak20231128/lib/squeak/5.0-202204190959-64bit/squeak: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=c7e8211b70431cf23cd03d1531d6b82f16366438, with debug_info, not stripped
Should the VM work out of the box without installing extra dependencies? If yes, could there something be missing in the build process? If not, can we please make the documentation on how to install the missing dependencies very accessible (e.g., include a readme in the VM bundles)?
Best, Christoph
Sent from Squeak Inbox Talk
On 2023-11-21T17:02:16+00:00, marcel.taeumel@hpi.de wrote:
Hi all --
Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Thank you!
Best, Marcel
We build with 20.04. No older runners available on GitHub. We should drop support for 18.04 ... 😎
________________________________ From: Tobias Pape Das.Linux@gmx.de Sent: Tuesday, November 28, 2023 9:46:16 PM To: Open Smalltalk Virtual Machine Development Discussion vm-dev@lists.squeakfoundation.org Subject: [Vm-dev] Re: Please test | Relase candidate for OSVM 2023
Please remember Ubuntu 18 has reached "normal" EOL in April already:
https://ubuntu.com/blog/ubuntu-18-04-eol-for-devices
And it ships with Glibc 2.27 (Even debian buster has 2.28…)
If we want to support older GLIBCen, we have to do strange dances: - for example, explicitly marking symbols to use "old" versoines ones https://web.archive.org/web/20160107032111/http://www.trevorpounds.com/blog/... (this seems excessive) (but pepople seem to have managed that: https://stackoverflow.com/a/69139182 ) - link statically, but that is, imho a Very Bad Idea™ - Kill the version info and cross fingers: https://stackoverflow.com/a/73388939 - Build on ubuntu 18.04. I don't know whether github still has this for runners…
it's messy
best regards -Tobias
On 28. Nov 2023, at 17:38, christoph.thiede@student.hpi.uni-potsdam.de christoph.thiede@student.hpi.uni-potsdam.de wrote:
Hi there,
happy to report a green bar for SimulationStudio under 6.0 using the new VM on Windows 10 22H2 (squeak.cog.spur_win64x64).
However, I cannot start the VM on WSL 1/Ubuntu 18.04 (squeak.cog.spur_linux64x64):
$ squeak /path/to/squeak60.image /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak)
With the previous VM, I did not have this issue.
$ file /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=db26fa3de79c67698b6850c38f487f719f2afd9c, for GNU/Linux 3.2.0, with debug_info, not stripped $ file /usr/bin/squeak.bak20231128/lib/squeak/5.0-202204190959-64bit/squeak /usr/bin/squeak.bak20231128/lib/squeak/5.0-202204190959-64bit/squeak: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=c7e8211b70431cf23cd03d1531d6b82f16366438, with debug_info, not stripped
Should the VM work out of the box without installing extra dependencies? If yes, could there something be missing in the build process? If not, can we please make the documentation on how to install the missing dependencies very accessible (e.g., include a readme in the VM bundles)?
Best, Christoph
Sent from Squeak Inbox Talk
On 2023-11-21T17:02:16+00:00, marcel.taeumel@hpi.de wrote:
Hi all --
Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Thank you!
Best, Marcel
I updated the change log with some compatibility notes: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431
For older systems, OSVM needs to be built manually. But it should be possible.
Best, Marcel
Am 29.11.2023 08:50:44 schrieb Taeumel, Marcel marcel.taeumel@hpi.de:
We build with 20.04. No older runners available on GitHub. We should drop support for 18.04 ... 😎
________________________________ From: Tobias Pape Das.Linux@gmx.de Sent: Tuesday, November 28, 2023 9:46:16 PM To: Open Smalltalk Virtual Machine Development Discussion vm-dev@lists.squeakfoundation.org Subject: [Vm-dev] Re: Please test | Relase candidate for OSVM 2023
Please remember Ubuntu 18 has reached "normal" EOL in April already:
https://ubuntu.com/blog/ubuntu-18-04-eol-for-devices
And it ships with Glibc 2.27 (Even debian buster has 2.28…)
If we want to support older GLIBCen, we have to do strange dances: - for example, explicitly marking symbols to use "old" versoines ones https://web.archive.org/web/20160107032111/http://www.trevorpounds.com/blog/... (this seems excessive) (but pepople seem to have managed that: https://stackoverflow.com/a/69139182 ) - link statically, but that is, imho a Very Bad Idea™ - Kill the version info and cross fingers: https://stackoverflow.com/a/73388939 - Build on ubuntu 18.04. I don't know whether github still has this for runners…
it's messy
best regards -Tobias
On 28. Nov 2023, at 17:38, christoph.thiede@student.hpi.uni-potsdam.de christoph.thiede@student.hpi.uni-potsdam.de wrote:
Hi there,
happy to report a green bar for SimulationStudio under 6.0 using the new VM on Windows 10 22H2 (squeak.cog.spur_win64x64).
However, I cannot start the VM on WSL 1/Ubuntu 18.04 (squeak.cog.spur_linux64x64):
$ squeak /path/to/squeak60.image /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak)
With the previous VM, I did not have this issue.
$ file /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=db26fa3de79c67698b6850c38f487f719f2afd9c, for GNU/Linux 3.2.0, with debug_info, not stripped $ file /usr/bin/squeak.bak20231128/lib/squeak/5.0-202204190959-64bit/squeak /usr/bin/squeak.bak20231128/lib/squeak/5.0-202204190959-64bit/squeak: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=c7e8211b70431cf23cd03d1531d6b82f16366438, with debug_info, not stripped
Should the VM work out of the box without installing extra dependencies? If yes, could there something be missing in the build process? If not, can we please make the documentation on how to install the missing dependencies very accessible (e.g., include a readme in the VM bundles)?
Best, Christoph
Sent from Squeak Inbox Talk
On 2023-11-21T17:02:16+00:00, marcel.taeumel@hpi.de wrote:
Hi all --
Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Thank you!
Best, Marcel
Hi
Thank you all for your work, its a great language.
./bin/squeak does not work...which is cool, I like the ./bin/spur64 command , the separation of vm and image is important, imho.
I chose "assert" because it asserts itself, so take it at its word and see what its got.
https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/download/20231121...
I downloaded the latest image bundle from https://files.squeak.org/trunk/Squeak6.1alpha-22880-64bit/
in my TEST subdirectory, I untarred both and made sure to run the correct binary..
./sqcogspur64linuxht/bin/spur64 Squeak6.1alpha-22880-64bit-202206021410-Linux-x64/shared/Squeak6.1alpha-22880-64bit.image
about 30 seconds into running all the tests, at MCMczInstallerTest >> testInstallFromStream the image hangs.
667 run
608 passes
10 expected failures
5 failures
44 errors
on a whim, I ran it as root, and the errors went down to 5.
cordially
--- Sent from Squeak Inbox Talk
On 2023-11-21T17:02:16+00:00, mailto:marcel.taeumel@hpi.de wrote:
Hi all --
Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Thank you!
Best, Marcel
Happy to report that I was able to build the new OSVM RC on Ubuntu 18.04 myself and reproduce a green bar for SimulationStudio under WSL 1.
Best, Christoph
--- Sent from Squeak Inbox Talk
On 2023-11-28T17:38:57+01:00, christoph.thiede@student.hpi.uni-potsdam.de wrote:
Hi there,
happy to report a green bar for SimulationStudio under 6.0 using the new VM on Windows 10 22H2 (squeak.cog.spur_win64x64).
However, I cannot start the VM on WSL 1/Ubuntu 18.04 (squeak.cog.spur_linux64x64):
$ squeak /path/to/squeak60.image /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak)
With the previous VM, I did not have this issue.
$ file /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=db26fa3de79c67698b6850c38f487f719f2afd9c, for GNU/Linux 3.2.0, with debug_info, not stripped $ file /usr/bin/squeak.bak20231128/lib/squeak/5.0-202204190959-64bit/squeak /usr/bin/squeak.bak20231128/lib/squeak/5.0-202204190959-64bit/squeak: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=c7e8211b70431cf23cd03d1531d6b82f16366438, with debug_info, not stripped
Should the VM work out of the box without installing extra dependencies? If yes, could there something be missing in the build process? If not, can we please make the documentation on how to install the missing dependencies very accessible (e.g., include a readme in the VM bundles)?
Best, Christoph
Sent from Squeak Inbox Talk
On 2023-11-21T17:02:16+00:00, marcel.taeumel(a)hpi.de wrote:
Hi all --
Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Thank you!
Best, Marcel
Hi Marcel,
FWIW, I had another crash during the same use case. Maybe the crash_2023-11-27.dmp is somewhat helpful.
Cheers, Bernhard
Am 26.11.2023 um 22:50 schrieb Bernhard Pieber bernhard@pieber.com:
Hi Marcel,
Thank you for building the release candidate. I just used the squeak.cog.spur_macos64x64 VM with the latest Cuis image for several hours. When I tried to save and quit the VM it crashed, see attachment. It seems to have saved the image correctly before the crash.
I used OSProcess extensively to call md5 to calculate file hashes. I ran into a lot of OSProcess errors. Maybe the crash has something to do with this.
Cheers, Bernhard
Am 21.11.2023 um 18:02 schrieb Taeumel, Marcel Marcel.Taeumel@hpi.de:
Hi all --
Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Thank you!
Best, Marcel
Hi Bernhard --
Yes, this looks like some kind of memory corruption. Maybe you could set up a little test script that does that md5 hashing extensively and mix it up with snapshotPrimitive ?
Best, Marcel
Am 30.11.2023 09:30:10 schrieb Bernhard Pieber bernhard@pieber.com:
Hi Marcel,
FWIW, I had another crash during the same use case. Maybe the crash_2023-11-27.dmp is somewhat helpful.
Cheers, Bernhard
Am 26.11.2023 um 22:50 schrieb Bernhard Pieber bernhard@pieber.com:
Hi Marcel,
Thank you for building the release candidate. I just used the squeak.cog.spur_macos64x64 VM with the latest Cuis image for several hours. When I tried to save and quit the VM it crashed, see attachment. It seems to have saved the image correctly before the crash.
I used OSProcess extensively to call md5 to calculate file hashes. I ran into a lot of OSProcess errors. Maybe the crash has something to do with this.
Cheers, Bernhard
Am 21.11.2023 um 18:02 schrieb Taeumel, Marcel Marcel.Taeumel@hpi.de:
Hi all --
Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Thank you!
Best, Marcel
Hi all --
There is a new release candidate OSVM 2023.12! :-)
Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202312181441
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Thank you!
Best, Marcel
Am 21.11.2023 18:02:11 schrieb Marcel marcel.taeumel@hpi.uni-potsdam.de:
Hi all --
Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Thank you!
Best, Marcel
Thanks Marcel,
I'm testing them for the upcoming release of Cuis 6.1. BTW, it is at https://github.com/jvuletich/CuisExperiments004 . Everybody is welcome to try it and five feedback.
Cheers,
On 12/20/2023 12:03 PM, Taeumel, Marcel wrote:
Hi all --
There is a new release candidate OSVM 2023.12! :-)
Please test this VM version (includes a small change log): _https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202312181441_
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Thank you!
Best, Marcel
Am 21.11.2023 18:02:11 schrieb Marcel marcel.taeumel@hpi.uni-potsdam.de:
Hi all --
Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Thank you!
Best, Marcel
vm-dev@lists.squeakfoundation.org