[Pharo-dev] [Vm-dev] Frequent SegFaults in PharoVM with Pharo 3.0

Clément Bera bera.clement at gmail.com
Tue Nov 26 09:56:07 EST 2013


2013/11/26 Max Leske <maxleske at gmail.com>

> Thanks for the explanation. I suspected something like that (interestingly
> when I tried disabling all options on my Mac it worked fine…).
>

This is because you didn't execute: 'OpalCompiler recompileAll'.

>
> I’ll dig some more and let you know.
>

We should dig into the '3 timesRepeat: [ Smalltalk garbageCollect ]',
because this may be a bug somewhere. Now we shouldn't dig into having a
system running without condition and loops inlined by the compiler, because
this is too much work (for example as Marcus said loops on all objects
should not create an object (even a context) ...). If we really want that
we will invest time. But right now it is not a priority.

>
>
> On 25.11.2013, at 18:42, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
>
>
> On Mon, Nov 25, 2013 at 9:37 AM, Sven Van Caekenberghe <sven at stfx.eu>wrote:
>
>>
>> On 25 Nov 2013, at 17:56, Clément Bera <bera.clement at gmail.com> wrote:
>>
>> > Yeah you cannot compile without inlining specific messages. You can
>> disable inlining of #timesRepeat: at image level because we added it for
>> fun to see if it was easy to do in Opal. Now all other optimizations were
>> in the old compiler and are mandatories. However, you can now in Opal
>> disable these optimized messages in a restricted area (such as a class and
>> its subclasses).
>> >
>> > To me, it is kind of a bug that we cannot disable those optimizations,
>> we should be able to do it (so 1 day in the very very far future we could
>> have the JIT inlining these control structure allowing us to implement all
>> these inlined messages in all classes). But one thing is that some methods
>> such as #whileTrue are not implemented in a way they really work (they have
>> not stop condition, so if the compiler does not inline it, it gives you an
>> infinite loop). Another thing is the interrupt point problem as Marcus said.
>> >
>> > I don't think your other bug is related Opal optimization, only
>> #timesRepeat: is new and therefore can be faulty (and in this case, the
>> bytecode is correct, so I guess it is faulty because it removes an
>> interrupt point).
>>
>> It is a bit scary that there is no explicit, crystal clear list of those
>> interrupt critical points, especially if skipping them can lead to VM
>> crashes.
>>
>
> Before we raise the alarm the first thing is to identify the cause of the
> VM crash.  It could still be a VM bug.  First track down the bug.  Don't
> try and find work-arounds.  Try and find the cause.  Only then can one
> develop a correct fix.  Anything else buries the true cause under hacks, a
> process that is truly scary ;-)
>
>
>>
>> > 2013/11/25 Marcus Denker <marcus.denker at inria.fr>
>> >
>> > On 25 Nov 2013, at 16:26, Max Leske <maxleske at gmail.com> wrote:
>> >
>> > > Thanks Clément, that seems to be it. Disabling the timesRepeat
>> inlining makes most of the builds run through but not all of them. It seems
>> like there’s another (Opal related?) problem (with the exact same
>> symptoms…).
>> > >
>> > > I’ve tried disabling all options, just to see what happens: all
>> builds fail with SegFaults…
>> >
>> > You can not compile without optimisations. There are places in the
>> image that would not work with e.g. whileTrue: optimisation disabled as it
>> would e.g. add an interrupt point where none is now
>> > And other things, like performance, or e.g. the loop that goes over all
>> objects, if that creates objects while running you have a problem…
>> >
>> >         Marcus
>> >
>>
>>
>>
>
>
> --
> best,
> Eliot
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131126/49a8eeaa/attachment-0002.html>


More information about the Pharo-dev mailing list