Bob Feretich wrote:
> Comments inline...
>
> On 9/7/2010 5:04 AM, Gilles Chanteperdrix wrote:
>> Bob Feretich wrote:
>>> I am seeing various Oops reports referencing my rt user task, but they
>>> don't provide any useful information regarding my program's state at the
>>> time of the Oops.
>>>
>>> The most common Oops is...
>>> Unable to handle kernel NULL pointer dereference at virtual address 0000000c
>>> ... snipped...
>> This tells us that a bug happens in kernel-space for some reason, while
>> trying to handle a user-space fault.
>>
>> Do you have a simple piece of code which I can run to reproduce this issue?
>>
> No. This problem started occurring when I integrated the whole system
> together. I'm going to have to work on it a bit to reduce it to a
> suitable code segment .
> The Xenomai content of the loop is:
> while (!end) {
> ...
> rc = rt_event_wait(&event1,..);
> ...
> rc = rt_event_clear(&event1,..);
> ...
> rc = rt_event_wait(&event2,..);
> ...
> rc = rt_event_clear(&event2,..);
> ...
> rc = rt_event_wait(&event3, TM_NONBLOC, ...);
> if (rc==0) end = 1;
> }
>
> I changed the way my system of programs worked and replaced the first
> two rt_event_wait()s with ioctls, which execute rtdm_event_wait()s.
> This fix seemed to work around the problem. Initial testing show no Oopses.
>
>>> Another is...
>>> Unable to handle kernel paging request at virtual address 70000049
>>> pgd = cf034000
>>> [70000049] *pgd=00000000
>>> Internal error: Oops: 805 [#1]
>>> last sysfs file: /sys/devices/virtual/gpio/gpio7/value
>>> Modules linked in: rtservo_driver rtasuspidvr
>>> CPU: 0 Not tainted (2.6.33 #10)
>>> PC is at 0x40038998
>>> LR is at 0x40038984
>>> pc : [<40038998>] lr : [<40038984>] psr: 60000113
>>> sp : cf0f3ff8 ip : 00000000 fp : 00000001
>>> r10: 40242c3c r9 : 00000000 r8 : 40242c40
>>> r7 : 000f0042 r6 : 40242c40 r5 : 402434b0 r4 : 00000000
>>> r3 : 00000a64 r2 : 70000049 r1 : ffffffab r0 : 00000000
>>> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
>>> Control: 10c5387d Table: 8f034019 DAC: 00000015
>>> Process navigator (pid: 646, stack limit = 0xcf0f22e8)
>>> Stack: (0xcf0f3ff8 to 0xcf0f4000)
>>> 3fe0: 00000000
>>> 00000000
>>> Code: 0affffe9 e3500000 059d3014 059d2008 (05823000)
>>> ---[ end trace 6d46aff735536a73 ]---
>> This is the real user-space fault. Happening at pc 0x40038998 which
>> corresponds to an address in your process. However, the stack pointer is
>> invalid here. So, the most probablie reason for such fault is that you
>> overwrote some piece of stack, which caused the return from a function
>> to try and use cf0f3ff8 as a stack address, causing the fault.
> 0x40038998 is somewhere in /usr/xenomai/lib/native.so.3.0.0. A load map
> that I captured from one small iteration after the above Oops showed the
> executable section of native.so starting at 0x40035000.
>
> I have a deadline in a few days, then some travel, so I can't dig
> further into the rt_event Oopses for two weeks.
Chances are high that the faults come from some memory corruption in the
application, or stack overflows, or things like that. If you pass an
invalid address to a Xenomai service, it will cause a segmentation
fault, but that does not make the Xenomai service buggy.
--
Gilles.
_______________________________________________
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
