Vm-dev February 2019

vm-dev@lists.squeakfoundation.org

33 participants
94 discussions

[OpenSmalltalk/opensmalltalk-vm] Support for musl (instead of GNU libc) when building the VM for embedded system (#304)
by Xuan Sang LE 14 Feb '20

14 Feb '20

Hello, I have a small issue when building (cross-compile) the Smalltalk VM on an ARM(v6) embedded linux system (Nano Pi neno and Raspberry Pi Zero) that uses Musl as default libc implementation. The problem is that the code and the configure script does not have official support for Musl, so I created a patch file that adds support to Musl, you can find the [patch here](https://github.com/lxsang/antix/blob/master/sm_vm_musl.patch). With this patch, i am able to cross-compile on the ARM toolchain for my system; with 4 plugins: ``` FilePlugin \ SqueakSSL \ SqueakFFIPrims \ SocketPlugin ``` You can find the build [script here](https://github.com/lxsang/antix/blob/master/packages/smalltalk-nano-p… For now, i can live with this dirty trick, but i would be verry happy if the mainline VM has official support to Musl. That's why i create this issue. Thanks -- 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/304

4 12

[OpenSmalltalk/opensmalltalk-vm] Problem linking Linux Sound Library (#360)
by Eva 09 Dec '19

09 Dec '19

On Linux Mint Sylvia, I could not play sounds (e.g. ``SampledSound beep``). This occurred in the newest SWA VM build of Squeak. Underlying problem seems to be that the Linux sound libraries for PulseAudio are not linked correctly. (Maybe this is the same as #118) With @krono I found this workaround: `` LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.1.0 LD_LIBRARY_PATH=/home/user/Dokumente/SWA2018.app/Contents/Linux-i686/bin/../lib/squeak/5.0-201810071412:/lib/x86_64-linux-gnu:/lib:/usr/lib/x86_64-linux-gnu:/usr/lib: /home/user/Dokumente/SWA2018.app/Contents/Linux-i686/bin/../lib/squeak/5.0-201810071412/squeak -vm-sound-pulse /home/user/Dokumente/SWA2018.app/Contents/Resources/SWA2018.image `` -- 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/360

9 16

[OpenSmalltalk/opensmalltalk-vm] libgit build fails because of libssl and libcrypto (#210)
by Javier Pimas 04 Dec '19

04 Dec '19

on /build.linux32x86/pharo.cog.spur/build I run ./mvm and get make[3]: *** No rule to make target '/usr/lib/i386-linux-gnu/libssl.so', needed by 'libgit2.so.0.25.1'. Stop. I worked around it by running sudo ln -s /lib/i386-linux-gnu/libssl.so.1.0.0 /usr/lib/i386-linux-gnu/libssl.so but shouldn't be necessary as libssl is downloaded and built by the script. The same happens with libcrypto -- 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/210

3 4

[OpenSmalltalk/opensmalltalk-vm] OSVM 201804030952 crashes in Context(Object)>copy (#265)
by Fabio Niephaus 26 Sep '19

26 Sep '19

OSVM `201804030952` sometimes crashes in `Context(Object)>copy` when running Squeak SUnit tests. Full stack trace at: https://travis-ci.org/squeak-smalltalk/squeak-app/jobs/387262157#L2073 Another trace is at: https://travis-ci.org/squeak-smalltalk/squeak-app/jobs/382950107#L1717 -- 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/265

3 5

Robust FFI with Memory Protection Keys
by Ben Coman 29 Jun '19

29 Jun '19

A problem with FFI is that if a callout segfaults, all of memory including that of the Image is suspect, and execution of the Image terminates. Occasionally I hunt around hoping to find technology to mitigate that problem. Maybe this time in I found something... Memory Protection Keys [1] Perhaps these could ensure Image memory safe when an FFI callout segfaults. IIUC the main problem with protecting Image memory on every FFI callout is the time it would take update the flags on every page of Image memory. Would being able to change the protection of a massive number of pages with one syscall make it feasible to wrap them around FFI callouts? This may be useful at least where the FFI use is more about reuse of existing functionality than about performance. Or at least useful while someone is learning/experimenting with FFI for the first time or while becoming familiar with some external library. Further info at [2] & [3]. cheers -ben [1] https://lwn.net/Articles/643797/ [2] http://man7.org/linux/man-pages/man7/pkeys.7.html [3] https://lwn.net/Articles/689395/

3 9

[OpenSmalltalk/opensmalltalk-vm] fix event memory leak (#373)
by maenu 28 Jun '19

28 Jun '19

Fixes a memory leak in the macOS event loop, see discussion on mailing list http://lists.squeakfoundation.org/pipermail/vm-dev/2019-February/030595.html You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/373 -- Commit Summary -- * fix event memory leak -- File Changes -- M platforms/iOS/vm/OSX/sqSqueakOSXApplication+events.m (18) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/373.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/373.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/373

5 16

Image crashing on startup, apparently during GC
by Damien Pollet 03 Jun '19

03 Jun '19

Hi, I have a Pharo image that crashes the VM on startup. The crash report below seems to incriminate GC. Should I make it available somewhere online? What's most convenient? Process: Pharo [64892] Path: /Users/USER/*/Pharo.app/Contents/MacOS/Pharo Identifier: org.pharo.Pharo Version: 5.0.201708271955 (5.0.201708271955) Code Type: X86-64 (Native) Parent Process: ??? [64888] Responsible: Pharo [64892] User ID: 501 Date/Time: 2018-03-19 20:27:03.906 +0100 OS Version: Mac OS X 10.13.3 (17D102) Report Version: 12 Anonymous UUID: 6D022236-78DD-6676-117F-EADA56D5D1BE Sleep/Wake UUID: AC9E4E55-3CDB-4B4F-A6B4-51ACB1177154 Time Awake Since Boot: 28000 seconds Time Since Wake: 6500 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x000000012b67c0b0 Exception Note: EXC_CORPSE_NOTIFY VM Regions Near 0x12b67c0b0: VM_ALLOCATE 000000011adfc000-00000001259fc000 [172.0M] rw-/rwx SM=PRV --> STACK GUARD 0000700005613000-0000700005614000 [ 4K] ---/rwx SM=NUL stack guard for thread 1 Application Specific Information: abort() called Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff53fbde3e __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff540fc150 pthread_kill + 333 2 libsystem_c.dylib 0x00007fff53f1a312 abort + 127 3 org.pharo.Pharo 0x0000000104ed8997 sigsegv + 190 4 libsystem_platform.dylib 0x00007fff540eff5a _sigtramp + 26 5 ??? 000000000000000000 0 + 0 6 org.pharo.Pharo 0x0000000104e73558 markObjects + 464 7 org.pharo.Pharo 0x0000000104e72d40 fullGC + 72 8 org.pharo.Pharo 0x0000000104e92dea primitiveFullGC + 45 9 org.pharo.Pharo 0x0000000104e52425 interpret + 26715 10 org.pharo.Pharo 0x0000000104e5c7f6 enterSmalltalkExecutiveImplementation + 152 11 org.pharo.Pharo 0x0000000104e4be6c interpret + 674 12 org.pharo.Pharo 0x0000000104ed9cc1 -[sqSqueakMainApplication runSqueak] + 394 13 com.apple.Foundation 0x00007fff2e6d696c __NSFirePerformWithOrder + 360 14 com.apple.CoreFoundation 0x00007fff2c579127 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 15 com.apple.CoreFoundation 0x00007fff2c57904f __CFRunLoopDoObservers + 527 16 com.apple.CoreFoundation 0x00007fff2c55b6a8 __CFRunLoopRun + 1240 17 com.apple.CoreFoundation 0x00007fff2c55af43 CFRunLoopRunSpecific + 483 18 com.apple.HIToolbox 0x00007fff2b872e26 RunCurrentEventLoopInMode + 286 19 com.apple.HIToolbox 0x00007fff2b872a9f ReceiveNextEventCommon + 366 20 com.apple.HIToolbox 0x00007fff2b872914 _BlockUntilNextEventMatchingListInModeWithFilter + 64 21 com.apple.AppKit 0x00007fff29b3df5f _DPSNextEvent + 2085 22 com.apple.AppKit 0x00007fff2a2d3b4c -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044 23 com.apple.AppKit 0x00007fff29b32d6d -[NSApplication run] + 764 24 com.apple.AppKit 0x00007fff29b01f1a NSApplicationMain + 804 -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

5 8

[OpenSmalltalk/opensmalltalk-vm] callout from interp.c code to objc/swift code need autorelease pool (#374)
by johnmci 13 Mar '19

13 Mar '19

original issue exposed in pumpRunLoopEventSendAndSignal but perhaps the autoreleasepool wrapper should be higher up in say ioProcessEvents() what is happening is the call out is creating autorelease objects, but when do they get released. Other call out should be audited for the same issue. Some routines might not need a wrapper? -- 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/374

5 9

Re: [Vm-dev] [squeak-dev] Squeak and Tonel
by Eliot Miranda 04 Mar '19

04 Mar '19

Hi All, Hi Torsten, Hi Jakob, On Thu, Feb 14, 2019 at 6:17 AM Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > as some of you might already know "Tonel" is a file-per-class format for > monticello repositories [1]. > > In Pharo land many projects are already converted to it - as regular "file > tree" solution faces issues > with git handling due to very long file names / deep file hierarchy (often > leading to trouble on Windows). > > Dales's Rowan (a new project/package manager for Smalltalk) supports > FileTree and also Tonel > repositories [2]. There is also a tool to convert from STORE (VisualWorks > Source-Code Versioning System) > to Tonel format [3]. > > So I wonder about adoption of Tonel in Squeak land. > > Any status/comments? > Last year I was given contract employment by Tudor Girba's feenk which in part was to involve me porting VMMaker.oscog to Pharo in order to reap the productivity benefits of the Glamorous Toolkit when applied to VMMaker. The major direction was to unify the opensmalltalk-vm repository with a Toned-Format repository holding the Smalltalk code. This project, though no fault of feenk's did not go well. A big part of it was my own emotional attachment to Squeak, my "muscle memory" with Squeak and my long experience with Smalltalk-80 derived meta programming which I make extensive use of in VMMaker.oscog. But a key issue was that I was not prepared to *move* VMMaker.oscog to Pharo; for me it is key that it can live in both places. In particular I will not risk VMMaker.oscog being stranded on Pharo as it moves away from the "image-based rendering model". This is not because I don't believe in pixel-independent rendering models, but because productivity in VMMaker depends much more than on GToolkit inspection on the key architectural feature of being completely, safely simulateable (not a real English word; but meaning capable of being simulated). As Pharo moves towards external libraries to implement its UI so the degree to which VMMaker is simulated is reduced. Thus crashes in external code cannot be handled with the same power as with errors presented within the Smalltalk environment itself, and this (as harsh experience over thirty five years has taught me) is far more important for overall productivity than having powerful tailorable inspectors. I therefore wanted a Tonel that could both function for Squeak's Monticello and for Pharo's Iceberg. I had modified the Tonel serialization a little to provide well-formatted support for method timestamps, which are still a key and extremely useful part of Squeak Monticello's "blame" equivalent. Until git author attribution can be imported into Squeak's Monticello (something I don't see happening) I wanted merely to be able to have a variant of Tonel, enabled for example by a class variable, and hence /not/ present in Pharo, that would allow VMMaker.oscog to use Tonel but still be functional inside Squeak. I asked Esteban and was met by a flat no. Not "OK, but this is an option only you will use", but a flat "not under any circumstance". So here I am joining in this thread reluctantly. I'm extremely frustrated by the state of Tonel in Squeak and between the two dialects. Clément had moved his Scorch optimizer to Tonel/git and I tried to use Metacello and Jakob's Tonel code to at least allow me to load that code and try and push forward on Sista/Scorch. The port *does not work*. Metacello fails to load Scorch. Neither Jakob nor Fabio, after putting in some effort, were able to fix the problem, and it is well beyond me. So I have accepted the fact that I will have to use the Monticello repository for Scorch/Sista. I had deep concerns that the pursuit of git integration would end up splitting the Pharo and Squeak communities and indeed this is now in progress. I am utterly unmotivated by the lack of cooperation, the sheer arrogance and bullying of those that say "you will move to git/tonel or else", and considering leaving VMMaker altogether. The only things that are keeping me interested are Ron Teitelbaum's Terf and me pursuing a PhD on register allocation in the context of Sista/Scorch with Robert Hirshfeld's group at HPI. Here's the kind of crap people like Ducasse throw at me: "Eliot At the end of the day I will probably ask the two phds that should work on language design to use truffle or pypy because let us face it we cannot work with the Pharo VM. Else we will simply have to fork it (because we do not want to have to jump over cuis, newspeak, squeak code constraints and I do not what) and it will be another drama is in the pico world of the “open” smalltalk VM. " I am so over this crap. _,,,^..^,,,_ best, Eliot

5 16

[OpenSmalltalk/opensmalltalk-vm] f20878: CogVM source as per VMMaker.oscog-eem.2523
by Eliot Miranda 28 Feb '19

28 Feb '19

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: f20878cdccf40ab6381602dc58074413eab2dffa https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/f20878cdccf40ab638… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2019-02-28 (Thu, 28 Feb 2019) Changed paths: M nsspur64src/vm/cogit.h M nsspur64src/vm/cointerp.c M nsspur64src/vm/cointerp.h M nsspur64src/vm/gcc3x-cointerp.c M nsspur64src/vm/interp.h M nsspursrc/vm/cogit.h M nsspursrc/vm/cointerp.c M nsspursrc/vm/cointerp.h M nsspursrc/vm/gcc3x-cointerp.c M nsspursrc/vm/interp.h M nsspurstack64src/vm/gcc3x-interp.c M nsspurstack64src/vm/interp.c M nsspurstack64src/vm/interp.h M nsspurstacksrc/vm/gcc3x-interp.c M nsspurstacksrc/vm/interp.c M nsspurstacksrc/vm/interp.h M spur64src/vm/cogit.h M spur64src/vm/cointerp.c M spur64src/vm/cointerp.h M spur64src/vm/cointerpmt.c M spur64src/vm/cointerpmt.h M spur64src/vm/gcc3x-cointerp.c M spur64src/vm/gcc3x-cointerpmt.c M spur64src/vm/interp.h M spurlowcode64src/vm/cogit.h M spurlowcode64src/vm/cogitX64SysV.c M spurlowcode64src/vm/cogitX64WIN64.c M spurlowcode64src/vm/cointerp.c M spurlowcode64src/vm/cointerp.h M spurlowcode64src/vm/gcc3x-cointerp.c M spurlowcode64src/vm/interp.h M spurlowcodesrc/vm/cogit.h M spurlowcodesrc/vm/cogitARMv5.c M spurlowcodesrc/vm/cogitIA32.c M spurlowcodesrc/vm/cogitMIPSEL.c M spurlowcodesrc/vm/cointerp.c M spurlowcodesrc/vm/cointerp.h M spurlowcodesrc/vm/gcc3x-cointerp.c M spurlowcodesrc/vm/interp.h M spurlowcodestack64src/vm/gcc3x-interp.c M spurlowcodestack64src/vm/interp.c M spurlowcodestack64src/vm/interp.h M spurlowcodestacksrc/vm/gcc3x-interp.c M spurlowcodestacksrc/vm/interp.c M spurlowcodestacksrc/vm/interp.h M spursista64src/vm/cogit.h M spursista64src/vm/cointerp.c M spursista64src/vm/cointerp.h M spursista64src/vm/gcc3x-cointerp.c M spursista64src/vm/interp.h M spursistasrc/vm/cogit.h M spursistasrc/vm/cointerp.c M spursistasrc/vm/cointerp.h M spursistasrc/vm/gcc3x-cointerp.c M spursistasrc/vm/interp.h M spursrc/vm/cogit.h M spursrc/vm/cointerp.c M spursrc/vm/cointerp.h M spursrc/vm/cointerpmt.c M spursrc/vm/cointerpmt.h M spursrc/vm/gcc3x-cointerp.c M spursrc/vm/gcc3x-cointerpmt.c M spursrc/vm/interp.h M spurstack64src/vm/gcc3x-interp.c M spurstack64src/vm/interp.c M spurstack64src/vm/interp.h M spurstacksrc/vm/gcc3x-interp.c M spurstacksrc/vm/interp.c M spurstacksrc/vm/interp.h M src/plugins/SqueakFFIPrims/IA32FFIPlugin.c M src/plugins/SqueakFFIPrims/SqueakFFIPrims.c M src/plugins/SqueakFFIPrims/X64SysVFFIPlugin.c M src/plugins/SqueakFFIPrims/X64Win64FFIPlugin.c M src/vm/cogit.h M src/vm/cogitARMv5.c M src/vm/cogitIA32.c M src/vm/cogitMIPSEL.c M src/vm/cointerp.c M src/vm/cointerp.h M src/vm/cointerpmt.c M src/vm/cointerpmt.h M src/vm/gcc3x-cointerp.c M src/vm/gcc3x-cointerpmt.c M src/vm/interp.h M stacksrc/vm/gcc3x-interp.c M stacksrc/vm/interp.c M stacksrc/vm/interp.h Log Message: ----------- CogVM source as per VMMaker.oscog-eem.2523 Spur: Fix image segment storage when there is insufficient contguous space to store the array of objects to be included in a segment. I wrote the code to answer a suitable error object (a SmallInteger of the required size), but forgot to handle the return, hence causing horrible crashes as the VM attempted to access objects in a SmallInteger. this was Max Leske's failing segment storage test case (a 66.5Mb segment). Handle the case by introducing a new error code (PrimErrNeedCompact) and having the primitive perform a full GC when it gets the error code, and then to retry segment storage. Have printFreeTree/printFreeChunk:printAsTreeNode: mark the root node with a '+' Fix some slips in free chunk integrity checking.

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev February 2019