Re: [Vm-dev] vm crash when using rairedTo: with fractions
Locked
Re: [Vm-dev] vm crash when using rairedTo: with fractions
 
|
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 |
Re: [Vm-dev] vm crash when using rairedTo: with fractions
|
|
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 > |
Re: [Vm-dev] vm crash when using rairedTo: with fractions
|
|
Hi Tim, I'd say: is this a showstopper?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? |
Re: [Vm-dev] vm crash when using rairedTo: with fractions
|
|
It’s a fair point - I guess if enough things crop up, then a 6.2 release gets contemplated.
Tim
|
Re: [Vm-dev] vm crash when using rairedTo: with fractions
|
|
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 >> > >> >> > |
|
|
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? 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
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |