You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by GitBox <gi...@apache.org> on 2020/01/21 17:21:57 UTC

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

patacongo commented 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.
   
   The latter case occurs 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 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.
   

----------------------------------------------------------------
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