structure to match the address of the instruction in the client program
which caused the fault.
CCMAIL: 88115-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2623
rendezvous with another thread before the signal arrived then check
whether the rendezvous is now complete or we may deadlock.
CCMAIL: 77369-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2621
Two were trivial. The one for strncmp is slightly trickier; you have to be
careful with the signedness of chars when comparing them... but the code
already casts s1 and s2 to (unsigned char*) before comparing them, so it's not
a problem.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2618
in C99 but not in C89 except as a GNU extension so it's probably
best not to rely on it.
Patch from Jeroen N. Witmond <jnw@xs4all.nl>.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2617
bit before "$(subdir)" has to specify the path from .in_place/ to the root.
It just so happened that $(top_builddir) was the same for all directories at
the same level in the hierarchy as .in_place/ (ie. one deep).
(I haven't bothered changing it in all the tool Makefile.am files, because I'll
do that when I factor out all their common bits into a single file, be it
before or after 2.2.0 is released.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2616
- introduce $(inplacedir) like everywhere else
- valgrind.spec doesn't need to be included in "make dist", because it gets
built from valgrind.spec.in at configure-time.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2615
dist". This avoids the need to put it in "EXTRA_DIST", and saves a few lines
in all the docs Makefile.am files.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2614
generate ugly warnings by trying to compile it.
Patch from Eric Estievenart <eric.estievenart@free.fr>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2613
NOT allow Valgrind to work with 64-bit executables - only with 32-bit
executables on an AMD64 box.
VG_(valgrind_end) now has a slightly different meaning to all the other
VG_(*_end) vars -- ie. it names the last byte, whereas the others go
one byte past the end.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2606
glibc - it doesn't matter for valgrind as we only have one version and
by not versioning them we work no matter what version is asked for.
CCMAIL: 86289-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2605
__attribute((regparm(n))) with REGPARM(n) everywhere. REGPARM() is defined in
vg_skin.h, but will eventually be defined separately for each arch.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2601
variables VG_ARCH, VG_OS and VG_PLATFORM (which equals ${VG_ARCH}-${VG_OS}).
Also added a check for the platform (arch/OS) combination.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2600
except it doesn't actually get built and so ex_main.c and the Makefile.am tend
to get out of date. Changed the docs to refer to Nulgrind as the example tool
for if you start writing a new one.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2599
as part of FV, but then later these changes become unnecessary. Anyway, it now
looks more like the other tools again.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2598
lower than that of any existing segment, it got it wrong due to the confusing
SkipList API. I wonder how many more bugs like that there are...?
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2596
for the original function with RTLD_NEXT doesn't work then try looking
for the __libc_ version of the function the RTLD_DEFAULT instead.
The reason for this is that, contrary to the dlsym documentation, it
seems that RTLD_NEXT doesn't always seem to find the definition that
would have been used if it weren't for the override. This is particularly
common wihen libpthread is pulled in implicitly by a dependency from
another library.
This should hopefully fix bug #85658.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2595
- corrected a few mistakes, eg. when printing them out, in prototypes
- made printing of "%p(%s)" args consistent
- removed 'sizeof_struct_user_fpxregs_struct' from PRE(ptrace)/POST(ptrace)
- allowing for the two different versions of open()
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2591
of VgTs_WaitJoiner) as non-existent for the purposes of cancellation.
This ensures that pthread_cancel returns ESRCH instead of trying to
cancel the thread, which would lead to the thread cleanup code being
run twice.
CCMAIL: 86730-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2587
library - it seems that I misunderstood hom the versioning works and
a system looking for a GLIBC_PRIVATE version of the clock routines
would not find the GLIB_2.2.3 one even with the inheritance. It only
seemed to be working on glibc 2.3 systems because of the version
overrides in the source code, but it failed on glibc 2.2.5 systems.
The new approach is to explicity create two versions of the routines
in question, one with a version of GLIBC_2.2.3 and one with a version
of GLIBC_PRIVATE instead. This has been tested on six different systems
and appears to work everywhere.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2586
that it is called as soon as libpthread.so is loaded even if pthread_create
is never called.
This ensures that pthread_exit will work correctly, and I think will also
cure the famous memory leak in the pthread specifics for the main thread.
CCMAIL: 86730-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2584
the GLIBC_2.2.3 section which is where they were in glibc before
they were moved to GLIBC_PRIVATE around the 2.2.5 time frame.
This makes older systems work correctly as librt will be looking
for the symbols with that version. In order to make newer systems
work we make GLIBC_PRIVATE a child of the most recent version in
the file (currently GLIBC_2.3.3) so that a librt which is looking
for the symbols with a version of GLIBC_PRIVATE will find them.
The real glibc pthread libraries have GLIBC_PRIVATE as a child of
the most recent version anyway, so this shouldn't cause any problems
and with this change librt seems to be OK both on old RedHat 7.1 systems
with glibc 2.2.3 and on Fedora Core 2 systems with glibc 2.3.3.
Hopefully this will fix FAQ 3.4 but I haven't removed that just yet.
CCMAIL: 86696-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2581
opcodes are properly validated. Using memcheck on ipcs now produces
no warnings on my machine.
This commit fixes bug #86987.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2580
lots of the details changed. Made the following generalisations:
- Recast everything to be entirely terms of bytes, instead of a mixture
of (32-bit) words and bytes. This is a bit easier to understand, and
made the following generalisations possible...
- Almost 64-bit clean; no longer assuming 32-bit words/pointers. Only
(I think) non-64-bit clean part is that VG_(malloc)() et al take an
Int as the size arg, and size_t is 64-bits on 64-bit machines.
- Made the alignment of blocks returned by malloc() et al completely
controlled by a single value, VG_MIN_MALLOC_SZB. (Previously there
were various magic numbers and assumptions about block alignment
scattered throughout.) I tested this, all the regression tests pass
with VG_MIN_MALLOC_SZB of 4, 8, 16, 32, 64. One thing required for
this was to make redzones elastic; the asked-for redzone size is now
the minimum size; it will use bigger ones if necessary to get the
required alignment.
Some other specific changes:
- Made use of types a bit more; ie. actually using the type 'Block',
rather than just having everything as arrays of words, so that should
be a bit safer.
- Removed the a->rz_check field, which was redundant wrt. a->clientmem.
- Fixed up the decision about which list to use so the 4 lists which
weren't ever being used now are -- the problem was that this hasn't
been properly updated when alignment changed from 4 to 8 bytes.
- Added a regression test for memalign() and posix_memalign().
memalign() was aborting if passed a bad alignment argument.
- Added some high-level comments in various places, explaining how the
damn thing works.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2579
(fewer) functions.
Also fixed execve() so that it works better with .in_place.
Also added a regression test for --trace-children=yes (there were none!)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2577
vg_include.h, where they must be otherwise vg_libtpthread.c has problems.
Added a comment explaining why they must be in vg_include.h.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2576
