Run time linker allocator locking hangs RTEMS

[dufault at hda.com]

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 <chrisj at rtems.org> wrote:
> 
> On 27/4/19 10:23 pm, dufault at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190428/d3828c67/attachment-0002.html>