On 28/11/2018 12:33, Michael Grunditz wrote:
> On Wed, 28 Nov 2018 at 11:42, Lee Noar <leenoar@sky.com> wrote:
>>
>> On 26/11/2018 15:53, Michael Grunditz wrote:
>>> void* mmapResult = mmap(NULL, BLOCK_SIZE + extra, PROT_READ |
>>> PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0);
>>>
>>> Fails with : Cannot allocate ram. BLOCK_SIZE is 64k and extra is 0.
>>>
>>> This error is from my "new" OWB codebase. Exactly the same mmap
>>> succeeds in old code.
>>>
>>> I have experimented with wimpslot , but no luck.
>>
>> That error is not from Unixlib. Best thing to do is to search your
>> code base for the error and see what leads to it being generated.
>>
>> Lee.
>
> memalign also fails in the same way. How can I allocate memory inside
> a shared lib? The same code works just find in a standalone file. btw
> it is "perror" that prints the errmessage,
Ok, there are 2 reasons why mmap can fail:
1) OS_DynamicArea returns an error. This could happen if the memory
request was too big, for example, but seems unlikely.
2) Only 8 mmap sections at any one time are supported. That includes
those that malloc may create for large requests, however, malloc
falls back to its normal allocation routines if there are already
8 mmaps. Attempting to create a 9th will result in ENOMEM.
memalign uses malloc and so will suffer the same limitations.
I usually replace any mmap calls with my own dynamic area memory
allocator.
Lee.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
No comments:
Post a Comment