Heap allocation for libbsd overwrites IMFS

Gedare Bloom gedare at rtems.org
Wed Jun 23 15:54:35 UTC 2021


On Wed, Jun 23, 2021 at 9:52 AM <Jan.Sommer at dlr.de> wrote:
>
>
>
> > -----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.
>
please do

> > > 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/
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users


More information about the users mailing list