From: Rob Landley <rob@landley.net>
To: Marc Ballarin <Ballarin.Marc@gmx.de>, Paul Jackson <pj@sgi.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Interesting race condition...
Date: Wed, 28 Jul 2004 11:46:49 -0500 [thread overview]
Message-ID: <200407281146.49166.rob@landley.net> (raw)
In-Reply-To: <20040728135444.79e67ea9.Ballarin.Marc@gmx.de>
On Wednesday 28 July 2004 06:54, Marc Ballarin wrote:
> On Wed, 28 Jul 2004 01:05:46 -0700
>
> Paul Jackson <pj@sgi.com> wrote:
> > Rob wrote:
> > > I just saw a funky thing. Here's the cut and past from the xterm...
> >
> > Can you reproduce this by cat'ing /proc/<pid>/cmdline? Can you get a
> > dump of the proc cmdline file to leak the environment sometimes?
> >
> > It is this file that 'ps' is dumping for these options. Adding the
> > 'e' option would also dump the /proc/<pid>/environ file (if readable).
> >
> > But you aren't adding 'e', so presumably the environment is "leaking"
> > into the the cmdline file.
> >
> > I suspect a kernel bug here - the ps code seems rather obvious and
> > unimpeachable.
>
> I ran the following loop for a while (> 9 million times) and could not
> reproduce the bug, but that might just be coincidence.
> Conditions were the same as in my other, succesful test.
>
> while [ 1 ];do
> cat /proc/self/cmdline >> TEST
> done
>
> Marc
I might have actually just killed the process I was grepping for (I was
grepping to see if it had actually gone away yet). Dunno if that helps...
I haven't been able to reproduce it either. I think the pipe to grep (or
something similar) is important because your test isn't doing what mine did:
one process was looking at another process at the instant of process creation
(or perhaps exit). Maybe the appropriate null terminator is written out
after the process goes live?
This is a UP system, but I have preemption on...
Rob
--
www.linucon.org: Linux Expo and Science Fiction Convention
October 8-10, 2004 in Austin Texas. (I'm the con chair.)
next prev parent reply other threads:[~2004-07-28 16:46 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-23 3:04 Interesting race condition Rob Landley
2004-07-23 7:33 ` Barry K. Nathan
2004-07-23 7:56 ` Hugo Mills
2004-07-24 8:13 ` Rob Landley
2004-07-24 13:40 ` Marc Ballarin
2004-07-26 16:04 ` David Weinehall
2004-07-26 17:20 ` Marc Ballarin
2004-07-23 10:01 ` P. Benie
2004-07-24 8:17 ` Rob Landley
2004-07-24 9:08 ` P. Benie
2004-07-27 20:40 ` Bill Davidsen
2004-07-28 8:00 ` Paul Jackson
2004-08-04 20:03 ` Robert White
2004-08-04 20:42 ` Roger Luethi
2004-07-28 8:05 ` Paul Jackson
2004-07-28 11:54 ` Marc Ballarin
2004-07-28 16:46 ` Rob Landley [this message]
2004-07-28 16:42 ` Rob Landley
2004-07-28 17:08 ` Tristan Wibberley
2004-07-29 23:56 ` Roger Luethi
2004-07-30 0:18 ` Jesper Juhl
2004-07-30 0:22 ` Jesper Juhl
2004-07-30 8:27 ` Marc Ballarin
2004-07-30 8:38 ` Roger Luethi
2004-08-20 10:15 ` Lee Revell
2004-08-20 12:51 ` Marc Ballarin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200407281146.49166.rob@landley.net \
--to=rob@landley.net \
--cc=Ballarin.Marc@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=pj@sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox