On Wed, Jun 23, 2021 at 9:52 AM <jan.som...@dlr.de> wrote: > > > > > -----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. > 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.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 _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
