<offlist> or1k printf causes crash

Hesham Moustafa heshamelmatary at gmail.com
Thu Aug 21 21:15:22 UTC 2014


On Thu, Aug 21, 2014 at 10:56 PM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
>
> On 8/21/2014 2:44 PM, Hesham Moustafa wrote:
>> Hi,
>>
>> I have been debugging since a while or1k code hopefully I'd find
>> what's wrong. Here's what I got.
> First I am moving this to devel@ so others can chime in.
>> First, I asked about this problem at #openrisc IRC channel, they told
>> me the problem might be that I have to take account of the red-zone, I
>> asked what's the red-zone and Stefan said the following:
>> "the first 128 bytes of the stack has to be stepped over, leaf
>> functions might use that without modifying the stack pointer, and gcc
>> takes advantage of the fact that there is a red zone in non-leaf
>> functions prologues too. i.e. it stores things on the stack and *then*
>> update the stack pointer"
> This is a bug in gcc. We have seen it on the ARM and there was a recent
> dust up from the Linux kernel community because it happened on x86-64.
> My understanding is that there was rework/improvement which triggered
> bugs in backends. But this needs to be fixed.
>
> The sp must be updated before the memory can be used. This is just
> a bug otherwise.
>> He suggested that I add 128 bytes to stack pointer before I jump to
>> _ISR_Handler (from start.S). I tried this solution and I was not
>> lucky. You may have some ideas where/when this red-zone make problem.
> You probably need to
>> Second, I discovered that there is unusual (unalign) exception happens
>> when using printf (which does not happen with printk). When I stack, I
>> found out the problem happens in rtems_semaphore_obtain(), when trying
>> to access the_semaphore data which its pointer is returned (invalid
>> pointer) from a call to _Objects_Get_isr_disable(). This exception
>> only happens after DISPATCH_NEEDED is true and _ISR_Handler jumps to
>> _Thread_Dispatch and make a successful context switch and run the
>> first task. The following is a snapshot of the output when
>> encountering this problem.
> What's the alignment of the task stack in the port? The stack may not be
> properly aligned for the widest access of the or1k.
If you mean the following:
#define CPU_STACK_ALIGNMENT        0
but even if with this macro assigned to 4 or 8, I got the same problem.
and from linkcmds.base
bsp_stack_align = DEFINED (bsp_stack_align) ? bsp_stack_align : 8;

>> "*** BEGIN OF TEST CLOCK TICK ***
>> TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
>> TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
>> TA3  - rtems_clock_get_tod - 09:00:00   12/31/1988
>> Fatal Error 263572 Halted"
> Can you tell what the instruction is? And the address it is trying to
> access.
The _Objects_Get_isr_disable() function returns a weird address for
Object (which in tern should be the_semaphore), this address is
0x8007, it seems like the value of the SR register. All previous
Object/the_semaphore addresses returned from
_Objects_Get_isr_disable() are higher addresses, that's why I indicate
that the last (0x8007) Object address is invalid.

>> I set a break point at  a call to _Objects_Get_isr_disable() and
>> continued until the call that returns the invalid Object pointer, and
>> typed bt to get the following stack:
> Another possibility is that the register/memory constraints on
> enable/disable
> interrupts isn't right and it is confusing gcc. You could be randomly
> clobbering
> registers anytime ISRs are disabled/enabled.
>
> Christian.. can you review that code?
>> "
>> #0  _Objects_Get_isr_disable (
>>     information=0x3ba54 <_Semaphore_Information>,
>>     id=436273156, location=0x406b4, level_p=0x406b0)
>>     at ../../../../../../rtems/c/src/../../cpukit/score/src/objectgetisr.c:34
>> #1  0x00014294 in _Semaphore_Get_interrupt_disable (
>>     id=436273156, location=0x406b4, level=0x406b0)
>>     at ../../cpukit/../../../or1k_or1ksim/lib/include/rtems/rtems/semimpl.h:196
>> #2  0x000142e0 in rtems_semaphore_obtain (id=436273156,
>>     option_set=0, timeout=0)
>>     at ../../../../../../rtems/c/src/../../cpukit/rtems/src/semobtain.c:47
>> #3  0x0000d648 in rtems_termios_write (arg=0x40730)
>>     at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/termios.c:1099
>> #4  0x00004380 in console_write (major=0, minor=0,
>>     arg=0x40730)
>>     at ../../../../../../../../rtems/c/src/lib/libbsp/or1k/or1ksim/../../shared/console_write.c:42
>> #5  0x00031cc4 in rtems_io_write (major=0, minor=0,
>>     argument=0x40730)
>>     at ../../../../../../rtems/c/src/../../cpukit/sapi/src/---Type
>> <return> to continue, or q <return> to quit---
>> iowrite.c:37
>> #6  0x000305f0 in rtems_deviceio_write (iop=0x46a30,
>>     buf=0x4088c, nbyte=1, major=0, minor=0)
>>     at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/sup_fs_deviceio.c:109
>> #7  0x0002fc70 in device_write (iop=0x46a30,
>>     buffer=0x4088c, count=1)
>>     at ../../../../../../rtems/c/src/../../cpukit/libfs/src/imfs/deviceio.c:90
>> #8  0x00038f14 in write (fd=2, buffer=0x4088c, count=1)
>>     at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/write.c:48
>> #9  0x00038d54 in _write_r (ptr=0x3db40, fd=2,
>>     buf=0x4088c, nbytes=1)
>>     at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/write_r.c:41
>> #10 0x00033198 in __swrite (ptr=0x3db40, cookie=0x3dd68,
>>     buf=0x4088c "T\004\b\220", n=1)
>>     at ../../../../../gcc-4.8.2/newlib/libc/stdio/stdio.c:97
>> #11 0x000357c0 in __sfvwrite_r (ptr=0x3db40, fp=0x3dd68,
>>     uio=0x40840)
>>     at ../../../../../gcc-4.8.2/newlib/libc/stdio/fvwrite.c---Type
>> <return> to continue, or q <return> to quit---
>> :99
>> #12 0x000338a0 in __sprint_r (ptr=ptr at entry=0x3db40,
>>     fp=fp at entry=0x3dd68, uio=uio at entry=0x40840)
>>     at ../../../../../gcc-4.8.2/newlib/libc/stdio/vfprintf.c:437
>> #13 0x000345e0 in __sprint_r (uio=0x40840, fp=0x3dd68,
>>     ptr=0x3db40)
>>     at ../../../../../gcc-4.8.2/newlib/libc/stdio/vfprintf.c:1776
>> #14 _vfiprintf_r (data=0x3db40, fp=fp at entry=0x3dd68,
>>     fmt0=fmt0 at entry=0x392d1 "%c", ap=0x40930,
>>     ap at entry=0x4092c)
>>     at ../../../../../gcc-4.8.2/newlib/libc/stdio/vfprintf.c:1776
>> #15 0x00032aec in fiprintf (fp=0x3dd68, fmt=0x392d1 "%c")
>>     at ../../../../../gcc-4.8.2/newlib/libc/stdio/fiprintf.c:50
>> #16 0x00002f28 in Test_task (unused=1)
>>     at ../../../../../../../rtems/c/src/../../testsuites/samples/ticker/tasks.c:43
>> #17 0x00031ddc in _Thread_Handler ()
>>     at ../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:192
>> ---Type <return> to continue, or q <return> to quit---
>> #18 0x00031d64 in _User_extensions_Thread_exitted (
>>     executing=0x3d92c)
>>     at ../../cpukit/../../../or1k_or1ksim/lib/include/rtems/score/userextimpl.h:243
>> Backtrace stopped: frame did not save the PC
>> "
>>
>> This problem does not happen with printk, because non of these newlib
>> stuff is called and consequently rtems_semaphore_obtain() is not
>> called after context switches and/or _ISR_Handler.
> printk is simple and may not be accessing memory in the same way. It
> also may
> be simple enough that an issue with incorrect register constraints on inline
> assembly aren't blowing it up.
>>
>>
>> On Tue, Aug 19, 2014 at 7:52 PM, Gedare Bloom <gedare at rtems.org> wrote:
>>> Submit the revised patch.
>>>
>>> -Gedare
>>>
>>> On Tue, Aug 19, 2014 at 1:49 PM, Hesham Moustafa
>>> <heshamelmatary at gmail.com> wrote:
>>>> Hi Gedare,
>>>> Thanks for providing this solution, I will try to imitate these two files
>>>> and run the test. The fixed patch for or1ksim is ready, should i submit it
>>>> or wait until I check this solution and hopefully figuring out what is
>>>> wrong?
>>>>
>>>> On Aug 19, 2014 7:08 PM, "Gedare Bloom" <gedare at rtems.org> wrote:
>>>>> Hi Hesham,
>>>>>
>>>>> I found this advice from Sebastian in our bugzilla related to another
>>>>> arch (bfin) that has some context-switch problems:
>>>>> "In order to test the exception code I would add the functions
>>>>>
>>>>> _CPU_Context_validate()
>>>>> _CPU_Context_volatile_clobber(
>>>>> )
>>>>>
>>>>> used in this test
>>>>>
>>>>> http://git.rtems.org/rtems/tree/testsuites/sptests/spcontext01/init.c
>>>>>
>>>>> For examples please have a look at the ARM, Nios 2 or PowerPC."
>>>>>
>>>>> You may like to try this out to debug your problem.
>>>>> Gedare
>
> --
> 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 devel mailing list