More weird behaviour on PowerPC.

[Till Straumann]

On 05/24/2010 03:00 PM, Nick Thomas wrote:
> Hi
>
> My colleague and I have spent the last couple of days upgrading our RTEMS OS
> from 4.7.1 to 4.7.3. At the same time we have added the -fno-strict-aliasing
> flag to the compiler.
>
> I don't this these modifications have helped in our stability issues,
> because I have just observed a weird thing with the new build :(
>
> It's just taken a 0x0700 (Program Exception). And looking at the call stack
> I see:
>
> (gdb) bt
> #0  0x00000014 in ?? ()
> #1  0x00000010 in ?? ()
> #2  0x00325148 in FILTER_Task_Entry ()
> #3  0x003197b8 in task_launch ()
>
>
> The last good address is 0x00325148. Which is indeed in FILTER_Task_Entry,
> the disassembly around 0x00325148 is:
>
> 0x0032513c<FILTER_Task_Entry+540>:	stw     r10,1864(r16)
> 0x00325140<FILTER_Task_Entry+544>:	sth     r0,4(r11)
> 0x00325144<FILTER_Task_Entry+548>:	bl      0x323964
> <FILTER_String_Length+60>
> 0x00325148<FILTER_Task_Entry+552>:	b       0x325024
> <FILTER_Task_Entry+260>
> 0x0032514c<FILTER_Task_Entry+556>:	lwz     r4,1912(r19)
> 0x00325150<FILTER_Task_Entry+560>:	li      r5,0
>
> So, at 0x00325148 is a simple branch instruction to an address earlier
> inside the same function. But, the call stack shows that it next went to
> 0x00000010 !!!!
>    
It doesn't necessarily show that. It could be (and this wouldn't
be a huge surprise) that the stack gets corrupted and doesn't reflect 
anymore
the true return addresses.

You can e.g., jump down into some subroutine which overruns
a stack variable (thus corrupting the stack). When the subroutine
returns it jumps into the woods instead of the caller
and raises a 0x700 exception.
> What on earth could make it do that?
>
> I don't know if this is useful, but here is the dump of the memory at those
> locations:
>
>    
That's not too helpful since the memory contents are already
dumped with the disassembly above.

You can extract more information from the register contents,
the memory contents of the stack at the time of the crash
and a disassembly + listing of the code (if any -- probably
the PC is somewhere in the woods but it could also be that
the text got corrupted) at the PC location where
the code crashed.

HTH
-- Till

>> md 0x0032513c 6
>>      
> 0032513c : 0x91500748  -1857026232 .P.H
> 00325140 : 0xb00b0004  -1341456380 ....
> 00325144 : 0x4bffe821   1275062305 K..!
> 00325148 : 0x4bfffedc   1275068124 K...
> 0032514c : 0x80930778  -2137847944 ...x
> 00325150 : 0x38a00000    950009856
>
> Regards
>
> Nick
>
>
> -----------------------------
> Nick Thomas
> Email: nick.thomas at pixsan.com
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>