On Tue, Oct 12, 2010 at 12:32 PM, Gilles Chanteperdrix <
gilles.chanteperd...@xenomai.org> wrote:
> Johan Cockx wrote:
> >
> >
> > On Tue, Oct 12, 2010 at 12:05 PM, Gilles Chanteperdrix
> > <gilles.chanteperd...@xenomai.org
> > <mailto:gilles.chanteperd...@xenomai.org>> wrote:
> >
> > Johan Cockx wrote:
> > >
> > >
> > > On Mon, Oct 11, 2010 at 4:07 PM, Gilles Chanteperdrix
> > > <gilles.chanteperd...@xenomai.org
> > <mailto:gilles.chanteperd...@xenomai.org>
> > > <mailto:gilles.chanteperd...@xenomai.org
> > <mailto:gilles.chanteperd...@xenomai.org>>> wrote:
> > >
> > > Johan Cockx wrote:
> > > > A printf in src/skins/posix/select.c confirms that
> __wrap_select
> > > is called.
> > >
> > > Ok, but there are many branches here, could you check whether
> > it emits
> > > the syscall, and if yes, what is the result of this syscall?
> > >
> > >
> > > First, it executes:
> > > err = XENOMAI_SKINCALL5(__pse51_muxid, __pse51_select, __nfds,
> > > __readfds, __writefds, __exceptfds, __timeout);
> > > (which expands to assembly code; is this the syscall you are
> > referring to?)
> > >
> > > This returns err == -9 ( == -EBADF), so it continues to call
> > > __real_select (which as far as I understand it calls the plain
> > > non-xenomai select) which returns 0 (timeout).
> > >
> > > EBADF suggests that there is something wrong with the file
> descriptor,
> > > but I have no clue what. The code that creates this file
> > descriptor was
> > > attached to my previous mail (recv.c).
> >
> > It means that one of the file descriptors you pass to select is not a
> > Xenomai file descriptor.
> >
> >
> > Ok, but the one file descriptor that I am passing in was created with a
> > socket() call, and since I am using the posix skin, I assume it should
> > be a Xenomai file descriptor. Is there any way that the socket() call
> > (using the posix skin) could return a non-Xenomai file descriptor?
>
> Yes, if it ends up calling __real_socket instead of socket. You can
> instrument the __wrap_socket code, the same way you did with
> __wrap_select, to see what happens.
>
Ok: __real_socket is not called, the XENOMAI_SKINCALL3(...) code returns
zero in this case.
> >
> >
> > > > Attached is a small stand-alone test case. It consists of
> two
> > > programs:
> > > > recv.c will wait for a udp message with a timeout of 10 sec
> > (using
> > > > select), and send.c will send a udp message. If recv is
> started
> > > and then
> > > > send (in another terminal), recv should return immediatly
> > without
> > > > timeout; however, it continues to wait until a timeout
> occurs.
> > >
> > > By standalone, I meant without RTnet. So, please verify that
> > you also
> > > get the bug without RTnet, and post a mail to the Xenomai-help
> > mailing
> > > list (as opposed to the rtnet mailing list, which is the
> > mailing list
> > > where you are posting currently).
> > >
> > >
> > > I am not sure how to test the bug with Xenomai but without RTnet.
> If I
> > > replace --posix-cflags and --posix-ldflags by --xeno-flags and
> > > --xeno-ldflags and use a plain (non-rt) IP address, there is no
> > problem.
> >
> > Try posix message queues.
> >
> > Sorry, not clear to me: how can I reproduce a bug related to UDP
> > messages with posix message queues?
>
> The point is to know whether it is a generic select bug or an UDP socket
> bug. If it happens with posix message queues, it is a select bug. If it
> happens only with UDP sockets, then it is related to UDP sockets somehow.
>
Ok. Message queues work correctly, so the bug seems to be related to UDP
sockets.
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
