> -----Original Message-----
> From: Sebastian Huber <sebastian.hu...@embedded-brains.de>
> Sent: Wednesday, June 23, 2021 11:47 AM
> To: Sommer, Jan <jan.som...@dlr.de>; users@rtems.org
> Subject: Re: Heap allocation for libbsd overwrites IMFS
>
>
>
> On 23/06/2021 10:32, jan.som...@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.hu...@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/
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
