On 27/4/19 10:23 pm, dufa...@hda.com wrote: > This is because RTL locks out heap operations. For ELF > files /rtems_rtl_alloc_lock() /calls /rtem_rtl_alloc_heap() /and that > calls /_RTEMS_Lock_allocator()/ which locks the heap. Then RTL calls /read() > /and the NFS threads try to use the heap. > > (gdb) up > #1 0x00135394 in rtems_rtl_alloc_lock () > at > /home/dufault/development/rtems/kernel/rtems/c/src/../../cpukit/libdl/rtl-allocator.c:119 > 119 rtl->allocator.allocator (RTEMS_RTL_ALLOC_LOCK, > (gdb) print rtl->allocator.allocator > $469 = (rtems_rtl_allocator) 0x1357c5 <rtems_rtl_alloc_heap> > (gdb)
Awesome investigation. I will take a look at the use of the allocator lock. The lock is being held in an attempt to make sure the allocation of the text section and the veneers are as close as possible. The veneer needs to located in a place where it can be reached. If the allocator lock is being held and NFS is using it while being used then we will deadlock. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
