|
From: Patrick O. <Pat...@in...> - 2005-03-16 12:45:28
|
On Tue, 2005-03-15 at 17:39 +0000, Tom Hughes wrote:
> In message <111...@ph...>
> Robert Walsh <rj...@du...> wrote:
>
> > > Valgrind will periodically open /proc/self/maps to do some sanity
> > > checking. If the thread changes its id so that it can't open its own
> > > /proc/self/maps, then this will fail. You can use --sanity-level=0 to
> > > turn off the sanity checking. I guess the proper fix would be for
> > > Valgrind to keep /proc/self/maps open from the start in case it gets
> > > into a state where it can't open it later (chroot would also cause this).
> >
> > You often can't seek on stuff in /proc - is maps any different?
>
> So open it once at the start, leave that descriptor along (positioned
> at start of file) and dup it each time you want to read the file ;-)
File descriptors duplicated with dup() share the same file pointer,
so that won't work. From "man dup":
After successful return of dup or dup2, the old and new
descriptors may
be used interchangeably. They share locks, file position
pointers and
flags; for example, if the file position is modified by using
lseek on
one of the descriptors, the position is also changed for the
other.
At least once I also observed problems reading from the /proc file
system with fgets on a 2.4 kernel: the result was garbled as if the
content of the open file had changed while reading it. I'm not sure what
the official, portable solution is, but reading with read() in larger
chunks seemed to help.
What I would expect is that open() creates a snapshot of the current
state and then delivers that static copy. That would defeat the idea of
opening the file only once, but at least it would avoid the race
conditions that seem to exist.
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Software & Solutions Group
Hermuelheimer Strasse 8a
50321 Bruehl
Germany
Tel: +49-2232-2090-30
Fax: +49-2232-2090-29
|