[Vm-dev] Optimization bug in Pharo 64-bit Mac VM [was BUG? A problem with callbacks that shows up in 64bits (but is on 32bits too)]

[Eliot Miranda]

Hi All, but especially Nicolas and C experts,

    if you build a Mac 64-bit Pharo VM in production and assert
configurations and run the below

wget files.pharo.org/get-files/60/pharo64.zip
wget files.pharo.org/get-files/60/sources.zip
unzip pharo64.zip
unzip sources.zip
pharo64cfvm Pharo64-60438.image eval "VGTigerDemo runDemo" &
pharo64cavm Pharo64-60438.image eval "VGTigerDemo runDemo"

you'll see that in the Assert VM the screen is clean and the tiger is
displayed within a white rectangle, but in the production VM there are lots
of garbage pixels at the bottom and bottom right of the screen.  So
somewhere in the display pipeline we have an optimization-related bug.  The
Assert VM is optimized at -O1 and the production VM at -Os (favour space
over time).

On Fri, Mar 10, 2017 at 12:13 PM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

> Hi Esteban,
>
>     first of all hanks so much for the instructions.  It's so nice to just
> run the commands below and be able to reproduce immediately instead of
> having to root around through build servers, following links.  Thanks, it
> saves me a huge amount of time.  i really appreciate the effort.
>
> Second, I find I can make the primitive fail much sooner if I pick up the
> main window and move it.  I was running it on one machine, wanted to run it
> on another with a different VM but the main window was in the way of the
> command.  So I moved the main window so I could read the command line and
> lo and behold it failed immediately.  So if I start the demo,and then pick
> up the window and move it, the primitive fails within very few seconds.
> That could be a clue.
>
> On Fri, Mar 10, 2017 at 7:35 AM, Esteban Lorenzano <estebanlm at gmail.com>
> wrote:
>
>>
>> Hi,
>>
>> I’m tumbling into an error in Pharo, because we use callbacks
>> intensively, in Athens(cairo)-to-World conversion in particular, and people
>> is sending always their crash reports… we made the whole conversion a lot
>> more robust since problems started to arise, but now I hit a wall I cannot
>> solve: I think problem is in something in callbacks.
>>
>> And problem is showing very easy on 64bits (while in 32bits it takes time
>> and is more random).
>>
>> Here is the easiest way to reproduce it (in mac):
>>
>> wget files.pharo.org/get-files/60/pharo64-mac-latest.zip
>> wget files.pharo.org/get-files/60/pharo64.zip
>> wget files.pharo.org/get-files/60/sources.zip
>> unzip pharo64-mac-latest.zip
>> unzip pharo64.zip
>> unzip sources.zip
>> ./Pharo.app/Contents/MacOS/Pharo ./Pharo64-60438.image eval "VGTigerDemo
>> runDemo"
>>
>> eventually (like 5-6 seconds after, if not immediately), you will have a
>> stack like this:
>>
>> SmallInteger(Object)>>primitiveFailed:
>> SmallInteger(Object)>>primitiveFailed
>> SmallInteger(VMCallbackContext64)>>primSignal:andReturnAs:fromContext:
>> GrafPort>>copyBits
>> GrafPort>>image:at:sourceRect:rule:
>> FormCanvas>>image:at:sourceRect:rule:
>> FormCanvas(Canvas)>>drawImage:at:sourceRect:
>> FormCanvas(Canvas)>>drawImage:at:
>> VGTigerDemo>>runDemo
>> VGTigerDemo class>>runDemo
>> UndefinedObject>>DoIt
>> OpalCompiler>>evaluate
>> OpalCompiler(AbstractCompiler)>>evaluate:
>> [ result := Smalltalk compiler evaluate: aStream.
>> self hasSessionChanged
>>         ifFalse: [ self stdout
>>                         print: result;
>>                         lf ] ] in EvaluateCommandLineHandler>>evaluate:
>> in Block: [ result := Smalltalk compiler evaluate: aStream....
>> BlockClosure>>on:do:
>> EvaluateCommandLineHandler>>evaluate:
>> EvaluateCommandLineHandler>>evaluateArguments
>> EvaluateCommandLineHandler>>activate
>> EvaluateCommandLineHandler class(CommandLineHandler class)>>activateWith:
>> [ aCommandLinehandler activateWith: commandLine ] in
>> PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in
>> Block: [ aCommandLinehandler activateWith: commandLine ]
>> BlockClosure>>on:do:
>> PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand:
>> PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand
>> PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument:
>> [ self
>>         handleArgument:
>>                 (self arguments
>>                         ifEmpty: [ '' ]
>>                         ifNotEmpty: [ :arguments | arguments first ]) ]
>> in PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block:
>> [ self...
>> BlockClosure>>on:do:
>> PharoCommandLineHandler(BasicCommandLineHandler)>>activate
>> PharoCommandLineHandler>>activate
>> PharoCommandLineHandler class(CommandLineHandler class)>>activateWith:
>> [ super activateWith: aCommandLine ] in PharoCommandLineHandler
>> class>>activateWith: in Block: [ super activateWith: aCommandLine ]
>>
>> Any idea?
>>
>> thanks!
>> Esteban
>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>



-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170310/12880479/attachment.html>