Re: [ECOS] Possible sockets/fd race condition

[Ross Wightman <rwightman at gmail dot com>]

On 11/16/05, Gary Thomas <gary@mlbassoc.com> wrote:
> On Wed, 2005-11-16 at 08:16 -0800, Jay Foster wrote:
> > Do you have ASSERTions turned on.  This could help identify a problem
> > earlier.
> >
> > I have seen other similar kinds of problems (with assertions turned on), but
> > have not spent any time trying to resolve them yet.  Assertions such as:
> >
> > eCos panic: cyg_fp_free() will close fd
> > eCos panic: sbdrop
> > eCos panic: soaccept: !NOFDREF
> > eCos panic: sofree: not queued
> > eCos panic: soclose: NOFDREF
> > eCos panic: Locking mutex I already own
> > eCos panic: sbflush: locked

Asserts are enabled. I have yet to see any asserts or panics fire.
Just an exception when the NULL pointer is dereferenced.

>
> The race mentioned below may indeed exist.  If protecting the basic call
> with splnet() works, I don't see a problem.

So far so good with the splnet in socreate. We've been hammering it
for 12+ hours now.

> Note: this particular problem may only show up by way of the way Ross'
> program works.  It is unusual to create and destroy sockets for every
> packet (which is what the pseudo-code implies) and this would then
> exercise any failures which might exist in the socreate() path.
>
> > Jay

The current state of our program does indeed stress such issues. We
also cranked up the rate of UDP sends to increase the probability of
the crash happening after we first saw it. Normally it should be
sending only one per second so the create/destroy of the socket
wouldn't be a performance issue. However the crash occurs in either
case, it's just a difference of waiting half a day or a few min for it
to occur.

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss