[Vm-dev] BUG? A problem with callbacks that shows up in 64bits (but is on 32bits too)

[Eliot Miranda]

Hi Nicolas, Hi Esteban, Hi Igor,

On Sun, Mar 12, 2017 at 5:36 AM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
> Couldn't it be that some Smalltalk memory has been relocated? (I'm
> thinking of the DisplayScreen bits)
>

That's indeed the main bug.  There are issues with callbacks that confuse
the error reporting and make it look like the
primSignal:andReturnAs:fromContext: primitive fails when in fact it is the
copyBits primitive that is failing.  But the problem is that the copyBits
primitive calls back through the lockSurfaces and unlockSurfaces callbacks,
and when a scavenge happens this moves destForm or sourceForm and the
primitive attempts to access them after the callback and hence ends up
accessing bad data and causes the primitive to fail.

I have fixed lockSurfaces and unlockSurfaces to not access destForm and
sourceForm after the lockSurfaces and unlockSurfaces calls (by making
sourceHandle and destHandle inst vars of BitBltSimulation) but it's not
fully fixed yet.  I think querySurfaces is still involved and then there's
the showDisplayBits:Left:Top:Right:Bottom: at the end.

I think I should commit the fixes I have so far and we should work towards
removing all stale accesses from BitBltSimulation>>copyBits and
BitBltSimulation>>warpBits.

These fixes include
changing  platforms/Cross/plugins/SurfacePlugin/SurfacePlugin.c so that the
callback functions can be optional, which reduces the number of callbacks
and ups the frame rate a bit.

2017-03-12 12:53 GMT+01:00 Esteban Lorenzano <estebanlm at gmail.com>:
>
>>
>> Hi,
>>
>> this is lockSurfaceFn:
>>
>> createLockSurfaceFn
>> ^ FFICallback
>> signature: #(void * (void *handle, int *pitch, int x, int y, int w, int
>> h))
>> block: [ :handle :pitch :x :y :w :h |
>> pitch signedLongAt: 1 put: (self get_stride: handle).
>> self get_data: handle ]
>>
>> and
>>
>> createUnlockSurfaceFn
>> ^ FFICallback
>> signature: #(int (void *handle, int x, int y, int w, int h))
>> block: [ :handle :x :y :w :h | 0 "Do nothing” ]
>>
>> cheers!
>> Esteban
>>
>> On 12 Mar 2017, at 03:34, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>
>> Hi Esteban,
>>
>> 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.
>>>
>>
>> My original theory is wrong.  As you suspected it is something to do with
>> the callback in primitiveCopyBits via lockSurfaces & unlockSurfaces.  Can
>> you tell me what the callback is and what code installs it into the
>> lockSurfaceFn and unlockSurfaceFn?
>>
>>
>>> 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/20170312/00bcc80b/attachment.html>