[Vm-dev] VM Maker: VMMaker.oscog-nice.1733.mcz

Fri Mar 18 20:26:11 UTC 2016

Ah got it in http://smalltalkhub.com/mc/nice/NiceVMExperiments/main
--------------------------------------
Name: VMMaker.oscog-nice.1515
Author: nice
Time: 9 November 2015, 12:16:42.195 am
UUID: 120aa03b-9686-4219-bd35-0e90011f64be
Ancestors: VMMaker.oscog-nice.1514

Fix spurious signed/unsigned BUG I reintroduced by restoring Eliot's
positive32BitIntegerFor: version

The main symptom is Bitmap improper store...
...due to (65536 bitOr: (65536 bitShift: 16)) answering -1...
--------------------------------------
But the diff did not help, I must track further

2016-03-18 21:07 GMT+01:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:

> Esteban
> I confirm that this happens on 32bits squeak.stack.spur too.
> I already got this error before in my branch, I think I forgot to apply
> one change.
> I'm looking now
>
> 2016-03-18 20:46 GMT+01:00 Eliot Miranda <eliot.miranda at gmail.com>:
>
>>
>> Hi Esteban,
>>
>> On Fri, Mar 18, 2016 at 9:27 AM, Esteban Lorenzano <estebanlm at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On 18 Mar 2016, at 16:56, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>>
>>> Hi Esteban,
>>>
>>>
>>> On Mar 18, 2016, at 8:23 AM, Esteban Lorenzano <estebanlm at gmail.com>
>>> wrote:
>>>
>>>
>>> On 18 Mar 2016, at 16:11, Nicolas Cellier <
>>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>>
>>>
>>>
>>> 2016-03-18 16:00 GMT+01:00 Esteban Lorenzano <estebanlm at gmail.com>:
>>>
>>>>
>>>> Hi Nico,
>>>>
>>>> somewhere between this and VMMaker.oscog-dtl.1730 all PharoVMs become
>>>> unusable :(
>>>> are you aware of this?
>>>> maybe I’m forgetting something in my builds?
>>>>
>>>> cheers,
>>>> Esteban
>>>>
>>>>
>>> Hi Esteban,
>>> Please provide more feedback
>>> - can/can't compile ?
>>>
>>> - VM crash ? instantly or on specific operations ?
>>>
>>> can compile, but image is unusable (no refresh of UI… error with Bitmaps
>>> I think).
>>>
>>> - all OS or OS specific ?
>>>
>>> all environments (mac, linux and win) have this problem.
>>>
>>> - which flavour - stack/cogit x spur/v3 x 32/64 bits ?
>>>
>>>   I presume cogit-spur-32bits for Pharo head?
>>>
>>> yes
>>>
>>> Maybe a few explanations accompanying a Jenkins link would do it
>>>
>>>
>>> I don’t know what more to say :)
>>> but if you download:
>>>
>>> wget -O- get.pharo.org/50+vmLatest | bash
>>>
>>> and execute it… you will see the problem.
>>>
>>> and that does not happens if you execute
>>>
>>> wget -O- get.pharo.org/50+vm | bash
>>>
>>> (the only difference between those VMs are your commits).
>>>
>>>
>>> Some things to try (Clément is across the hall; he can help)
>>>
>>> no, today I’m not there :)
>>>
>>>
>>> 1. build an assert-enabled VM and run this.  You may get very useful
>>> error information.  You can use the -trace flag to get it to output the
>>> sends the VM makes and see where the first error is
>>>
>>> that’s the first thing I did… it does not says anything :(
>>> The only information I have is a stack trace:
>>>
>>
>> So start the assert VM under gdb or lldb.  Put a breakpoint in the
>> function "warning" and run it with "run -breaksel errorImproperStore"
>> and the VM will breakpoint in warning when errorImproperStore is sent.
>>
>> Now get a C backtrace and see if the VM is in the interpreter or if in
>> machine code.  If in interpreter walk up the C stack until you're in the
>> function interpret then use "call shortPrintFrameAndCallers(localFP)" to
>> get the backtrace of frames.  If this fails, rerun using a debug VM
>> (localFP may be optimised and so it may work only in the unoptimised debug
>> VM).
>>
>> If not in the interpreter (there will be some weird call stack pointing
>> back into form frame that won't have a name, but just an address), use
>> "call printStackCallStack()" to get the backtrace.
>>
>> Now, once you have located the frame for Bitmap(Object)>>at:put:, use
>> "call printFrame(TheFramePointerValue)" to print the frame in detail,
>> including arguments, temporaries and stack contents, etc.  That should show
>> you what the argument is and whether there's a bug in Bitmap>>at:put; or
>> some other bug.  You can print the sender frame by using the "saved fp"
>> value.  You should be able to narrow down that cause a lot using these
>> functions.  It's not a patch on the Smalltalk debugger; it's slow and error
>> prone, but you can debug images that won't start.  It's much easier in the
>> simulator, but possible in gdb/lldb.
>>
>> Good luck!
>>
>>
>>>
>>> Bitmap(Object)>>error:
>>> Bitmap(Object)>>errorImproperStore
>>> Bitmap(Object)>>at:put:
>>> Bitmap class(ArrayedCollection class)>>with:
>>> Color>>bitPatternForDepth:
>>> Form>>bitPatternFor:
>>> BitBlt>>fillColor:
>>>
>>> BitBlt>>setDestForm:sourceForm:fillColor:combinationRule:destOrigin:sourceOrigin:extent:clipRect:
>>> BitBlt
>>> class>>destForm:sourceForm:fillColor:combinationRule:destOrigin:sourceOrigin:extent:clipRect:
>>> Form(DisplayMedium)>>fillShape:fillColor:at:
>>> Form(DisplayMedium)>>fillShape:fillColor:
>>> CursorWithMask>>asCursorForm
>>> HandMorph>>showTemporaryCursor:hotSpotOffset:
>>> HandMorph>>showTemporaryCursor:
>>> RubEditingArea(RubAbstractTextArea)>>showOverEditableTextCursor
>>> RubEditingArea(RubAbstractTextArea)>>mouseEnter:
>>> RubEditingArea(Morph)>>handleMouseEnter:
>>> MouseMoveEvent(MouseEvent)>>sentTo:
>>> MouseMoveEvent>>sentTo:
>>> RubEditingArea(Morph)>>handleEvent:
>>> MouseOverHandler>>transform:from:andSendTo:
>>> [ self transform: evt from: anEvent andSendTo: aLeftMorph ] in
>>> MouseOverHandler>>inform:to:originatedFrom:ifNotFocusedDo: in Block: [ self
>>> transform: evt from: anEvent andSendTo: aLe...etc...
>>> True>>ifTrue:ifFalse:
>>> MouseOverHandler>>inform:to:originatedFrom:ifNotFocusedDo:
>>> [ :anEnteredMorph |
>>> self
>>> inform: asMouseEnterEvent
>>> to: anEnteredMorph
>>> originatedFrom: anEvent
>>> ifNotFocusedDo: [  ] ] in MouseOverHandler>>handleAsMouseEnter: in
>>> Block: [ :anEnteredMorph | ...
>>> Array(SequenceableCollection)>>reverseDo:
>>> MouseOverHandler>>handleAsMouseEnter:
>>> MouseOverHandler>>processMouseOver:
>>> HandMorph>>handleEvent:
>>> HandMorph>>processEvents
>>>
>>> cheers,
>>> Esteban
>>>
>>>
>>>
>>> 2. Open the image in the simulator, but that may be difficult with pharo
>>> cuz it uses so many external libraries.  Nite that you can still, with a
>>> little effort, do this but you have to write the plugin simulation code
>>> that maps from calls in the simulator to calls against the host VM's
>>> facilities.  For example, in the simulator the FilePluginSimulator defers
>>> to the host Smalltalk system to access files so the simulated VM can still
>>> access files just like the real VM, which defers to the stdio library or
>>> win32 APIs to access files.
>>>
>>> The simulator is not just worth maintaining it is /essential/ to being
>>> able to debug the VM effectively.  It should be a goal to have the Pharo
>>> image runnable in the simulator.
>>>
>>>
>>>
>>> cheers,
>>> Esteban
>>>
>>>
>>> I've experimented macosx stack spur 64 bits with simulator,
>>> and I use most of these changes in my own VM branch, except the
>>> fetch64/store64 message sends
>>> I'll check ASAP (this will be tonight)
>>>
>>> Nicolas
>>>
>>>
>>>
>>>> > On 17 Mar 2016, at 22:49, commits at source.squeak.org wrote:
>>>> >
>>>> >
>>>> > Nicolas Cellier uploaded a new version of VMMaker to project VM Maker:
>>>> > http://source.squeak.org/VMMaker/VMMaker.oscog-nice.1733.mcz
>>>> >
>>>> > ==================== Summary ====================
>>>> >
>>>> > Name: VMMaker.oscog-nice.1733
>>>> > Author: nice
>>>> > Time: 17 March 2016, 11:45:52.436 pm
>>>> > UUID: cc4513ea-67e5-4b41-b7bd-2fc790ac0102
>>>> > Ancestors: VMMaker.oscog-nice.1732
>>>> >
>>>> > Oups (Oops) forgot the <doNotGenerate> for simulated #stSizeOf:
>>>> version.
>>>> >
>>>> > =============== Diff against VMMaker.oscog-nice.1732 ===============
>>>> >
>>>> > Item was changed:
>>>> >  ----- Method: SpurMemoryManager>>stSizeOf: (in category 'object
>>>> access') -----
>>>> >  stSizeOf: oop
>>>> >       "Return the number of indexable fields in the receiver"
>>>> > +     <doNotGenerate>
>>>> >       ^oop basicSize!
>>>> >
>>>
>>>
>>>
>>>
>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160318/1a2162f0/attachment.htm