|
From: Burton S. <BSt...@co...> - 2005-03-15 13:17:43
|
Our app does a uid switch with this:
/* user id specified on commandline */
if((setgid(myGlobals.groupId) != 0) || (setuid(myGlobals.userId) != 0)) {
traceEvent(CONST_TRACE_FATALERROR, "Unable to change user ID");
exit(-1);
}
traceEvent(CONST_TRACE_ALWAYSDISPLAY, "Now running as requested user '%s'
(%d:%d)",
myGlobals.effectiveUserName, myGlobals.userId,
myGlobals.groupId);
Once the switch occurs, valgrind (rc4) fails shortly after:
Tue 15 Mar 2005 07:03:43 AM CST Plugins started... continuing with
initialization
Tue 15 Mar 2005 07:03:43 AM CST Now running as requested user 'ntop'
(1001:100)
Tue 15 Mar 2005 07:03:43 AM CST INIT: Created pid file
(/devel/ntop/ntop.pid)
Tue 15 Mar 2005 07:03:43 AM CST Device 0. eth1
(active)
Tue 15 Mar 2005 07:03:43 AM CST Device 1. eth2
(active)
Tue 15 Mar 2005 07:03:43 AM CST Note: Reporting device initally set to 0
[eth1]
==15519== TRANSLATE: 0x1CCAECC0 redirected to 0x1B902F87
Tue 15 Mar 2005 07:03:43 AM CST MEMORY: Base memory load is 0.01MB (0+0)
Tue 15 Mar 2005 07:03:43 AM CST MEMORY: Base interface structure (no hashes
loaded) is 0.28MB each
Tue 15 Mar 2005 07:03:43 AM CST MEMORY: or 0.55MB for 2 interfaces
Tue 15 Mar 2005 07:03:43 AM CST MEMORY: ipTraffixMatrix structure (no
TrafficEntry loaded) is 8.01MB
Tue 15 Mar 2005 07:03:43 AM CST THREADMGMT: pcapDispatch(eth1) thread
running [p15519, t585038768]...
Tue 15 Mar 2005 07:03:43 AM CST THREADMGMT: Started thread (585038768) for
network packet sniffing on eth1
Tue 15 Mar 2005 07:03:43 AM CST THREADMGMT: Started thread (595532720) for
network packet sniffing on eth2
Tue 15 Mar 2005 07:03:43 AM CST THREADMGMT: pcapDispatch(eth2) thread
running [p15519, t595532720]...
==15519== FATAL: can't open /proc/self/maps
If I disable the switch with our (-u root) parameter (which I can live
with), it doesn't fail:
Tue 15 Mar 2005 07:05:26 AM CST Now running as requested user 'root' (0:0)
Tue 15 Mar 2005 07:05:26 AM CST INIT: Created pid file (/var/run/ntop.pid)
Tue 15 Mar 2005 07:05:26 AM CST Device 0. eth1
(active)
Tue 15 Mar 2005 07:05:26 AM CST Device 1. eth2
(active)
Tue 15 Mar 2005 07:05:26 AM CST Note: Reporting device initally set to 0
[eth1]
==15535== TRANSLATE: 0x1CCAECC0 redirected to 0x1B902F87
Tue 15 Mar 2005 07:05:26 AM CST MEMORY: Base memory load is 0.01MB (0+0)
Tue 15 Mar 2005 07:05:26 AM CST MEMORY: Base interface structure (no hashes
loaded) is 0.28MB each
Tue 15 Mar 2005 07:05:26 AM CST MEMORY: or 0.55MB for 2 interfaces
Tue 15 Mar 2005 07:05:26 AM CST MEMORY: ipTraffixMatrix structure (no
TrafficEntry loaded) is 8.01MB
Tue 15 Mar 2005 07:05:26 AM CST THREADMGMT: pcapDispatch(eth1) thread
running [p15535, t585038768]...
Tue 15 Mar 2005 07:05:27 AM CST THREADMGMT: Started thread (585038768) for
network packet sniffing on eth1
Tue 15 Mar 2005 07:05:27 AM CST THREADMGMT: pcapDispatch(eth2) thread
running [p15535, t595532720]...
Tue 15 Mar 2005 07:05:27 AM CST THREADMGMT: Started thread (595532720) for
network packet sniffing on eth2
Tue 15 Mar 2005 07:05:46 AM CST RRD: Cycle 1 ended, 0 RRDs updated
Tue 15 Mar 2005 07:07:56 AM CST FINGERPRINT: ending cycle 1 - checked 2,
resolved 2
Tue 15 Mar 2005 07:10:27 AM CST FINGERPRINT: ending cycle 2 - checked 1,
resolved 1
Tue 15 Mar 2005 07:10:47 AM CST RRD: Cycle 2 ended, 195 RRDs updated
However, 2.2 works fine w/o the parameter.
It's hard to tell what's causing the error, as there is a lot of processing
between the 'thread running' message and any subsequent log messages. And
running valgrind under gdb gives a SIGSEGV very early on.
Command line:
/usr/bin/valgrind --verbose --suppressions=/devel/ntop/valgrind.supp
--leak-check=yes --trace-children=yes --num-callers=6 --gen-suppressions=yes
/devel/bin/ntop -i eth1,eth2 @/etc/ntopdevel.conf
-----Burton
|
|
From: Jeremy F. <je...@go...> - 2005-03-15 17:29:32
|
Burton Strauss wrote:
>However, 2.2 works fine w/o the parameter.
>
>It's hard to tell what's causing the error, as there is a lot of processing
>between the 'thread running' message and any subsequent log messages.
>
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).
J
|
|
From: Robert W. <rj...@du...> - 2005-03-15 17:35:34
|
> Valgrind will periodically open /proc/self/maps to do some sanity=20 > checking. If the thread changes its id so that it can't open its own=20 > /proc/self/maps, then this will fail. You can use --sanity-level=3D0 to=20 > turn off the sanity checking. I guess the proper fix would be for=20 > Valgrind to keep /proc/self/maps open from the start in case it gets=20 > 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? --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Burton S. <BSt...@co...> - 2005-03-15 18:44:32
|
Yup it's 2.6 and yes, --sanity-level=0 worked around it.
Thanks!
-----Burton
-----Original Message-----
From: Jeremy Fitzhardinge [mailto:je...@go...]
Sent: Tuesday, March 15, 2005 11:29 AM
To: Burton Strauss
Cc: val...@li...
Subject: Re: [Valgrind-users] BUG(?) w/ setuid()/setgid() and threads ??
Burton Strauss wrote:
>However, 2.2 works fine w/o the parameter.
>
>It's hard to tell what's causing the error, as there is a lot of
>processing between the 'thread running' message and any subsequent log
messages.
>
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).
J
|
|
From: Jeremy F. <je...@go...> - 2005-03-15 17:39:14
|
Robert Walsh wrote:
>You often can't seek on stuff in /proc - is maps any different?
>
/proc/<pid>/maps is seekable. In fact, all the file-like-files are
seekable, I think.
J
|
|
From: Tom H. <to...@co...> - 2005-03-15 17:39:56
|
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 ;-)
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
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
|
|
From: Robert W. <rj...@du...> - 2005-03-15 17:44:19
|
> >You often can't seek on stuff in /proc - is maps any different? > > > /proc/<pid>/maps is seekable. In fact, all the file-like-files are > seekable, I think. Maybe maps is special or this is a recent feature? The stuff that ganglia looks at (like loadavg) definitely isn't seekable on all the platforms it cares to support, so it has to open them each time. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Bryan O'S. <bo...@se...> - 2005-03-15 18:03:39
|
On Tue, 2005-03-15 at 09:44 -0800, Robert Walsh wrote: > > >You often can't seek on stuff in /proc - is maps any different? > > > > > /proc/<pid>/maps is seekable. In fact, all the file-like-files are > > seekable, I think. > > Maybe maps is special or this is a recent feature? The stuff that > ganglia looks at (like loadavg) definitely isn't seekable on all the > platforms it cares to support, so it has to open them each time. It's new in 2.6. A lot of /proc files have changed over to the seq_file interface, which supports seeking (although not to random offsets). Some have not, though. <b -- Bryan O'Sullivan <bo...@se...> |