Vm-dev April 2016

vm-dev@lists.squeakfoundation.org

35 participants
202 discussions

error "please insert disk" (windows vm)
by Nicolai Hess 14 Jan '17

14 Jan '17

we have the following bug report 16928 <https://pharo.fogbugz.com/f/cases/16928/no-disk-in-the-drive-reply-to-World…> "no disk in the drive" reply to World | Save As (and other places) "On a clean Pharo4.0 #40618 image, on Windows 7 World Menu | Save As brings up a modal alert window, "There is no disk in the drive. Please insert a disk into drive <etc>" On my system, it does this 4 times. I'm assuming that each instance refers to one of the card-reader drives which are attached, but without a card inserted. This is a pain to deal with every single time a File Browser or World | Save As dialog is opened. Could the alerts either be - only raised when that specific drive is requested by a user action or, less preferably - given by a non-modal window, and fading away after a period" I was able to reproduce this error on squeaks and pharos window vm. (insert a usb card reader, with card, wait some time , remove only the card, every access on this drive, for example open a FileList and scroll to the drive letter). The solution I found is to call SetErrorMode( *SEM_FAILCRITICALERRORS)* I would like to propose the following change to sqwin32directory.c wrap the call to FindFirstFileW/FindNextFileW with UINT prevMode = SetErrorMode(SEM_FAILCRITICALERRORS); call FindFirstFileW/FindNextFileW SetErrorMode(prevMode); ... and call this functions in at least dir_lookup() (the other file/directory methods are save). Alternative solution, we could call the SetErrorMode function once at program start but I don't know if there are other "useful" errors message that we don't want to disable. I tested both solution, both seems to work fine. What do you think?

1 3

New case to crash Spur VM
by Denis Kudriashov 09 Dec '16

09 Dec '16

Hi In debugger (Squeak or Pharo) try "step over" for expression "Object basicSize": image will crash. We have opened issue for this in Pharo tracker 17962 <https://pharo.fogbugz.com/f/cases/17962/Image-is-crashed-when-step-over-Obj…>

5 12

ffi-test-main.c fails on FreeBSD
by Gary Dunn 12 Aug '16

12 Aug '16

In conjunction with getting Open Cobalt running on FreeBSD I have been looking into the problems with SqueakFFIPrims on FreeBSD and have reached a point that is beyond my understanding. I am not sure if the fix should come from the VM side or the FreeBSD port maintainer. I needed to get source code back into the ports tree so I did a make in /usr/ports/lang/squeak. I already had the 3.9 tarball, so that just repopulated the source and did the initial build. In the "files" folder I found patch files typical for a FreeBSD port. These patch source files from a generic tarball to work with FreeBSD. The one of interest was patch-platforms__unix__plugins__SqueakFFIPrims__ffi-config which contains ----x-----x----- --- platforms/unix/plugins/SqueakFFIPrims/ffi-config.org Wed Apr 26 20:27:53 2006 +++ platforms/unix/plugins/SqueakFFIPrims/ffi-config Wed Apr 26 20:29:00 2006 @@ -39,6 +39,7 @@ case ${abi} in linux) abi=sysv;; + freebsd*) abi=sysv;; darwin*) abi=darwin;; *) abi=libffi; lib="-lffi";; esac -----x-----x----- I then had the folder work/Squeak-3.9-7/platforms/unix/plugins/SqueakFFIPrims In it is a file 00README which explains how to test FFI. It says to run ffi-test-config but I have no such file. It says to type "make" to build a test suite but the build failed. It says to try with make CPU=any ABI=libffi LIB=-lffi which also failed. I traced the problem to the gcc search paths for includes and libraries -- turns out FreeBSD only searches /usr/include and /usr/lib when the required files are in /usr/local/include and /usr/local/lib. After some fiddling I finally had a "main" to test. It failed: ffi-test-main.c failed at line 361. Here is a bit from that file, ending with line 361: ffiInitialize(); for (ul= 0; ul < 15; ++ul) ffiPushSingleFloat(fa[ul]); GO(FFITypeSingleFloat, many); f= ffiReturnFloatValue(); ffiCleanup(); CHECK(f - ff < FLT_EPSILON); I worked out the CHECK macro but could not find what FLT_EPSILON is. At that point I decided to stop and come to you for help. Where do I go from here? -- Gary Dunn, Honolulu osp(a)aloha.com http://openslate.net/ http://e9erust.blogspot.com/ Sent from Slate001

5 8

Tasks of the heartbeat code
by Holger Freyther 27 Jul '16

27 Jul '16

Dear Eliot, I tried to understand the basic load of the VM and I have two questions for the heartbeat code. Is it right that there are two concerns for the code? 1.) Call forceInterruptCheckFromHeartbeat periodically 2.) Update the clock as seen by the image 1st is useful to interrupt Processes like […] repeat with a pre-emptive scheduler? On a different note do backwards jumps generate interrupt checks too? 2nd is this an optimization to not have to generate the clock when the primitive is being used? thanks holger

4 12

New Cog VMs available
by Eliot Miranda 14 Jul '16

14 Jul '16

... at http://www.mirandabanda.org/files/Cog/VM/VM.r3684 CogVM binaries as per VMMaker.oscog-eem.1834/r3684 General: Correct undue sign extension wile promoting 32 to 64 bits int in fetchLong64:ofObject: This was causing trouble in non spur object memory (V3). Fix slowdown of update on 64-bit x64 by using int variables for the tides in sqExternalSemaphores.c and inline assembler for the sqCompareAndSwap in sqAtomicOps.h. Fix slips in offset time primitives. They need to pop argumentCount + 1, not argumentCount. Define an optional primitive as the fast primitive fail code so that unselected optional primitives are in the prmitiveTable as fast primitive fails. Spur: Have WideString>>at: fail to answer an out-of-range character in the interpreter primitive (as well as in the JIT). Fix bug in following state on primitive failure. The old code would always follow to depth 1, even if the accessor depth was 0. Hard-code primitiveSize's depth to 0 (accessing length in at:[put:] and size causes the stack depth computation to answer 1 instead of 0 for these primitives. Fix assert and dequeueMourner for case where mournQueue is nil. - fixed a bug in receiver accessing in immutability primitive for mirror primitive. - change primitiveSetOrHasIdentityHash to patch the class table if the new hash is set to a behavior (the primitive knows it's a behavior if the second (optional) argument is true) For example: FullBlockClosure tryPrimitive: 161 withArgs: {38.true} No longer follow the method and context fields in a closure in activateNewClosureMethod:numArgs:mayContextSwitch:; the caller will have failed if these are forwarders, so no need to check again. Cogit: Add a primitive that answers pc map data for methods which can be used to better decorate methods in the VM Profiler. Refactor the pc map enumeration facilities so that the Sista pic data primitive can share the same enumerator. Do this by collapsing the isBackwardBranch and annotation parameters into a single parameter. Follow selectors in the openPICList post Spur become. Fix the ARM's caller-saved register mask now that we can name all the actual registers. Reworked machine code generation of immutability so for common stores it uses a single trampoline for both store checks and immutability checks. - improved support for register allocation: branch merge successfully compiled with register moved instead of spilling. Sista Cogit: Don't bother to add counters to conditional jumps implementing and: and or:. Added the remote inst var access bytecode in sista V1 bytecode set without interfering with existing code. Plugins: Upgrade LargeIntegersPlugin to v2.0 LargeInteger primitives now deal with 32-bits digits. No change to image code. Memory is 8 bytes aligned on Spur. When storing 32/64 bits large integers values, allways fill the eight bytes whatever the effectivily used size, rather than bother with dissertion of size. Generate integer type checking as C macros rather than direct/indirect interpreterProxy function call in plugins. This, and 32-bit accessing mean singificantly faster large integer arithmetic. Fix primAlienReplace to use positiveMachineIntegerValueOf: instead of positive32BitValueOf:. BitBltPlugin operates on 32bit word units, therefore it's better to declare its operands as 'unsigned int' rather than sqInt. On 32bit VM, this doesn't change anything, but on 64bits spur, it makes this snippet work: | wideString source pos blt expectedWideString | source := #[1 64 255 14 1 64 48 251]. expectedWideString := WideString fromByteArray: source. wideString := WideString new: source size // 4. pos := 0. blt := (BitBlt toForm: (Form new hackBits: wideString)) sourceForm: (Form new hackBits: source). blt combinationRule: Form over; sourceX: 0; sourceY: pos // 4; height: wideString byteSize // 4; width: 4; destX: 0; destY: 0; copyBits. wideString restoreEndianness. self assert: wideString = expectedWideString Hence it fixes loading/diffing MCZ with wide character. Mac OS Builds: Don't link with -fvisibility=hidden; it breaks external plugins. Use -fvisibility=default instead. This fixes e.g. UnixOSProcessPlugin on Mac OS X. Windows Builds: The Windows VMs are no longer "dpiAware". If you want one-to-one pixel mapping check the README for ins ructions. It's a simple edit. _,,,^..^,,,_ best, Eliot

7 20

Tracing a Spur Image from Smalltalk
by timfelgentreff 03 Jun '16

03 Jun '16

I've updated the SystemTracer package to trace a Spur-format image. This works as far as I can tell, producing a header that looks just like the header produced by the VM and the objects written also look good. I can also open the image in RSqueak, but not on Spur. It crashes immediately and produces a Smalltalk backtrace that looks like it never manages to return from the image-saving method (but the names in the Stack-trace all look ok, leading me to believe that enough objects got written ok to figure out classes, method names, find the right Process to run and so forth). Curiously, the old SystemTracer2 class that writes Cog-format images also produces images that cannot be opened by Cog VMs, only Interpreter VMs. So I assume there are other assumptions that maybe the JIT makes when starting up. So my question is, what assumptions could there be, and where could I start looking. Cheers, Tim (If you're wondering why I'm using the Smalltalk-level tracing at all - in our quest to create (with RSqueakVM) a Squeak VM that runs Squeak code fast enough that we no longer have to rely on C code from plugins or optional primitives, we're trying to see how far we can push this, and e.g. write the image from within itself, too.) -- View this message in context: http://forum.world.st/Tracing-a-Spur-Image-from-Smalltalk-tp4881224.html Sent from the Squeak VM mailing list archive at Nabble.com.

4 11

Simulator tutorial
by Ben Coman 18 May '16

18 May '16

One of the advertised niceties is running the VM in a simulator. I've been wondering for a while how to try it. I found this ancient tutorial... https://www.youtube.com/watch?v=2J1yjWtuwJU which saves current image as 'source.image' then in original image does... (InterpreterSimulatorLSB new openOn: 'source.image') test as advised at 2:15, but I get "Error: basicNew: failed" at the line methodCache := Array new: MethodCacheSize. where MethodCacheSize is nil. Is this still the correct way to invoke the simulator? I tried also "(StackInterpreterSimulatorLSB new openOn: 'source.image') test" with same result. If I use the example at the bottom of StackInterpreterSimulator class comment I get "Error: incomaptible image format" Also btw, the class comment of SimulatorMorph references Simulator>>openAsMorph which doesn't exist. Should this be StackInterpreterSimulator? I'm running on Linux-x86 platform. cheers -ben

4 8

Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We are in "code freeze" for Pharo 5)
by Nicolai Hess 15 May '16

15 May '16

I traced this back to Object>>withArgs:executeMethod: (primitive 188) in OpalCompiler>>#evaluate It does not happen on squeaks spur vm as far as I know (but I don't know what is the latests squeak spur vm). 2016-02-08 5:17 GMT+01:00 Martin Dias <tinchodias(a)gmail.com>: > Very interesting... > > I created case 17543 > <https://pharo.fogbugz.com/f/cases/17543/VM-crash-in-Windows-when-compiling-…>, > with Vincent's script and other quotes from this thread. I did it because > this Windows issue is independent from Epicea (whose integration only > exposed the Windows issue). > > Martin > > On Sat, Feb 6, 2016 at 6:41 AM, Max Leske <maxleske(a)gmail.com> wrote: > >> Changing the scheduler didn’t have any effect. However, it seems to me >> that the size of the input matters. I can make it work in two ways: >> 1. delete a line. If the line’s too short it won’t work though >> 2. delete a couple of characters from some symbols >> >> That would suggest that not the number of symbols / items in the array is >> significant but the number of bytes. So maybe there’s a problem with memory >> allocation in the VM. I haven’t been able to come up with an exact number, >> but the VM starts crashing at around 7096 characters. Sometimes I can go >> over 7100, other times not. Smaller numbers always work. >> >> HTH, >> Max >> >> On 06 Feb 2016, at 07:25, Ben Coman <btc(a)openInWorld.com >> <btc(a)openinworld.com>> wrote: >> >> On Sat, Feb 6, 2016 at 12:59 PM, Martin Dias <tinchodias(a)gmail.com> >> wrote: >> >> In fact, this integration step >> (https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z) >> was >> already passed by Epicea in December. That was before spur, it might be >> related to spur. >> >> That time, the integration of Epicea revealed a bug in delay's >> scheduling... >> >> >> Was that these issues integrated in build 50466... >> https://pharo.fogbugz.com/default.asp?17066 >> https://pharo.fogbugz.com/default.asp?13756 >> >> which should have left the current scheduler as >> DelayExperimentalSpinScheduler >> but in current build 50564 "Delay delaySchedulerClass" --> >> DelayMicrosecondScheduler >> >> Maybe Delay class >> initialize has been executed since >> Scheduler ifNotNil: [ Scheduler stopTimerEventLoop ]. >> Scheduler := DelayMicrosecondScheduler new. >> Scheduler startTimerEventLoop. >> Smalltalk addToStartUpList: self. >> >> but I don't see any updates that might have invoked it. >> Anyway, maybe changing that will help. >> >> cheers -ben >> >> >> >> maybe now it's revealing some bug in Windows+spur...? >> >> Martin >> >> >> On Fri, Feb 5, 2016 at 10:09 AM, Blondeau Vincent >> <vincent.blondeau(a)worldline.com> wrote: >> >> >> If you remove any line, it stops crashing… >> >> I really don’t know what is going on… >> >> >> >> Vincent >> >> >> >> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org >> <pharo-dev-bounces(a)lists.pharo.org>] De la part de >> Henrik Nergaard >> Envoyé : vendredi 5 février 2016 14:03 >> >> >> À : Pharo Development List >> Objet : Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] >> We are in "code freeze" for Pharo 5) >> >> >> >> Removing >> >> #(IRPrinterV2 #(visitStoreTemp: visitStoreRemoteTemp: >> visitPopIntoLiteralVariable: visitPushTemp: visitReturnLiteral: >> visitStoreInstVar: visitStoreLiteralVariable: visitPushLiteralVariable: >> visitPushInstVar: visitJump: visitPushLiteral: label: visitPushArray: >> visitPopIntoTemp: visitReturnInstVar: visitPopIntoRemoteTemp: >> visitTempVector: visitJumpIf: visitPushRemoteTemp: visitPopIntoInstVar: >> visitSend: )) >> >> And it stops crashing. >> >> >> >> - BTW, there is not crash.dmp, does it works with spur? >> >> >> >> https://pharo.fogbugz.com/f/cases/17506/when-an-Image-crashes-a-crash-dmp-f… >> >> >> >> Best regards, >> >> Henrik >> >> >> >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of >> Blondeau Vincent >> Sent: Friday, February 5, 2016 1:54 PM >> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> Subject: Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: >> [ANN] We are in "code freeze" for Pharo 5) >> >> >> >> Very strange bug indeed that happens on windows machines that crashes the >> VM. I succeeded to reduce the problem to an evaluation of a collection… >> >> Can someone have the same issue under Windows or Mac? >> >> >> >> To reproduce : Copy paste the contents of the attached file in the >> playground and print it or do it >> >> It works on pre-spur vm. >> >> >> >> BTW, there is not crash.dmp, does it works with spur? >> >> Vincent >> >> >> >> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de >> Marcus Denker >> Envoyé : vendredi 5 février 2016 13:01 >> À : Pharo Development List >> Objet : Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] >> We are in "code freeze" for Pharo 5) >> >> >> >> >> >> On 05 Feb 2016, at 12:40, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> >> I will try do integrate it now… >> >> >> >> >> >> >> >> No, it still fails. >> >> >> >> >> >> https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/labe… >> >> >> >> The last test it executed seems to be this: >> >> running suite: Refactoring-Tests-Environment >> >> starting testcase: RBBrowserEnvironmentTest>>testAndEnvironment ... >> >> Very strange... >> >> Marcus >> >> >> >> >> >> ________________________________ >> >> >> Ce message et les pièces jointes sont confidentiels et réservés à l'usage >> exclusif de ses destinataires. Il peut également être protégé par le >> secret >> professionnel. Si vous recevez ce message par erreur, merci d'en avertir >> immédiatement l'expéditeur et de le détruire. L'intégrité du message ne >> pouvant être assurée sur Internet, la responsabilité de Worldline ne >> pourra >> être recherchée quant au contenu de ce message. Bien que les meilleurs >> efforts soient faits pour maintenir cette transmission exempte de tout >> virus, l'expéditeur ne donne aucune garantie à cet égard et sa >> responsabilité ne saurait être recherchée pour tout dommage résultant d'un >> virus transmis. >> >> This e-mail and the documents attached are confidential and intended >> solely for the addressee; it may also be privileged. If you receive this >> e-mail in error, please notify the sender immediately and destroy it. As >> its >> integrity cannot be secured on the Internet, the Worldline liability >> cannot >> be triggered for the message content. Although the sender endeavours to >> maintain a computer virus-free network, the sender does not warrant that >> this transmission is virus-free and will not be liable for any damages >> resulting from any virus transmitted. >> >> >> ________________________________ >> >> Ce message et les pièces jointes sont confidentiels et réservés à l'usage >> exclusif de ses destinataires. Il peut également être protégé par le >> secret >> professionnel. Si vous recevez ce message par erreur, merci d'en avertir >> immédiatement l'expéditeur et de le détruire. L'intégrité du message ne >> pouvant être assurée sur Internet, la responsabilité de Worldline ne >> pourra >> être recherchée quant au contenu de ce message. Bien que les meilleurs >> efforts soient faits pour maintenir cette transmission exempte de tout >> virus, l'expéditeur ne donne aucune garantie à cet égard et sa >> responsabilité ne saurait être recherchée pour tout dommage résultant d'un >> virus transmis. >> >> This e-mail and the documents attached are confidential and intended >> solely for the addressee; it may also be privileged. If you receive this >> e-mail in error, please notify the sender immediately and destroy it. As >> its >> integrity cannot be secured on the Internet, the Worldline liability >> cannot >> be triggered for the message content. Although the sender endeavours to >> maintain a computer virus-free network, the sender does not warrant that >> this transmission is virus-free and will not be liable for any damages >> resulting from any virus transmitted. >> >> >> >

1 1

Spur corrupts large images when saving
by Yuriy Tymchuk 03 May '16

03 May '16

Dear vm developers, I’ve encountered multiple times an issue when my images cannot be opened after saving (only on spur). I think that this happens when image is large, and the following script results in a corrupt image almost 100%: curl get.pharo.org/50+vm | bash ./pharo Pharo.image --no-default-preferences eval --save \ "Smalltalk globals at: #ReallyBigArray put: (ByteArray new: 1024*1024*1000). 'Done'" ./pharo Pharo.image printVersion The last line is there just to make image do something and for me it fails all the times. I hope that this can help to troubleshoot the issue with the vm. Also here are my system & hardware specs: System Version: OS X 10.11.3 (15D21) Model Identifier: MacBookPro11,5 Processor Name: Intel Core i7 Processor Speed: 2.8 GHz Total Number of Cores: 4 Memory: 16 GB Cheers! Uko

15 57

Cuis now runs with latest Cog, but I don't understand the problem we had
by Juan Vuletich 02 May '16

02 May '16

Hi Eliot, Folks, Until today, Cuis wouldn't run with any Cog VM newer than #3370. Phil Bellalouna just found the problem. I short, the problem is Character>>#= calling primitive 110 directly. For some reason, primitive 110 works ok if called from #== but not if called from #=, at least in Character. If you want to see the problem, just get latest Cuis from https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev and run it with latest Cog. It will start ok. Then browse Character>>#= and uncomment the <primitive: 110> line, and debuggers immediately arise. I'm posting this because I can't understand why does this happen, and maybe this leads to some fix/enh in Cog. Besides, I'm curious and I'd like to know. So, please take a look and enlighten me. Thanks, Juan Vuletich

5 13

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 April 2016