Re: [PATCH RFA] Retry open of /proc/PID/ctl in procfs.c

[Kevin Buettner <kevinb at cygnus dot com>]

On Apr 13,  3:23pm, Michael Snyder wrote:

> Kevin Buettner wrote:
> > 
> > I request approval for committing the patch below.  The comments in the
> > patch explain why this patch is needed.  (It definitely cures some
> > intermittent problems that I'm seeing on AIX5.)
> 
> Is this just an issue of avoiding a race condition between gdb opening
> the "file" and the kernel creating it?

Yes.  I believe the problem that I'm seeing on AIX5 is due to a race
condition.  The race is between GDB and the kernel to see who can
open/create /proc/PID/ctl first.  The kernel usually wins this race,
but roughly one time out of fifty, GDB wins it instead.

> I can certainly imagine this being an issue on any platform, so I'm
> glad you didn't ifdef it, but I wonder if this is the only place
> where it might show up?

I think similar problems show up elsewhere too.  E.g, see

    http://sources.redhat.com/ml/gdb/2001-04/msg00078.html

In this bug report, Damien Kick reports that...

    'truss'ing the running 'gdb' shows that the failure in '/proc'
    comes from an attempt to 'open' '/proc/pid/status' that fails with
    EAGAIN.

This is on sparc-sun-solaris2.7.

The problem that Damien reported is not precisely the same as the
problem that I'm seeing on AIX5, but retrying the open() seems like
the right thing to do for Damien's problem too.

> Would it be worth it to add a "nohang" argument to open_procinfo_files?

It did occur to me that it might be better to move the retry logic
into open_procinfo_files().  I suppose the "nohang" argument you refer
to would only cause the open to be attempted only once?

> If not, then I say this change is fine.

I'll rework my patch so that the retry logic is located in
open_procinfo_files() instead and resubmit it.

Thanks for your feedback.

Kevin