On FreeBSD, Firefox uses the kern.proc.pathname.PID sysctl
to get the binary path (where PID can be the actual pid
or -1). The user path is /usr/local/bin/firefox which is
a symlink to /usr/local/lib/firefox/firefox.
This was failing because we were not handling this MIB.
That meant that the sysctl returned the path for the
binary of the running tool (e.g.,
/home/paulf/scratch/valgrind/memcheck/memcheck-amd64-freebsd).
Firefox looks for files in the same directory.
Since it was the wrong directory it failed to find them and
exited.
I also noticed a lot of _umtx_op errors. On analysis they
are spurious. The wake ops take an "obj" argument, a pointer
to a variable. They only use the address as a key for
lookups and don't read the contents.
Sync VEX/LICENSE.GPL with top-level COPYING file. We used 3 different
addresses for writing to the FSF to receive a copy of the GPL. Replace
all different variants with an URL <http://www.gnu.org/licenses/>.
The following files might still have some slightly different (L)GPL
copyright notice because they were derived from other programs:
- files under coregrind/m_demangle which come from libiberty:
cplus-dem.c, d-demangle.c, demangle.h, rust-demangle.c,
safe-ctype.c and safe-ctype.h
- coregrind/m_demangle/dyn-string.[hc] derived from GCC.
- coregrind/m_demangle/ansidecl.h derived from glibc.
- VEX files for FMA detived from glibc:
host_generic_maddf.h and host_generic_maddf.c
- files under coregrin/m_debuginfo derived from LZO:
lzoconf.h, lzodefs.h, minilzo-inl.c and minilzo.h
- files under coregrind/m_gdbserver detived from GDB:
gdb/signals.h, inferiors.c, regcache.c, regcache.h,
regdef.h, remote-utils.c, server.c, server.h, signals.c,
target.c, target.h and utils.c
Plus the following test files:
- none/tests/ppc32/testVMX.c derived from testVMX.
- ppc tests derived from QEMU: jm-insns.c, ppc64_helpers.h
and test_isa_3_0.c
- tests derived from bzip2 (with embedded GPL text in code):
hackedbz2.c, origin5-bz2.c, varinfo6.c
- tests detived from glibc: str_tester.c, pth_atfork1.c
- test detived from GCC libgomp: tc17_sembar.c
- performance tests derived from bzip2 or tinycc (with embedded GPL
text in code): bz2.c, test_input_for_tinycc.c and tinycc.c
At startup valgrind fetches the current working directory and stashes
it away to be used later (in debug messages, read config files or create
log files). But if the current working directory didn't exist (or there
was some other error getting its path) then valgrind would go in an
endless loop. This was caused by assuming that any error meant a larger
buffer needed to be created to store the cwd path (ERANGE). However
there could be other reasons calling getcwd failed.
Fix this by only looping and resizing the buffer when the error is
ERANGE. Any other error just means we cannot fetch and store the current
working directory. Fix all callers to check get_startup_wd() returns
NULL. Only abort startup if a relative path needs to be used for
user supplied relative log files. Debug messages will just show
"<NO CWD>". And skip reading any config files from the startup_wd
if it doesn't exist.
Also add a new testcase that tests executing valgrind in a deep,
inaccessible and/or non-existing directory (none/tests/nocwd.vgtest).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15989
Change VG_(resolve_filename) to not truncate the result which is returned
in a static buffer now. Fix callsites.
Simplify VG_(di_notify_pdb_debuginfo) to use VG_(resolve_filename).
Fix VG_(readlink) prototype.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14628
This changes VG_(record_startup_wd) to dynamically allocate a large
enough buffer for the directory name. As the dynamic memory manager has
started up a while ago, this is quite safe. Also rewrite VG_(get_startup_wd)
to simply return the directory name. No more messing with copying it
around. Adapt call sites.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14579
getdents has been deprecated since linux 2.4 and newer arches (arm64)
might no longer provide the getdents syscall. Use getdents64 for reading
the /proc/self/fd/ dir so --track-fds=yes works reliable on all arches.
Without this the none/tests/fdleak*vgtest might fail.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14384
I tried using 'svn merge' to do the merge but it did a terrible job and
there were bazillions of conflicts. So instead I just took the diff between
the branch and trunk at r10155, applied the diff to the trunk, 'svn add'ed
the added files (no files needed to be 'svn remove'd) and committed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10156
DARWIN branch. A big ugly DARWIN/trunk sync commit, mostly to do with
changing the representation of SysRes and vki_sigset_t. Functionality of
the trunk shouldn't be changed by it.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9876
family of syscalls is impossible to write in a way that's portable and
correct. On some targets (eg x86-linux) you need to do sys_stat64 and
receive the results in a 'struct vki_stat64'. But on other targets
(eg amd64-linux) neither sys_stat64 nor 'struct vki_stat64' exist.
This commit adds a new type, 'struct vg_stat', which contains 64 bit
fields in all the right places, and makes VG_(stat) and VG_(fstat) use
it. This means callers to the two functions no longer need to worry
about the is-it-64-bit-clean-or-not question, since these routines
reformat the received data into a'struct vg_stat'. Kind of like what
glibc must have been doing for decades.
This (indirectly) fixes a bug on x86-linux, in which m_debuginfo would
sometimes fail to read debug info, due to VG_(di_notify_mmap) using
VG_(stat) (hence sys_stat) on the file, which failed, and when in fact
it should have used sys_stat64. Bug reported and tracked down by
Marc-Oliver Straub.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8522
VG_(record_startup_wd) which records the working directory at startup,
and VG_(get_startup_wd) which later tells you what value was recorded.
This works because all uses of VG_(getcwd) serve only to record the
directory at process start anyway. The motivation is that AIX does
not support sys_getcwd directly, so it's easier for the launcher to
ship in the required value using an environment variable. On Linux
sys_getcwd is used as before.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6764
- AIX implementations of various stuff, nothing surprising.
- For all platforms: make VG_(read) and VG_(write) return (negative)
actual error values rather than producing -1 for all failures.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6267
changes from r4341 through r4787 inclusive). That branch is now dead.
Please do not commit anything else to it.
For the most part the merge was not troublesome. The main areas of
uncertainty are:
- build system: I had to import by hand Makefile.core-AM_CPPFLAGS.am
and include it in a couple of places. Building etc seems to still
work, but I haven't tried building the documentation.
- syscall wrappers: Following analysis by Greg & Nick, a whole lot of
stuff was moved from -generic to -linux after the branch was created.
I think that is satisfactorily glued back together now.
- Regtests: although this appears to work, no .out files appear, which
is strange, and makes it hard to diagnose regtest failures. In
particular memcheck/tests/x86/scalar.stderr.exp remains in a
conflicted state.
- amd64 is broken (slightly), and ppc32 will be unbuildable. I'll
attend to the former shortly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4789
being executed then propagate the error from the stat instead of just
return ENOACCES all the time. Fixes bug #110208.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4330
- m_main: if --log-file-qualifier applies, do not add ".pid"
at the end of the name
- Fix the logic which detected whether the just-devised name
already existed. This was broken (by me) because it could not
distinguish the reasons for failing to open the logfile.
Doing this required changing the return type of VG_(open)
from Int to SysRes (to make failure reasons visible) and
that's the cause of most of the changes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4228
