[Vm-dev] [squeak-dev] Endless recursion: "String new: -1"
Eliot Miranda
eliot.miranda at gmail.com
Thu Jul 7 21:23:25 UTC 2016
> On Jul 7, 2016, at 1:48 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
>
>
>
>> On 07.07.2016, at 19:48, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>
>> On Thu, Jul 7, 2016 at 10:27 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
>>
>>
>>> On 07.07.2016, at 18:44, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>>
>>> On Thu, Jul 7, 2016 at 5:42 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
>>>
>>> Hi all
>>>
>>> (cc vm-dev)
>>>> On 07.07.2016, at 14:28, David T. Lewis <lewis at mail.msen.com> 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
>
>
>
More information about the Vm-dev
mailing list