Need help finding the cause of an ARM4 Exception

Richi Dubey richidubey at gmail.com
Thu Aug 13 19:21:03 UTC 2020


Thanks for your detailed reply. All this helped.

You should be able to print the exception context and see what are the
> values of some different registers. This might be helpful.

How do I do this? Right now I am printing individual variables that I find
important by using 'p'.

typedef struct
> {
>   bool visited[ RTEMS_ZERO_LENGTH_ARRAY ];
> } Scheduler_strong_APA_Visited;
> I don't see where this gets initialized.
> You have Scheduler_strong_APA_Visited *visited;
> inside of the context. Then you get
> visited = self->visited->visited;
> Probably this is now a pointer to a 0-length array, and you make a
> bunch of bad writes past the end of it.
>

Thanks for this observation. It has been resolved now.

This code is initializing the default scheduler context for strong
> apa. You need to make sure this initializer is in sync with the
> definition of the strong apa context structure layout. Right now, this
> is not matching up correctly with how you have defined
> Scheduler_strong_APA_Context;

Done.

>
> If there is code that casts a Scheduler_SMP_Node* to an
> Scheduler_strong_APA_Node* it will not work correctly the way you have
> structured the Scheduler_strong_APA_Node, because you have something
> (Chain_Node) in the structure prior to the Scheduler_SMP_Node.
> I think you need to review how C structs are laid out in memory.


Okay, that completely slipped from my view. That is corrected now. Thank
you

On Thu, Aug 13, 2020 at 2:20 AM Gedare Bloom <gedare at rtems.org> wrote:

> On Wed, Aug 12, 2020 at 2:28 PM Richi Dubey <richidubey at gmail.com> wrote:
> >
> > Hi,
> >
> > Can someone please help me figure out why I am getting the
> _ARMV4_Exception_data_abort_default?
> >
> > I have attached the gdb script (Provided by Mr. Huber) that I used with
> this email. I have also printed the commands I have used to run gdb and
> qemu.
> >
> > I have provided my view on this exception and the link to PR with my
> changes at the end.
> >
> > qemu executed with the command:
> >
> --------------------------------------------------------------------------------------------------------------------------
> >  ./qemu-system-arm -net none -nographic -M realview-pbx-a9 -m 256M
> -kernel
> ~/quick-start/build/b3-realview/arm-rtems5/c/realview_pbx_a9_qemu/testsuites/smptests/smpstrongapa01.exe
> -smp 3 -S -s
> >
> >
> --------------------------------------------------------------------------------------------------------------------------
> >
> > GDB commands used:
> >
> --------------------------------------------------------------------------------------------------------------------------
> >
> >  ~/quick-start/rtems/5/bin$ ./arm-rtems5-gdb --command=arm.gdb
> ~/quick-start/build/b3-realview/arm-rtems5/c/realview_pbx_a9_qemu/testsuites/smptests/smpstrongapa01.exe
> > .
> > .
> > .
> > Loading section .fini_array, size 0x4 lma 0x121184
> > Loading section .rtemsroset, size 0x74 lma 0x121188
> > Loading section .data, size 0x530 lma 0x200000
> > Start address 0x00100040, load size 136967
> > Transfer rate: 26751 KB/sec, 1778 bytes/write.
> > (gdb) continue
> > Continuing.
> >
> > 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
> > 70 sub sp, #MORE_CONTEXT_SIZE
> > (gdb) bt
> > #0  _ARMV4_Exception_data_abort_default () at
> /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/cpu/arm/armv4-exception-default.S:70
> > #1  0x00118c64 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:318
> > Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> > (gdb) reset
> > Loading section .start, size 0x8e0 lma 0x100000
> > Loading section .text, size 0x1f00c lma 0x100900
> > Loading section .init, size 0xc lma 0x11f90c
> > Loading section .fini, size 0xc lma 0x11f918
> > Loading section .rodata, size 0x184b lma 0x11f928
> > Loading section .ARM.exidx, size 0x8 lma 0x121174
> > Loading section .eh_frame, size 0x4 lma 0x12117c
> > Loading section .init_array, size 0x4 lma 0x121180
> > Loading section .fini_array, size 0x4 lma 0x121184
> > Loading section .rtemsroset, size 0x74 lma 0x121188
> > Loading section .data, size 0x530 lma 0x200000
> > Start address 0x00100040, load size 136967
> > Transfer rate: 8359 KB/sec, 1778 bytes/write.
> > (gdb) b _Scheduler_strong_APA_Get_lowest_scheduled
> > Breakpoint 7 at 0x118bee: file
> /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/schedulerstrongapa.c,
> line 287.
> > (gdb) continue
> > Continuing.
> >
> > Thread 1 hit Breakpoint 7, _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:287
> > 287  front = 0;
> > (gdb) ni
> > 0x00118bf0 287  front = 0;
> > (gdb)
> > 289  rear = -1;
> > (gdb)
> > 0x00118bf6 289  rear = -1;
> > (gdb)
> > 291  self = _Scheduler_strong_APA_Get_self( context );
> > (gdb)
> > 0x00118bfa 291  self = _Scheduler_strong_APA_Get_self( context );
> > (gdb)
> > 0x00118bfe 291  self = _Scheduler_strong_APA_Get_self( context );
> > (gdb)
> > 293  visited = self->visited->visited;
> > (gdb)
> > 0x00118c02 293  visited = self->visited->visited;
> > (gdb)
> > 0x00118c04 293  visited = self->visited->visited;
> > (gdb)
> > 294  queue = self->queue->Cpu;
> > (gdb)
> > 0x00118c08 294  queue = self->queue->Cpu;
> > (gdb)
> > 0x00118c0a 294  queue = self->queue->Cpu;
> > (gdb)
> > 295  caller = self->caller->caller;
> > (gdb)
> > 0x00118c0e 295  caller = self->caller->caller;
> > (gdb)
> > 0x00118c10 295  caller = self->caller->caller;
> > (gdb)
> > 297  filter_priority = _Scheduler_Node_get_priority( filter_base );
> > (gdb)
> > 0x00118c14 297  filter_priority = _Scheduler_Node_get_priority(
> filter_base );
> > (gdb)
> > 0x00118c18 297  filter_priority = _Scheduler_Node_get_priority(
> filter_base );
> > (gdb)
> > 298  filter_priority = SCHEDULER_PRIORITY_PURIFY( filter_priority );
> > (gdb)
> > 0x00118c20 298  filter_priority = SCHEDULER_PRIORITY_PURIFY(
> filter_priority );
> > (gdb)
> > 0x00118c24 298  filter_priority = SCHEDULER_PRIORITY_PURIFY(
> filter_priority );
> > (gdb)
> > 0x00118c28 298  filter_priority = SCHEDULER_PRIORITY_PURIFY(
> filter_priority );
> > (gdb)
> > 0x00118c2c 298  filter_priority = SCHEDULER_PRIORITY_PURIFY(
> filter_priority );
> > (gdb)
> > 0x00118c30 298  filter_priority = SCHEDULER_PRIORITY_PURIFY(
> filter_priority );
> > (gdb)
> > 300  ret = NULL; //To remove compiler warning.
> > (gdb)
> > 0x00118c36 300  ret = NULL; //To remove compiler warning.
> > (gdb)
> > 304  filter_node = _Scheduler_strong_APA_Node_downcast( filter_base );
> > (gdb)
> > 0x00118c3a 304  filter_node = _Scheduler_strong_APA_Node_downcast(
> filter_base );
> > (gdb)
> > 0x00118c3e 304  filter_node = _Scheduler_strong_APA_Node_downcast(
> filter_base );
> > (gdb)
> > 306  max_priority_num = 0;//Max (Lowest) priority encountered so far.
> > (gdb)
> > 0x00118c44 306  max_priority_num = 0;//Max (Lowest) priority encountered
> so far.
> > (gdb)
> > 312  cpu_max = _SMP_Get_processor_maximum();
> > (gdb)
> > 0x00118c4c 312  cpu_max = _SMP_Get_processor_maximum();
> > (gdb)
> > 314  for ( cpu_index = 0 ; cpu_index < cpu_max ; ++cpu_index ) {
> > (gdb)
> > 0x00118c50 314  for ( cpu_index = 0 ; cpu_index < cpu_max ; ++cpu_index
> ) {
> > (gdb)
> > 0x00118c52 314  for ( cpu_index = 0 ; cpu_index < cpu_max ; ++cpu_index
> ) {
> > (gdb)
> > 0x00118cb2 314  for ( cpu_index = 0 ; cpu_index < cpu_max ; ++cpu_index
> ) {
> > (gdb)
> > 0x00118cb4 314  for ( cpu_index = 0 ; cpu_index < cpu_max ; ++cpu_index
> ) {
> > (gdb)
> > 0x00118cb6 314  for ( cpu_index = 0 ; cpu_index < cpu_max ; ++cpu_index
> ) {
> > (gdb)
> > 0x00118cb8 314  for ( cpu_index = 0 ; cpu_index < cpu_max ; ++cpu_index
> ) {
> > (gdb)
> > 315    visited[ cpu_index ] = false;
> > (gdb)
> > 0x00118c56 315    visited[ cpu_index ] = false;
> > (gdb)
> > 0x00118c58 315    visited[ cpu_index ] = false;
> > (gdb)
> > 0x00118c5a 315    visited[ cpu_index ] = false;
> > (gdb)
> > 0x00118c5c 315    visited[ cpu_index ] = false;
> > (gdb)
> >
> > 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
> > 70 sub sp, #MORE_CONTEXT_SIZE
> > (gdb)
> > 71 stmdb sp!, {r0-r12}
> > (gdb)
>
> You should be able to print the exception context and see what are the
> values of some different registers. This might be helpful.
>
> data_abort means you tried to access some bad data address with a
> memory read/write - this is often either a null pointer or a corrupted
> pointer.
>
> I'm a little bit confused about
>
> https://github.com/richidubey/rtems/pull/7/files#diff-37221bf93c4995ceebac60adf1ab84b3R109
>
> typedef struct
> {
>   bool visited[ RTEMS_ZERO_LENGTH_ARRAY ];
> } Scheduler_strong_APA_Visited;
>
> I don't see where this gets initialized.
>
> You have Scheduler_strong_APA_Visited *visited;
> inside of the context. Then you get
> visited = self->visited->visited;
>
> Probably this is now a pointer to a 0-length array, and you make a
> bunch of bad writes past the end of it.
>
> >
> --------------------------------------------------------------------------------------------------------------------------
> >
> > The exception occurs just after the visited array gets (or tries to get)
> initialized.
> > I believe this could be because :
> >
> > 1) I might not have defined the variable properly here between lines 260
> to 262 . I do not understand how this configuration definition works in
> this case, i.e. for SCHEDULER_STRONG_APA_CONTEXT_NAME( name  ) or for
> #define RTEMS_SCHEDULER_STRONG_APA( name, prio_count ). I would appreciate
> it if someone could explain to me how this works.
> >
>
> This code is initializing the default scheduler context for strong
> apa. You need to make sure this initializer is in sync with the
> definition of the strong apa context structure layout. Right now, this
> is not matching up correctly with how you have defined
> Scheduler_strong_APA_Context;
>
> > 2) Of this comment by Dr. Bloom. which I still don't know how to
> address. Someone, please help me out with this as well.
> >
>
> If there is code that casts a Scheduler_SMP_Node* to an
> Scheduler_strong_APA_Node* it will not work correctly the way you have
> structured the Scheduler_strong_APA_Node, because you have something
> (Chain_Node) in the structure prior to the Scheduler_SMP_Node.
>
> I think you need to review how C structs are laid out in memory.
>
> > Please find the Pull Request at:
> https://github.com/richidubey/rtems/pull/7
> >
> > Thanks,
> > Richi.
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200814/af162c9b/attachment-0001.html>


More information about the devel mailing list