All, I stumbled upon the following error when simulating a copy of a 3.8.1 (6502) image (full log attached) : Bitmap(Object)>>error: Receiver: a Bitmap of length 5499668 Arguments and temporary variables: aString: 'Improper store into indexable object' Receiver's instance variables: a Bitmap of length 5499668 The simulator loads the image correctly and both validate and validateActiveContext tests pass. But when I try to run test, it throws this error. VM version is: 4.16.7-3775 #1 XShm Tue May 5 22:44:20 IST 2020 /usr/bin/cc Linux s400 4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux The simulator works fine with 2.2 image but gives error on a 3.8.1 image with VMMaker loaded in it. Has anyone seen this error before? Any help in tracing this bug is appreciated. Regards .. Subbu SqueakDebug.log (4K) Download Attachment |
Seems wrong with floating point value here ? Bitmap(Object)>>at:put: Receiver: a Bitmap of length 5499668Arguments and temporary variables: index: 4902231 value: 0.006711409395973154 Receiver's instance variables: a Bitmap of length 5499668 Best, Karl On Tue, May 5, 2020 at 8:01 PM K K Subbu <[hidden email]> wrote: All, |
On 06/05/20 1:19 am, karl ramberg wrote: > > Bitmap(Object)>>at:put: > Receiver: a Bitmap of length 5499668 > Arguments and temporary variables: > index: 4902231 > value: 0.006711409395973154 > Receiver's instance variables: > a Bitmap of length 5499668 When I trace the stack, this occurs when a float value 1.0 is stored in the first slot of a float array of size 6 through an plugin (FloatArrayPlugin). The Bitmap here is memory (sized in words). When running on native VM, this code works fine but triggers an error when simulator tries to mimic a CArray at:put:. ---- memory 4118397 (words) a CArray arrayBaseAddress: 14488972 (bytes) ptrOffset: 0 unitSize: 4 CArray>>at: offset put: val ptrOffset = 0 ifFalse: [self error: 'only expect base address to receive at:put: message']. unitSize = 1 ifTrue: [^ interpreter byteAt: arrayBaseAddress + offset put: val]. unitSize = 4 ifTrue: [^ interpreter longAt: arrayBaseAddress + (offset * 4) put: val]. InterpreterSimulatorLSB>>longAt: byteAddress put: a32BitValue ^memory at: (byteAddress // 4) + 1 put: a32BitValue ----- But I don't understand why a valid store into memory with an index within bounds raises an error: ----- Object>>at: index put: value index isInteger ifTrue: [self class isVariable ifTrue: [(index >= 1 and: [index <= self size]) ifTrue: [self errorImproperStore] ifFalse: [self errorSubscriptBounds: index]] ----- I could reproduce this error on released images on Ubuntu Linux (64bit host). * Run Squeak3.8.1-6747full.image (this contains VMMaker code) * Open a workspace and inspect: InterpreterSimulator new openOn: 'Squeak32-3.8g-6548.image') * run 'self test' from the code pane of inspector * after swapping bytes and relocating objects, an error dialog pops up (see attached log) Regards .. Subbu SqueakDebug.log (5K) Download Attachment |
Hi Subbu, I had to make some changes to get the Balloon plugin to simulate correctly. You might want to take a look at BalloonArray and CArray et al in VMMaker.oscog and see your way to porting the changes to VMMaker. Better would be to get Interpreter up-to-date in VMMaker.oscog. A sensible end point has to be an Interpreter which is refactored like StackInterprteer is (i.e. it does not inherit from ObjectMemory) and that has the improvements Andreas implemented to e.g. the sample profile primitives, etc. Right now we have a fork, and I have no cycles I can spend to working on Interpreter in either context. I'd love to see someone tackle being able to derive a classic Interpreter VM from VMMaker.oscog. VMMaker.oscog has a much improved Slang, and of course is where Cog is developed. On Thu, May 7, 2020 at 12:46 AM K K Subbu <[hidden email]> wrote: On 06/05/20 1:19 am, karl ramberg wrote: _,,,^..^,,,_ best, Eliot |
On 08/05/20 2:47 am, Eliot Miranda wrote: > Hi Subbu, > > I had to make some changes to get the Balloon plugin to simulate > correctly. You might want to take a look at BalloonArray and CArray et > al in VMMaker.oscog and see your way to porting the changes to VMMaker. > Better would be to get Interpreter up-to-date in VMMaker.oscog. A > sensible end point has to be an Interpreter which is refactored like > StackInterprteer is (i.e. it does not inherit from ObjectMemory) and > that has the improvements Andreas implemented to e.g. the sample profile > primitives, etc. Right now we have a fork, and I have no cycles I can > spend to working on Interpreter in either context. I'd love to see > someone tackle being able to derive a classic Interpreter VM from > VMMaker.oscog. VMMaker.oscog has a much improved Slang, and of course > is where Cog is developed. Eliot, Thank you very much for these pointers. I am a weekend Squeaker, but I will get more time to work on VM later this month and you have just given me a worthy goal. Regards .. Subbu |
In reply to this post by Karl Ramberg
On 06/05/20 1:19 am, karl ramberg wrote: > Seems wrong with floating point value here ? > > Bitmap(Object)>>at:put: > Receiver: a Bitmap of length 5499668 > Arguments and temporary variables: > index: 4902231 > value: 0.006711409395973154 > Receiver's instance variables: > a Bitmap of length 5499668 The problem turned out to be that the simulator allocates a Bitmap for its memory and Bitmap does not support at:put: in SVN trunk. It only supports ByteAt:put: :-(. I then tried simulating Squeak32 3.8 image on Squeak 5.3+VMMaker but the simulator crashed even earlier - many ivars being used before init. E.g. it calls on primitiveVMParameter which tries to read stats* even before they are bound in GC. I am not sure of what I should do now. Should I get InterpreterSimulator working in VMMaker and then port it to VMMaker.oscog or get it working in VMMaker.oscog directly? Regards .. Subbu |
Hi Subbu, > On May 11, 2020, at 6:17 AM, K K Subbu <[hidden email]> wrote: > > On 06/05/20 1:19 am, karl ramberg wrote: > >> Seems wrong with floating point value here ? >> Bitmap(Object)>>at:put: >> Receiver: a Bitmap of length 5499668 >> Arguments and temporary variables: >> index: 4902231 >> value: 0.006711409395973154 >> Receiver's instance variables: >> a Bitmap of length 5499668 > > The problem turned out to be that the simulator allocates a Bitmap for its memory and Bitmap does not support at:put: in SVN trunk. It only supports ByteAt:put: :-(. > > I then tried simulating Squeak32 3.8 image on Squeak 5.3+VMMaker but the simulator crashed even earlier - many ivars being used before init. E.g. it calls on primitiveVMParameter which tries to read stats* even before they are bound in GC. > > I am not sure of what I should do now. Should I get InterpreterSimulator working in VMMaker and then port it to VMMaker.oscog or get it working in VMMaker.oscog directly? Because VMMaker.oscog works and is the production environment for opensmalltalk VMs it will be more effective to work within VMMaker.oscog, not breaking anything, having the full VMMaker.oscog facilities available, than working within VMMaker and porting later. IMO. Eliot, _,,,^..^,,,_ (phone) |
On 11/05/20 7:27 pm, Eliot Miranda wrote: >> I am not sure of what I should do now. Should I get >> InterpreterSimulator working in VMMaker and then port it to >> VMMaker.oscog or get it working in VMMaker.oscog directly? > Because VMMaker.oscog works and is the production environment for > opensmalltalk VMs it will be more effective to work within > VMMaker.oscog, not breaking anything, having the full VMMaker.oscog > facilities available, than working within VMMaker and porting later. > IMO. Thanks, Eliot for your lightning quick response. My hesitation is not around technical efforts but around merging large pieces of code into mainstream code. Is this really useful enough to get into VMMaker.oscog directly? If not, I wouldn't want to upload large code chunks and risk its release schedules. I will be content with my VMMaker weekend hacks. But if this is something that needs to get into oscog, then I have to plan to merge code in small reviewable chunks to avoid disruptions. Regards .. Subbu |
Free forum by Nabble | Edit this page |