Jeff Weber wrote:
> On Monday 16 April 2007 15:05, Philippe Gerum wrote:
>
> > Could you disassemble the code around location 0x80fb8c5?
> The latest version of my code has moved the the addresses a bit:
> Xenomai: Switching mythread to secondary mode after exception #14 from
> user-space at 0x80fb8cd (pid 3590)
>
> (gdb) disas
> Dump of assembler code for function _ZN4AMSC8CRtDequeIcE9push_backERKc:
> 0x080fb8b4 <_ZN4AMSC8CRtDequeIcE9push_backERKc+0>: push %ebp
> 0x080fb8b5 <_ZN4AMSC8CRtDequeIcE9push_backERKc+1>: mov %esp,%ebp
> 0x080fb8b7 <_ZN4AMSC8CRtDequeIcE9push_backERKc+3>: sub $0x8,%esp
> 0x080fb8ba <_ZN4AMSC8CRtDequeIcE9push_backERKc+6>: mov 0x8(%ebp),%edx
> 0x080fb8bd <_ZN4AMSC8CRtDequeIcE9push_backERKc+9>: mov 0x8(%ebp),%eax
> 0x080fb8c0 <_ZN4AMSC8CRtDequeIcE9push_backERKc+12>: mov 0x8(%eax),%eax
> 0x080fb8c3 <_ZN4AMSC8CRtDequeIcE9push_backERKc+15>: mov (%edx),%edx
> 0x080fb8c5 <_ZN4AMSC8CRtDequeIcE9push_backERKc+17>: add %eax,%edx
> 0x080fb8c7 <_ZN4AMSC8CRtDequeIcE9push_backERKc+19>: mov 0xc(%ebp),%eax
> 0x080fb8ca <_ZN4AMSC8CRtDequeIcE9push_backERKc+22>: movzbl (%eax),%eax
> 0x080fb8cd <_ZN4AMSC8CRtDequeIcE9push_backERKc+25>: mov %al,(%edx)
> 0x080fb8cf <_ZN4AMSC8CRtDequeIcE9push_backERKc+27>: mov 0x8(%ebp),%eax
> 0x080fb8d2 <_ZN4AMSC8CRtDequeIcE9push_backERKc+30>: add $0x8,%eax
> 0x080fb8d5 <_ZN4AMSC8CRtDequeIcE9push_backERKc+33>: mov %eax,0x4(%esp)
> 0x080fb8d9 <_ZN4AMSC8CRtDequeIcE9push_backERKc+37>: mov 0x8(%ebp),%eax
> 0x080fb8dc <_ZN4AMSC8CRtDequeIcE9push_backERKc+40>: mov %eax,(%esp)
> 0x080fb8df <_ZN4AMSC8CRtDequeIcE9push_backERKc+43>: call 0x80fcb18
> <_ZN4AMSC8CRtDequeIcE3incERi>
>
> >
> > > as well as the delivery of SIGXCPU to my application (at my request).
> > >
> > > How do I prevent this page fault?
> > >
> > > Is this issue covered by the recent NOCOW activity?
> >
> > Possibly. You need I-pipe 1.7-03 and Xenomai >= v2.3.1 to get the
> > ondemand mapping scheme disabled by the nucleus when your thread starts.
> I am not familiar with the purpose and implementation of the NOCOW patch.
> How would the patch affect my page fault issue?
If the fault you observe is due to an access to some memory after a call
to fork or one of its derivative (such as system, popen, etc...), the
patch would have copied the whole real-time process address space at
fork time instead of setting up COW mappings.
--
Gilles Chanteperdrix.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
