Re: [squeak-dev] Endless recursion: "String new: -1"
Locked
Re: [squeak-dev] Endless recursion: "String new: -1"
 
|
Hi all (cc vm-dev) On 07.07.2016, at 14:28, David T. Lewis <[hidden email]> wrote: > I think the problem is in the primitive error code checking. The primitive > is failing with #'bad argument' but the fallback code attempts to handle it > as #'insufficient object memory'. It then tries to free some memory, fails > to correct the problem, and raises a "Space is low" notifier. > I noted that when we moved to Spur initially and I tried to fix tests. The AllocationTest failed, and I changed ec == #'insufficient object memory' ifTrue: to (ec == #'insufficient object memory' or: [ec == #'bad argument']) ifTrue: in Behavior>>#basicNew: Maybe that was an error? @Eliot, why does Spur return #'bad argument' instead of #'insufficient object memory' when too much memory is to be allocated? Best regards -Tobias > Dave > > > On Thu, Jul 07, 2016 at 09:23:14AM +0200, Levente Uzonyi wrote: >> Someone seems to have trimmed the versions in the changes file. In Squeak >> 4.4 Behavior >> #basicNew: had the following body: >> >> <primitive: 71> >> self isVariable ifFalse: >> [self error: self printString, ' cannot have variable sized >> instances']. >> (sizeRequested isInteger and: [sizeRequested >= 0]) ifTrue: >> ["arg okay; space must be low." >> OutOfMemory signal. >> ^ self basicNew: sizeRequested "retry if user proceeds"]. >> self primitiveFailed >> >> So, non-integer and negative arguments were primitive failures. >> >> Levente >> >> >> On Wed, 6 Jul 2016, David T. Lewis wrote: >> >>> On Wed, Jul 06, 2016 at 06:43:25AM -0700, marcel.taeumel wrote: >>>> Hi, there! >>>> >>>> Is it okay that there is an endless recursion when evaluating "String >>>> new: -1"? >>> >>> No, it is not okay. It should fail with a primitive failure. >>> >>> Dave >>> >>> >>>> >>>> ... >>>> ByteString class(Behavior)>>handleFailingFailingBasicNew: >>>> ByteString class(Behavior)>>handleFailingBasicNew: >>>> ByteString class(Behavior)>>basicNew: >>>> ByteString class(Behavior)>>handleFailingFailingBasicNew: >>>> ByteString class(Behavior)>>handleFailingBasicNew: >>>> ByteString class(Behavior)>>basicNew: >>>> ByteString class(Behavior)>>handleFailingFailingBasicNew: >>>> ByteString class(Behavior)>>handleFailingBasicNew: >>>> ByteString class(Behavior)>>basicNew: >>>> ... >>>> >>>> I would like to have an error signaled instead. Note that the -1 is just >>>> an >>>> example for a bad computation. The error I get is "Space is low" then. :-) >>>> >>>> >>>> Best, >>>> Marcel >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://forum.world.st/Endless-recursion-String-new-1-tp4905179.html >>>> Sent from the Squeak - Dev mailing list archive at Nabble.com. |
Re: [squeak-dev] Endless recursion: "String new: -1"
|
|
On Thu, Jul 7, 2016 at 5:42 AM, Tobias Pape <[hidden email]> wrote:
If it does, there's a bug. I'll go look.
_,,,^..^,,,_ best, Eliot |
Re: [squeak-dev] Endless recursion: "String new: -1"
|
|
In reply to this post by Tobias Pape
On Thu, Jul 7, 2016 at 5:42 AM, Tobias Pape <[hidden email]> wrote:
It doesn't. It answers bad argument for anything other than an integer in the range 0 to 2^32-1 or 0 to 2^64-1. I think your commit of topa 10/7/2015 20:41 for Behavior>>basicNew: is wrong, and should be reverted.
_,,,^..^,,,_ best, Eliot |
Re: [squeak-dev] Endless recursion: "String new: -1"
|
|
On 07.07.2016, at 18:44, Eliot Miranda <[hidden email]> wrote: > On Thu, Jul 7, 2016 at 5:42 AM, Tobias Pape <[hidden email]> wrote: > > Hi all > > (cc vm-dev) > On 07.07.2016, at 14:28, David T. Lewis <[hidden email]> wrote: > > > I think the problem is in the primitive error code checking. The primitive > > is failing with #'bad argument' but the fallback code attempts to handle it > > as #'insufficient object memory'. It then tries to free some memory, fails > > to correct the problem, and raises a "Space is low" notifier. > > > > I noted that when we moved to Spur initially and I tried to fix tests. > The AllocationTest failed, and I changed > > ec == #'insufficient object memory' ifTrue: > > to > (ec == #'insufficient object memory' or: [ec == #'bad argument']) ifTrue: > > in Behavior>>#basicNew: > > Maybe that was an error? > > @Eliot, why does Spur return #'bad argument' instead of #'insufficient object memory' when > too much memory is to be allocated? > > It doesn't. It answers bad argument for anything other than an integer in the range 0 to 2^32-1 or 0 to 2^64-1. But logically, it should return #'insufficient object memory' for > 2^64-1. Your change to return #'bad argument' with Spur broke AllocationTest>>#testOutOfMemorySignal which worked on pre-Spur Cog and interpreter. Best regards -Tobias PS: the test that predates spur: testOutOfMemorySignal "Ensure that OOM is signaled eventually" | sz | sz := 512*1024*1024. "work around the 1GB alloc bug" self should:[(1 to: 2000) collect:[:i| Array new: sz]] raise: OutOfMemory. "Call me when this test fails, I want your machine" sz := 1024*1024*1024*1024. self should:[Array new: sz] raise: OutOfMemory. The test failed, technically you have to call David lewis now ;) > I think your commit of topa 10/7/2015 20:41 for Behavior>>basicNew: is wrong, and should be reverted. > > > Best regards > -Tobias > > > > Dave > > > > > > On Thu, Jul 07, 2016 at 09:23:14AM +0200, Levente Uzonyi wrote: > >> Someone seems to have trimmed the versions in the changes file. In Squeak > >> 4.4 Behavior >> #basicNew: had the following body: > >> > >> <primitive: 71> > >> self isVariable ifFalse: > >> [self error: self printString, ' cannot have variable sized > >> instances']. > >> (sizeRequested isInteger and: [sizeRequested >= 0]) ifTrue: > >> ["arg okay; space must be low." > >> OutOfMemory signal. > >> ^ self basicNew: sizeRequested "retry if user proceeds"]. > >> self primitiveFailed > >> > >> So, non-integer and negative arguments were primitive failures. > >> > >> Levente > >> > >> > >> On Wed, 6 Jul 2016, David T. Lewis wrote: > >> > >>> On Wed, Jul 06, 2016 at 06:43:25AM -0700, marcel.taeumel wrote: > >>>> Hi, there! > >>>> > >>>> Is it okay that there is an endless recursion when evaluating "String > >>>> new: -1"? > >>> > >>> No, it is not okay. It should fail with a primitive failure. > >>> > >>> Dave > >>> > >>> > >>>> > >>>> ... > >>>> ByteString class(Behavior)>>handleFailingFailingBasicNew: > >>>> ByteString class(Behavior)>>handleFailingBasicNew: > >>>> ByteString class(Behavior)>>basicNew: > >>>> ByteString class(Behavior)>>handleFailingFailingBasicNew: > >>>> ByteString class(Behavior)>>handleFailingBasicNew: > >>>> ByteString class(Behavior)>>basicNew: > >>>> ByteString class(Behavior)>>handleFailingFailingBasicNew: > >>>> ByteString class(Behavior)>>handleFailingBasicNew: > >>>> ByteString class(Behavior)>>basicNew: > >>>> ... > >>>> > >>>> I would like to have an error signaled instead. Note that the -1 is just > >>>> an > >>>> example for a bad computation. The error I get is "Space is low" then. :-) > >>>> > >>>> > >>>> Best, > >>>> Marcel > >>>> > >>>> > >>>> |
Re: [squeak-dev] Endless recursion: "String new: -1"
|
|
On Thu, Jul 7, 2016 at 10:27 AM, Tobias Pape <[hidden email]> wrote:
I disagree. There are implementation limits. So answering #'unsupported operation' or #'bad argument 's as logical and defensible as #'out of memory' and actually truer. The VM does /not/ try and allocate memory beyond the address space size. So actually the failure for > the range 0 to 2^32-1 or 0 to 2^64-1 as #'out of memory' is untrue; the reason is not because the ysste, os out of memory; the reason is that this is a bad argument, outside of the valid range of the primitive. Your change to return #'bad argument' with Spur broke AllocationTest>>#testOutOfMemorySignal which That's a problem with the test.
Sure. IMO this should be checking Smalltalk wordSize and choosing a value which is within the available address space. Don't make the tail wag the dog.
_,,,^..^,,,_ best, Eliot |
Re: [squeak-dev] Endless recursion: "String new: -1"
|
|
On 07.07.2016, at 19:48, Eliot Miranda <[hidden email]> wrote: > On Thu, Jul 7, 2016 at 10:27 AM, Tobias Pape <[hidden email]> wrote: > > > On 07.07.2016, at 18:44, Eliot Miranda <[hidden email]> wrote: > > > On Thu, Jul 7, 2016 at 5:42 AM, Tobias Pape <[hidden email]> wrote: > > > > Hi all > > > > (cc vm-dev) > > On 07.07.2016, at 14:28, David T. Lewis <[hidden email]> wrote: > > > > > I think the problem is in the primitive error code checking. The primitive > > > is failing with #'bad argument' but the fallback code attempts to handle it > > > as #'insufficient object memory'. It then tries to free some memory, fails > > > to correct the problem, and raises a "Space is low" notifier. > > > > > > > I noted that when we moved to Spur initially and I tried to fix tests. > > The AllocationTest failed, and I changed > > > > ec == #'insufficient object memory' ifTrue: > > > > to > > (ec == #'insufficient object memory' or: [ec == #'bad argument']) ifTrue: > > > > in Behavior>>#basicNew: > > > > Maybe that was an error? > > > > @Eliot, why does Spur return #'bad argument' instead of #'insufficient object memory' when > > too much memory is to be allocated? > > > > It doesn't. It answers bad argument for anything other than an integer in the range 0 to 2^32-1 or 0 to 2^64-1. > > But logically, it should return #'insufficient object memory' for > 2^64-1. > > I disagree. There are implementation limits. So answering #'unsupported operation' or #'bad argument 's as logical and defensible as #'out of memory' and actually truer. The VM does /not/ try and allocate memory beyond the address space size. So actually the failure for > the range 0 to 2^32-1 or 0 to 2^64-1 as #'out of memory' is untrue; the reason is not because the ysste, os out of memory; the reason is that this is a bad argument, outside of the valid range of the primitive. Why it is a problem to answer "I want a gazillion bytes of memory" with "that's too much" instead of "I don't understand you" ? It's Smalltalk, after all, not C. Best regards -Tobias > > > Your change to return #'bad argument' with Spur broke AllocationTest>>#testOutOfMemorySignal which > worked on pre-Spur Cog and interpreter. > > That's a problem with the test. > > > Best regards > -Tobias > > PS: the test that predates spur: > > testOutOfMemorySignal > "Ensure that OOM is signaled eventually" > | sz | > sz := 512*1024*1024. "work around the 1GB alloc bug" > self should:[(1 to: 2000) collect:[:i| Array new: sz]] raise: OutOfMemory. > > "Call me when this test fails, I want your machine" > sz := 1024*1024*1024*1024. > self should:[Array new: sz] raise: OutOfMemory. > > The test failed, technically you have to call David lewis now ;) > > Sure. IMO this should be checking Smalltalk wordSize and choosing a value which is within the available address space. Don't make the tail wag the dog. > > > > > > I think your commit of topa 10/7/2015 20:41 for Behavior>>basicNew: is wrong, and should be reverted. > > > > > > Best regards > > -Tobias > > > > > > > Dave > > > > > > > > > On Thu, Jul 07, 2016 at 09:23:14AM +0200, Levente Uzonyi wrote: > > >> Someone seems to have trimmed the versions in the changes file. In Squeak > > >> 4.4 Behavior >> #basicNew: had the following body: > > >> > > >> <primitive: 71> > > >> self isVariable ifFalse: > > >> [self error: self printString, ' cannot have variable sized > > >> instances']. > > >> (sizeRequested isInteger and: [sizeRequested >= 0]) ifTrue: > > >> ["arg okay; space must be low." > > >> OutOfMemory signal. > > >> ^ self basicNew: sizeRequested "retry if user proceeds"]. > > >> self primitiveFailed > > >> > > >> So, non-integer and negative arguments were primitive failures. > > >> > > >> Levente > > >> > > >> > > >> On Wed, 6 Jul 2016, David T. Lewis wrote: > > >> > > >>> On Wed, Jul 06, 2016 at 06:43:25AM -0700, marcel.taeumel wrote: > > >>>> Hi, there! > > >>>> > > >>>> Is it okay that there is an endless recursion when evaluating "String > > >>>> new: -1"? > > >>> > > >>> No, it is not okay. It should fail with a primitive failure. > > >>> > > >>> Dave > > >>> > > >>> > > >>>> > > >>>> ... > > >>>> ByteString class(Behavior)>>handleFailingFailingBasicNew: > > >>>> ByteString class(Behavior)>>handleFailingBasicNew: > > >>>> ByteString class(Behavior)>>basicNew: > > >>>> ByteString class(Behavior)>>handleFailingFailingBasicNew: > > >>>> ByteString class(Behavior)>>handleFailingBasicNew: > > >>>> ByteString class(Behavior)>>basicNew: > > >>>> ByteString class(Behavior)>>handleFailingFailingBasicNew: > > >>>> ByteString class(Behavior)>>handleFailingBasicNew: > > >>>> ByteString class(Behavior)>>basicNew: > > >>>> ... > > >>>> > > >>>> I would like to have an error signaled instead. Note that the -1 is just > > >>>> an > > >>>> example for a bad computation. The error I get is "Space is low" then. :-) > > >>>> > > >>>> > > >>>> Best, > > >>>> Marcel > > >>>> > > >>>> > > >>>> |
Re: [squeak-dev] Endless recursion: "String new: -1"
|
|
In reply to this post by Eliot Miranda-2
On 07.07.2016, at 19:48, Eliot Miranda <[hidden email]> wrote: > I disagree. There are implementation limits. So answering #'unsupported operation' or #'bad argument 's as logical and defensible as #'out of memory' and actually truer. The VM does /not/ try and allocate memory beyond the address space size. So actually the failure for > the range 0 to 2^32-1 or 0 to 2^64-1 as #'out of memory' is untrue; the reason is not because the ysste, os out of memory; the reason is that this is a bad argument, outside of the valid range of the primitive. Disregarding my other tongue in cheek reply, does that mean, the test worked in older images/Vms, because those treated every failure due to arguments (be it size or kind) as 'out of memory'? Best regards -Tobias |
Re: [squeak-dev] Endless recursion: "String new: -1"
|
|
In reply to this post by Tobias Pape
> On Jul 7, 2016, at 1:48 PM, Tobias Pape <[hidden email]> wrote: > > > >> On 07.07.2016, at 19:48, Eliot Miranda <[hidden email]> wrote: >> >> On Thu, Jul 7, 2016 at 10:27 AM, Tobias Pape <[hidden email]> wrote: >> >> >>> On 07.07.2016, at 18:44, Eliot Miranda <[hidden email]> wrote: >>> >>> On Thu, Jul 7, 2016 at 5:42 AM, Tobias Pape <[hidden email]> wrote: >>> >>> Hi all >>> >>> (cc vm-dev) >>>> On 07.07.2016, at 14:28, David T. Lewis <[hidden email]> wrote: >>>> >>>> I think the problem is in the primitive error code checking. The primitive >>>> is failing with #'bad argument' but the fallback code attempts to handle it >>>> as #'insufficient object memory'. It then tries to free some memory, fails >>>> to correct the problem, and raises a "Space is low" notifier. >>> >>> I noted that when we moved to Spur initially and I tried to fix tests. >>> The AllocationTest failed, and I changed >>> >>> ec == #'insufficient object memory' ifTrue: >>> >>> to >>> (ec == #'insufficient object memory' or: [ec == #'bad argument']) ifTrue: >>> >>> in Behavior>>#basicNew: >>> >>> Maybe that was an error? >>> >>> @Eliot, why does Spur return #'bad argument' instead of #'insufficient object memory' when >>> too much memory is to be allocated? >>> >>> It doesn't. It answers bad argument for anything other than an integer in the range 0 to 2^32-1 or 0 to 2^64-1. >> >> But logically, it should return #'insufficient object memory' for > 2^64-1. >> >> I disagree. There are implementation limits. So answering #'unsupported operation' or #'bad argument 's as logical and defensible as #'out of memory' and actually truer. The VM does /not/ try and allocate memory beyond the address space size. So actually the failure for > the range 0 to 2^32-1 or 0 to 2^64-1 as #'out of memory' is untrue; the reason is not because the ysste, os out of memory; the reason is that this is a bad argument, outside of the valid range of the primitive. > > Why it is a problem to answer > "I want a gazillion bytes of memory" > with > "that's too much" > instead of > "I don't understand you" > ? That's not what the error codes mean. #'out of memory' means "I can't find that much free memory". #'bad argument" means a variety of things from out-of-bounds (cf at:) to wring class. > It's Smalltalk, after all, not C. I'm sorry. I'm not following. > > Best regards > -Tobias > > >> >> >> Your change to return #'bad argument' with Spur broke AllocationTest>>#testOutOfMemorySignal which >> worked on pre-Spur Cog and interpreter. >> >> That's a problem with the test. >> >> >> Best regards >> -Tobias >> >> PS: the test that predates spur: >> >> testOutOfMemorySignal >> "Ensure that OOM is signaled eventually" >> | sz | >> sz := 512*1024*1024. "work around the 1GB alloc bug" >> self should:[(1 to: 2000) collect:[:i| Array new: sz]] raise: OutOfMemory. >> >> "Call me when this test fails, I want your machine" >> sz := 1024*1024*1024*1024. >> self should:[Array new: sz] raise: OutOfMemory. >> >> The test failed, technically you have to call David lewis now ;) >> >> Sure. IMO this should be checking Smalltalk wordSize and choosing a value which is within the available address space. Don't make the tail wag the dog. >> >> >> >> >>> I think your commit of topa 10/7/2015 20:41 for Behavior>>basicNew: is wrong, and should be reverted. >>> >>> >>> Best regards >>> -Tobias >>> >>> >>>> Dave >>>> >>>> >>>>> On Thu, Jul 07, 2016 at 09:23:14AM +0200, Levente Uzonyi wrote: >>>>> Someone seems to have trimmed the versions in the changes file. In Squeak >>>>> 4.4 Behavior >> #basicNew: had the following body: >>>>> >>>>> <primitive: 71> >>>>> self isVariable ifFalse: >>>>> [self error: self printString, ' cannot have variable sized >>>>> instances']. >>>>> (sizeRequested isInteger and: [sizeRequested >= 0]) ifTrue: >>>>> ["arg okay; space must be low." >>>>> OutOfMemory signal. >>>>> ^ self basicNew: sizeRequested "retry if user proceeds"]. >>>>> self primitiveFailed >>>>> >>>>> So, non-integer and negative arguments were primitive failures. >>>>> >>>>> Levente >>>>> >>>>> >>>>>> On Wed, 6 Jul 2016, David T. Lewis wrote: >>>>>> >>>>>>> On Wed, Jul 06, 2016 at 06:43:25AM -0700, marcel.taeumel wrote: >>>>>>> Hi, there! >>>>>>> >>>>>>> Is it okay that there is an endless recursion when evaluating "String >>>>>>> new: -1"? >>>>>> >>>>>> No, it is not okay. It should fail with a primitive failure. >>>>>> >>>>>> Dave >>>>>> >>>>>> >>>>>>> >>>>>>> ... >>>>>>> ByteString class(Behavior)>>handleFailingFailingBasicNew: >>>>>>> ByteString class(Behavior)>>handleFailingBasicNew: >>>>>>> ByteString class(Behavior)>>basicNew: >>>>>>> ByteString class(Behavior)>>handleFailingFailingBasicNew: >>>>>>> ByteString class(Behavior)>>handleFailingBasicNew: >>>>>>> ByteString class(Behavior)>>basicNew: >>>>>>> ByteString class(Behavior)>>handleFailingFailingBasicNew: >>>>>>> ByteString class(Behavior)>>handleFailingBasicNew: >>>>>>> ByteString class(Behavior)>>basicNew: >>>>>>> ... >>>>>>> >>>>>>> I would like to have an error signaled instead. Note that the -1 is just >>>>>>> an >>>>>>> example for a bad computation. The error I get is "Space is low" then. :-) >>>>>>> >>>>>>> >>>>>>> Best, >>>>>>> Marcel > > > |
Re: [squeak-dev] Endless recursion: "String new: -1"
|
|
In reply to this post by Tobias Pape
> On Jul 7, 2016, at 2:03 PM, Tobias Pape <[hidden email]> wrote: > > > >> On 07.07.2016, at 19:48, Eliot Miranda <[hidden email]> wrote: >> >> I disagree. There are implementation limits. So answering #'unsupported operation' or #'bad argument 's as logical and defensible as #'out of memory' and actually truer. The VM does /not/ try and allocate memory beyond the address space size. So actually the failure for > the range 0 to 2^32-1 or 0 to 2^64-1 as #'out of memory' is untrue; the reason is not because the ysste, os out of memory; the reason is that this is a bad argument, outside of the valid range of the primitive. > > Disregarding my other tongue in cheek reply, > does that mean, the test worked in older images/Vms, because those treated every failure due to > arguments (be it size or kind) as 'out of memory'? Not quite. The code used to work because there were no primitive error codes and so u teepee ration of wha was wrong was left up to the image code, inferring (sometimes inaccurately) what had failed from the arguments. > > Best regards > -Tobias |
Re: [squeak-dev] Endless recursion: "String new: -1"
|
|
In reply to this post by Eliot Miranda-2
On 07.07.2016, at 23:23, Eliot Miranda <[hidden email]> wrote: > > > > >> On Jul 7, 2016, at 1:48 PM, Tobias Pape <[hidden email]> wrote: >> >> >> >>> On 07.07.2016, at 19:48, Eliot Miranda <[hidden email]> wrote: >>> >>> On Thu, Jul 7, 2016 at 10:27 AM, Tobias Pape <[hidden email]> wrote: >>> >>> >>>> On 07.07.2016, at 18:44, Eliot Miranda <[hidden email]> wrote: >>>> >>>> On Thu, Jul 7, 2016 at 5:42 AM, Tobias Pape <[hidden email]> wrote: >>>> >>>> Hi all >>>> >>>> (cc vm-dev) >>>>> On 07.07.2016, at 14:28, David T. Lewis <[hidden email]> wrote: >>>>> >>>>> I think the problem is in the primitive error code checking. The primitive >>>>> is failing with #'bad argument' but the fallback code attempts to handle it >>>>> as #'insufficient object memory'. It then tries to free some memory, fails >>>>> to correct the problem, and raises a "Space is low" notifier. >>>> >>>> I noted that when we moved to Spur initially and I tried to fix tests. >>>> The AllocationTest failed, and I changed >>>> >>>> ec == #'insufficient object memory' ifTrue: >>>> >>>> to >>>> (ec == #'insufficient object memory' or: [ec == #'bad argument']) ifTrue: >>>> >>>> in Behavior>>#basicNew: >>>> >>>> Maybe that was an error? >>>> >>>> @Eliot, why does Spur return #'bad argument' instead of #'insufficient object memory' when >>>> too much memory is to be allocated? >>>> >>>> It doesn't. It answers bad argument for anything other than an integer in the range 0 to 2^32-1 or 0 to 2^64-1. >>> >>> But logically, it should return #'insufficient object memory' for > 2^64-1. >>> >>> I disagree. There are implementation limits. So answering #'unsupported operation' or #'bad argument 's as logical and defensible as #'out of memory' and actually truer. The VM does /not/ try and allocate memory beyond the address space size. So actually the failure for > the range 0 to 2^32-1 or 0 to 2^64-1 as #'out of memory' is untrue; the reason is not because the ysste, os out of memory; the reason is that this is a bad argument, outside of the valid range of the primitive. >> >> Why it is a problem to answer >> "I want a gazillion bytes of memory" >> with >> "that's too much" >> instead of >> "I don't understand you" >> ? > > That's not what the error codes mean. #'out of memory' means "I can't find that much free memory". #'bad argument" means a variety of things from out-of-bounds (cf at:) to wring class. Ah. BTW: do we have some more comprehensive explantion for the errorcodes? (that would maybe be good to auto-generate user information) > >> It's Smalltalk, after all, not C. > > I'm sorry. I'm not following. Nevermind :) > >> >> Best regards >> -Tobias >> >> >>> >>> >>> Your change to return #'bad argument' with Spur broke AllocationTest>>#testOutOfMemorySignal which >>> worked on pre-Spur Cog and interpreter. >>> >>> That's a problem with the test. >>> >>> >>> Best regards >>> -Tobias >>> >>> PS: the test that predates spur: >>> >>> testOutOfMemorySignal >>> "Ensure that OOM is signaled eventually" >>> | sz | >>> sz := 512*1024*1024. "work around the 1GB alloc bug" >>> self should:[(1 to: 2000) collect:[:i| Array new: sz]] raise: OutOfMemory. >>> >>> "Call me when this test fails, I want your machine" >>> sz := 1024*1024*1024*1024. >>> self should:[Array new: sz] raise: OutOfMemory. >>> >>> The test failed, technically you have to call David lewis now ;) >>> >>> Sure. IMO this should be checking Smalltalk wordSize and choosing a value which is within the available address space. Don't make the tail wag the dog. >>> >>> >>> >>> >>>> I think your commit of topa 10/7/2015 20:41 for Behavior>>basicNew: is wrong, and should be reverted. >>>> >>>> >>>> Best regards >>>> -Tobias >>>> >>>> >>>>> Dave |
Re: [squeak-dev] Endless recursion: "String new: -1"
|
|
In reply to this post by Eliot Miranda-2
On 07.07.2016, at 23:24, Eliot Miranda <[hidden email]> wrote: > > > >> On Jul 7, 2016, at 2:03 PM, Tobias Pape <[hidden email]> wrote: >> >> >> >>> On 07.07.2016, at 19:48, Eliot Miranda <[hidden email]> wrote: >>> >>> I disagree. There are implementation limits. So answering #'unsupported operation' or #'bad argument 's as logical and defensible as #'out of memory' and actually truer. The VM does /not/ try and allocate memory beyond the address space size. So actually the failure for > the range 0 to 2^32-1 or 0 to 2^64-1 as #'out of memory' is untrue; the reason is not because the ysste, os out of memory; the reason is that this is a bad argument, outside of the valid range of the primitive. >> >> Disregarding my other tongue in cheek reply, >> does that mean, the test worked in older images/Vms, because those treated every failure due to >> arguments (be it size or kind) as 'out of memory'? > > Not quite. The code used to work because there were no primitive error codes and so u teepee ration of wha was wrong was left up to the image code, inferring (sometimes inaccurately) what had failed from the arguments. That makes sense. Thanks -Tobias > >> >> Best regards >> -Tobias |
Re: [squeak-dev] Endless recursion: "String new: -1"
|
|
In reply to this post by Tobias Pape
On Thu, Jul 07, 2016 at 11:03:43PM +0200, Tobias Pape wrote: > > > On 07.07.2016, at 19:48, Eliot Miranda <[hidden email]> wrote: > > > I disagree. There are implementation limits. So answering #'unsupported operation' or #'bad argument 's as logical and defensible as #'out of memory' and actually truer. The VM does /not/ try and allocate memory beyond the address space size. So actually the failure for > the range 0 to 2^32-1 or 0 to 2^64-1 as #'out of memory' is untrue; the reason is not because the ysste, os out of memory; the reason is that this is a bad argument, outside of the valid range of the primitive. > > Disregarding my other tongue in cheek reply, > does that mean, the test worked in older images/Vms, because those treated every failure due to > arguments (be it size or kind) as 'out of memory'? > No, in Squeak 4.5 trying to recover from the 'out of memory' condition is done if and only if the sizeRequested was a positive integer, otherwise it is a primitiveFailed condition. ByteString class>>basicNew: sizeRequested "Primitive. Answer an instance of this class with the number of indexable variables specified by the argument, sizeRequested. Fail if this class is not indexable or if the argument is not a positive Integer, or if there is not enough memory available. Essential. See Object documentation whatIsAPrimitive." <primitive: 71> self isVariable ifFalse: [self error: self printString, ' cannot have variable sized instances']. (sizeRequested isInteger and: [sizeRequested >= 0]) ifTrue: ["arg okay; space must be low." OutOfMemory signal. ^ self basicNew: sizeRequested "retry if user proceeds"]. self primitiveFailed Dave |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |