Weird FFI method redefinition in Pharo 6

Hi,

Mmm… FFIMethodRegistry is reseting the method value to its old value because you modified the method but you did not executed it (you simulated it, I guess), and FFICalloutAPI updates the registry on method execution. 

Then on image shutdown the methods are reseted to their original value.

This is usually not an issue, but running with the simulator can cause that problem.

Esteban

On 3 Mar 2019, at 23:03, Eliot Miranda <[hidden email]> wrote:

Hi All,

    I'm trying to debug remaining limitations in Image Segment support in Spur using a case provided by Max Leske.  This is a pair of Pharo 6 images, one of which saves an image segment the other which loads it.  Both use OSEnvironment>>getEnv: to access environment variables.

The base definition of OSEnvironment>>getEnv: is

!OSEnvironment methodsFor: 'accessing' stamp: 'auto 5/3/2016 10:31'!

getEnv: arg1

        "This method calls the Standard C Library getenv() function. The name of the argument (arg1) should fit decompiled version."

         ^ self ffiCall: #( String getenv (String arg1) ) module: LibC! !

but as I'm using the VM Simulator to debug the image segment issues I need to avoid the FFI, which isn't yet simulateable.  So I redefine OSEnvironment>>getEnv: as follows, and then save and exit.

!OSEnvironment methodsFor: 'accessing' stamp: 'EliotMiranda 02/27/2019 17:09'!

getEnv: aByteStringOrByteArray

        "This method calls the Standard C Library getenv() function. The name of the argument (arg1) should fit decompiled version."

        <primitive: 'primitiveGetenv' module: '' error: ec>

        ec == #'bad argument' ifTrue:

                [aByteStringOrByteArray isString ifFalse:

                        [^self getEnv: aByteStringOrByteArray asString]].

        self primitiveFail! !

But, and here's the weird bit, when I start up the image, the new definition has been discarded and replaced by the original.  WTF?!?!  Why is this happening?  How can I disable this?

The only way that I've found I am able to save with a new version is by doing a Save As... to a new name.  This is fine, but I find the current behavior extremely unhelpful.  Is it a bug?  If it is intended, whats the rationale?

_,,,^..^,,,_

best, Eliot

On 4 Mar 2019, at 16:02, Eliot Miranda <[hidden email]> wrote:

Hi Esteban,

On Mon, Mar 4, 2019 at 4:31 AM Esteban Lorenzano <[hidden email]> wrote:

Hi,

Mmm… FFIMethodRegistry is reseting the method value to its old value because you modified the method but you did not executed it (you simulated it, I guess), and FFICalloutAPI updates the registry on method execution. 

Then on image shutdown the methods are reseted to their original value.

This is usually not an issue, but running with the simulator can cause that problem.

It happens with or without the simulator.  If I redefine the method and save, expecting that on startup the new version will be executed, and startup with the normal VM, the method is reset.  Surely this is a bug and the method should be removed from the FFI registry when it is redefined with no FFI usage in it.  Right?

Then indeed, that may be a bug… still, I need to check the best way to fix it (we need to introduce a check when compiling to reset the ffi method… I guess with a compiler plugin).

Esteban

 

Esteban

On 3 Mar 2019, at 23:03, Eliot Miranda <[hidden email]> wrote:

Hi All,

    I'm trying to debug remaining limitations in Image Segment support in Spur using a case provided by Max Leske.  This is a pair of Pharo 6 images, one of which saves an image segment the other which loads it.  Both use OSEnvironment>>getEnv: to access environment variables.

The base definition of OSEnvironment>>getEnv: is

!OSEnvironment methodsFor: 'accessing' stamp: 'auto 5/3/2016 10:31'!

getEnv: arg1

        "This method calls the Standard C Library getenv() function. The name of the argument (arg1) should fit decompiled version."

         ^ self ffiCall: #( String getenv (String arg1) ) module: LibC! !

but as I'm using the VM Simulator to debug the image segment issues I need to avoid the FFI, which isn't yet simulateable.  So I redefine OSEnvironment>>getEnv: as follows, and then save and exit.

!OSEnvironment methodsFor: 'accessing' stamp: 'EliotMiranda 02/27/2019 17:09'!

getEnv: aByteStringOrByteArray

        "This method calls the Standard C Library getenv() function. The name of the argument (arg1) should fit decompiled version."

        <primitive: 'primitiveGetenv' module: '' error: ec>

        ec == #'bad argument' ifTrue:

                [aByteStringOrByteArray isString ifFalse:

                        [^self getEnv: aByteStringOrByteArray asString]].

        self primitiveFail! !

But, and here's the weird bit, when I start up the image, the new definition has been discarded and replaced by the original.  WTF?!?!  Why is this happening?  How can I disable this?

The only way that I've found I am able to save with a new version is by doing a Save As... to a new name.  This is fine, but I find the current behavior extremely unhelpful.  Is it a bug?  If it is intended, whats the rationale?

_,,,^..^,,,_

best, Eliot

-- 

_,,,^..^,,,_

best, Eliot