Heap allocation for libbsd overwrites IMFS

[Jan.Sommer at dlr.de]

> -----Original Message-----
> From: Sebastian Huber <sebastian.huber at embedded-brains.de>
> Sent: Wednesday, June 23, 2021 11:47 AM
> To: Sommer, Jan <Jan.Sommer at dlr.de>; users at rtems.org
> Subject: Re: Heap allocation for libbsd overwrites IMFS
> 
> 
> 
> On 23/06/2021 10:32, Jan.Sommer at dlr.de wrote:
> > One of our applications for the Zedboard fails with fatal error after the
> setup of the network stack in libbsd.
> > So far I traced it down to the point that the memory allocation for libbsd
> overwrites parts of the IMFS of rtems.
> > When opening device files later this will lead to the crash.
> > The backtrace looks like this for the bad allocation looks like this:
> > _Heap_Block_split	../../../../../c/src/../../cpukit/score/src/heap.c:313
> 	0x10dd58
> > _Heap_Block_allocate_from_begin
> 	../../../../../c/src/../../cpukit/score/src/heap.c:378	0x10dfd6
> > _Heap_Block_allocate
> 	../../../../../c/src/../../cpukit/score/src/heap.c:465	0x10dfd6
> > _Heap_Allocate_aligned_with_boundary
> 	../../../../../c/src/../../cpukit/score/src/heapallocate.c:265
> 	0x10e19c
> > rtems_heap_allocate_aligned_with_boundary
> 	../../../../../c/src/../../cpukit/libcsupport/src/malloc_deferred.c:92
> 	0x10962e
> > malloc	../../../../../c/src/../../cpukit/libcsupport/src/malloc.c:39
> 	0x10950e
> > _bsd_malloc	../../rtemsbsd/rtems/rtems-kernel-malloc.c:80
> 	0x170048
> > [more libbsd]
> > ifconfig	../../freebsd/sbin/ifconfig/ifconfig.c:1024	0x1724fa
> >
> 
> You probably have a general memory corruption issue. As a first step I would
> enable RTEMS_DEBUG = True to enable the heap protection. This could help
> to debug the issue.
> 

With this enabled a few asserts failed during early system initialization which were not related to our problem.
I could post the points where this happened, but I don't know enough about the internals to fix them.

> > With 1 GiB of RAM, available memory shouldn't be a problem.
> > At the moment we have configured the system with
> CONFIGURE_UNLIMITED_OBJECTS and
> CONFIGURE_UNIFIED_WORK_AREAS.
> 
> This is fine.
> 

Yes, turns out the rtems_bsd_initialize would blow the stack of the init task and then the trouble starts.
I now increased the init task's stack size to the same level as the normal user tasks and enabled the stack checker.

Thanks,

    Jan

> > Maybe that is not right in this case. Are there any suggestions how to
> better configure the system?
> > I found CONFIGURE_MEMORY_OVERHEAD in the docs, but I am not so
> sure how to use it or if it would help.
> 
> No, it would not help.
> 
> --
> 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/