Vm-dev September 2020

vm-dev@lists.squeakfoundation.org

28 participants
331 discussions

[OpenSmalltalk/opensmalltalk-vm] Unable to build OSVM on macOS Catalina (#470)
by Fabio Niephaus 20 Oct '20

20 Oct '20

#### Steps to reproduce: ```bash cd build.macos64x64/squeak.cog.spur make debug ``` #### Errors ``` /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSArray.h:109:12: error: attributes may not be specified on a category @interface NSArray<ObjectType> (NSArrayDiffing) ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSArray.h:196:12: error: attributes may not be specified on a category @interface NSMutableArray<ObjectType> (NSMutableArrayDiffing) ^ In file included from <built-in>:1: In file included from ./../../platforms/iOS/vm/SqueakPureObjc_Prefix.pch:12: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:48: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSKeyValueCoding.h:8: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSOrderedSet.h:112:12: error: attributes may not be specified on a category @interface NSOrderedSet<ObjectType> (NSOrderedSetDiffing) ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSOrderedSet.h:187:12: error: attributes may not be specified on a category @interface NSMutableOrderedSet<ObjectType> (NSMutableOrderedSetDiffing) ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/470

3 2

[OpenSmalltalk/opensmalltalk-vm] ArmV6 crash on start. (#487)
by KrzysztofJeszke 20 Oct '20

20 Oct '20

I downloaded squeak 5.3 image fresh from the site (32-bit) and tried to run it in this vm on a Rpi Zero W. Crash.dmp outputs``` Segmentation fault Mon Apr 20 21:39:41 2020 /home/pi/squeak/lib/squeak/5.0-202003021730/squeak Squeak VM version: 5.0-202003021730 Tue Mar 3 09:42:45 UTC 2020 gcc 4.9.2 [Production Spur VM] Built from: CoInterpreter VMMaker.oscog-nice.2712 uuid: da64ef0b-fb0a-4770-ac16-f9b448234615 Mar 3 2020 With: StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid: e40f3e94-3a54-411b-9613-5d19114ea131 Mar 3 2020 Revision: VM: 202003021730 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Mar 2 18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Build host: Linux travis-job-97835d24-79f4-41d1-b7e9-c81bd8bf7149 4.4.0-104-generic #127~14.04.1-Ubuntu SMP Mon Dec 11 12:44:15 UTC 2017 armv7l GNU/Linux plugin path: ./../lib/squeak/5.0-202003021730 [default: /home/pi/squeak/lib/squeak/5.0-202003021730/] C stack backtrace & registers: r0 0x021b79d8 r1 0x00000002 r2 0x01000d34 r3 0x00000000 r4 0x00216288 r5 0x00000000 r6 0xbeec682c r7 0x0379170b r8 0x001e7414 r9 0x0021e268 r10 0x00000000 fp 0xbeec489c ip 0x00224250 sp 0xbeec4810 lr 0x000748b4 pc 0x0007055c *[0x0] /lib/arm-linux-gnueabihf/libc.so.6(vsprintf+0x80)[0xb6cee228] Smalltalk stack dump: 0xbeec6860 I SmalltalkImage>setGCParameters 0x233a9d0: a(n) SmalltalkImage 0xbeec6888 I SmalltalkImage>snapshot:andQuit:withExitCode:embedded: 0x233a9d0: a(n) SmalltalkImage 0x47d16d0 s SmalltalkImage>snapshot:andQuit:embedded: 0x47d26f8 s SmalltalkImage>snapshot:andQuit: 0x47d27b8 s [] in ReleaseBuilder class>saveAndQuit 0x47d2890 s WorldState>runStepMethodsIn: 0x47d2920 s PasteUpMorph>runStepMethods 0x47d29f0 s WorldState>doOneCycleNowFor: 0x47d2a50 s WorldState>doOneCycleFor: 0x47d2ac0 s PasteUpMorph>doOneCycle 0x47d2b20 s [] in MorphicProject>spawnNewProcess 0x47d2b80 s [] in BlockClosure>newProcess Most recent primitives basicNew size at: basicNew: decompress:fromByteArray:at: beCursorWithMask: vmParameterAt: fractionPart truncated stack page bytes 4096 available headroom 2788 minimum unused headroom 3740 (Segmentation fault) Segmentation fault Mon Apr 20 21:41:26 2020 /home/pi/squeak/lib/squeak/5.0-202003021730/squeak Squeak VM version: 5.0-202003021730 Tue Mar 3 09:42:45 UTC 2020 gcc 4.9.2 [Production Spur VM] Built from: CoInterpreter VMMaker.oscog-nice.2712 uuid: da64ef0b-fb0a-4770-ac16-f9b448234615 Mar 3 2020 With: StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid: e40f3e94-3a54-411b-9613-5d19114ea131 Mar 3 2020 Revision: VM: 202003021730 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Mar 2 18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Build host: Linux travis-job-97835d24-79f4-41d1-b7e9-c81bd8bf7149 4.4.0-104-generic #127~14.04.1-Ubuntu SMP Mon Dec 11 12:44:15 UTC 2017 armv7l GNU/Linux plugin path: ./../lib/squeak/5.0-202003021730 [default: /home/pi/squeak/lib/squeak/5.0-202003021730/] C stack backtrace & registers: r0 0x00000000 r1 0x00000dcd r2 0x00216288 r3 0x00b04c70 r4 0x00216288 r5 0x00000000 r6 0xbeaf382c r7 0x00224250 r8 0x001e7414 r9 0x00000000 r10 0x00216288 fp 0xbeaf189c ip 0x00224250 sp 0xbeaf17e0 lr 0x0006ae84 pc 0x0004c4bc *[0x0] /lib/arm-linux-gnueabihf/libc.so.6(vsprintf+0x80)[0xb6c6e228] Smalltalk stack dump: 0xbeaf3860 I SmalltalkImage>setGCParameters 0xe3a9d0: a(n) SmalltalkImage 0xbeaf3888 I SmalltalkImage>snapshot:andQuit:withExitCode:embedded: 0xe3a9d0: a(n) SmalltalkImage 0x32d16d0 s SmalltalkImage>snapshot:andQuit:embedded: 0x32d26f8 s SmalltalkImage>snapshot:andQuit: 0x32d27b8 s [] in ReleaseBuilder class>saveAndQuit 0x32d2890 s WorldState>runStepMethodsIn: 0x32d2920 s PasteUpMorph>runStepMethods 0x32d29f0 s WorldState>doOneCycleNowFor: 0x32d2a50 s WorldState>doOneCycleFor: 0x32d2ac0 s PasteUpMorph>doOneCycle 0x32d2b20 s [] in MorphicProject>spawnNewProcess 0x32d2b80 s [] in BlockClosure>newProcess Most recent primitives basicNew size at: basicNew: decompress:fromByteArray:at: beCursorWithMask: vmParameterAt: fractionPart truncated stack page bytes 4096 available headroom 2788 minimum unused headroom 3740 (Segmentation fault) ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/487

3 3

[OpenSmalltalk/opensmalltalk-vm] Latest commit segfaults win64x64.squeak.cog.spur (#498)
by Marcel Taeumel 20 Oct '20

20 Oct '20

ee89a4dad04442463252b6a368a8ba373288a774 Trying to load a 64-bit image, the VM segfaults in gcc3x-cointerp.c line 2809 `memset(theStackMemory, 0, stackPagesBytes);` Other win64x64 targets might be affected. I tested both a custom build and bintray version: https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.cog.spu… -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/498

3 4

[OpenSmalltalk/opensmalltalk-vm] Bump minimal supported Windows version to Windows 8 (0x0602). (#499)
by Marcel Taeumel 19 Oct '20

19 Oct '20

Also fixes a minor issue in MSVC Makefile for 64x64, which tried 0x0801 for Windows 8 and 0x1001 for Windows 10. The latter would actually be 0x0A00. See https://docs.microsoft.com/de-de/cpp/porting/modifying-winver-and-win32-win… Also in the Makefile for 64x64, define both _WIN32 and _WIN64. See https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros Also in the Makefile for 64x64, define both WIN32 and WIN64 because those can be used to identify the Windows platform in application code such as in processors/IA32/bochs. I am not aware of any #ifdef WIN64 at the moment. Most code uses #ifdef _WIN64 to check for that. Note that, having defined both _WIN32 and _WIN64, code for 32-bit and 64-bit must always begin with #ifdef _WIN64 and only then #elif _WIN32. I think that the MSVC compiler defines _WIN32 and _WIN64 automatically. Yet, now it is documented in the Makefile. You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/499 -- Commit Summary -- * Bump minimal supported Windows version to Windows 8 (0x0602). -- File Changes -- M build.win32x86/common/Makefile.msvc.tools (7) M build.win32x86/common/Makefile.tools (9) M build.win64x64/common/Makefile.msvc.tools (8) M build.win64x64/common/Makefile.tools (7) M platforms/win32/vm/sqWin32.h (41) M platforms/win32/vm/sqWin32Main.c (77) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/499.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/499.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/499

4 8

[OpenSmalltalk/opensmalltalk-vm] unix: use dlopen's lookup mechanism when not specifying a path (#497)
by Tom Beckmann 19 Oct '20

19 Oct '20

This allows FFI modules to be specified in the same manner as you would when linking to them (-lGL --> GL, instead of /usr/lib/x86_64-linux-gnu/libGL.so as was required before this change, unless you manually placed /usr/lib/x86_64-linux-gnu in your LD_LIBRARY_PATH). I don't know whether this will have unintended consequences for some use cases, since a lot of different systems end up calling this function. I tested the change for a while on Ubuntu 20.04 with no odd behavior occurring (but instead finally being able to load FFI modules without providing an absolute path or changing my LD_LIBRARY_PATH manually). Some more insights on why this was necessary: We have a long list of different ways of resolving a module. Among those is looking through the directories in the LD_LIBRARY_PATH envvar, which however only contains those directories I manually added, not all that ldconfig would consider. In our list of directories, we were already passing an empty string once, which would do nothing unless an absolute path was given, since we only proceed to look up a library if the given path is a valid directory. Providing `dlopen` with just a library name, without any path information, however, allows it to look through all directories as configured in ldconfig. You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/497 -- Commit Summary -- * unix: use dlopen's lookup mechanism when not specifying a path -- File Changes -- M platforms/unix/vm/sqUnixExternalPrims.c (17) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/497.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/497.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/497

3 9

[OpenSmalltalk/opensmalltalk-vm] Customization for Pharo & About Dialog (#388)
by Pablo Tesone 19 Oct '20

19 Oct '20

- We added customization for Pharo to allow a different menu to be used. - We modified the default action of help menu to open an URL (only for Pharo) - We added a Info.plist property with the string value of the URL (only for Pharo) - And also the about dialog was not receiving the close event, we have fixed that. It was related with the filtering of events for SDL. @demarey You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/388 -- Commit Summary -- * Adding a custom Menu for Pharo VMs * Adding a optional URL for the help, only fr Pharo * Handling correctly the events of the about window * Making the about window property as weak. -- File Changes -- M build.macos32x86/common/Makefile.app (8) M build.macos32x86/pharo.cog.spur.lowcode/Makefile (3) M build.macos32x86/pharo.cog.spur.minheadless/Makefile (2) M build.macos32x86/pharo.cog.spur/Makefile (1) M build.macos32x86/pharo.cog.spur/plugins.ext (2) M build.macos32x86/pharo.cog.v3/Makefile (2) M build.macos32x86/pharo.sista.spur/Makefile (2) M build.macos32x86/pharo.stack.spur.lowcode/Makefile (2) M build.macos32x86/pharo.stack.spur/Makefile (2) M build.macos64x64/common/Makefile.app (8) M build.macos64x64/pharo.cog.spur.lowcode/Makefile (1) M build.macos64x64/pharo.cog.spur/Makefile (1) M build.macos64x64/pharo.sista.spur/Makefile (1) M build.macos64x64/pharo.stack.spur.lowcode/Makefile (1) M build.macos64x64/pharo.stack.spur/Makefile (1) A platforms/iOS/vm/English.lproj/Pharo-MainMenu-opengl.xib (1261) A platforms/iOS/vm/English.lproj/Pharo-MainMenu.xib (1261) M platforms/iOS/vm/OSX/Pharo-Info.plist (2) M platforms/iOS/vm/OSX/SqueakOSXApplication.m (30) M platforms/iOS/vm/OSX/sqSqueakOSXApplication+events.m (16) M platforms/iOS/vm/OSX/sqSqueakOSXApplication.h (5) M platforms/iOS/vm/OSX/sqSqueakOSXApplication.m (1) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/388.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/388.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/388

7 12

[OpenSmalltalk/opensmalltalk-vm] Removes support for NO_VIRTUAL_MEMORY on win32 platform (#504)
by Marcel Taeumel 19 Oct '20

19 Oct '20

You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/504 -- Commit Summary -- * Removes support for NO_VIRTUAL_MEMORY on win32 platform -- File Changes -- M platforms/win32/vm/sqWin32.h (1) M platforms/win32/vm/sqWin32Alloc.c (4) M platforms/win32/vm/sqWin32Alloc.h (3) M platforms/win32/vm/sqWin32Main.c (15) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/504.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/504.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/504

3 2

corruption of PC in context objects or not (?)
by Andrei Chis 30 Sep '20

30 Sep '20

Hi, We are getting often crashes on our CI when calling `Context>copyTo:` in a GT image and a vm build from https://github.com/feenkcom/opensmalltalk-vm. To sum up during `Context>copyTo:`, `Object>>#copy` is called on a context leading to a segmentation fault crash. Looking at that context in lldb the pc looks off. It has the value `0xfffffffffea7f6e1`. (lldb) call (void *) printOop(0x1206b6990) 0x1206b6990: a(n) Context 0x1206b6a48 0xfffffffffea7f6e1 0x9 0x1146b2e08 0x1206b6b00 0x1206b6b28 0x1206b6b50 Can this indicate some corruption or is it expected to have such values? `CoInterpreter>>ensureContextHasBytecodePC:` has code that also handles negative values for the pc which suggests that this might be expected. Changing `Context>copyTo:` by adding a `self pc` before calling `self copy` leads to no more crashes. Not sure if there is a reason for that or just plain luck. A simple reduced stack is below (more details in this issue [1]). The crash happens always with contexts reified as objects (in this case 0x1206b6990 s [] in GtExamplesCommandLineHandler>runPackages). Could this suggest some kind of issue in the vm when reifying contexts, or just some other problem with memory corruption? 0x7ffeefbb4380 M Context(Object)>copy 0x1206b6990: a(n) Context 0x7ffeefbb43b8 M Context>copyTo: 0x1206b6990: a(n) Context 0x7ffeefbb4400 M Context>copyTo: 0x1206b5ae0: a(n) Context ... 0x7ffeefba6078 M Context>copyTo: 0x110548b28: a(n) Context 0x7ffeefba60d0 I Context>copyTo: 0x110548a70: a(n) Context 0x7ffeefba6118 I MessageNotUnderstood(Exception)>freezeUpTo: 0x110548a20: a(n) MessageNotUnderstood 0x7ffeefba6160 I MessageNotUnderstood(Exception)>freeze 0x110548a20: a(n) MessageNotUnderstood 0x7ffeefba6190 M [] in GtExampleEvaluator>result 0x110544fb8: a(n) GtExampleEvaluator 0x7ffeefba61c8 M BlockClosure>cull: 0x110545188: a(n) BlockClosure 0x7ffeefba6208 M Context>evaluateSignal: 0x110548c98: a(n) Context 0x7ffeefba6240 M Context>handleSignal: 0x110548c98: a(n) Context 0x7ffeefba6278 M Context>handleSignal: 0x110548be0: a(n) Context 0x7ffeefba62b0 M MessageNotUnderstood(Exception)>signal 0x110548a20: a(n) MessageNotUnderstood 0x7ffeefba62f0 M GtDummyExamplesWithInheritanceSubclassB(Object)>doesNotUnderstand: exampleH 0x1105487d8: a(n) GtDummyExamplesWithInheritanceSubclassB 0x7ffeefba6328 M GtExampleEvaluator>primitiveProcessExample:withEvaluationContext: 0x110544fb8: a(n) GtExampleEvaluator ... 0x7ffeefbe64d0 M [] in GtExamplesHDReport class(HDReport class)>runPackages: 0x1145e41c8: a(n) GtExamplesHDReport class 0x7ffeefbe6520 M [] in Set>collect: 0x1206b5ab0: a(n) Set 0x7ffeefbe6568 M Array(SequenceableCollection)>do: 0x1206b5c50: a(n) Array 0x1206b5b98 s Set>collect: 0x1206b5ae0 s GtExamplesHDReport class(HDReport class)>runPackages: 0x1206b6990 s [] in GtExamplesCommandLineHandler>runPackages 0x1206b6a48 s BlockClosure>ensure: 0x1206b6b68 s UIManager class>nonInteractiveDuring: 0x1206b6c48 s GtExamplesCommandLineHandler>runPackages 0x1206b6d98 s GtExamplesCommandLineHandler>activate 0x1206b75d0 s GtExamplesCommandLineHandler class(CommandLineHandler class)>activateWith: 0x1207d2f00 s [] in PharoCommandLineHandler(BasicCommandLineHandler)>activateSubCommand: 0x1207e6620 s BlockClosure>on:do: 0x1207f7ab8 s PharoCommandLineHandler(BasicCommandLineHandler)>activateSubCommand: 0x120809d40 s PharoCommandLineHandler(BasicCommandLineHandler)>handleSubcommand 0x12082ca60 s PharoCommandLineHandler(BasicCommandLineHandler)>handleArgument: 0x120789938 s [] in PharoCommandLineHandler(BasicCommandLineHandler)>activate 0x1207a83e0 s BlockClosure>on:do: 0x1207b57a0 s [] in PharoCommandLineHandler(BasicCommandLineHandler)>activate 0x1207bf830 s [] in BlockClosure>newProcess Cheers, Andrei [1] https://github.com/feenkcom/gtoolkit/issues/1440

3 21

Still Failing: OpenSmalltalk/opensmalltalk-vm#2218 (Cog - ab8ac9c)
by Travis CI 30 Sep '20

30 Sep '20

Build Update for OpenSmalltalk/opensmalltalk-vm ------------------------------------- Build: #2218 Status: Still Failing Duration: 1 hr, 19 mins, and 29 secs Commit: ab8ac9c (Cog) Author: Eliot Miranda Message: Fix win32 sqImageFileClose; forgot to change the definition when the declaration was changed in sqPlatformSpecific.h. View the changeset: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/1f626d0e80f9...ab… View the full build log and details: https://travis-ci.org/github/OpenSmalltalk/opensmalltalk-vm/builds/73150536… -- You can unsubscribe from build emails from the OpenSmalltalk/opensmalltalk-vm repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8795279&ut…. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notificati…. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

1 0

Build failed: opensmalltalk-vm 1.0.2219
by AppVeyor 30 Sep '20

30 Sep '20

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev September 2020