________________________________________________________________________
Applicable Environment
________________________________________________________________________
- Topic: stat() function never returns
- SDP: 6.4.1
- Target: Any supported target
________________________________________________________________________
Recommendation________________________________________________________________________
Sometimes a call to stat() within an application ends up getting
stuck forever and never returns. Attaching a debugger to the process
shows
ConnectAttach()
_connect_request()
_connect_request()
_connect_ctrl()
_connect_entry()
_connect()
_connect_combine()
stat()
A Kernel trace will likely show the call to ConnectAttach() Enter and then get pre-empted by an interrupt or something similar.
Taking further look into the system will show things like the pulse queue for your process is completely backed up.
What is happening is under the covers stat() calls
ConnectAttach(). ConnectAttach() will look for a free channel to use,
however the vectors that store the channels have a large amount of
pending pulses. The system will need to traverse these trying to find a
spare spot, however this takes a significant amount of time and CPU
resources to do. What ends up happening is that the time slice either
runs out or in the case described here an interrupt goes off and causes
the ConnectAttach() function to get preempted. So when the stat call
gets a chance to run again it has to start all over again traversing the
list.
What is misleading is that this is a memory issue where there is
not actually enough free spots in the fdcons and chancons vectors,
rather the issue is CPU horsepower to traverse these lists in the amount
of time available.
This problem occurs because there is a build of up pending
pulses, this can be a result of the thread in charge of receiving the
pulses is blocked due to another operation or semaphore/mutex preventing
the thread from running, or not handling pulses at all (e.g.
_NTO_CHF_DISCONNECT pulses).
To resolve this ensure that all pulses are processed and received within your application.
