RTEMS crash with error 18 (RTEMS_CALLED_FROM_ISR) again.

Joel Sherrill joel.sherrill at OARcorp.com
Wed Feb 17 16:44:13 UTC 2010


On 02/17/2010 10:41 AM, Nick Thomas wrote:
> Hi,
>
> I have had this error 18 crash again. When the debugger back trace clearly
> shows that the call tree originates from a task.
>
> Looking through the disassembly is looks like the error 18 is called from
> rtems_region_get_segment function, from line 69 in regiongetsegment.c .
>
> #0  _CPU_Fatal_error (_error=18)
>      at
> ../../../../../../../rtems-4.7.1/c/src/lib/libcpu/powerpc/old-exceptions/cpu
> .c:380
> #1  0x005f3330 in _Internal_error_Occurred (the_source=INTERNAL_ERROR_CORE,
>      is_internal=0, the_error=18)
>      at
> ../../../../../../rtems-4.7.1/c/src/../../cpukit/score/src/interr.c:61
> #2  0x005e6e5c in rtems_region_get_segment (id=838926341, size=8,
>      option_set=1, timeout=0, segment=0xfa421c)
>      at
> ../../../../../../rtems-4.7.1/c/src/../../cpukit/rtems/src/regiongetsegment.
> c:69
>
>    
This does not clearly show you are in a task.  It shows you tried
to allocate memory.  Possibly from an ISR.  There would have to be
more stack back trace to be clearly anything.  Who called 
rtems_region_get_segment?
> There is some inlined functions involved here, so it's difficult to follow
> the code.
> But, the disassembly of rtems_region_get_segment clearly shows that error 18
> is in there:
> (See 6 lines from bottom of the following disassembly list).
>
>
> (gdb) disassem 0x5e6da4
> Dump of assembler code for function rtems_region_get_segment:
> 0x005e6da4<rtems_region_get_segment+0>:	stwu    r1,-64(r1)
> 0x005e6da8<rtems_region_get_segment+4>:	mflr    r0
> 0x005e6dac<rtems_region_get_segment+8>:	stw     r31,60(r1)
> 0x005e6db0<rtems_region_get_segment+12>:	stw     r0,68(r1)
> 0x005e6db4<rtems_region_get_segment+16>:	mr      r31,r1
> 0x005e6db8<rtems_region_get_segment+20>:	stw     r3,24(r31)
> 0x005e6dbc<rtems_region_get_segment+24>:	stw     r4,28(r31)
> 0x005e6dc0<rtems_region_get_segment+28>:	stw     r5,32(r31)
> 0x005e6dc4<rtems_region_get_segment+32>:	stw     r6,36(r31)
> 0x005e6dc8<rtems_region_get_segment+36>:	stw     r7,40(r31)
> 0x005e6dcc<rtems_region_get_segment+40>:	lwz     r0,40(r31)
> 0x005e6dd0<rtems_region_get_segment+44>:	cmpwi   cr7,r0,0
> 0x005e6dd4<rtems_region_get_segment+48>:	bne-    cr7,0x5e6de4
> <rtems_region_get_segment+64>
> 0x005e6dd8<rtems_region_get_segment+52>:	li      r0,9
> 0x005e6ddc<rtems_region_get_segment+56>:	stw     r0,52(r31)
> 0x005e6de0<rtems_region_get_segment+60>:	b       0x5e7180
> <rtems_region_get_segment+988>
> 0x005e6de4<rtems_region_get_segment+64>:	lwz     r9,40(r31)
> 0x005e6de8<rtems_region_get_segment+68>:	li      r0,0
> 0x005e6dec<rtems_region_get_segment+72>:	stw     r0,0(r9)
> 0x005e6df0<rtems_region_get_segment+76>:	lwz     r0,28(r31)
> 0x005e6df4<rtems_region_get_segment+80>:	cmpwi   cr7,r0,0
> 0x005e6df8<rtems_region_get_segment+84>:	bne-    cr7,0x5e6e08
> <rtems_region_get_segment+100>
> 0x005e6dfc<rtems_region_get_segment+88>:	li      r9,8
> 0x005e6e00<rtems_region_get_segment+92>:	stw     r9,52(r31)
> 0x005e6e04<rtems_region_get_segment+96>:	b       0x5e7180
> <rtems_region_get_segment+988>
> 0x005e6e08<rtems_region_get_segment+100>:	lis     r9,119
> 0x005e6e0c<rtems_region_get_segment+104>:	lwz     r9,3392(r9)
> 0x005e6e10<rtems_region_get_segment+108>:	li      r0,0
> 0x005e6e14<rtems_region_get_segment+112>:	stw     r0,20(r31)
> 0x005e6e18<rtems_region_get_segment+116>:	lwz     r0,20(r31)
> 0x005e6e1c<rtems_region_get_segment+120>:	mfmsr   r0
> 0x005e6e20<rtems_region_get_segment+124>:	andc    r9,r0,r9
> 0x005e6e24<rtems_region_get_segment+128>:	mtmsr   r9
> 0x005e6e28<rtems_region_get_segment+132>:	stw     r0,20(r31)
> 0x005e6e2c<rtems_region_get_segment+136>:	lis     r9,130
> 0x005e6e30<rtems_region_get_segment+140>:	lwz     r0,-7660(r9)
> 0x005e6e34<rtems_region_get_segment+144>:	cmpwi   cr7,r0,0
> 0x005e6e38<rtems_region_get_segment+148>:	beq-    cr7,0x5e6e5c
> <rtems_region_get_segment+184>
> 0x005e6e3c<rtems_region_get_segment+152>:	bl      0x5e71a0
> <_System_state_Get>
> 0x005e6e40<rtems_region_get_segment+156>:	mr      r0,r3
> 0x005e6e44<rtems_region_get_segment+160>:	cmplwi  cr7,r0,1
> 0x005e6e48<rtems_region_get_segment+164>:	ble-    cr7,0x5e6e5c
> <rtems_region_get_segment+184>
> 0x005e6e4c<rtems_region_get_segment+168>:	li      r3,0
> 0x005e6e50<rtems_region_get_segment+172>:	li      r4,0
> 0x005e6e54<rtems_region_get_segment+176>:	li      r5,18
> 0x005e6e58<rtems_region_get_segment+180>:	bl      0x5f32c0
> <_Internal_error_Occurred>
> 0x005e6e5c<rtems_region_get_segment+184>:	lis     r9,130
> 0x005e6e60<rtems_region_get_segment+188>:	lwz     r9,-7612(r9)
> 0x005e6e64<rtems_region_get_segment+192>:	addi    r0,r9,16
> 0x005e6e68<rtems_region_get_segment+196>:	addi    r9,r31,20
>
>
> I'm no expert in assembler, but is this something to do with
> _System_state_Get ? (Shown a few lines above).
>
> I can't find _System_state_Get in my source code, but the disassembly looks
> like this:
> Dump of assembler code for function _System_state_Get:
> 0x005d8594<_System_state_Get+0>:	stwu    r1,-16(r1)
> 0x005d8598<_System_state_Get+4>:	stw     r31,12(r1)
> 0x005d859c<_System_state_Get+8>:	mr      r31,r1
> 0x005d85a0<_System_state_Get+12>:	lis     r9,130
> 0x005d85a4<_System_state_Get+16>:	lwz     r0,-7560(r9)
> 0x005d85a8<_System_state_Get+20>:	mr      r3,r0
> 0x005d85ac<_System_state_Get+24>:	lwz     r11,0(r1)
> 0x005d85b0<_System_state_Get+28>:	lwz     r31,-4(r11)
> 0x005d85b4<_System_state_Get+32>:	mr      r1,r11
> 0x005d85b8<_System_state_Get+36>:	blr
> End of assembler dump.
>
>
> Can anyone shed some light onto this problem from the above?
> Previously I have looked at the ISR_nest_Level variable, but that is zero
> when this crash happens.
>
> So, the question is, why does an error 18 occur when in task context?
>
>
> Any help greatly appreciated.
>
>
> 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
>    


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985





More information about the users mailing list