Vm-dev April 2019

vm-dev@lists.squeakfoundation.org

23 participants
69 discussions

[OpenSmalltalk/opensmalltalk-vm] Image buffer corruption when running build.macos64x64 targets (#392)
by Gene Ragan 22 Nov '19

22 Nov '19

Building from the latest sources on the Cog branch, I see the attached image when loading various images using various OSX builds. I have tried the 64-bit Pharo, Squeak and newspeak builds with their associated images. I see some variation of the attached image below. If I rollback the source to the 201901172323 tag, I am able to build and load an image and see the window as expected. <img width="811" alt="Screen Shot 2019-04-23 at 6 47 51 PM" src="https://user-images.githubusercontent.com/32800969/56627814-3fea6280-65fc-1…"> -- 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/392

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

VM Maker: ImageFormat-kks.35.mcz
by commits＠source.squeak.org 10 May '19

10 May '19

David T. Lewis uploaded a new version of ImageFormat to project VM Maker: http://source.squeak.org/VMMaker/ImageFormat-kks.35.mcz ==================== Summary ==================== Name: ImageFormat-kks.35 Author: kks Time: 10 April 2019, 11:21:27.422478 pm UUID: 67c4b2d3-702b-447e-890c-1ba698a71b4f Ancestors: ImageFormat-kks.34 Removed tests for 68004, 68021 formats since 68004 is no longer a base version number. =============== Diff against ImageFormat-kks.34 =============== Item was changed: ----- Method: ImageFormatTest>>testIsValidVersionNumber (in category 'testing') ----- testIsValidVersionNumber self should: [ImageFormat fromInteger: 0] raise: Error. self should: [ImageFormat fromInteger: (6502 bitAnd: 16r80000000)] raise: Error. self should: [ImageFormat fromInteger: (6502 bitAt: 31 put: 1)] raise: Error. self should: [ImageFormat fromInteger: 6500] raise: Error. self should: [ImageFormat fromInteger: 6501] raise: Error. self should: [ImageFormat fromInteger: 6503] raise: Error. "Cog requires both capabilities" self should: [ImageFormat fromInteger: 68001] raise: Error. "Cog requires both capabilities" self assert: ImageFormat default isValidVersionNumber. self assert: (ImageFormat wordSize: 4 closures: false) isValidVersionNumber. self assert: (ImageFormat wordSize: 4 closures: true) isValidVersionNumber. self assert: (ImageFormat wordSize: 8 closures: false) isValidVersionNumber. self assert: (ImageFormat wordSize: 8 closures: true) isValidVersionNumber. self assert: (ImageFormat fromInteger: 6502) isValidVersionNumber. self assert: (ImageFormat fromInteger: (6502 bitAt: 31 put: 0)) isValidVersionNumber. self assert: (ImageFormat fromInteger: 6521) isValidVersionNumber. self assert: (ImageFormat fromInteger:68000) isValidVersionNumber. self assert: (ImageFormat fromInteger:68002) isValidVersionNumber. - self assert: (ImageFormat fromInteger:68004) isValidVersionNumber. self assert: (ImageFormat fromInteger:68003) isValidVersionNumber. "valid but unused, as with 68019" self assert: (ImageFormat fromInteger: 68019) isValidVersionNumber. - self assert: (ImageFormat fromInteger: 68021) isValidVersionNumber. !

3 2

[OpenSmalltalk/opensmalltalk-vm] WASM Compile Target? (#387)
by Eric Gade 01 May '19

01 May '19

Hello all! As some of you might be aware, there has been a lot of progress in the web-world in developing [WebAssembly](https://webassembly.org/). Many environments and languages can now compile to the wasm binary format. Projects are doing things like [putting full Python interpreters and environments in the browser](https://github.com/iodide-project/pyodide), etc. There is even a nascent movement to come up with a consistent [system interface standard](https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembl… for WebAssembly, allowing developers to run wasm code on any platform -- not just the web. My question is this: what would it take to get the opensmalltalk-vm to compile to WebAssembly and has anyone involved with it considered the option so far? There would be a great many advantages to running a Smalltalk in the browser this way. -- 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/387

7 10

Re: [Vm-dev] Intercepting at:put: problems
by Ana Laura Felisatti 30 Apr '19

30 Apr '19

Hi! Just to clarify, we've actually modified the StackInterpreter>>commonAtPut: with a call to our code. We are building the Stack Spur VM on Mac 64bits. To validate whether our code was executed or not we've added printf entries to the C code produced in gcc3x-interp.c which is how we noticed the difference between regular execution and debug with proceed or over. Here's the modified extract of commonAtPut: !StackInterpreter methodsFor: 'indexing primitive support' stamp: 'ALF & MDS 4/7/2019 18:57'! commonAtPut: stringy "This code is called if the receiver responds primitively to at:Put:. N.B. this does *not* use the at cache, instead inlining stObject:at:put:. Using the at cache here would require that callers set messageSelector and lkupClass and that is onerous and error-prone, and in any case, inlining produces much better performance than using the at cache here." | value index rcvr | <inline: true> "to get it inlined in primitiveAtPut and primitiveStringAtPut" self initPrimCall. self keepCollectionTypeInformation. rcvr := self stackValue: 2. index := self stackValue: 1. value := self stackTop. ... And here's an extract of our code highlighting how we attempt to get the current MethodContext. !StackInterpreter methodsFor: 'dynamic type information' stamp: 'ALF MTQP 4/21/2019 15:46'! keepCollectionTypeInformation <inline: true> | senderContext receiverObject isLiveTypingCollectionObject contentTypesArray isSenderContextMethodContext collectionsContentType keepSearchingCollectionSender loopbackIndex maxLoopbackIndex| loopbackIndex := 0. maxLoopbackIndex := 4. keepSearchingCollectionSender := true. senderContext := self ensureFrameIsMarried: framePointer SP: stackPointer. [keepSearchingCollectionSender and: [loopbackIndex < maxLoopbackIndex]] whileTrue: [ senderContext = objectMemory nilObject ifFalse: [ isSenderContextMethodContext := (objectMemory is: senderContext instanceOf: (objectMemory splObj: ClassMethodContext) compactClassIndex: ClassMethodContextCompactIndex)-0. isSenderContextMethodContext ifTrue: [ receiverObject := objectMemory fetchPointer: ReceiverIndex ofObject: senderContext. receiverObject = objectMemory nilObject ifFalse: [ isLiveTypingCollectionObject := (objectMemory is: receiverObject instanceOf: (objectMemory splObj: ClassLiveTypingCollection) compactClassIndex: 0)-0. isLiveTypingCollectionObject ifTrue: [ ... We are using a custom implementation of OrderedCollection, LiveTypingCollection just to limit the code exposure and have made it a known class to the VM for that reason. Is there anything we are missing around the at:put: primitive execution and the commonAtPut: implementation it triggers? Is there another way to obtain the current MethodContext? Thanks On Mon, Apr 29, 2019 at 9:00 AM <vm-dev-request(a)lists.squeakfoundation.org> wrote: > Send Vm-dev mailing list submissions to > vm-dev(a)lists.squeakfoundation.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.squeakfoundation.org/mailman/listinfo/vm-dev > or, via email, send a message with subject or body 'help' to > vm-dev-request(a)lists.squeakfoundation.org > > You can reach the person managing the list at > vm-dev-owner(a)lists.squeakfoundation.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Vm-dev digest..." > > > Today's Topics: > > 1. Intercepting at:put: problems (Ana Laura Felisatti) > 2. Re: Intercepting at:put: problems (tim Rowledge) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 28 Apr 2019 15:04:13 -0300 > From: Ana Laura Felisatti <anafelisatti(a)gmail.com> > To: vm-dev(a)lists.squeakfoundation.org > Subject: [Vm-dev] Intercepting at:put: problems > Message-ID: > <CACxgkY= > iy+DqqaOUjCTEQHhexnjyUfrPRwHukNLXT_48y_ZZaw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi! > > We're working with Hernan Wilkinson on the Live Typing VM implementation > and have recently found a very strange behaviour. We are trying to capture > the type of objects stored within an OrderedCollection by intercepting the > at:put: method of Object, since that's what ends up being executed > internally by the OrderedCollection using an internal Array. To identify > whether the at:put: is being executed from that OrderCollection context we > inspect the MethodContext nesting. > > So far we have intercepted the StackInterpreter commonAtPut: to execute our > logic, which attempts to retrieve the current MethodContext, analyse up to > 4 levels up looking for an OrderedCollection receiver and in that case > store the type information. > > The problem is that our code never executes on a regular execution but does > while debugging. In fact, it works as expected when we simply hit "Proceed" > but fails when we hit "Over" instead, which is quite unexpected. > > We would like to know if there's anything we might be missing here about > the execution of primitives like at:put: or acquiring the current > MethodContext from the VM side. > > Thanks! > -- > A. Felisatti >

2 1

Intercepting at:put: problems
by Ana Laura Felisatti 28 Apr '19

28 Apr '19

Hi! We're working with Hernan Wilkinson on the Live Typing VM implementation and have recently found a very strange behaviour. We are trying to capture the type of objects stored within an OrderedCollection by intercepting the at:put: method of Object, since that's what ends up being executed internally by the OrderedCollection using an internal Array. To identify whether the at:put: is being executed from that OrderCollection context we inspect the MethodContext nesting. So far we have intercepted the StackInterpreter commonAtPut: to execute our logic, which attempts to retrieve the current MethodContext, analyse up to 4 levels up looking for an OrderedCollection receiver and in that case store the type information. The problem is that our code never executes on a regular execution but does while debugging. In fact, it works as expected when we simply hit "Proceed" but fails when we hit "Over" instead, which is quite unexpected. We would like to know if there's anything we might be missing here about the execution of primitives like at:put: or acquiring the current MethodContext from the VM side. Thanks! -- A. Felisatti

2 1

Build failed: opensmalltalk-vm 1.0.1738
by AppVeyor 27 Apr '19

27 Apr '19

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev April 2019