[GitHub] [incubator-nuttx] patacongo edited a comment on issue #136: Hard fault in networking stack.

[GitBox <gi...@apache.org>]

patacongo edited a comment on issue #136: Hard fault in networking stack.
URL: https://github.com/apache/incubator-nuttx/issues/136#issuecomment-576787858
 
 
   "R15 is inside _net_timedwait and R14 is inside nxsem_wait."
   That is the classic example of memory corruption.  That usually occurs because of a stack overrun or sometimes from using a bad memory location.
   
   In this case, you are looking at the VICTIM of the corruption, not the CULPRIT that caused the corruption.  This classic failure occurs like this:
   
   - Task A, the VICTIM,  calls nxsem_wait() and is suspended, perhaps for a long period of time.
   - During that long period of time, Task B, the CULPRIT, runs and exceeds it stack limit, clobbering task resources of the VICTIM.
   - When the victim is restarted in nxsem_wait(), it crashes immediately because its stack or some other resource has been corrupted.
   
   The usually fix that works 80% of the time is to increase the stack size of Task B, the CULPRIT or, sometimes Task A, the VICTIM.
   
   Task A's stack must be increased in the case when Task A is both the VICTIM and CUPRIT.  This happens when Task A's stack is too small so when it is suspended, its critical stack area hold the current state lies outside of its stack limits and in some other tasks memory memory space.  The failure scenario is the same as above except that Task B is not the CULPRIT.  It innocently clobbers Task A's stack.
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services