[Vm-dev] [squeak-dev] Endless recursion: "String new: -1"

[Tobias Pape]

On 07.07.2016, at 23:23, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> 
> 
> 
> 
>> 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.

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