On Wed, Aug 12, 2020 at 2:28 PM Richi Dubey <richidu...@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@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
