Vm-dev September 2019

vm-dev@lists.squeakfoundation.org

21 participants
118 discussions

[OpenSmalltalk/opensmalltalk-vm] Where to find VM .st source code? (#423)
by Laurent Julliard 29 Nov '19

29 Nov '19

Hi everyone, Sorry for this newbie question but I'm unclear as to where I can the Smalltalk/Slang source code for the VM and the associated Slang to C translator. Thank you for your help! -- 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/423

5 5

[OpenSmalltalk/opensmalltalk-vm] 32-bit libB3DAcceleratorPlugin.dylib fails to link; 32-bit Squeak B3DAcceleratorPlugin links against metal. (#385)
by Eliot Miranda 22 Nov '19

22 Nov '19

Seems to be something strange with the B3DAcceleratorPlugin on 32-bit macos. The pharo libB3DAcceleratorPlugin.dylib fails to link missing: createOpenGLTextureLayerHandle destroyOpenGLTextureLayerHandle getMainWindowOpenGLContext setOpenGLTextureLayerContent The Squeak one links, but apparently against Metal, which isn't going to work since Metal is 64-bit only (or so I've been told). -- 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/385

2 2

[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] Remove macRoman translation of keyboard keyValue in Win32 VM (#401)
by Nicolas Cellier 04 Nov '19

04 Nov '19

There is code that transforms the presumably latin-1 key value into approximately MacRoman encoding in platforms/win32/vm/sqWin32Window.c I let the archeologists debate if this code dates from Jurassic period or more distant paleozoic era, all I know is that we pay for what we don't buy... Thus I propose to entirely remove that piece of code and disentangle a bit the spaghetti keyboard handling. We indeed do not need this extra level of complexity anymore, images do not use macRoman encoding for a long time On the contrary, images have to undo the translation by sending `macToSqueak` message in various subclasses of `KeyboardInputInterpreter`. For the transition period, old images running on new VMs, or new images running on old VMs, might encounter a few hickups while interpreting non ASCII characters in case of exotic `KeyboardInputInterpreter`. That won't be the case of main `UTF32InputInterpreter` since it mostly uses the utf32 code passed through `eventBuffer sixth` position rather than keyValue passed thru `eventBuffer third`, except for some CTRL+key for which the keyValue is more-than-often < 128, and thus unaffcted by the proposed change. -- 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/401

2 3

[OpenSmalltalk/opensmalltalk-vm] Some BitBlt operations read past source end (#426)
by Nicolas Cellier 20 Oct '19

20 Oct '19

While running an assert or debug VM, I noticed repeated logs in console: > (((usqInt)sourceIndex)) < endOfSource 2132 This corresponds to failing assert: in BitBltSimulation slang srcLongAt: idx <inline: #always> self assert: idx asUnsignedInteger < endOfSource. ^self long32At: idx It is easily reproducible with this Squeak test: BitmapStreamTests new testShortIntegerArrayReadRefStream2. Such read past end is benign, except in rare case when we read past a page boundary and cause a SEGV! Via LLDB or via VM SImulation, we can find that it is related to the case when we `preload `a word from source and next source word because we think that we need more than 1 source word to fill 1st dest word. I have identified and hopefully fixed the bug in VMMaker.oscog-nice.2563 https://source.squeak.org/VMMaker/VMMaker.oscog-nice.2563.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/issues/426

1 1

[OpenSmalltalk/opensmalltalk-vm] Latest Linux VM can't handle -vm-display-null (#421)
by Max Leske 16 Oct '19

16 Oct '19

On Linux (Debian 10, Ubuntu 14.04.5) `curl get.pharo.org/64/vmLatest80 | bash; ./pharo` fails with > could not find module vm-display-null -- 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/421

3 5

Difficult to debug VM crash with full blocks and Sista V1
by Eliot Miranda 04 Oct '19

04 Oct '19

Hi All, there is a VM bug in 64-bit Spur with the Sista V1 bytecode set and full blocks. The symptom is that when waiting for a remote Monticello repository to update and/or deliver a package version the system crashes in JITTED code after what appears to be some kind of wait. This is a reliably occurring bug b ut maddeningly difficult to reproduce. The bug reliably occurs when interacting with a remote rep[ository (e.g. http://source.squeak.org/VMMaker) when the server is "cold", and hence makes the image wait. Every time I have tried to repeat the failing sequence the crash has not occurre3d, I think because the server is now "hot" and serves up the version quickly. Today I even tried shutting down my machine for over an hour and rebooting. But I could not get the crash to occur even though it seems to me that every time I try it the first time in the4 day it does crash. This is an important bug to fix. If it cannot be fixed then full blocks and Sista V1 are not ready for use in the upcoming Squeak release. I am looking for help in debugging this. - is anyone else uising the 64-bit VM with full blocks and Sista V1 who sees hard VM crashes? If so, under what circumstances? - is it possible to flush caches in the http://source.squeak.org/VMMaker server, or could people tolerate me rebooting the server? - is there a way of introducing network delays in Mac OS that might help me induce the bug? - can anyone think of any other strategies I might take to try and reproduce this? I may have to try and reproduce e the bug in the simulator to have a chance of identifying the bug. Does anyone have a good enough mental model of the Monticello server interaction and have energy to help me figure this one out? Here is some information from the last crash I did see in the debugger (alas it is incomplete; there are a number of additional pieces of info I could have collected). (lldb) thr b * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) * frame #0: 0x000000010de5700a frame #1: 0x000000010dd7b174 frame #2: 0x000000010dd45f1c frame #3: 0x000000010dd44534 frame #4: 0x000000010dd44c60 (lldb) x/10i 0x000000010de5700a (lldb) call printStackCallStackOf($rbp) 0x7ffeefbdfc30 M Heap>upHeap: 0x11273ca90: a(n) Heap 0x7ffeefbdfc68 M Heap>add: 0x11273ca90: a(n) Heap 0x7ffeefbdfca0 M Delay class>scheduleDelay:from: 0x1123ebfb8: a(n) Delay class 0x7ffeefbdfcf0 M Delay class>handleTimerEvent 0x1123ebfb8: a(n) Delay class 0x7ffeefbdfd20 M Delay class>runTimerEventLoop 0x1123ebfb8: a(n) Delay class (lldb) x/10i 0x000000010dd7b174 0x10dd7b174: 48 8b 55 10 movq 0x10(%rbp), %rdx 0x10dd7b178: 48 89 ec movq %rbp, %rsp 0x10dd7b17b: 5d popq %rbp 0x10dd7b17c: c2 10 00 retq $0x10 0x10dd7b17f: cc int3 0x10dd7b180: cc int3 0x10dd7b181: cc int3 0x10dd7b182: cc int3 0x10dd7b183: cc int3 0x10dd7b184: cc int3 (lldb) print whereIs(0x000000010dd7b174) (char *) $0 = 0x00000001000f83ff " is in generated methods" (lldb) call printCogMethodFor((void *)0x000000010dd7b174) 0x10dd7afc0 <-> 0x10dd7b198: method: 0x112f23c10 selector: 0x112232c20 add: (lldb) print whereIs(0x000000010de5700a) (char *) $1 = 0x00000001000f83ff " is in generated methods" (lldb) call printCogMethodFor((void *)0x000000010de5700a) 0x10de56ba0 <-> 0x10de57078: method: 0x1126ec218 prim 23856 selector: 0x7ffeefbf3d20 this method ends up being the fitted version of Delay class>> startTimerEventLoop _,,,^..^,,,_ best, Eliot

6 20

Re: [Vm-dev] Vm-dev Difficult to debug VM crash with full blocks and SistaV1
by Susan 30 Sep '19

30 Sep '19

Hi sweetie. I'm a 30 y.o. woman looking for romance. I'm ready to try ANYTHING in the bedroom ;) You can see my pics, you can view them in my gallery: my photos On Mon, Sep 30, 2019, at 1:27 AM, Open wrote: >Hi Nicolas, > >On Wed, Sep 25, 2019 at 12:32 AM Nicolas Cellier > wrote: > > > I noticed that many crash happen in testSendTimeout. > This test is organizing a race: > - Smalltalk fill the socket send buffer > - the OS tries to drain > > The other thing I noticed is that SocketTest suite run takes 7 to 8s on > macos while only 2 to 3s on ubuntu and windows > So it might be that some test times out on macos, while it doesn't on > other OS. > > This would explain >

1 0

Still Failing: OpenSmalltalk/opensmalltalk-vm#1813 (Cog - c114ece)
by Travis CI 30 Sep '19

30 Sep '19

Build Update for OpenSmalltalk/opensmalltalk-vm ------------------------------------- Build: #1813 Status: Still Failing Duration: 1 hr, 45 mins, and 16 secs Commit: c114ece (Cog) Author: Eliot Miranda Message: CogVM source as per VMMaker.oscog-eem.2568 CoInterpreter: Fix a slip in printing contexts. Cogit: Eliminate a bogus assert in compileFullBlockMethodFrameBuild: (and explain why). Stop generating forwarder following code for constants and self in methods in followed because self can be a forwarder in blocks without inst var accesses (anyway self == something in block is not super common). View the changeset: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/3023fbc21592...c1… View the full build log and details: https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/591257530?utm_m… -- 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

[OpenSmalltalk/opensmalltalk-vm] c114ec: CogVM source as per VMMaker.oscog-eem.2568
by Eliot Miranda 30 Sep '19

30 Sep '19

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: c114ece5b58154eaa3972d28f83c6f7b9f04ae6c https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c114ece5b58154eaa3… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2019-09-29 (Sun, 29 Sep 2019) Changed paths: M nsspur64src/vm/cogit.h M nsspur64src/vm/cogitX64SysV.c M nsspur64src/vm/cogitX64WIN64.c M nsspur64src/vm/cointerp.c M nsspur64src/vm/cointerp.h M nsspur64src/vm/gcc3x-cointerp.c M nsspursrc/vm/cogit.h M nsspursrc/vm/cogitARMv5.c M nsspursrc/vm/cogitIA32.c M nsspursrc/vm/cogitMIPSEL.c M nsspursrc/vm/cointerp.c M nsspursrc/vm/cointerp.h M nsspursrc/vm/gcc3x-cointerp.c M nsspurstack64src/vm/gcc3x-interp.c M nsspurstack64src/vm/interp.c M nsspurstacksrc/vm/gcc3x-interp.c M nsspurstacksrc/vm/interp.c M spur64src/vm/cogit.h M spur64src/vm/cogitX64SysV.c M spur64src/vm/cogitX64WIN64.c 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 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 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 spurlowcodestack64src/vm/gcc3x-interp.c M spurlowcodestack64src/vm/interp.c M spurlowcodestacksrc/vm/gcc3x-interp.c M spurlowcodestacksrc/vm/interp.c M spursista64src/vm/cogit.h M spursista64src/vm/cogitX64SysV.c M spursista64src/vm/cogitX64WIN64.c M spursista64src/vm/cointerp.c M spursista64src/vm/cointerp.h M spursista64src/vm/gcc3x-cointerp.c M spursistasrc/vm/cogit.h M spursistasrc/vm/cogitARMv5.c M spursistasrc/vm/cogitIA32.c M spursistasrc/vm/cogitMIPSEL.c M spursistasrc/vm/cointerp.c M spursistasrc/vm/cointerp.h M spursistasrc/vm/gcc3x-cointerp.c M spursrc/vm/cogit.h M spursrc/vm/cogitARMv5.c M spursrc/vm/cogitIA32.c M spursrc/vm/cogitMIPSEL.c 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 spurstack64src/vm/gcc3x-interp.c M spurstack64src/vm/interp.c M spurstacksrc/vm/gcc3x-interp.c M spurstacksrc/vm/interp.c M src/plugins/BitBltPlugin/BitBltPlugin.c M src/plugins/SocketPlugin/SocketPlugin.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 stacksrc/vm/gcc3x-interp.c M stacksrc/vm/interp.c Log Message: ----------- CogVM source as per VMMaker.oscog-eem.2568 CoInterpreter: Fix a slip in printing contexts. Cogit: Eliminate a bogus assert in compileFullBlockMethodFrameBuild: (and explain why). Stop generating forwarder following code for constants and self in methods in followed because self can be a forwarder in blocks without inst var accesses (anyway self == something in block is not super common).

1 0

← Newer
1
2
3
4
5
6
7
...
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev September 2019