|
From: Julian S. <js...@ac...> - 2005-09-24 18:28:09
|
The new address space manager (which includes a major overhaul of command-line handling) seems to be working fairly convincingly now. On my reference box I get == 180 tests, 7 stderr failures, 1 stdout failure ================= memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/faultstatus (stderr) none/tests/x86/int (stderr) Other distros have more failures. Of these, the last 2 also happen on the trunk. The remaining ones are leak checker problems -- I think it is scanning too much memory. I'll look at it. Current issues are: ---------- Fix the leak checker. ---------- Reading of args from from $VALGRIND_OPTS, ./.valgrindrc and ~/.valgrindrc is currently disabled (m_commandline.c:augment_command_line). ---------- I'd like to get rid of VG_(client_base) and VG_(client_end) because I don't think they do anything useful any more. However, they are still mentioned in PIE mumbo-jumbo in m_ume.c which I don't understand. ---------- Qt designer and GIMP work, but OOo 1.1.3 is still crashing. It appears that it reads /proc/self/cmdline to find out the executable name and incorporates that in subsequent paths. That doesn't work now since what it gets is "valgrind [vargs] clientname [cargs]" etc, and it all goes south shortly thereafter. OOo does work on 3.0.1. I find that odd given that (AIUI) the stage1/ stage2 scheme is 3.0.X is similar to the aspacem scheme, except for the static vs dynamicness of stage2. Anybody know how this worked on 3.0.1? ---------- I'd like to merge all this back to the trunk early next week. Any objections? J |
|
From: Robert W. <rj...@du...> - 2005-09-24 18:42:41
|
> Qt designer and GIMP work, but OOo 1.1.3 is still crashing. It appears > that it reads /proc/self/cmdline to find out the executable name and > incorporates that in subsequent paths. That doesn't work now since > what it gets is "valgrind [vargs] clientname [cargs]" etc, and it all > goes south shortly thereafter. Hmm. I did a workaround a while back that fixed something in /proc, but can't for the life of me remember what it was. I think it was /proc/self/exe symlink reading. Perhaps we need to similarly intercept /proc/self/cmdline? That's likely to be harder, though, since it's not just a single call that needs to be intercepted. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Julian S. <js...@ac...> - 2005-09-24 19:01:20
|
> Hmm. I did a workaround a while back that fixed something in /proc, but
> can't for the life of me remember what it was. I think it
> was /proc/self/exe symlink reading.
I think it's this:
/*
* Handle the case where readlink is looking at /proc/self/exe or
* /proc/<pid>/exe.
*/
SET_STATUS_from_SysRes( VG_(do_syscall3)(saved, ARG1, ARG2, ARG3));
/* jrs 20050604: where does the magic value 2 come from? It seems
like it should be a kernel error value, but we don't know of any
such. */
if (SWHAT == SsFailure && RES_unchecked == 2) {
HChar name[25];
VG_(sprintf)(name, "/proc/%d/exe", VG_(getpid)());
if (VG_(strcmp)((Char *)ARG1, name) == 0 ||
VG_(strcmp)((Char *)ARG1, "/proc/self/exe") == 0) {
VG_(sprintf)(name, "/proc/self/fd/%d", VG_(clexecfd));
SET_STATUS_from_SysRes( VG_(do_syscall3)(saved, (UWord)name, ARG2,
ARG3));
}
}
Quite an elegant kludge.
> Perhaps we need to similarly intercept /proc/self/cmdline?
Yes. The least worst thing I can think of is to create a file
/tmp/valgrind_fake_proc_self_cmdline_<pid> at startup, and intercept
any attempts to open /proc/self/cmdline and reroute it to said
file instead. Problem is the need to delete the file at the end,
given all the multifarious crashing-out exit points there are.
I'd still like to know how/why 3.0.1 works OK. Perhaps there is
some magic way to tell the kernel to emit something different
from the default stuff in /proc/<pid>/cmdline?
J
|
|
From: Tom H. <to...@co...> - 2005-09-24 21:39:07
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> > Perhaps we need to similarly intercept /proc/self/cmdline?
>
> Yes. The least worst thing I can think of is to create a file
> /tmp/valgrind_fake_proc_self_cmdline_<pid> at startup, and intercept
> any attempts to open /proc/self/cmdline and reroute it to said
> file instead. Problem is the need to delete the file at the end,
> given all the multifarious crashing-out exit points there are.
Create it then delete it but hang on to the file handle and when
the client asks to open /proc/self/cmdline give them a dup of the
handle you are hanging on to.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-09-24 23:21:32
|
> > Yes. The least worst thing I can think of is to create a file > > /tmp/valgrind_fake_proc_self_cmdline_<pid> at startup, and intercept > > any attempts to open /proc/self/cmdline and reroute it to said > > file instead. Problem is the need to delete the file at the end, > > given all the multifarious crashing-out exit points there are. > > Create it then delete it but hang on to the file handle and when > the client asks to open /proc/self/cmdline give them a dup of the > handle you are hanging on to. That sounds great, but you mean there is some kind of filesystem magic which keeps the file alive (in a garbage-collection sense) until all fds which refer to it disappear? I guess so; I've always wondered how those online-update things work, replacing this.so and that.so whilst surely some process is still referencing them. Will try it. Would get us out of a hole if it works. J |
|
From: Nicholas N. <nj...@cs...> - 2005-09-24 23:25:45
|
On Sun, 25 Sep 2005, Julian Seward wrote: > That sounds great, but you mean there is some kind of filesystem magic > which keeps the file alive (in a garbage-collection sense) until all > fds which refer to it disappear? I guess so; I've always wondered > how those online-update things work, replacing this.so and that.so > whilst surely some process is still referencing them. I believe that's the reason why you have to reboot Windows machines so often after installing new software, as opposed to Unix machines -- Windows doesn't automatically hang onto file handles when the corresponding file is deleted, so a program using a deleted file will have the rug pulled out from underneath it. I think Unix uses reference counting in the implementation. N |
|
From: Tom H. <to...@co...> - 2005-09-24 23:34:14
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> > > Yes. The least worst thing I can think of is to create a file
> > > /tmp/valgrind_fake_proc_self_cmdline_<pid> at startup, and intercept
> > > any attempts to open /proc/self/cmdline and reroute it to said
> > > file instead. Problem is the need to delete the file at the end,
> > > given all the multifarious crashing-out exit points there are.
> >
> > Create it then delete it but hang on to the file handle and when
> > the client asks to open /proc/self/cmdline give them a dup of the
> > handle you are hanging on to.
>
> That sounds great, but you mean there is some kind of filesystem magic
> which keeps the file alive (in a garbage-collection sense) until all
> fds which refer to it disappear? I guess so; I've always wondered
> how those online-update things work, replacing this.so and that.so
> whilst surely some process is still referencing them.
Absolutely - on unix a file is represented by an inode which is
entirely separate to any directory entries which may happen to
point at that inode. That's how hard links work - a directory
entry is basically just a name and an inode number and if multiple
directories point at the same inode you have hard links.
An inode is only deleted when there are no directory entries
referring to it and no open file descriptors for it so a file
will continue to exist (but not appear in the filesystem) if
it has been deleted but there are still open descriptors on it.
It is also why you can overwrite a running program - the process
that has the old version mapped continues to see that version but
any new process get the new version as that is where the directory
entry now points.
It's all so much nicer than Windows where overwriting or deleting
an open file will give you a nasty error ;-)
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Maurice v. d. P. <gri...@ge...> - 2005-09-24 19:56:01
|
On Sat, Sep 24, 2005 at 07:27:45PM +0100, Julian Seward wrote: > Qt designer and GIMP work, but OOo 1.1.3 is still crashing. It appears > that it reads /proc/self/cmdline to find out the executable name and > incorporates that in subsequent paths. That doesn't work now since > what it gets is "valgrind [vargs] clientname [cargs]" etc, and it all > goes south shortly thereafter. Would it be worth checking how gdb does it? Reading /proc/self/cmdline =66rom a program running within valgrind 3.0.1 gives "valgrind", but =66rom within gdb it gives the name of the program being run. Regards, Maurice. --=20 Maurice van der Pot Gentoo Linux Developer gri...@ge... http://www.gentoo.org Creator of BiteMe! gri...@kf... http://www.kfk4ever.com |
|
From: Tom H. <to...@co...> - 2005-09-24 21:39:58
|
In message <200...@kf...>
Maurice van der Pot <gri...@ge...> wrote:
> On Sat, Sep 24, 2005 at 07:27:45PM +0100, Julian Seward wrote:
> > Qt designer and GIMP work, but OOo 1.1.3 is still crashing. It appears
> > that it reads /proc/self/cmdline to find out the executable name and
> > incorporates that in subsequent paths. That doesn't work now since
> > what it gets is "valgrind [vargs] clientname [cargs]" etc, and it all
> > goes south shortly thereafter.
>
> Would it be worth checking how gdb does it? Reading /proc/self/cmdline
> from a program running within valgrind 3.0.1 gives "valgrind", but
> from within gdb it gives the name of the program being run.
Under gdb the client program is a separate process with it's own
directory in /proc - gdb just controls it with ptrace.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|