Smalltalk › Pharo › Pharo Smalltalk Developers

Cog VM binaries as per VMMaker.oscog-eem.152/r2538.

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Eliot Miranda-2

Cog VM binaries as per VMMaker.oscog-eem.152/r2538.

Fix tricky context state bug that can cause crashes in the GC.

Contextpart>runUntilErrorOrReturnFrom: may pop the last argument.

Hence if a frame is married in this state its spouse context won't have

its last argument slot initialized. If later the frame is divorced and the

arguments are not updated the last argument slot can be left with this

uninitialized slot and ... bang.

The solution is to update arguments as well as stack contents when

divorcing. This is good also because it removes the VM's assumption

that method arguments are read-only, and that's only enforced by the

Smalltalk bytecode compiler, not by the bytecode.

--
best,

Eliot

Philippe Marschall-2-3

Re: Cog VM binaries as per VMMaker.oscog-eem.152/r2538.

On 03.03.2012 23:21, Eliot Miranda wrote:

>
>
>
>
> Cog VM binaries as per VMMaker.oscog-eem.152/r2538
> <http://www.mirandabanda.org/files/Cog/VM/VM.r2538/>.
> Fix tricky context state bug that can cause crashes in the GC.
> Contextpart>runUntilErrorOrReturnFrom: may pop the last argument.
> Hence if a frame is married in this state its spouse context won't have
> its last argument slot initialized. If later the frame is divorced and the
> arguments are not updated the last argument slot can be left with this
> uninitialized slot and ... bang.
> The solution is to update arguments as well as stack contents when
> divorcing. This is good also because it removes the VM's assumption
> that method arguments are read-only, and that's only enforced by the
> Smalltalk bytecode compiler, not by the bytecode.

I just wanted to report that my LD_LIBRARY_PATH problems are gone and
the VM starts again on 64bit. Also TCP_CORK seems to work.

Thanks
Philippe

Frank Shearar-3

Re: Cog VM binaries as per VMMaker.oscog-eem.152/r2538.

On 4 March 2012 19:44, Philippe Marschall <[hidden email]> wrote:

> On 03.03.2012 23:21, Eliot Miranda wrote:
>>
>>
>>
>>
>>
>> Cog VM binaries as per VMMaker.oscog-eem.152/r2538
>> <http://www.mirandabanda.org/files/Cog/VM/VM.r2538/>.
>>
>> Fix tricky context state bug that can cause crashes in the GC.
>> Contextpart>runUntilErrorOrReturnFrom: may pop the last argument.
>> Hence if a frame is married in this state its spouse context won't have
>> its last argument slot initialized. If later the frame is divorced and
>> the
>> arguments are not updated the last argument slot can be left with this
>> uninitialized slot and ... bang.
>> The solution is to update arguments as well as stack contents when
>> divorcing. This is good also because it removes the VM's assumption
>> that method arguments are read-only, and that's only enforced by the
>> Smalltalk bytecode compiler, not by the bytecode.
>
>
> I just wanted to report that my LD_LIBRARY_PATH problems are gone and the VM
> starts again on 64bit. Also TCP_CORK seems to work.

On my Ubuntu Lucid install the magic statement in the case returns

/lib/tls/i686/cmov/libc.so.6

So with the addition of

/lib/tls/i686/cmov/libc*) SVMLLP="/lib/tls/i686/cmov:/usr/lib";;

to the script, things seem OK: image booted, it updated, it passed the
UUID tests. I'm just running the full suite of tests now. Right, and
it didn't crash on playing that beep, which scared the __ out of me.
OK, the entire suite ran without crashing, which is great! Thanks,
Eliot!

I did have 18 failures and 38 errors, but that's the topic of a separate mail.

frank

> Thanks
> Philippe
>
>

Eliot Miranda-2

Re: Cog VM binaries as per VMMaker.oscog-eem.152/r2538.

On Sun, Mar 4, 2012 at 12:36 PM, Frank Shearar <[hidden email]> wrote:

On 4 March 2012 19:44, Philippe Marschall <[hidden email]> wrote:
> On 03.03.2012 23:21, Eliot Miranda wrote:
>>
>>
>>
>>
>>
>> Cog VM binaries as per VMMaker.oscog-eem.152/r2538
>> <http://www.mirandabanda.org/files/Cog/VM/VM.r2538/>.
>>
>> Fix tricky context state bug that can cause crashes in the GC.
>> Contextpart>runUntilErrorOrReturnFrom: may pop the last argument.
>> Hence if a frame is married in this state its spouse context won't have
>> its last argument slot initialized. If later the frame is divorced and
>> the
>> arguments are not updated the last argument slot can be left with this
>> uninitialized slot and ... bang.
>> The solution is to update arguments as well as stack contents when
>> divorcing. This is good also because it removes the VM's assumption
>> that method arguments are read-only, and that's only enforced by the
>> Smalltalk bytecode compiler, not by the bytecode.
>
>
> I just wanted to report that my LD_LIBRARY_PATH problems are gone and the VM
> starts again on 64bit. Also TCP_CORK seems to work.

On my Ubuntu Lucid install the magic statement in the case returns

/lib/tls/i686/cmov/libc.so.6

So with the addition of

/lib/tls/i686/cmov/libc*) SVMLLP="/lib/tls/i686/cmov:/usr/lib";;

to the script, things seem OK: image booted, it updated, it passed the
UUID tests. I'm just running the full suite of tests now. Right, and
it didn't crash on playing that beep, which scared the __ out of me.
OK, the entire suite ran without crashing, which is great! Thanks,

Thanks Frank! People, please keep these corrections to LD_LIBRARY_PATH coming. And if any ubuntu guru can figure out how to discard the sceme on ubuntu and what the script shoudl do on ubuntu I'll happily integrate that too.

Eliot!

I did have 18 failures and 38 errors, but that's the topic of a separate mail.

frank

> Thanks
> Philippe
>
>

--
best,

Eliot