test for rtems_workspace_greedy_allocate

[Sebastian Huber]

On 08/02/2021 05:51, Chris Johns wrote:

> On 8/2/21 2:41 pm, Chris Johns wrote:
>> Hello,
>>
>> I see the call `rtems_workspace_greedy_allocate` is in `src/rtems` and publicly
>> available via the installed header file `rtems/support.h`.
> Sorry the code is libcsupport.
>
>> Are there tests for this and similar support calls?
>>
>> I ask because tests in rtems.git and rtems-libbsd.git testsuites depend on this
>> call and it appears to be broken on psim and PowerPC hardware. Recent psim test
>> results from Joel show `spprivenv01.exe` failing and I think it is
>> `rtems_workspace_greedy_allocate` or friends that maybe the issue ..
>>
>> https://lists.rtems.org/pipermail/build/2021-February/025169.html
>
> The in the test after calling greedy ...
>
> https://git.rtems.org/rtems/tree/testsuites/sptests/spprivenv01/init.c#n58
>
> ... calloc ends up being called and the first alloc fails however the allocator
> calls `rtems_malloc_extend_handler` and that ends up in the `sbrk` call in
> bsps/powerpc/shared/start/sbrk.c.
>
> Should the greedy call consume all memory that could be allocated and so does
> the extend handler needs to be called until it has been exhausted as well?

We already have a ticket for this:


https://devel.rtems.org/ticket/3982

I am not sure how to fix this. Maybe we should force the sbrk() support 
to first give us all the memory of the system. Another approach is to 
remove the sbrk() support. What is the benefit of it?

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/