I think you might need to do two passes if that’s straight-forward. Then you can count, lock, allocate, unlock, read.
> On Apr 27, 2019, at 22:09 , Chris Johns <chr...@rtems.org> wrote: > > 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 Peter ----------------- Peter Dufault HD Associates, Inc. Software and System Engineering This email is delivered through the public internet using protocols subject to interception and tampering.
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
