Stack checker broken on PowerPC/virtex BSP - 4.7.99.1 or later
Joel Sherrill
joel.sherrill at oarcorp.com
Thu Aug 16 13:59:07 UTC 2007
Robert S. Grimes wrote:
> Chris Johns wrote:
>
>> Robert S. Grimes wrote:
>>
>>> I see you have changed cpukit/score/include/rtems/score/object.h a tiny
>>> bit - is that the extent of this change?
>>>
>>>
>> Yes that is the fix. It is small but it stops the score writing past
>> the end of the system object table. In other words it stops it
>> corrupting memory.
>>
>>
> Yes, but that is not the memory being corrupted! I have applied just
> the above mentioned patch to the 4.7.99.2 tarball, and the results are
> the same.
>
> I've narrowed it down to the invocation of this macro:
>
> #define Stack_check_Dope_stack(_stack) \
> memset((_stack)->area, BYTE_PATTERN, (_stack)->size)
>
> In the suspect code, this translates to this:
> memset(0xe75c0, 0xa5, 0x2808);
>
> Thus, it is attempting to set the area from 0xE75C0 to 0xE9DC8
>
> This is the relevant output of the application build process - the .num
> map file:
>
> 000e0000 A stack.start
> 000e8000 A IntrStack_start
> 000e8000 A stack.end
> 000ec000 A intrStack
> 00100000 A _endloader
> 00800000 A _HeapSize
>
>
> A little fishy? Yeah, but I don't know why... Anyway, here is the
> exception output:
>
> Exception handling initialization done
> opb_intc_init: mask = 0x7
> exception handler called for exception 7
> Next PC or Address of fault = A5A5A5A4
> Saved MSR = 0
> R0 = A5A5A5A5
> R1 = E7EB4
> R2 = C56D8
> R3 = 1
> R4 = A5
> R5 = 0
> R6 = FEFFFFFF
> R7 = D0000
> R8 = D327C
> R9 = E9DC8
> R10 = 1
> R11 = E9DC8
> R12 = 0
> R13 = FFFEA680
> R14 = FFFFFFFF
> R15 = FFFFFFFF
> R16 = FFFFFFFF
> R17 = FFFFFFFF
> R18 = FFFFFFFF
> R19 = FFFFFFFF
> R20 = FFFFFFFF
> R21 = FFFFFFFF
> R22 = FFFE0000
> R23 = FFFE0000
> R24 = 0
> R25 = D3154
> R26 = 1
> R27 = 0
> R28 = D0000
> R29 = D33FC
> R30 = E0F38
> R31 = A5A5A5A5
> CR = 39000033
> CTR = 0
> XER = E000007F
> LR = A5A5A5A5
> MSR = 0
> DAR = 0
> Stack Trace:
> IP: 0xA5A5A5A4, LR: 0xA5A5A5A5
> --^ 0x00000000
>
>
> So it is clearly trying to execute code in the just-doped stack, though
> I don't know why...
>
> Anything else I should try?
>
I really suspect that the RTEMS workspace (and possibly the
C Program Heap) is overlapping the initial stack and possibly
the interrupt stack
Break at RTEMS_Malloc_Initialize and look at the first
two arguments (start and length).
While there look at the first two entries in what
_Configuration_Table points to (workspace start and size).
Draw a memory map showing the range of your program's
text, data, bss, interrupt stack, starting stack, C Program
Heap, and RTEMS Workspace.
Give the symptoms and the addresses you posted above,
it is really looking like a memory map issue.
--joel
> -Bob
>
More information about the users
mailing list