Need help finding the cause of an ARM4 Exception

Wed Aug 12 20:50:36 UTC 2020

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