[Vm-dev] vm crash when using rairedTo: with fractions

Sun Aug 13 22:12:24 UTC 2017

So, i've patched Squeak (I hope I made no mistake, I'm not Smalltalking
much these days)
See http://source.squeak.org/trunk/Kernel-nice.1111.diff
I'm not willing to contribute to Pharo immediately because no time to play
with a fragile infrastucture.
If you badly need the patch in Pharo, feel free to plagiarize.

Nicolas

2017-08-13 14:47 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:

>
>
> 2017-08-13 12:13 GMT+02:00 Andrei Chis <chisvasileandrei at gmail.com>:
>
>>
>>
>>
>> On Thu, Aug 10, 2017 at 10:42 PM, Nicolas Cellier <
>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>
>>>
>>>
>>>
>>> 2017-08-10 22:19 GMT+02:00 Andrei Chis <chisvasileandrei at gmail.com>:
>>>
>>>>
>>>> Hi Nicolas,
>>>>
>>>> Thanks for the info. Indeed sending #asFloat to the operand leads to a
>>>> correct behaviour.
>>>>
>>>> Just then is there a need for this special use case for handling
>>>> Fractions if it can lead to such problematic behaviour? Would the
>>>> logarithmic way ((aNumber * self ln) exp) not be enough? On this example
>>>> the computation takes a few minutes before crashing the image.
>>>>
>>>>
>>> Having (1/1000 raisedTo: 2/3) = (1/100)  is a nice thing and we want to
>>> keep it.
>>>
>>
>> Indeed, it's a nice to have feature.
>>
>>
>>> But once we detect that we can't have an exact result, we should adopt a
>>> more efficient strategy.
>>>
>>
>> Do you know if the vm plugin fix from Eliot addresses also this or there
>> should some more actions taken on the image side?
>>
>>
>>>
>>> There are corner cases where we want to avoid overflow/underflow in
>>> intermediate values, such as (1<<2000 + 1) raisedTo: 1/200 or ((1<<2000 +
>>> 1) reciprocal raisedTo: 1/200, so we must not convert asFloat too soon.
>>> But since ln already handles those edge cases (at least in Squeak, I
>>> have to check Pharo), ((aNumber * self ln) exp) is a good approximation
>>> (a few ulp off, depending on the quality of underlying libm).
>>>
>>
>> For now I switched to using ((aNumber * self ln) exp)  and it's working
>> well.
>>
>> Cheers,
>> Andrei
>>
>>
> Hi Andrei,
> an image side modification is necessary if we want to gain more efficiency.
> The question is whether we want to have correctly rounded results or not
> for Integer>>nthRoot:.
> If not, ((aNumber * self ln) exp) is OK (it can be a few ulp off as I
> told before).
> For Fraction, there's no point in rounding some term correctly then
> spoiling by an inexact raisedTo: and an inexact /.
> I started to look at it in Squeak (same code), then it will be time to
> port in Pharo.
>
> Nicolas
>
>
>>
>>> Nicolas
>>>
>>>
>>>> Cheers,
>>>> Andrei
>>>>
>>>> On Thu, Aug 10, 2017 at 9:27 PM, Nicolas Cellier <
>>>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>>>
>>>>>
>>>>> Hi Andrei,
>>>>> indeed, the method does not scale well...
>>>>>
>>>>> If the result is an exact Fraction, then it will answer the Fraction.
>>>>> Else if not exact, it will be converted to a Float.
>>>>>
>>>>> The problem is that it will try to answer nearest Float with a rather
>>>>> naive algorithm.
>>>>> Moreover, computing the nthRoot: first, then raising the result to the
>>>>> power of numerator will cumulate rounding errors.
>>>>> So trying to get a very accurate nthRoot: first in case of Float
>>>>> result is not a good strategy anyway.
>>>>>
>>>>> Why the VM crashes exactly is another problem and remains to see, we'd
>>>>> prefer an Exception.
>>>>>
>>>>> As a workaround, I suggest sending asFloat to the receiver and/or
>>>>> operand.
>>>>>
>>>>>
>>>>> 2017-08-10 12:02 GMT+02:00 Andrei Chis <chisvasileandrei at gmail.com>:
>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I was executing this code  '(2009/2000) ** (3958333/100000)' with the
>>>>>> Pharo6.1 distribution and the vm crashed with she stack attached below.
>>>>>> Tried it on both mac and windows 10.
>>>>>> Seems that #raisedTo: has a special case for fractions that ends up
>>>>>> calling #nthRoot: like '2009 nthRoot: 100000' leading to the crash.
>>>>>>
>>>>>> Cheers,
>>>>>> Andrei
>>>>>>
>>>>>>
>>>>>> 0xaddeac M LargePositiveInteger(Integer)>quo: 0x314093e8: a(n)
>>>>>> LargePositiveInteger
>>>>>> 0xaddec8 M LargePositiveInteger(LargeInteger)>quo: 0x314093e8: a(n)
>>>>>> LargePositiveInteger
>>>>>> 0xaddee8 M LargePositiveInteger(Integer)>// 0x314093e8: a(n)
>>>>>> LargePositiveInteger
>>>>>> 0xaddf04 M LargePositiveInteger(LargeInteger)>// 0x314093e8: a(n)
>>>>>> LargePositiveInteger
>>>>>> 0xaddf34 I LargePositiveInteger(Integer)>nthRootTruncated:
>>>>>> 0x30cc8350: a(n) LargePositiveInteger
>>>>>> 0xaddf5c I LargePositiveInteger(Integer)>nthRootRounded: 0x30cc8350:
>>>>>> a(n) LargePositiveInteger
>>>>>> 0xaddf88 I SmallInteger(Integer)>nthRoot: 0xfb3=2009
>>>>>> 0xaddfb4 I Fraction>nthRoot: 0x4f9a940: a(n) Fraction
>>>>>> 0xaddfd8 I Fraction(Number)>raisedTo: 0x4f9a940: a(n) Fraction
>>>>>> 0xaddffc I Fraction(Number)>** 0x4f9a940: a(n) Fraction
>>>>>> 0xade018 M UndefinedObject>DoIt 0x5fe5d00: a(n) UndefinedObject
>>>>>> 0xade048 I OpalCompiler>evaluate 0x4f9a998: a(n) OpalCompiler
>>>>>> 0xade074 I RubSmalltalkEditor>evaluate:andDo: 0x305e5878: a(n)
>>>>>> RubSmalltalkEditor
>>>>>> 0xade09c I RubSmalltalkEditor>highlightEvaluateAndDo: 0x305e5878:
>>>>>> a(n) RubSmalltalkEditor
>>>>>> 0xade0b8 M GLMMorphicPharoScriptRenderer(
>>>>>> GLMMorphicPharoCodeRenderer)>popupPrint 0x3062fdc8: a(n)
>>>>>> GLMMorphicPharoScri
>>>>>> enderer
>>>>>> 0xade0d8 I MorphicAlarm(MessageSend)>value 0x4f9ab20: a(n)
>>>>>> MorphicAlarm
>>>>>> 0xade0f4 M MorphicAlarm>value: 0x4f9ab20: a(n) MorphicAlarm
>>>>>> 0xade114 M WorldState>triggerAlarmsBefore: 0x71bb5e0: a(n) WorldState
>>>>>> 0xade140 M WorldState>runLocalStepMethodsIn: 0x71bb5e0: a(n)
>>>>>> WorldState
>>>>>> 0xade164 M WorldState>runStepMethodsIn: 0x71bb5e0: a(n) WorldState
>>>>>> 0xade180 M WorldMorph>runStepMethods 0x6ab7778: a(n) WorldMorph
>>>>>> 0xade198 M WorldState>doOneCycleNowFor: 0x71bb5e0: a(n) WorldState
>>>>>> 0xade1b4 M WorldState>doOneCycleFor: 0x71bb5e0: a(n) WorldState
>>>>>> 0xade1d0 M WorldMorph>doOneCycle 0x6ab7778: a(n) WorldMorph
>>>>>> 0xade1e8 M WorldMorph class>doOneCycle 0x6a9f960: a(n) WorldMorph
>>>>>> class
>>>>>> 0xade200 M [] in MorphicUIManager>spawnNewProcess 0x2cc88718: a(n)
>>>>>> MorphicUIManager
>>>>>> 0xade220 I [] in BlockClosure>newProcess 0x2f178150: a(n) BlockClosure
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170814/4536b769/attachment-0001.html>