Hi all --
What's you overall feeling of having a new release candidate of the OSVM?
Overall pace has been decreasing during the last weeks. Maybe this is a good time then? Latest commit was about 10 hours ago. So, wait for 2-3 days and then tag that version, produce binaries and test those?
Best, Marcel
Hi all --
Please test this VM version: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203]
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Best, Marcel Am 01.12.2021 10:38:47 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
What's you overall feeling of having a new release candidate of the OSVM?
Overall pace has been decreasing during the last weeks. Maybe this is a good time then? Latest commit was about 10 hours ago. So, wait for 2-3 days and then tag that version, produce binaries and test those?
Best, Marcel
Hi,
I ran some tests this morning on the systems I can put my hands on. In all cases it is the squeak.cog.spur downloads.
* MacOS Catalina on x86-64.
** works perfectly.
** sound checked and works perfectly.
** The menu shows Squeak 5.0 but the version number in About SqueakOSXApp is probably ok.
* Linux x86-64 based on Ubuntu 20.4.
** works perfectly.
** sound checked and works perfectly.
* Windows 10 19.09 on Win64
** works perfectly
** sound checked and works perfectly.
* Linux ARMv8 based on Ubuntu 18.4
** works perfectly.
** sound can not be checked.
* Linux ARMv6 Raspberry PI running a currentish version of PiOS based on Debian 10.4
** works perfectly.
** sound can not be checked.
* Linux ARMv6 Raspberry PI running an old version of PiOS based on Debian 9.3
** does not work, a glibc version problem
** I would not worry about this but I just checked to be complete. Let's stick with currentish versions of PiOS
In addition I have downloaded the source for the same version and built it on all of the above linux systems and they all run. So, for example, the old Raspberry PI system can be just built from source if someone really needs Squeak to run. It takes on the order of 3 minutes.
cheers
bruce
On 2021-12-09T10:57:56.000+01:00, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi all -- Please test this VM version: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203] Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines. Best, Marcel -------------------------
Am 01.12.2021 10:38:47 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all -- What's you overall feeling of having a new release candidate of the OSVM? Overall pace has been decreasing during the last weeks. Maybe this is a good time then? Latest commit was about 10 hours ago. So, wait for 2-3 days and then tag that version, produce binaries and test those? Best, Marcel
Hi Marcel,
The SHA2 plugin (primitiveSHA256ProcessBufferUpdatingHash) still crashes with that VM on 64-bit linux. The plugin code works with earlier versions, so it's either a VM change of the past 6-9 months, a code generator bug or a compiler bug IMO.
To reproduce the crash, evaluate the following:
Installer ss project: 'Registers'; install: 'Registers-Core'. Installer ss project: 'Cryptography'; addPackage: 'CryptographyHashing'; addPackage: 'CryptographyHashingTests'; install. (Smalltalk classNamed: #SHA256WithSHA2PluginTest) run: #testInputs
Interestingly another test (SHA512WithSHA2PluginTest) using a very similar primitive but with DoubleWords works fine. So perhaps it's an alignment issue.
Assert and debug VMs do not have that issue, so it's not that easy to debug it. What I found was that buffer's value at https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/99f1116c0f7a4ba9a0bf8... was not the expected pointer, so the subsequent copying into it resulted in segmentation fault.
Levente
Hi Levente --
Windows VM crashes, too. But at a different test: #testHMACSH512Spec.
And the filename for the crash-dmp is broken.
Best, Marcel
Am 10.12.2021 13:43:45 schrieb Levente Uzonyi leves@caesar.elte.hu:
Hi Marcel,
The SHA2 plugin (primitiveSHA256ProcessBufferUpdatingHash) still crashes with that VM on 64-bit linux. The plugin code works with earlier versions, so it's either a VM change of the past 6-9 months, a code generator bug or a compiler bug IMO.
To reproduce the crash, evaluate the following:
Installer ss project: 'Registers'; install: 'Registers-Core'. Installer ss project: 'Cryptography'; addPackage: 'CryptographyHashing'; addPackage: 'CryptographyHashingTests'; install. (Smalltalk classNamed: #SHA256WithSHA2PluginTest) run: #testInputs
Interestingly another test (SHA512WithSHA2PluginTest) using a very similar primitive but with DoubleWords works fine. So perhaps it's an alignment issue.
Assert and debug VMs do not have that issue, so it's not that easy to debug it. What I found was that buffer's value at https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/99f1116c0f7a4ba9a0bf8... was not the expected pointer, so the subsequent copying into it resulted in segmentation fault.
Levente
Hmm... Clang seems to be part of the problem. A gcc build on Ubuntu 18.04 did not crash.
squeak.cog.spur_win64x64 (Windows 10 21H2) Clang 13.0.0 - CRASH Clang 8.0.1 - CRASH
squeak.cog.spur_linux64x64 (Ubuntu 18.04) gcc 7.5.0 - OK (with some failing tests) Clang 9.0.0 - CRASH Am 10.12.2021 14:40:26 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Levente --
Windows VM crashes, too. But at a different test: #testHMACSH512Spec.
And the filename for the crash-dmp is broken.
Best, Marcel
Am 10.12.2021 13:43:45 schrieb Levente Uzonyi leves@caesar.elte.hu:
Hi Marcel,
The SHA2 plugin (primitiveSHA256ProcessBufferUpdatingHash) still crashes with that VM on 64-bit linux. The plugin code works with earlier versions, so it's either a VM change of the past 6-9 months, a code generator bug or a compiler bug IMO.
To reproduce the crash, evaluate the following:
Installer ss project: 'Registers'; install: 'Registers-Core'. Installer ss project: 'Cryptography'; addPackage: 'CryptographyHashing'; addPackage: 'CryptographyHashingTests'; install. (Smalltalk classNamed: #SHA256WithSHA2PluginTest) run: #testInputs
Interestingly another test (SHA512WithSHA2PluginTest) using a very similar primitive but with DoubleWords works fine. So perhaps it's an alignment issue.
Assert and debug VMs do not have that issue, so it's not that easy to debug it. What I found was that buffer's value at https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/99f1116c0f7a4ba9a0bf8... was not the expected pointer, so the subsequent copying into it resulted in segmentation fault.
Levente
Ugg Groan.
Given it is Clang, which is agressive on taking the undefined parts of the C standards as undefined, combined with the debug ones not crashing means that there is probably some code that looks ok but is actually taking advantage of something that is not defined in C.
We could try turning off optimization for this plugin but that is a hack and not a fix.
I might get lucky and see if I can scare some sensible message out of Clang about what it thinks is undefined.
cheers
bruce
On 2021-12-10T15:06:41.000+01:00, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hmm... Clang seems to be part of the problem. A gcc build on Ubuntu 18.04 did not crash. squeak.cog.spur_win64x64 (Windows 10 21H2) Clang 13.0.0 - CRASH Clang 8.0.1 - CRASH squeak.cog.spur_linux64x64 (Ubuntu 18.04) gcc 7.5.0 - OK (with some failing tests) Clang 9.0.0 - CRASH -------------------------
Am 10.12.2021 14:40:26 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Levente -- Windows VM crashes, too. But at a different test: #testHMACSH512Spec. <image.png> And the filename for the crash-dmp is broken. Best, Marcel
Am 10.12.2021 13:43:45 schrieb Levente Uzonyi leves@caesar.elte.hu: Hi Marcel, The SHA2 plugin (primitiveSHA256ProcessBufferUpdatingHash) still crashes with that VM on 64-bit linux. The plugin code works with earlier versions, so it's either a VM change of the past 6-9 months, a code generator bug or a compiler bug IMO. To reproduce the crash, evaluate the following: Installer ss project: 'Registers'; install: 'Registers-Core'. Installer ss project: 'Cryptography'; addPackage: 'CryptographyHashing'; addPackage: 'CryptographyHashingTests'; install. (Smalltalk classNamed: #SHA256WithSHA2PluginTest) run: #testInputs Interestingly another test (SHA512WithSHA2PluginTest) using a very similar primitive but with DoubleWords works fine. So perhaps it's an alignment issue. Assert and debug VMs do not have that issue, so it's not that easy to debug it. What I found was that buffer's value at https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/99f1116c0f7a4ba9a0bf8... was not the expected pointer, so the subsequent copying into it resulted in segmentation fault. Levente
Interestingly, the debug build for Windows produces test failures. Debug builds on both Windows 10 and Ubuntu 18.04 have the same errors.
ERRORS CryptoHashFunctionTest>>#testHMAC CryptoHashFunctionTest>>#testHMACMD5Spec CryptoHashFunctionTest>>#testHMACSHA1Spec CryptoHashFunctionTest>>#testHMACSHA256Spec CryptoHashFunctionTest>>#testHMACSHA512Spec CryptoHashFunctionTest>>#testLargeSHA1 CryptoHashFunctionTest>>#testMD5 CryptoHashFunctionTest>>#testSHA1 CryptoHashFunctionTest>>#testSHA256 CryptoHashFunctionTest>>#testSHA512
Example #testMAC MessageNotUnderstood: ByteArray >> asInteger
Is there some code missing here?
FAILURES (Windows 10 only) HMACTest>>#testEmptyStringWithKeyKey SHA384WithSHA2PluginTest>>#testInputStream SHA384WithSHA2PluginTest>>#testInputs SHA512WithSHA2PluginTest>>#testInputStream SHA512WithSHA2PluginTest>>#testInputs SHA512p224WithSHA2PluginTest>>#testInputStream SHA512p224WithSHA2PluginTest>>#testInputs SHA512p256WithSHA2PluginTest>>#testInputStream SHA512p256WithSHA2PluginTest>>#testInputs
Example #testInputs Expected: cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e Actual: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Why is this working in the debug build on Ubuntu? Am 10.12.2021 15:06:41 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hmm... Clang seems to be part of the problem. A gcc build on Ubuntu 18.04 did not crash.
squeak.cog.spur_win64x64 (Windows 10 21H2) Clang 13.0.0 - CRASH Clang 8.0.1 - CRASH
squeak.cog.spur_linux64x64 (Ubuntu 18.04) gcc 7.5.0 - OK (with some failing tests) Clang 9.0.0 - CRASH Am 10.12.2021 14:40:26 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Levente --
Windows VM crashes, too. But at a different test: #testHMACSH512Spec.
And the filename for the crash-dmp is broken.
Best, Marcel
Am 10.12.2021 13:43:45 schrieb Levente Uzonyi leves@caesar.elte.hu:
Hi Marcel,
The SHA2 plugin (primitiveSHA256ProcessBufferUpdatingHash) still crashes with that VM on 64-bit linux. The plugin code works with earlier versions, so it's either a VM change of the past 6-9 months, a code generator bug or a compiler bug IMO.
To reproduce the crash, evaluate the following:
Installer ss project: 'Registers'; install: 'Registers-Core'. Installer ss project: 'Cryptography'; addPackage: 'CryptographyHashing'; addPackage: 'CryptographyHashingTests'; install. (Smalltalk classNamed: #SHA256WithSHA2PluginTest) run: #testInputs
Interestingly another test (SHA512WithSHA2PluginTest) using a very similar primitive but with DoubleWords works fine. So perhaps it's an alignment issue.
Assert and debug VMs do not have that issue, so it's not that easy to debug it. What I found was that buffer's value at https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/99f1116c0f7a4ba9a0bf8... was not the expected pointer, so the subsequent copying into it resulted in segmentation fault.
Levente
Hi all --
So, I am trying to debug this on Windows. I want to figure out why the SHA-384 and beyond are not working in the debug build.
Here is the code:
#(newMD5 newSHA1 newSHA224 newSHA256 newSHA384 newSHA512 newSHA512p224 newSHA512p256) collect: [:sym | sym -> ((HashFunction perform: sym) hmac key: 'key'; hashMessage: '') hex] as: OrderedDictionary
Best, Marcel
Am 10.12.2021 15:30:49 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Interestingly, the debug build for Windows produces test failures. Debug builds on both Windows 10 and Ubuntu 18.04 have the same errors.
ERRORS CryptoHashFunctionTest>>#testHMAC CryptoHashFunctionTest>>#testHMACMD5Spec CryptoHashFunctionTest>>#testHMACSHA1Spec CryptoHashFunctionTest>>#testHMACSHA256Spec CryptoHashFunctionTest>>#testHMACSHA512Spec CryptoHashFunctionTest>>#testLargeSHA1 CryptoHashFunctionTest>>#testMD5 CryptoHashFunctionTest>>#testSHA1 CryptoHashFunctionTest>>#testSHA256 CryptoHashFunctionTest>>#testSHA512
Example #testMAC MessageNotUnderstood: ByteArray >> asInteger
Is there some code missing here?
FAILURES (Windows 10 only) HMACTest>>#testEmptyStringWithKeyKey SHA384WithSHA2PluginTest>>#testInputStream SHA384WithSHA2PluginTest>>#testInputs SHA512WithSHA2PluginTest>>#testInputStream SHA512WithSHA2PluginTest>>#testInputs SHA512p224WithSHA2PluginTest>>#testInputStream SHA512p224WithSHA2PluginTest>>#testInputs SHA512p256WithSHA2PluginTest>>#testInputStream SHA512p256WithSHA2PluginTest>>#testInputs
Example #testInputs Expected: cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e Actual: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Why is this working in the debug build on Ubuntu? Am 10.12.2021 15:06:41 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hmm... Clang seems to be part of the problem. A gcc build on Ubuntu 18.04 did not crash.
squeak.cog.spur_win64x64 (Windows 10 21H2) Clang 13.0.0 - CRASH Clang 8.0.1 - CRASH
squeak.cog.spur_linux64x64 (Ubuntu 18.04) gcc 7.5.0 - OK (with some failing tests) Clang 9.0.0 - CRASH Am 10.12.2021 14:40:26 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Levente --
Windows VM crashes, too. But at a different test: #testHMACSH512Spec.
And the filename for the crash-dmp is broken.
Best, Marcel
Am 10.12.2021 13:43:45 schrieb Levente Uzonyi leves@caesar.elte.hu:
Hi Marcel,
The SHA2 plugin (primitiveSHA256ProcessBufferUpdatingHash) still crashes with that VM on 64-bit linux. The plugin code works with earlier versions, so it's either a VM change of the past 6-9 months, a code generator bug or a compiler bug IMO.
To reproduce the crash, evaluate the following:
Installer ss project: 'Registers'; install: 'Registers-Core'. Installer ss project: 'Cryptography'; addPackage: 'CryptographyHashing'; addPackage: 'CryptographyHashingTests'; install. (Smalltalk classNamed: #SHA256WithSHA2PluginTest) run: #testInputs
Interestingly another test (SHA512WithSHA2PluginTest) using a very similar primitive but with DoubleWords works fine. So perhaps it's an alignment issue.
Assert and debug VMs do not have that issue, so it's not that easy to debug it. What I found was that buffer's value at https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/99f1116c0f7a4ba9a0bf8... was not the expected pointer, so the subsequent copying into it resulted in segmentation fault.
Levente
Hi all --
Well, this is weird (plugins/SHA2Plugin/SHA2Plugin.c, generated):
174: (((unsigned long *) (((unsigned long long*) bytes))))[i] = (SQ_SWAP_8_BYTES(((((unsigned long *) doubleWords))[i])));
Why does this work on 32-bit platforms (ILP32)? Why does this work on 64-bit Windows (LLP64)? Why does this work on 64-bit Linux (LP64)?
Anyway. I tried to debug the strange behavior of "primitiveCopyDoubleWordsIntoBytesBigEndian" in the debug build on Windows.
End of July 2021, the #FastCPrimitiveFlag was set in that method. (CryptographyPlugins-eem.23) Maybe that was not a good idea. Or maybe we just found a bug in the "Fast C primitives" mechanism.
Eliot? :-)
I just removed the flag but the generated code (see above) still cuts of stuff like some type casting went wrong. (debug build)
!!! I removed all #FastCPrimitiveFlag from the SHA2Plugin. And the VM does not crash anymore! (fast build) But those tests bother me. See above that line of generated code. It's broken.
***
I suspect an interference of #FastCPrimitiveFlag and a Clang compiler optimization flag.
Best, Marcel Am 10.12.2021 15:47:24 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
So, I am trying to debug this on Windows. I want to figure out why the SHA-384 and beyond are not working in the debug build.
Here is the code:
#(newMD5 newSHA1 newSHA224 newSHA256 newSHA384 newSHA512 newSHA512p224 newSHA512p256) collect: [:sym | sym -> ((HashFunction perform: sym) hmac key: 'key'; hashMessage: '') hex] as: OrderedDictionary
Best, Marcel
Am 10.12.2021 15:30:49 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Interestingly, the debug build for Windows produces test failures. Debug builds on both Windows 10 and Ubuntu 18.04 have the same errors.
ERRORS CryptoHashFunctionTest>>#testHMAC CryptoHashFunctionTest>>#testHMACMD5Spec CryptoHashFunctionTest>>#testHMACSHA1Spec CryptoHashFunctionTest>>#testHMACSHA256Spec CryptoHashFunctionTest>>#testHMACSHA512Spec CryptoHashFunctionTest>>#testLargeSHA1 CryptoHashFunctionTest>>#testMD5 CryptoHashFunctionTest>>#testSHA1 CryptoHashFunctionTest>>#testSHA256 CryptoHashFunctionTest>>#testSHA512
Example #testMAC MessageNotUnderstood: ByteArray >> asInteger
Is there some code missing here?
FAILURES (Windows 10 only) HMACTest>>#testEmptyStringWithKeyKey SHA384WithSHA2PluginTest>>#testInputStream SHA384WithSHA2PluginTest>>#testInputs SHA512WithSHA2PluginTest>>#testInputStream SHA512WithSHA2PluginTest>>#testInputs SHA512p224WithSHA2PluginTest>>#testInputStream SHA512p224WithSHA2PluginTest>>#testInputs SHA512p256WithSHA2PluginTest>>#testInputStream SHA512p256WithSHA2PluginTest>>#testInputs
Example #testInputs Expected: cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e Actual: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Why is this working in the debug build on Ubuntu? Am 10.12.2021 15:06:41 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hmm... Clang seems to be part of the problem. A gcc build on Ubuntu 18.04 did not crash.
squeak.cog.spur_win64x64 (Windows 10 21H2) Clang 13.0.0 - CRASH Clang 8.0.1 - CRASH
squeak.cog.spur_linux64x64 (Ubuntu 18.04) gcc 7.5.0 - OK (with some failing tests) Clang 9.0.0 - CRASH Am 10.12.2021 14:40:26 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Levente --
Windows VM crashes, too. But at a different test: #testHMACSH512Spec.
And the filename for the crash-dmp is broken.
Best, Marcel
Am 10.12.2021 13:43:45 schrieb Levente Uzonyi leves@caesar.elte.hu:
Hi Marcel,
The SHA2 plugin (primitiveSHA256ProcessBufferUpdatingHash) still crashes with that VM on 64-bit linux. The plugin code works with earlier versions, so it's either a VM change of the past 6-9 months, a code generator bug or a compiler bug IMO.
To reproduce the crash, evaluate the following:
Installer ss project: 'Registers'; install: 'Registers-Core'. Installer ss project: 'Cryptography'; addPackage: 'CryptographyHashing'; addPackage: 'CryptographyHashingTests'; install. (Smalltalk classNamed: #SHA256WithSHA2PluginTest) run: #testInputs
Interestingly another test (SHA512WithSHA2PluginTest) using a very similar primitive but with DoubleWords works fine. So perhaps it's an alignment issue.
Assert and debug VMs do not have that issue, so it's not that easy to debug it. What I found was that buffer's value at https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/99f1116c0f7a4ba9a0bf8... was not the expected pointer, so the subsequent copying into it resulted in segmentation fault.
Levente
Hi all, either the plugin slang or the generated code has problems: see https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/6f2914e4484fa2d6f0e01...
(((unsigned long *) (((unsigned long long*) bytes))))[i] = (SQ_SWAP_8_BYTES (((((unsigned long *) doubleWords))[i])));
This ain't gonna work on windows 64bits where long are 32bits (LLP64). Also incorrect on 32bits VM...
Le ven. 10 déc. 2021 à 15:47, Marcel Taeumel marcel.taeumel@hpi.de a écrit :
Hi all --
So, I am trying to debug this on Windows. I want to figure out why the SHA-384 and beyond are not working in the debug build.
Here is the code:
#(newMD5 newSHA1 newSHA224 newSHA256 newSHA384 newSHA512 newSHA512p224 newSHA512p256) collect: [:sym | sym -> ((HashFunction perform: sym) hmac key: 'key'; hashMessage: '') hex] as: OrderedDictionary
Best, Marcel
Am 10.12.2021 15:30:49 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Interestingly, the debug build for Windows produces test failures. Debug builds on both Windows 10 and Ubuntu 18.04 have the same errors.
ERRORS CryptoHashFunctionTest>>#testHMAC CryptoHashFunctionTest>>#testHMACMD5Spec CryptoHashFunctionTest>>#testHMACSHA1Spec CryptoHashFunctionTest>>#testHMACSHA256Spec CryptoHashFunctionTest>>#testHMACSHA512Spec CryptoHashFunctionTest>>#testLargeSHA1 CryptoHashFunctionTest>>#testMD5 CryptoHashFunctionTest>>#testSHA1 CryptoHashFunctionTest>>#testSHA256 CryptoHashFunctionTest>>#testSHA512
Example #testMAC MessageNotUnderstood: ByteArray >> asInteger
Is there some code missing here?
FAILURES (Windows 10 only) HMACTest>>#testEmptyStringWithKeyKey SHA384WithSHA2PluginTest>>#testInputStream SHA384WithSHA2PluginTest>>#testInputs SHA512WithSHA2PluginTest>>#testInputStream SHA512WithSHA2PluginTest>>#testInputs SHA512p224WithSHA2PluginTest>>#testInputStream SHA512p224WithSHA2PluginTest>>#testInputs SHA512p256WithSHA2PluginTest>>#testInputStream SHA512p256WithSHA2PluginTest>>#testInputs
Example #testInputs Expected: cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e Actual: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Why is this working in the debug build on Ubuntu?
Am 10.12.2021 15:06:41 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hmm... Clang seems to be part of the problem. A gcc build on Ubuntu 18.04 did not crash.
squeak.cog.spur_win64x64 (Windows 10 21H2) Clang 13.0.0 - CRASH Clang 8.0.1 - CRASH
squeak.cog.spur_linux64x64 (Ubuntu 18.04) gcc 7.5.0 - OK (with some failing tests) Clang 9.0.0 - CRASH
Am 10.12.2021 14:40:26 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Levente --
Windows VM crashes, too. But at a different test: #testHMACSH512Spec.
And the filename for the crash-dmp is broken.
Best, Marcel
Am 10.12.2021 13:43:45 schrieb Levente Uzonyi leves@caesar.elte.hu:
Hi Marcel,
The SHA2 plugin (primitiveSHA256ProcessBufferUpdatingHash) still crashes with that VM on 64-bit linux. The plugin code works with earlier versions, so it's either a VM change of the past 6-9 months, a code generator bug or a compiler bug IMO.
To reproduce the crash, evaluate the following:
Installer ss project: 'Registers'; install: 'Registers-Core'. Installer ss project: 'Cryptography'; addPackage: 'CryptographyHashing'; addPackage: 'CryptographyHashingTests'; install. (Smalltalk classNamed: #SHA256WithSHA2PluginTest) run: #testInputs
Interestingly another test (SHA512WithSHA2PluginTest) using a very similar primitive but with DoubleWords works fine. So perhaps it's an alignment issue.
Assert and debug VMs do not have that issue, so it's not that easy to debug it. What I found was that buffer's value at
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/99f1116c0f7a4ba9a0bf8... was not the expected pointer, so the subsequent copying into it resulted in segmentation fault.
Levente
Hi Both,
see commit 97b4903b4b88f22c1bd11760f107852c63f9db40 Author: Eliot Miranda eliot.miranda@gmail.com Date: Sat Dec 11 11:58:58 2021 -0800
src/plugins/SHA2Plugin/SHA2Plugin.c as per CryptographyPlugins-eem.24
Fix crashes in primitiveSHA256ProcessBufferUpdatingHash when compiling with Clang on x86_64 due to SSE instructions which require 128-bit stack alignment.
I need to know about any other such crashes pronto.
On Fri, Dec 10, 2021 at 4:43 AM Levente Uzonyi leves@caesar.elte.hu wrote:
Hi Marcel,
The SHA2 plugin (primitiveSHA256ProcessBufferUpdatingHash) still crashes with that VM on 64-bit linux. The plugin code works with earlier versions, so it's either a VM change of the past 6-9 months, a code generator bug or a compiler bug IMO.
To reproduce the crash, evaluate the following:
Installer ss project: 'Registers'; install: 'Registers-Core'. Installer ss project: 'Cryptography'; addPackage: 'CryptographyHashing'; addPackage: 'CryptographyHashingTests'; install. (Smalltalk classNamed: #SHA256WithSHA2PluginTest) run: #testInputs
Interestingly another test (SHA512WithSHA2PluginTest) using a very similar primitive but with DoubleWords works fine. So perhaps it's an alignment issue.
Assert and debug VMs do not have that issue, so it's not that easy to debug it. What I found was that buffer's value at
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/99f1116c0f7a4ba9a0bf8... was not the expected pointer, so the subsequent copying into it resulted in segmentation fault.
Levente
Hi,
Thanks very much!
This version:
and
Date: Sat Dec 11 11:58:58 2021 CommitHash: 97b4903b4
and ran this test:
Installer ss
project: 'Registers';
install: 'Registers-Core'.
Installer ss
project: 'Cryptography';
addPackage: 'CryptographyHashing';
addPackage: 'CryptographyHashingTests';
install.
(Smalltalk classNamed: #SHA256WithSHA2PluginTest) run: #testInputs
and
Linux64x64 had no crashes, but a few expected failures.
Linux64ARMv8 had no crashes but some unexpected test failures
Linux32ArmV6 had no crashes but some unexpected test failures.
So thanks, this bug seems squashed.
cheers
bruce
On 2021-12-11T21:02:23.000+01:00, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Both, see commit 97b4903b4b88f22c1bd11760f107852c63f9db40Author: Eliot Miranda eliot.miranda@gmail.com Date: Sat Dec 11 11:58:58 2021 -0800 src/plugins/SHA2Plugin/SHA2Plugin.c as per CryptographyPlugins-eem.24 Fix crashes in primitiveSHA256ProcessBufferUpdatingHash when compiling with Clang on x86_64 due to SSE instructions which require 128-bit stack alignment. I need to know about any other such crashes pronto. On Fri, Dec 10, 2021 at 4:43 AM Levente Uzonyi leves@caesar.elte.hu wrote:
Hi Marcel, The SHA2 plugin (primitiveSHA256ProcessBufferUpdatingHash) still crashes with that VM on 64-bit linux. The plugin code works with earlier versions, so it's either a VM change of the past 6-9 months, a code generator bug or a compiler bug IMO. To reproduce the crash, evaluate the following: Installer ss project: 'Registers'; install: 'Registers-Core'. Installer ss project: 'Cryptography'; addPackage: 'CryptographyHashing'; addPackage: 'CryptographyHashingTests'; install. (Smalltalk classNamed: #SHA256WithSHA2PluginTest) run: #testInputs Interestingly another test (SHA512WithSHA2PluginTest) using a very similar primitive but with DoubleWords works fine. So perhaps it's an alignment issue. Assert and debug VMs do not have that issue, so it's not that easy to debug it. What I found was that buffer's value at https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/99f1116c0f7a4ba9a0bf8... was not the expected pointer, so the subsequent copying into it resulted in segmentation fault. Levente
-- _,,,^..^,,,_ best, Eliot -------------------------
Hi Eliot, hi all --
VM 202112111958 is still crashing on Windows 10 (64-bit). File name for crash dump still with Chinese characters :-O
(Smalltalk classNamed: #CryptoHashFunctionTest) run: #testHMACSHA512Spec
--------------------------- Fatal Squeak VM error --------------------------- Sorry but the Squeak VM has crashed.
Exception code: c0000005 Exception address: 0000000067b81940 Current byte code: -1 Primitive index: 0
Crashed in the VM thread
This information will be stored in the file
with a complete stack dump --------------------------- OK ---------------------------
Best, Marcel Am 12.12.2021 19:17:30 schrieb Bruce O'Neel bruce.oneel@pckswarms.ch: Hi,
Thanks very much!
This version:
and
Date: Sat Dec 11 11:58:58 2021 CommitHash: 97b4903b4
and ran this test:
Installer ss
project: 'Registers';
install: 'Registers-Core'.
Installer ss
project: 'Cryptography';
addPackage: 'CryptographyHashing';
addPackage: 'CryptographyHashingTests';
install.
(Smalltalk classNamed: #SHA256WithSHA2PluginTest) run: #testInputs
and
Linux64x64 had no crashes, but a few expected failures.
Linux64ARMv8 had no crashes but some unexpected test failures
Linux32ArmV6 had no crashes but some unexpected test failures.
So thanks, this bug seems squashed.
cheers
bruce
On 2021-12-11T21:02:23.000+01:00, Eliot Miranda eliot.miranda@gmail.com wrote: Hi Both,
see commit 97b4903b4b88f22c1bd11760f107852c63f9db40 Author: Eliot Miranda <eliot.miranda@gmail.com [mailto:eliot.miranda@gmail.com]> Date: Sat Dec 11 11:58:58 2021 -0800
src/plugins/SHA2Plugin/SHA2Plugin.c as per CryptographyPlugins-eem.24
Fix crashes in primitiveSHA256ProcessBufferUpdatingHash when compiling with Clang on x86_64 due to SSE instructions which require 128-bit stack alignment.
I need to know about any other such crashes pronto.
On Fri, Dec 10, 2021 at 4:43 AM Levente Uzonyi <leves@caesar.elte.hu [mailto:leves@caesar.elte.hu]> wrote:
Hi Marcel,
The SHA2 plugin (primitiveSHA256ProcessBufferUpdatingHash) still crashes with that VM on 64-bit linux. The plugin code works with earlier versions, so it's either a VM change of the past 6-9 months, a code generator bug or a compiler bug IMO.
To reproduce the crash, evaluate the following:
Installer ss project: 'Registers'; install: 'Registers-Core'. Installer ss project: 'Cryptography'; addPackage: 'CryptographyHashing'; addPackage: 'CryptographyHashingTests'; install. (Smalltalk classNamed: #SHA256WithSHA2PluginTest) run: #testInputs
Interestingly another test (SHA512WithSHA2PluginTest) using a very similar primitive but with DoubleWords works fine. So perhaps it's an alignment issue.
Assert and debug VMs do not have that issue, so it's not that easy to debug it. What I found was that buffer's value at https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/99f1116c0f7a4ba9a0bf8... [https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/99f1116c0f7a4ba9a0bf8...] was not the expected pointer, so the subsequent copying into it resulted in segmentation fault.
Levente
--
_,,,^..^,,,_
best, Eliot
Hi all --
With "CryptographyPlugins-mt.25" from the Inbox, the crash is gone. Can somebody with write access merge it? Thanks. :-)
Best, Marcel Am 13.12.2021 09:57:10 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Eliot, hi all --
VM 202112111958 is still crashing on Windows 10 (64-bit). File name for crash dump still with Chinese characters :-O
(Smalltalk classNamed: #CryptoHashFunctionTest) run: #testHMACSHA512Spec
--------------------------- Fatal Squeak VM error --------------------------- Sorry but the Squeak VM has crashed.
Exception code: c0000005 Exception address: 0000000067b81940 Current byte code: -1 Primitive index: 0
Crashed in the VM thread
This information will be stored in the file
with a complete stack dump --------------------------- OK ---------------------------
Best, Marcel Am 12.12.2021 19:17:30 schrieb Bruce O'Neel bruce.oneel@pckswarms.ch: Hi,
Thanks very much!
This version:
and
Date: Sat Dec 11 11:58:58 2021 CommitHash: 97b4903b4
and ran this test:
Installer ss
project: 'Registers';
install: 'Registers-Core'.
Installer ss
project: 'Cryptography';
addPackage: 'CryptographyHashing';
addPackage: 'CryptographyHashingTests';
install.
(Smalltalk classNamed: #SHA256WithSHA2PluginTest) run: #testInputs
and
Linux64x64 had no crashes, but a few expected failures.
Linux64ARMv8 had no crashes but some unexpected test failures
Linux32ArmV6 had no crashes but some unexpected test failures.
So thanks, this bug seems squashed.
cheers
bruce
On 2021-12-11T21:02:23.000+01:00, Eliot Miranda eliot.miranda@gmail.com wrote: Hi Both,
see commit 97b4903b4b88f22c1bd11760f107852c63f9db40 Author: Eliot Miranda <eliot.miranda@gmail.com [mailto:eliot.miranda@gmail.com]> Date: Sat Dec 11 11:58:58 2021 -0800
src/plugins/SHA2Plugin/SHA2Plugin.c as per CryptographyPlugins-eem.24
Fix crashes in primitiveSHA256ProcessBufferUpdatingHash when compiling with Clang on x86_64 due to SSE instructions which require 128-bit stack alignment.
I need to know about any other such crashes pronto.
On Fri, Dec 10, 2021 at 4:43 AM Levente Uzonyi <leves@caesar.elte.hu [mailto:leves@caesar.elte.hu]> wrote:
Hi Marcel,
The SHA2 plugin (primitiveSHA256ProcessBufferUpdatingHash) still crashes with that VM on 64-bit linux. The plugin code works with earlier versions, so it's either a VM change of the past 6-9 months, a code generator bug or a compiler bug IMO.
To reproduce the crash, evaluate the following:
Installer ss project: 'Registers'; install: 'Registers-Core'. Installer ss project: 'Cryptography'; addPackage: 'CryptographyHashing'; addPackage: 'CryptographyHashingTests'; install. (Smalltalk classNamed: #SHA256WithSHA2PluginTest) run: #testInputs
Interestingly another test (SHA512WithSHA2PluginTest) using a very similar primitive but with DoubleWords works fine. So perhaps it's an alignment issue.
Assert and debug VMs do not have that issue, so it's not that easy to debug it. What I found was that buffer's value at https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/99f1116c0f7a4ba9a0bf8... [https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/99f1116c0f7a4ba9a0bf8...] was not the expected pointer, so the subsequent copying into it resulted in segmentation fault.
Levente
--
_,,,^..^,,,_
best, Eliot
Hi Marcel,
I can confirm that VectorEnginePlugin works ok on the cog.spur for x64 on Linux, Windows and MacOS variants with latest Cuis.
Thanks!
On 12/9/2021 6:57 AM, Marcel Taeumel wrote:
Hi all --
Please test this VM version: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Best, Marcel
Am 01.12.2021 10:38:47 schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hi all --
What's you overall feeling of having a new release candidate of the OSVM?
Overall pace has been decreasing during the last weeks. Maybe this is a good time then? Latest commit was about 10 hours ago. So, wait for 2-3 days and then tag that version, produce binaries and test those?
Best, Marcel
Hi all --
Here is the next release candidate: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228]
Note that the macOS build artifacts are still unsigned and not notarized but will be as soon as I attach those to our squeak-app bundling job [1], which produces ready-to-run artifacts [2]. So, if you cannot manage to execute the macOS artifacts in this form, please report, compile yourself, and/or wait for a separate notification on the squeak-app bundles.
Best, Marcel
[1] https://github.com/squeak-smalltalk/squeak-app/actions [2] http://files.squeak.org/trunk/
Am 09.12.2021 10:57:56 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
Please test this VM version: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203]
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Best, Marcel Am 01.12.2021 10:38:47 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
What's you overall feeling of having a new release candidate of the OSVM?
Overall pace has been decreasing during the last weeks. Maybe this is a good time then? Latest commit was about 10 hours ago. So, wait for 2-3 days and then tag that version, produce binaries and test those?
Best, Marcel
On Mon, Dec 20, 2021 at 03:31:00PM +0100, Marcel Taeumel wrote:
Hi all --
Here is the next release candidate: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228]
I see no issues with the VM, except that I have a library version issue that prevents connection to source.squeak.org. This is on Ubuntu 16.04 LTS, which is an older version which is at end of life and no longer supported. IMO this should *not* be considered a show stopper for release, although it will probably cause problems for some people who are not keeping their Linux systems up to date.
The library version problem is:
SqueakSSL tryLoading /usr/local/bin/../lib/squeak/5.0-202112022203-64bit/SqueakSSL.so: dlopen: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.27' not found (required by /usr/local/bin/../lib/squeak/5.0-202112022203-64bit/SqueakSSL.so)
And my system is:
$ cat /proc/version Linux version 4.15.0-142-generic (buildd@lgw01-amd64-039) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.12)) #146~16.04.1-Ubuntu SMP Tue Apr 13 09:27:15 UTC 2021
Dave
Hi Dave --
It looks like that SqueakSSL uses "glob.h" and glob()/globfree() in "platforms/unix/plugins/SqueakSSL/openssl_overlay.h". That needs glibc 2.27.
... glob_t g = {0}; if (0 == glob(possible_files, GLOB_NOSORT, NULL, &g)) { if (g.gl_pathc > 0) { for (size_t i = 0; i < g.gl_pathc; i++) { char* fullfile = basename(g.gl_pathv[i]); if (strnlen(fullfile, PATH_MAX) > name_len) { libnames[libname_count] = strndup(fullfile, PATH_MAX); libname_count++; } } } globfree(&g); ...
What's "ldd --version" on your Ubuntu 16.04 LTS?
Best, Marcel
***
nm SqueakSSL.so | grep GLIBC U __asprintf_chk@@GLIBC_2.8 U calloc@@GLIBC_2.2.5 w __cxa_finalize@@GLIBC_2.2.5 U dirname@@GLIBC_2.2.5 U dl_iterate_phdr@@GLIBC_2.2.5 U free@@GLIBC_2.2.5 U getenv@@GLIBC_2.2.5 U globfree@@GLIBC_2.2.5 U glob@@GLIBC_2.27 U inet_pton@@GLIBC_2.2.5 U memchr@@GLIBC_2.2.5 U memcmp@@GLIBC_2.2.5 U __memcpy_chk@@GLIBC_2.3.4 U __printf_chk@@GLIBC_2.3.4 U puts@@GLIBC_2.2.5 U qsort@@GLIBC_2.2.5 U realloc@@GLIBC_2.2.5 U __stack_chk_fail@@GLIBC_2.4 U stderr@@GLIBC_2.2.5 U stdout@@GLIBC_2.2.5 U strchr@@GLIBC_2.2.5 U strdup@@GLIBC_2.2.5 U strlen@@GLIBC_2.2.5 U strncasecmp@@GLIBC_2.2.5 U strncmp@@GLIBC_2.2.5 U strndup@@GLIBC_2.2.5 U strnlen@@GLIBC_2.2.5 U strsep@@GLIBC_2.2.5 U strtok_r@@GLIBC_2.2.5 U strverscmp@@GLIBC_2.2.5 U __xpg_basename@@GLIBC_2.2.5
nm FileAttributesPlugin.so | grep GLIBC U access@@GLIBC_2.2.5 U calloc@@GLIBC_2.2.5 U chmod@@GLIBC_2.2.5 U chown@@GLIBC_2.2.5 U closedir@@GLIBC_2.2.5 w __cxa_finalize@@GLIBC_2.2.5 U __errno_location@@GLIBC_2.2.5 U free@@GLIBC_2.2.5 U lchown@@GLIBC_2.2.5 U localtime@@GLIBC_2.2.5 U __lxstat@@GLIBC_2.2.5 U __memcpy_chk@@GLIBC_2.3.4 U memcpy@@GLIBC_2.14 U opendir@@GLIBC_2.2.5 U readdir@@GLIBC_2.2.5 U readlink@@GLIBC_2.2.5 U rewinddir@@GLIBC_2.2.5 U __stack_chk_fail@@GLIBC_2.4 U strlen@@GLIBC_2.2.5 U __xstat@@GLIBC_2.2.5
nm UnixOSProcessPlugin.so | grep GLIBC U calloc@@GLIBC_2.2.5 U chdir@@GLIBC_2.2.5 U close@@GLIBC_2.2.5 U confstr@@GLIBC_2.2.5 U __cxa_atexit@@GLIBC_2.2.5 w __cxa_finalize@@GLIBC_2.2.5 U dup2@@GLIBC_2.2.5 U dup@@GLIBC_2.2.5 U __errno_location@@GLIBC_2.2.5 U execve@@GLIBC_2.2.5 U _exit@@GLIBC_2.2.5 U fcntl@@GLIBC_2.2.5 U fdopen@@GLIBC_2.2.5 U feof@@GLIBC_2.2.5 U fflush@@GLIBC_2.2.5 U fileno@@GLIBC_2.2.5 U fork@@GLIBC_2.2.5 U fpathconf@@GLIBC_2.2.5 U __fprintf_chk@@GLIBC_2.3.4 U free@@GLIBC_2.2.5 U fwrite@@GLIBC_2.2.5 U getcwd@@GLIBC_2.2.5 U getdtablesize@@GLIBC_2.2.5 U getegid@@GLIBC_2.2.5 U getenv@@GLIBC_2.2.5 U geteuid@@GLIBC_2.2.5 U getgid@@GLIBC_2.2.5 U getpgid@@GLIBC_2.2.5 U getpgrp@@GLIBC_2.2.5 U getpid@@GLIBC_2.2.5 U getppid@@GLIBC_2.2.5 U getuid@@GLIBC_2.2.5 U kill@@GLIBC_2.2.5 U malloc@@GLIBC_2.2.5 U nice@@GLIBC_2.2.5 U pathconf@@GLIBC_2.2.5 U perror@@GLIBC_2.2.5 U pipe@@GLIBC_2.2.5 U pthread_kill@@GLIBC_2.2.5 U pthread_self@@GLIBC_2.2.5 U pthread_sigmask@@GLIBC_2.2.5 U putenv@@GLIBC_2.2.5 U realpath@@GLIBC_2.3 U rewind@@GLIBC_2.2.5 U setbuf@@GLIBC_2.2.5 U setitimer@@GLIBC_2.2.5 U setpgid@@GLIBC_2.2.5 U setsid@@GLIBC_2.2.5 U sigaction@@GLIBC_2.2.5 U sigaddset@@GLIBC_2.2.5 U sigaltstack@@GLIBC_2.2.5 U sigemptyset@@GLIBC_2.2.5 U signal@@GLIBC_2.2.5 U __stack_chk_fail@@GLIBC_2.4 U statvfs@@GLIBC_2.2.5 U stderr@@GLIBC_2.2.5 U stdin@@GLIBC_2.2.5 U stdout@@GLIBC_2.2.5 U strerror@@GLIBC_2.2.5 U strlen@@GLIBC_2.2.5 U strncpy@@GLIBC_2.2.5 U sysconf@@GLIBC_2.2.5 U unsetenv@@GLIBC_2.2.5 U vfork@@GLIBC_2.2.5 U waitpid@@GLIBC_2.2.5 U __xstat@@GLIBC_2.2.5
nm SqueakFFIPrims.so | grep GLIBC w __cxa_finalize@@GLIBC_2.2.5 U fclose@@GLIBC_2.2.5 U fflush@@GLIBC_2.2.5 U fopen@@GLIBC_2.2.5 U __fprintf_chk@@GLIBC_2.3.4 U free@@GLIBC_2.2.5 U fwrite@@GLIBC_2.2.5 U malloc@@GLIBC_2.2.5 U memcpy@@GLIBC_2.14 U __printf_chk@@GLIBC_2.3.4 U puts@@GLIBC_2.2.5 U __stack_chk_fail@@GLIBC_2.4 U strlen@@GLIBC_2.2.5 U strncpy@@GLIBC_2.2.5
Am 20.12.2021 16:47:51 schrieb David T. Lewis lewis@mail.msen.com: On Mon, Dec 20, 2021 at 03:31:00PM +0100, Marcel Taeumel wrote:
Hi all --
Here is the next release candidate: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228]
I see no issues with the VM, except that I have a library version issue that prevents connection to source.squeak.org. This is on Ubuntu 16.04 LTS, which is an older version which is at end of life and no longer supported. IMO this should *not* be considered a show stopper for release, although it will probably cause problems for some people who are not keeping their Linux systems up to date.
The library version problem is:
SqueakSSL tryLoading /usr/local/bin/../lib/squeak/5.0-202112022203-64bit/SqueakSSL.so: dlopen: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.27' not found (required by /usr/local/bin/../lib/squeak/5.0-202112022203-64bit/SqueakSSL.so)
And my system is:
$ cat /proc/version Linux version 4.15.0-142-generic (buildd@lgw01-amd64-039) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.12)) #146~16.04.1-Ubuntu SMP Tue Apr 13 09:27:15 UTC 2021
Dave
On Mon, Dec 20, 2021 at 06:14:26PM +0100, Marcel Taeumel wrote:
Hi Dave --
It looks like that SqueakSSL uses "glob.h" and glob()/globfree() in "platforms/unix/plugins/SqueakSSL/openssl_overlay.h". That needs glibc 2.27.
... ?? ?? ?? ?? glob_t g = {0}; ?? ?? ?? ?? if (0 == glob(possible_files, GLOB_NOSORT, NULL, &g)) { ?? ?? ?? ?? ?? ?? if (g.gl_pathc > 0) { ?? ?? ?? ?? ?? ?? ?? ?? for (size_t i = 0; i < g.gl_pathc; i++) { ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? char* fullfile = basename(g.gl_pathv[i]); ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? if (strnlen(fullfile, PATH_MAX) > name_len) { ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? libnames[libname_count] = strndup(fullfile, PATH_MAX); ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? libname_count++; ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? } ?? ?? ?? ?? ?? ?? ?? ?? } ?? ?? ?? ?? ?? ?? } ?? ?? ?? ?? ?? ?? globfree(&g); ...
What's "ldd --version" on your Ubuntu 16.04 LTS?
$ ldd --version ldd (Ubuntu GLIBC 2.23-0ubuntu11.3) 2.23 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper.
Hi,
Same tests as last time. Same results all good except for the ancient Raspberry Pi.
I also ran the CryptrographyHashingTests and unlike before when I got only 4 expected failures this time I also got 10 errors. That said I think the last time I ran CryptorgraphyHashingTests I may have run this on a gcc compiled version rather than the release candidate clang version.
I also note that tinyBenchmarks runs faster on the clang version that I see on my gcc versions.
cheers
bruce
I ran some tests this morning on the systems I can put my hands on. In all cases it is the squeak.cog.spur downloads.
* MacOS Catalina on x86-64.
** works perfectly.
** sound checked and works perfectly.
** The menu shows Squeak 5.0 but the version number in About SqueakOSXApp is probably ok.
* Linux x86-64 based on Ubuntu 20.4.
** works perfectly.
** sound checked and works perfectly.
* Windows 10 19.09 on Win64
** works perfectly
** sound checked and works perfectly.
* Linux ARMv8 based on Ubuntu 18.4
** works perfectly.
** sound can not be checked.
* Linux ARMv6 Raspberry PI running a currentish version of PiOS based on Debian 10.4
** works perfectly.
** sound can not be checked.
* Linux ARMv6 Raspberry PI running an old version of PiOS based on Debian 9.3
** does not work, a glibc version problem
** I would not worry about this but I just checked to be complete. Let's stick with currentish versions of PiOS
On 2021-12-20T19:32:53.000+01:00, David T. Lewis lewis@mail.msen.com wrote:
On Mon, Dec 20, 2021 at 06:14:26PM +0100, Marcel Taeumel wrote:
Hi Dave -- It looks like that SqueakSSL uses "glob.h" and glob()/globfree() in "platforms/unix/plugins/SqueakSSL/openssl_overlay.h". That needs glibc 2.27. ... ?? ?? ?? ?? glob_t g = {0}; ?? ?? ?? ?? if (0 == glob(possible_files, GLOB_NOSORT, NULL, &g)) { ?? ?? ?? ?? ?? ?? if (g.gl_pathc 0) { ?? ?? ?? ?? ?? ?? ?? ?? for (size_t i = 0; i < g.gl_pathc; i++) { ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? char* fullfile = basename(g.gl_pathv[i]); ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? if (strnlen(fullfile, PATH_MAX) name_len) { ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? libnames[libname_count] = strndup(fullfile, PATH_MAX); ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? libname_count++; ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? } ?? ?? ?? ?? ?? ?? ?? ?? } ?? ?? ?? ?? ?? ?? } ?? ?? ?? ?? ?? ?? globfree(&g); ... What's "ldd --version" on your Ubuntu 16.04 LTS?
$ ldd --version ldd (Ubuntu GLIBC 2.23-0ubuntu11.3) 2.23 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper.
Hi Bruce,
You should see 4 expected failures for the test cases which would use the old SHA256Plugin which has been superseded by the SHA2Plugin. The former is not shipped with the VM anymore. The tests are automatically marked as expected failure if their plugin is not available. All the other tests should pass, as they do on my machine using squeak.cog.spur_linux64x64. What errors do you see?
Levente
Hi,
So I did:
Download the release artifact from
https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228
$ tar xf squeak.cog.spur_linux64x64.tar.gz
$ ./sqcogspur64linuxht/bin/spur64 ./Squeak6.0alpha-20883-64bit
doit of this:
Installer ss project: 'Registers'; install: 'Registers-Core'. Installer ss project: 'Cryptography'; addPackage: 'CryptographyHashing'; addPackage: 'CryptographyHashingTests'; install.
a printit of this (Smalltalk classNamed: #SHA256WithSHA2PluginTest) run: #testInputs
returned
1 run in 0:00:00:00.014, 1 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes
which before crashed.
Then I opened up TestRunner, chose CryptographyHashingTests and ran all the selected tests.
This is on system derived from Ubuntu 20.4
$ cat /etc/upstream-release/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu Focal Fossa"
running on this
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 36 bits physical, 48 bits virtual
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 58
Model name: Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz
which happens to be a 2014 or so MacMini.
cheers
bruce
On 2021-12-21T16:15:31.000+01:00, Levente Uzonyi leves@caesar.elte.hu wrote:
Hi Bruce, You should see 4 expected failures for the test cases which would use the old SHA256Plugin which has been superseded by the SHA2Plugin. The former is not shipped with the VM anymore. The tests are automatically marked as expected failure if their plugin is not available. All the other tests should pass, as they do on my machine using squeak.cog.spur_linux64x64. What errors do you see? Levente
Hi,
Sorry, late 2012 mac mini.
cheers
bruce
On 2021-12-21T20:14:15.000+01:00, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Hi, So I did: Download the release artifact from https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228 $ tar xf squeak.cog.spur_linux64x64.tar.gz $ ./sqcogspur64linuxht/bin/spur64 ./Squeak6.0alpha-20883-64bit doit of this: Installer ss project: 'Registers'; install: 'Registers-Core'. Installer ss project: 'Cryptography'; addPackage: 'CryptographyHashing'; addPackage: 'CryptographyHashingTests'; install. a printit of this (Smalltalk classNamed: #SHA256WithSHA2PluginTest) run: #testInputs returned 1 run in 0:00:00:00.014, 1 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes which before crashed. Then I opened up TestRunner, chose CryptographyHashingTests and ran all the selected tests. This is on system derived from Ubuntu 20.4 $ cat /etc/upstream-release/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=20.04 DISTRIB_CODENAME=focal DISTRIB_DESCRIPTION="Ubuntu Focal Fossa" running on this Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 36 bits physical, 48 bits virtual CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 58 Model name: Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz which happens to be a 2014 or so MacMini. cheers bruce <image.png> On 2021-12-21T16:15:31.000+01:00, Levente Uzonyi leves@caesar.elte.hu wrote:
Hi Bruce, You should see 4 expected failures for the test cases which would use the old SHA256Plugin which has been superseded by the SHA2Plugin. The former is not shipped with the VM anymore. The tests are automatically marked as expected failure if their plugin is not available. All the other tests should pass, as they do on my machine using squeak.cog.spur_linux64x64. What errors do you see? Levente
-------------------------
Hi all --
There will be another release candidate because our current build system for Windows (i.e., MSYS+MinGW) hard-codes a manifest into the executable, which prevents us from enabling High-DPI-Awareness.
Stay tuned.
Best, Marcel Am 20.12.2021 15:31:00 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
Here is the next release candidate: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228]
Note that the macOS build artifacts are still unsigned and not notarized but will be as soon as I attach those to our squeak-app bundling job [1], which produces ready-to-run artifacts [2]. So, if you cannot manage to execute the macOS artifacts in this form, please report, compile yourself, and/or wait for a separate notification on the squeak-app bundles.
Best, Marcel
[1] https://github.com/squeak-smalltalk/squeak-app/actions [2] http://files.squeak.org/trunk/
Am 09.12.2021 10:57:56 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
Please test this VM version: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203]
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Best, Marcel Am 01.12.2021 10:38:47 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
What's you overall feeling of having a new release candidate of the OSVM?
Overall pace has been decreasing during the last weeks. Maybe this is a good time then? Latest commit was about 10 hours ago. So, wait for 2-3 days and then tag that version, produce binaries and test those?
Best, Marcel
Hi all --
Well, I figured that the pre-compiled (default) manifest only bothers 32-bit builds for Windows because there we use gcc instead of clang. I am still trying to understand how we can fix the 32-bit builds for Windows in this regard. Just deleting
msys64/mingw32/i686-w64-mingw32/lib/default-manifest.o
does not do the trick as the linking step (ld) will fail quite early [1]:
i686-w64-mingw32-gcc -o mkNamedPrims.exe -mconsole -m32 ../../../platforms/win32/util/mkNamedPrims.c C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.3.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find default-manifest.o: No such file or directory collect2.exe: error: ld returned 1 exit status make: *** [../common/Makefile:221: mkNamedPrims.exe] Error 1
***
So, the question is: Should I try to fix this and then make another release candidate, which would include the already pushed [2] SqueakSSL fixes for Ubuntu 16 as well? Or should we keep the current one? What about that hard-to-reproduce/debug BitBlt segfault [3]? Hmm...
Best, Marcel
[1] https://github.com/msys2/MSYS2-packages/issues/454 [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog [3] http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-December/217834.... Am 27.12.2021 10:20:57 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
There will be another release candidate because our current build system for Windows (i.e., MSYS+MinGW) hard-codes a manifest into the executable, which prevents us from enabling High-DPI-Awareness.
Stay tuned.
Best, Marcel Am 20.12.2021 15:31:00 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
Here is the next release candidate: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228]
Note that the macOS build artifacts are still unsigned and not notarized but will be as soon as I attach those to our squeak-app bundling job [1], which produces ready-to-run artifacts [2]. So, if you cannot manage to execute the macOS artifacts in this form, please report, compile yourself, and/or wait for a separate notification on the squeak-app bundles.
Best, Marcel
[1] https://github.com/squeak-smalltalk/squeak-app/actions [2] http://files.squeak.org/trunk/
Am 09.12.2021 10:57:56 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
Please test this VM version: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203]
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Best, Marcel Am 01.12.2021 10:38:47 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
What's you overall feeling of having a new release candidate of the OSVM?
Overall pace has been decreasing during the last weeks. Maybe this is a good time then? Latest commit was about 10 hours ago. So, wait for 2-3 days and then tag that version, produce binaries and test those?
Best, Marcel
On Jan 6, 2022, at 7:05 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi all --
Well, I figured that the pre-compiled (default) manifest only bothers 32-bit builds for Windows because there we use gcc instead of clang. I am still trying to understand how we can fix the 32-bit builds for Windows in this regard. Just deleting
msys64/mingw32/i686-w64-mingw32/lib/default-manifest.o
does not do the trick as the linking step (ld) will fail quite early [1]:
i686-w64-mingw32-gcc -o mkNamedPrims.exe -mconsole -m32 ../../../platforms/win32/util/mkNamedPrims.c C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.3.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find default-manifest.o: No such file or directory collect2.exe: error: ld returned 1 exit status make: *** [../common/Makefile:221: mkNamedPrims.exe] Error 1
So, the question is: Should I try to fix this and then make another release candidate, which would include the already pushed [2] SqueakSSL fixes for Ubuntu 16 as well? Or should we keep the current one? What about that hard-to-reproduce/debug BitBlt segfault [3]? Hmm...
My feeling is that we should fix all of these, and include the primitive suspend fix. I shall refrain from making any changes other than in fixing these four issues.
Best, Marcel
[1] https://github.com/msys2/MSYS2-packages/issues/454 [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog [3] http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-December/217834....
Am 27.12.2021 10:20:57 schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hi all --
There will be another release candidate because our current build system for Windows (i.e., MSYS+MinGW) hard-codes a manifest into the executable, which prevents us from enabling High-DPI-Awareness.
Stay tuned.
Best, Marcel
Am 20.12.2021 15:31:00 schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hi all --
Here is the next release candidate: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228
Note that the macOS build artifacts are still unsigned and not notarized but will be as soon as I attach those to our squeak-app bundling job [1], which produces ready-to-run artifacts [2]. So, if you cannot manage to execute the macOS artifacts in this form, please report, compile yourself, and/or wait for a separate notification on the squeak-app bundles.
Best, Marcel
[1] https://github.com/squeak-smalltalk/squeak-app/actions [2] http://files.squeak.org/trunk/
Am 09.12.2021 10:57:56 schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hi all --
Please test this VM version: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Best, Marcel
Am 01.12.2021 10:38:47 schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hi all --
What's you overall feeling of having a new release candidate of the OSVM?
Overall pace has been decreasing during the last weeks. Maybe this is a good time then? Latest commit was about 10 hours ago. So, wait for 2-3 days and then tag that version, produce binaries and test those?
Best, Marcel
Hi Eliot --
My feeling is that we should fix all of these, and include the primitive suspend fix. I shall refrain from making any changes other than in fixing these four issues.
Let's do that. There is still time. :-) I updated the squeak-app bundling to be able to include any tagged OSVM version. So we can continue testing both vm and bundles. The current bundles include the VM tag 202112201228.
http://files.squeak.org/trunk/Squeak6.0alpha-20966-64bit/Squeak6.0alpha-2096...
http://files.squeak.org/trunk/Squeak6.0alpha-20966-64bit/Squeak6.0alpha-2096...
http://files.squeak.org/trunk/Squeak6.0alpha-20966-64bit/Squeak6.0alpha-2096...
http://files.squeak.org/trunk/Squeak6.0alpha-20966-64bit/Squeak6.0alpha-2096...
http://files.squeak.org/trunk/Squeak6.0alpha-20966-64bit/
Best, Marcel Am 06.01.2022 16:55:22 schrieb Eliot Miranda eliot.miranda@gmail.com:
On Jan 6, 2022, at 7:05 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi all --
Well, I figured that the pre-compiled (default) manifest only bothers 32-bit builds for Windows because there we use gcc instead of clang. I am still trying to understand how we can fix the 32-bit builds for Windows in this regard. Just deleting
msys64/mingw32/i686-w64-mingw32/lib/default-manifest.o
does not do the trick as the linking step (ld) will fail quite early [1]:
i686-w64-mingw32-gcc -o mkNamedPrims.exe -mconsole -m32 ../../../platforms/win32/util/mkNamedPrims.c C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.3.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find default-manifest.o: No such file or directory collect2.exe: error: ld returned 1 exit status make: *** [../common/Makefile:221: mkNamedPrims.exe] Error 1
***
So, the question is: Should I try to fix this and then make another release candidate, which would include the already pushed [2] SqueakSSL fixes for Ubuntu 16 as well? Or should we keep the current one? What about that hard-to-reproduce/debug BitBlt segfault [3]? Hmm...
My feeling is that we should fix all of these, and include the primitive suspend fix. I shall refrain from making any changes other than in fixing these four issues.
Best, Marcel
[1] https://github.com/msys2/MSYS2-packages/issues/454 [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog [3] http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-December/217834....
Am 27.12.2021 10:20:57 schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hi all --
There will be another release candidate because our current build system for Windows (i.e., MSYS+MinGW) hard-codes a manifest into the executable, which prevents us from enabling High-DPI-Awareness.
Stay tuned.
Best, Marcel
Am 20.12.2021 15:31:00 schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hi all --
Here is the next release candidate: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228]
Note that the macOS build artifacts are still unsigned and not notarized but will be as soon as I attach those to our squeak-app bundling job [1], which produces ready-to-run artifacts [2]. So, if you cannot manage to execute the macOS artifacts in this form, please report, compile yourself, and/or wait for a separate notification on the squeak-app bundles.
Best, Marcel
[1] https://github.com/squeak-smalltalk/squeak-app/actions [2] http://files.squeak.org/trunk/
Am 09.12.2021 10:57:56 schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hi all --
Please test this VM version: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203]
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Best, Marcel
Am 01.12.2021 10:38:47 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
What's you overall feeling of having a new release candidate of the OSVM?
Overall pace has been decreasing during the last weeks. Maybe this is a good time then? Latest commit was about 10 hours ago. So, wait for 2-3 days and then tag that version, produce binaries and test those?
Best, Marcel
Hi all --
It looks like all urgent fixes have made it into the Cog branch by now. I think we can make a new release candidate at the beginning of next week. :-)
We just have to: - Re-generate the sources for VMMaker.oscog-mt.3178 to include #primitiveMultipleBytecodeSetsActive and #primitiveBytecodeSetsAvailable (thanks Dave!) - Figure out two minor issues in the 32-bit build concerning callbacks and (longlong) type coercion in the SqueakFFIPrims plugin; if not, should not be a show stopper :-)
Best, Marcel Am 06.01.2022 16:05:14 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
Well, I figured that the pre-compiled (default) manifest only bothers 32-bit builds for Windows because there we use gcc instead of clang. I am still trying to understand how we can fix the 32-bit builds for Windows in this regard. Just deleting
msys64/mingw32/i686-w64-mingw32/lib/default-manifest.o
does not do the trick as the linking step (ld) will fail quite early [1]:
i686-w64-mingw32-gcc -o mkNamedPrims.exe -mconsole -m32 ../../../platforms/win32/util/mkNamedPrims.c C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.3.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find default-manifest.o: No such file or directory collect2.exe: error: ld returned 1 exit status make: *** [../common/Makefile:221: mkNamedPrims.exe] Error 1
***
So, the question is: Should I try to fix this and then make another release candidate, which would include the already pushed [2] SqueakSSL fixes for Ubuntu 16 as well? Or should we keep the current one? What about that hard-to-reproduce/debug BitBlt segfault [3]? Hmm...
Best, Marcel
[1] https://github.com/msys2/MSYS2-packages/issues/454 [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog [3] http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-December/217834.... Am 27.12.2021 10:20:57 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
There will be another release candidate because our current build system for Windows (i.e., MSYS+MinGW) hard-codes a manifest into the executable, which prevents us from enabling High-DPI-Awareness.
Stay tuned.
Best, Marcel Am 20.12.2021 15:31:00 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
Here is the next release candidate: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228]
Note that the macOS build artifacts are still unsigned and not notarized but will be as soon as I attach those to our squeak-app bundling job [1], which produces ready-to-run artifacts [2]. So, if you cannot manage to execute the macOS artifacts in this form, please report, compile yourself, and/or wait for a separate notification on the squeak-app bundles.
Best, Marcel
[1] https://github.com/squeak-smalltalk/squeak-app/actions [2] http://files.squeak.org/trunk/
Am 09.12.2021 10:57:56 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
Please test this VM version: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203]
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Best, Marcel Am 01.12.2021 10:38:47 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
What's you overall feeling of having a new release candidate of the OSVM?
Overall pace has been decreasing during the last weeks. Maybe this is a good time then? Latest commit was about 10 hours ago. So, wait for 2-3 days and then tag that version, produce binaries and test those?
Best, Marcel
Hi,
Just for refrerence I have built 6cd4bb2c4 on linux x86-64, Linux Armv7, and Linux Armv8 and it seems to check out.
So for the systems that few people use we're ready to go!
cheers
bruce
On 2022-04-08T17:12:34.000+02:00, Marcel Taeumel marcel.taeumel@hpi.de wrote:
------------------------- Hi all -- It looks like all urgent fixes have made it into the Cog branch by now. I think we can make a new release candidate at the beginning of next week. :-) We just have to: - Re-generate the sources for VMMaker.oscog-mt.3178 to include #primitiveMultipleBytecodeSetsActive and #primitiveBytecodeSetsAvailable (thanks Dave!) - Figure out two minor issues in the 32-bit build concerning callbacks and (longlong) type coercion in the SqueakFFIPrims plugin; if not, should not be a show stopper :-) Best, Marcel
Am 06.01.2022 16:05:14 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all -- Well, I figured that the pre-compiled (default) manifest only bothers 32-bit builds for Windows because there we use gcc instead of clang. I am still trying to understand how we can fix the 32-bit builds for Windows in this regard. Just deleting msys64/mingw32/i686-w64-mingw32/lib/default-manifest.o does not do the trick as the linking step (ld) will fail quite early [1]: i686-w64-mingw32-gcc -o mkNamedPrims.exe -mconsole -m32 ../../../platforms/win32/util/mkNamedPrims.c C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.3.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find default-manifest.o: No such file or directory collect2.exe: error: ld returned 1 exit status make: *** [../common/Makefile:221: mkNamedPrims.exe] Error 1 *** So, the question is: Should I try to fix this and then make another release candidate, which would include the already pushed [2] SqueakSSL fixes for Ubuntu 16 as well? Or should we keep the current one? What about that hard-to-reproduce/debug BitBlt segfault [3]? Hmm... Best, Marcel [1] https://github.com/msys2/MSYS2-packages/issues/454 [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog [3] http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-December/217834....
Am 27.12.2021 10:20:57 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all -- There will be another release candidate because our current build system for Windows (i.e., MSYS+MinGW) hard-codes a manifest into the executable, which prevents us from enabling High-DPI-Awareness. Stay tuned. Best, Marcel
Am 20.12.2021 15:31:00 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all -- Here is the next release candidate: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228] Note that the macOS build artifacts are still unsigned and not notarized but will be as soon as I attach those to our squeak-app bundling job [1], which produces ready-to-run artifacts [2]. So, if you cannot manage to execute the macOS artifacts in this form, please report, compile yourself, and/or wait for a separate notification on the squeak-app bundles. Best, Marcel [1] https://github.com/squeak-smalltalk/squeak-app/actions [2] http://files.squeak.org/trunk/
Am 09.12.2021 10:57:56 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all -- Please test this VM version: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203] Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines. Best, Marcel
Am 01.12.2021 10:38:47 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all -- What's you overall feeling of having a new release candidate of the OSVM? Overall pace has been decreasing during the last weeks. Maybe this is a good time then? Latest commit was about 10 hours ago. So, wait for 2-3 days and then tag that version, produce binaries and test those? Best, Marcel
Hi all --
All 32-bit builds are fine by now. https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/06dca1d00d207477356...
To my knowledge, there are two remaining issues with the ARM64 builds:
- Pushing struct args that are larger than 16 bytes - FFICallbacks (not Alien)
The issue with the struct args I did flag in the FFI tests.
However, I will take another look at FFI callbacks crashing the VM on Tuesday. Yet, projects out there are more likely to use Alien callbacks than SqueakFFI callbacks. So this is not a big issue. I just want to be sure that it is basically unrelated to the IA32ABI plugin.
Sorry for the delay. Feel free to start testing this commit right now: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/06dca1d00d207477356...
Happy Easter!
Best, Marcel Am 08.04.2022 17:12:34 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
It looks like all urgent fixes have made it into the Cog branch by now. I think we can make a new release candidate at the beginning of next week. :-)
We just have to: - Re-generate the sources for VMMaker.oscog-mt.3178 to include #primitiveMultipleBytecodeSetsActive and #primitiveBytecodeSetsAvailable (thanks Dave!) - Figure out two minor issues in the 32-bit build concerning callbacks and (longlong) type coercion in the SqueakFFIPrims plugin; if not, should not be a show stopper :-)
Best, Marcel Am 06.01.2022 16:05:14 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
Well, I figured that the pre-compiled (default) manifest only bothers 32-bit builds for Windows because there we use gcc instead of clang. I am still trying to understand how we can fix the 32-bit builds for Windows in this regard. Just deleting
msys64/mingw32/i686-w64-mingw32/lib/default-manifest.o
does not do the trick as the linking step (ld) will fail quite early [1]:
i686-w64-mingw32-gcc -o mkNamedPrims.exe -mconsole -m32 ../../../platforms/win32/util/mkNamedPrims.c C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.3.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find default-manifest.o: No such file or directory collect2.exe: error: ld returned 1 exit status make: *** [../common/Makefile:221: mkNamedPrims.exe] Error 1
***
So, the question is: Should I try to fix this and then make another release candidate, which would include the already pushed [2] SqueakSSL fixes for Ubuntu 16 as well? Or should we keep the current one? What about that hard-to-reproduce/debug BitBlt segfault [3]? Hmm...
Best, Marcel
[1] https://github.com/msys2/MSYS2-packages/issues/454 [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog [3] http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-December/217834.... Am 27.12.2021 10:20:57 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
There will be another release candidate because our current build system for Windows (i.e., MSYS+MinGW) hard-codes a manifest into the executable, which prevents us from enabling High-DPI-Awareness.
Stay tuned.
Best, Marcel Am 20.12.2021 15:31:00 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
Here is the next release candidate: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228]
Note that the macOS build artifacts are still unsigned and not notarized but will be as soon as I attach those to our squeak-app bundling job [1], which produces ready-to-run artifacts [2]. So, if you cannot manage to execute the macOS artifacts in this form, please report, compile yourself, and/or wait for a separate notification on the squeak-app bundles.
Best, Marcel
[1] https://github.com/squeak-smalltalk/squeak-app/actions [2] http://files.squeak.org/trunk/
Am 09.12.2021 10:57:56 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
Please test this VM version: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203]
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Best, Marcel Am 01.12.2021 10:38:47 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
What's you overall feeling of having a new release candidate of the OSVM?
Overall pace has been decreasing during the last weeks. Maybe this is a good time then? Latest commit was about 10 hours ago. So, wait for 2-3 days and then tag that version, produce binaries and test those?
Best, Marcel
... of course I forgot to mention another issue. It is related to the "headless" mode on macOS.
These FFI tests show this issue (on macOS 10.15): https://github.com/marceltaeumel/squeak-ffi/actions
Best, Marcel Am 16.04.2022 12:00:35 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
All 32-bit builds are fine by now. https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/06dca1d00d207477356...
To my knowledge, there are two remaining issues with the ARM64 builds:
- Pushing struct args that are larger than 16 bytes - FFICallbacks (not Alien)
The issue with the struct args I did flag in the FFI tests.
However, I will take another look at FFI callbacks crashing the VM on Tuesday. Yet, projects out there are more likely to use Alien callbacks than SqueakFFI callbacks. So this is not a big issue. I just want to be sure that it is basically unrelated to the IA32ABI plugin.
Sorry for the delay. Feel free to start testing this commit right now: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/06dca1d00d207477356...
Happy Easter!
Best, Marcel Am 08.04.2022 17:12:34 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
It looks like all urgent fixes have made it into the Cog branch by now. I think we can make a new release candidate at the beginning of next week. :-)
We just have to: - Re-generate the sources for VMMaker.oscog-mt.3178 to include #primitiveMultipleBytecodeSetsActive and #primitiveBytecodeSetsAvailable (thanks Dave!) - Figure out two minor issues in the 32-bit build concerning callbacks and (longlong) type coercion in the SqueakFFIPrims plugin; if not, should not be a show stopper :-)
Best, Marcel Am 06.01.2022 16:05:14 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
Well, I figured that the pre-compiled (default) manifest only bothers 32-bit builds for Windows because there we use gcc instead of clang. I am still trying to understand how we can fix the 32-bit builds for Windows in this regard. Just deleting
msys64/mingw32/i686-w64-mingw32/lib/default-manifest.o
does not do the trick as the linking step (ld) will fail quite early [1]:
i686-w64-mingw32-gcc -o mkNamedPrims.exe -mconsole -m32 ../../../platforms/win32/util/mkNamedPrims.c C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.3.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find default-manifest.o: No such file or directory collect2.exe: error: ld returned 1 exit status make: *** [../common/Makefile:221: mkNamedPrims.exe] Error 1
***
So, the question is: Should I try to fix this and then make another release candidate, which would include the already pushed [2] SqueakSSL fixes for Ubuntu 16 as well? Or should we keep the current one? What about that hard-to-reproduce/debug BitBlt segfault [3]? Hmm...
Best, Marcel
[1] https://github.com/msys2/MSYS2-packages/issues/454 [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog [3] http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-December/217834.... Am 27.12.2021 10:20:57 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
There will be another release candidate because our current build system for Windows (i.e., MSYS+MinGW) hard-codes a manifest into the executable, which prevents us from enabling High-DPI-Awareness.
Stay tuned.
Best, Marcel Am 20.12.2021 15:31:00 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
Here is the next release candidate: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228]
Note that the macOS build artifacts are still unsigned and not notarized but will be as soon as I attach those to our squeak-app bundling job [1], which produces ready-to-run artifacts [2]. So, if you cannot manage to execute the macOS artifacts in this form, please report, compile yourself, and/or wait for a separate notification on the squeak-app bundles.
Best, Marcel
[1] https://github.com/squeak-smalltalk/squeak-app/actions [2] http://files.squeak.org/trunk/
Am 09.12.2021 10:57:56 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
Please test this VM version: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203]
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Best, Marcel Am 01.12.2021 10:38:47 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
What's you overall feeling of having a new release candidate of the OSVM?
Overall pace has been decreasing during the last weeks. Maybe this is a good time then? Latest commit was about 10 hours ago. So, wait for 2-3 days and then tag that version, produce binaries and test those?
Best, Marcel
Hi all --
Here is the next (?! final ?!) release candidate: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202204190959 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202204190959]
Note that the macOS build artifacts are still unsigned and not notarized but will be as soon as I attach those to our squeak-app bundling job [1], which produces ready-to-run artifacts [2]. So, if you cannot manage to execute the macOS artifacts in this form, please report, compile yourself, and/or wait for a separate notification on the squeak-app bundles.
Best, Marcel
[1] https://github.com/squeak-smalltalk/squeak-app/actions [https://github.com/squeak-smalltalk/squeak-app/actions] [2] http://files.squeak.org/trunk/ [http://files.squeak.org/trunk/] Am 20.12.2021 15:31:00 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
Here is the next release candidate: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228]
Note that the macOS build artifacts are still unsigned and not notarized but will be as soon as I attach those to our squeak-app bundling job [1], which produces ready-to-run artifacts [2]. So, if you cannot manage to execute the macOS artifacts in this form, please report, compile yourself, and/or wait for a separate notification on the squeak-app bundles.
Best, Marcel
[1] https://github.com/squeak-smalltalk/squeak-app/actions [2] http://files.squeak.org/trunk/
Am 09.12.2021 10:57:56 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
Please test this VM version: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203]
Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.
Best, Marcel Am 01.12.2021 10:38:47 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all --
What's you overall feeling of having a new release candidate of the OSVM?
Overall pace has been decreasing during the last weeks. Maybe this is a good time then? Latest commit was about 10 hours ago. So, wait for 2-3 days and then tag that version, produce binaries and test those?
Best, Marcel
vm-dev@lists.squeakfoundation.org
-
Bruce O'Neel -
David T. Lewis -
Eliot Miranda -
Juan Vuletich -
Levente Uzonyi -
Marcel Taeumel -
Nicolas Cellier