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

Eliot Miranda eliot.miranda at gmail.com
Fri Mar 18 19:46:39 UTC 2016


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


More information about the Vm-dev mailing list