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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Mar 18 20:07:15 UTC 2016


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/5bc1f484/attachment-0001.htm


More information about the Vm-dev mailing list