<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If you hit this break point, try to use<br>bt<br>and then set a conditional break point to the offending function, reset<br>the target, and run again.</blockquote>I will use this. Thanks again.<div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It depends on the correctness of the program call stack though, so you may on<br>occasion find the bt is corrupt/fails.</blockquote><div>Yes, That is exactly what happened. Why does this happen though? What is meant by backtrace or the function call stack being corrupted? How can a stack that stores the name of series of function that call one another get corrupt?</div><div><br></div><div>------------------------------------------------------------    </div>Thread 1 hit Breakpoint 2, _ARMV4_Exception_data_abort_default () at /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/cpu/arm/armv4-exception-default.S:70<br>70              sub     sp, #MORE_CONTEXT_SIZE<br>(gdb) bt<br>#0  _ARMV4_Exception_data_abort_default () at /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/cpu/arm/armv4-exception-default.S:70<br>#1  0x00118bfe in _Scheduler_strong_APA_Get_lowest_scheduled (context=0x200620 <_Configuration_Scheduler_strong_APA_dflt>, filter_base=0x201910 <_RTEMS_tasks_Objects+600>) at /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/schedulerstrongapa.c:288<br>Backtrace stopped: previous frame inner to this frame (corrupt stack?)</div><div>------------------------------------------------------------<br><div> </div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 11, 2020 at 6:45 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Aug 11, 2020 at 4:30 AM Sebastian Huber<br>
<<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
><br>
> On 11/08/2020 11:40, Richi Dubey wrote:<br>
> > (gdb) continue<br>
> > Continuing.<br>
> ><br>
> > Thread 1 hit Breakpoint 2, _ARMV4_Exception_data_abort_default () at<br>
> > /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/cpu/arm/armv4-exception-default.S:70<br>
><br>
> If you hit this break point, try to use<br>
><br>
> bt<br>
><br>
> and then set a conditional break point to the offending function, reset<br>
> the target, and run again.<br>
><br>
<br>
Yes, the backtrace is most important at this point, because you are<br>
still trying to figure out how you got to the exception. It depends on<br>
the correctness of the program call stack though, so you may on<br>
occasion find the bt is corrupt/fails. In such cases, you may need to<br>
set breakpoints during the RTEMS initialization/startup sequence. The<br>
boot_card() is a good place to start from in those cases.<br>
<br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div>