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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Stephane Ducasse-3
Tx eliot.


On Fri, Aug 11, 2017 at 12:55 AM, Eliot Miranda <[hidden email]> wrote:

> Hi Andrei,
>
> On Thu, Aug 10, 2017 at 3:02 AM, Andrei Chis <[hidden email]>
> wrote:
>>
>>
>> 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.
>
>
> The plugin is now fixed; see VMMaker.oscog-eem.2262.  I'll generate code
> soon (am debugging something you're familiar with that takes several hours
> to run and don't want to generate sources while it's running).  But I'm glad
> you've found a better way!  This case creates 600k byte large integers and
> takes forever to run :-)
>
>>
>> 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
>>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot

Reply | Threaded
Open this post in threaded view
|

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

Tim Mackinnon
Is there a way for this to get back into 6.1 - so we can shoot for a stable 6.x version that will last us for a year while 7.x is under development?

I’m not familiar with how point release are handled in Pharo, and I get the impression that this is going to be a slightly rockier year as there have been some pretty revolutionary changes made to get us here.

As its a vm change does this mean we get 6.2 queued up somehow?

Tim

> On 13 Aug 2017, at 20:12, Stephane Ducasse <[hidden email]> wrote:
>
> Tx eliot.
>
>
> On Fri, Aug 11, 2017 at 12:55 AM, Eliot Miranda <[hidden email]> wrote:
>> Hi Andrei,
>>
>> On Thu, Aug 10, 2017 at 3:02 AM, Andrei Chis <[hidden email]>
>> wrote:
>>>
>>>
>>> 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.
>>
>>
>> The plugin is now fixed; see VMMaker.oscog-eem.2262.  I'll generate code
>> soon (am debugging something you're familiar with that takes several hours
>> to run and don't want to generate sources while it's running).  But I'm glad
>> you've found a better way!  This case creates 600k byte large integers and
>> takes forever to run :-)
>>
>>>
>>> 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
>>>
>>
>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
>


Reply | Threaded
Open this post in threaded view
|

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

Nicolas Cellier
Hi Tim,
I'd say: is this a showstopper?
How often do you raise a Fraction to the power of another Fraction with large denominator (> 10000)?
Or is it used indirectly by some kind of Framework?

If yes then open a pharo bug entry and mark for 6.x, else just wait 7.x...

Nicolas

2017-08-14 10:49 GMT+02:00 Tim Mackinnon <[hidden email]>:
Is there a way for this to get back into 6.1 - so we can shoot for a stable 6.x version that will last us for a year while 7.x is under development?

I’m not familiar with how point release are handled in Pharo, and I get the impression that this is going to be a slightly rockier year as there have been some pretty revolutionary changes made to get us here.

As its a vm change does this mean we get 6.2 queued up somehow?

Tim

> On 13 Aug 2017, at 20:12, Stephane Ducasse <[hidden email]> wrote:
>
> Tx eliot.
>
>
> On Fri, Aug 11, 2017 at 12:55 AM, Eliot Miranda <[hidden email]> wrote:
>> Hi Andrei,
>>
>> On Thu, Aug 10, 2017 at 3:02 AM, Andrei Chis <[hidden email]>
>> wrote:
>>>
>>>
>>> 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.
>>
>>
>> The plugin is now fixed; see VMMaker.oscog-eem.2262.  I'll generate code
>> soon (am debugging something you're familiar with that takes several hours
>> to run and don't want to generate sources while it's running).  But I'm glad
>> you've found a better way!  This case creates 600k byte large integers and
>> takes forever to run :-)
>>
>>>
>>> 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
>>>
>>
>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
>



Reply | Threaded
Open this post in threaded view
|

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

Tim Mackinnon
It’s a fair point - I guess if enough things crop up, then a 6.2 release gets contemplated.

Tim

On 14 Aug 2017, at 10:29, Nicolas Cellier <[hidden email]> wrote:

Hi Tim,
I'd say: is this a showstopper?
How often do you raise a Fraction to the power of another Fraction with large denominator (> 10000)?
Or is it used indirectly by some kind of Framework?

If yes then open a pharo bug entry and mark for 6.x, else just wait 7.x...

Nicolas

2017-08-14 10:49 GMT+02:00 Tim Mackinnon <[hidden email]>:
Is there a way for this to get back into 6.1 - so we can shoot for a stable 6.x version that will last us for a year while 7.x is under development?

I’m not familiar with how point release are handled in Pharo, and I get the impression that this is going to be a slightly rockier year as there have been some pretty revolutionary changes made to get us here.

As its a vm change does this mean we get 6.2 queued up somehow?

Tim

> On 13 Aug 2017, at 20:12, Stephane Ducasse <[hidden email]> wrote:
>
> Tx eliot.
>
>
> On Fri, Aug 11, 2017 at 12:55 AM, Eliot Miranda <[hidden email]> wrote:
>> Hi Andrei,
>>
>> On Thu, Aug 10, 2017 at 3:02 AM, Andrei Chis <[hidden email]>
>> wrote:
>>>
>>>
>>> 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.
>>
>>
>> The plugin is now fixed; see VMMaker.oscog-eem.2262.  I'll generate code
>> soon (am debugging something you're familiar with that takes several hours
>> to run and don't want to generate sources while it's running).  But I'm glad
>> you've found a better way!  This case creates 600k byte large integers and
>> takes forever to run :-)
>>
>>>
>>> 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
>>>
>>
>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
>




Reply | Threaded
Open this post in threaded view
|

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

Stephane Ducasse-3
In reply to this post by Nicolas Cellier
I like your answer nicolas.
If this is really important for any business or any dev around let us know
we can just tag it and we will port it for 6.2.

Stef


On Mon, Aug 14, 2017 at 11:29 AM, Nicolas Cellier
<[hidden email]> wrote:

> Hi Tim,
> I'd say: is this a showstopper?
> How often do you raise a Fraction to the power of another Fraction with
> large denominator (> 10000)?
> Or is it used indirectly by some kind of Framework?
>
> If yes then open a pharo bug entry and mark for 6.x, else just wait 7.x...
>
> Nicolas
>
>
> 2017-08-14 10:49 GMT+02:00 Tim Mackinnon <[hidden email]>:
>>
>> Is there a way for this to get back into 6.1 - so we can shoot for a
>> stable 6.x version that will last us for a year while 7.x is under
>> development?
>>
>> I’m not familiar with how point release are handled in Pharo, and I get
>> the impression that this is going to be a slightly rockier year as there
>> have been some pretty revolutionary changes made to get us here.
>>
>> As its a vm change does this mean we get 6.2 queued up somehow?
>>
>> Tim
>>
>> > On 13 Aug 2017, at 20:12, Stephane Ducasse <[hidden email]>
>> > wrote:
>> >
>> > Tx eliot.
>> >
>> >
>> > On Fri, Aug 11, 2017 at 12:55 AM, Eliot Miranda
>> > <[hidden email]> wrote:
>> >> Hi Andrei,
>> >>
>> >> On Thu, Aug 10, 2017 at 3:02 AM, Andrei Chis
>> >> <[hidden email]>
>> >> wrote:
>> >>>
>> >>>
>> >>> 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.
>> >>
>> >>
>> >> The plugin is now fixed; see VMMaker.oscog-eem.2262.  I'll generate
>> >> code
>> >> soon (am debugging something you're familiar with that takes several
>> >> hours
>> >> to run and don't want to generate sources while it's running).  But I'm
>> >> glad
>> >> you've found a better way!  This case creates 600k byte large integers
>> >> and
>> >> takes forever to run :-)
>> >>
>> >>>
>> >>> 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
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> _,,,^..^,,,_
>> >> best, Eliot
>> >
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

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

Ben Coman
In reply to this post by Tim Mackinnon


On Mon, Aug 14, 2017 at 4:49 PM, Tim Mackinnon <[hidden email]> wrote:
Is there a way for this to get back into 6.1 - so we can shoot for a stable 6.x version that will last us for a year while 7.x is under development?

I’m not familiar with how point release are handled in Pharo, and I get the impression that this is going to be a slightly rockier year as there have been some pretty revolutionary changes made to get us here.

As its a vm change does this mean we get 6.2 queued up somehow?

We don't (yet) have a massive-cyber-corp backer, so with limited resources there are only limited point releases - usually only one, half-way to two-thirds through the year.  But we already got 6.1, so I'm not sure affects things.  

Now the first rule is that fixes must go into the current dev branch and then backported.  So get it into Pharo 7 and queue it up for (maybe) 6.2.  

cheers -ben
 

Tim

> On 13 Aug 2017, at 20:12, Stephane Ducasse <[hidden email]> wrote:
>
> Tx eliot.
>
>
> On Fri, Aug 11, 2017 at 12:55 AM, Eliot Miranda <[hidden email]> wrote:
>> Hi Andrei,
>>
>> On Thu, Aug 10, 2017 at 3:02 AM, Andrei Chis <[hidden email]>
>> wrote:
>>>
>>>
>>> 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.
>>
>>
>> The plugin is now fixed; see VMMaker.oscog-eem.2262.  I'll generate code
>> soon (am debugging something you're familiar with that takes several hours
>> to run and don't want to generate sources while it's running).  But I'm glad
>> you've found a better way!  This case creates 600k byte large integers and
>> takes forever to run :-)
>>
>>>
>>> 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
>>>
>>
>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
>