<div dir="ltr">Great advice. I'll keep these points in my mind. Thanks.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 11, 2020 at 10:27 PM Gedare Bloom <<a href="mailto:gedare@rtems.org">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 9:07 AM Richi Dubey <<a href="mailto:richidubey@gmail.com" target="_blank">richidubey@gmail.com</a>> wrote:<br>
>><br>
>> 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.<br>
><br>
> I will use this. Thanks again.<br>
><br>
>> It depends on the correctness of the program call stack though, so you may on<br>
>> occasion find the bt is corrupt/fails.<br>
><br>
> 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?<br>
><br>
The return address of each caller is stored on the stack. GDB uses<br>
those return addresses (and frame size information) to determine the<br>
backtrace. If something smashes the stack and overwrites the return<br>
address, then you can't get a backtrace.<br>
<br>
> ------------------------------------------------------------<br>
> 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?)<br>
<br>
The end of the bt may not actually be corruption, since you're<br>
debugging a kernel there isn't always a clean ending. Here though, it<br>
is suspicious. You should have some notion of what function called<br>
_Scheduler_strong_APA_Get_lowest_scheduled(). Now though you can set<br>
your breakpoint at this function, do a bt, and track through what the<br>
function does. It may not be the first time it gets called that leads<br>
the exception though. So you may have some trial and error.<br>
<br>
> ------------------------------------------------------------<br>
><br>
><br>
> 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>
>><br>
>> 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>