Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> 
>>M. Koehrer wrote:
>>
>>>Hi Jan, hi everybody,
>>>
>>>I have stripped down my program that is crashing Xenomai even further.
>>>(I have attached the complete source code).
>>>No rtnet is required.
>>>Now I have the following real time task:
>>>
>>>static void realtimetask(void *arg)
>>>{
>>>    system("ls -l");
>>
>>If you want to use system (or any function calling fork, eg popen or
>>vfork) with Xenomai, you have to make sure to fault all pages mapped
>>with write permission after the fork before trying to use services in
>>priimary mode, because fork write protects all pages with write
>>permission and notably the threads stacks. A piece of code that faults
>>all pages follows.
> 
> 
> Let me check if I got this correctly: fork calls mark all pages
> write-protected - also those of the father process, or only those of the
> new child? That would mean we see unexpected page faults, right?
> Anything more (probably not a lock-up)?

Not all page faults are inocuous. I discovered this behaviour of fork
when chasing a lock-up that was caused by an xnshadow_relax that did not
work. It turned out that a page fault occured because of the thread
stack page protection in an xn_copy_to_user, after the calling thread
had been kicked. Trying to relax a kicked thread can not work, and
triggers a nucleus panic.

There may be other pathes where a page fault may be deadly.

Now, in Mathias case, the fact that printf helps is probably the sign
that the deadly fault occurs on the thread stack, because printf touches
the thread stack (remember?, printf segfaults when the thread stack is
too small).

The fact that the bug only occurs with 2.6.19 shows that maybe 2.6.19 is
accessing the thread stack whereas previous versions did not.

> 
> I think we should document this special property somewhere, e.g. in the
> wiki, maybe also a demo program in the examples repos.

I agree.

-- 
                                                 Gilles Chanteperdrix

_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help

Reply via email to