Tom Hughes [Wed, 17 Nov 2004 00:02:04 +0000 (00:02 +0000)]
Change VG_(nuke_all_threads) to disassociate the the stacks of the threads
being killed from the threads rather than marking them as inaccessible.
This should fix the problem with the environment (and other data from the
stacks of other threads) causing warnings after a fork. I believe that
VG_(nuke_all_threads) is only called in places where this is the behaviour
that we want or where it doesn't matter because we're about to exit anyway.
Tom Hughes [Tue, 16 Nov 2004 19:44:06 +0000 (19:44 +0000)]
The calculation used to round the size of a new thread's stack to a
multiple of the page size had an off by one error. Fixed it to use
the PGROUNDUP macro instead of trying to do the calculation itself
and then get it wrong.
Tom Hughes [Fri, 29 Oct 2004 18:36:17 +0000 (18:36 +0000)]
When a thread is cancelled only abort pending system calls if
the thread is set for asynchronous cancellation and cancellation
is enabled. This fixes a long standing occasional failure in
the pth_cancel2 test.
Tom Hughes [Thu, 28 Oct 2004 08:16:38 +0000 (08:16 +0000)]
Yet another attempt to quash the assertions in the pthread forwarding code.
It appears that the resolution of the address is to forward to is now
working properly but that on some systems the second part of the assertion
fails because the dynamic linker resolves the name of the function being
forwarded to the glibc version rather than the version in valgrind's pthread
library.
The solution is to use dlopen to explicitly obtain a handle to valgrind's
pthread library and then lookup the symbol with dlsym when doing the
comparison in the assertion.
Tom Hughes [Thu, 28 Oct 2004 08:15:38 +0000 (08:15 +0000)]
The fix for bug 85811 added decoding of many extra negative type
numbers in stabs and also removed the expectation of a trailing
semicolon after the type number as gcc didn't seem to be putting
one in. It seems that older gcc's do add one however, so we now
skip one if it is there.
Tom Hughes [Thu, 28 Oct 2004 08:09:53 +0000 (08:09 +0000)]
Fixed get_height to ensure that SK_MAXHEIGHT-1 is the maximum level we
will allocate for a skip list entry as many routines use arrays of
size SK_MAXHEIGHT to hold a set of level pointers which means that a
level of SK_MAXHEIGHT is not valid due to C arrays being zero based.
This led to a number of subtle and hard to locate problems caused by
stack based arrays being overflowed by one entry when a node was
allocated with the maximum level. As each node only has a one in two
million or so chance of getting a level of SK_MAXHEIGHT this didn't
actually happen all that often.
Tom Hughes [Thu, 28 Oct 2004 07:56:44 +0000 (07:56 +0000)]
When augmenting the argument vector from the VALGRIND_OPTS environment
variable and/or the .valgrindrc files, make sure that enough space is
allocated for all the old arguments, not just those that are arguments
to valgrind itself.
Fix for bug 91162: cope with jumps to bogus addresses when there is a SEGV
signal handler present -- previously, Valgrind would abort unnecessarily on
this case.
Add README_DEVELOPERS to the 'make dist' tarball (since it's mentioned in
README), and add some instructions about attaching GDB to Valgrind itself
within it.
To get 32-bit programs working on Opteron, VG_(valgrind_end) was recently
changed to name the last byte in Valgrind's section, rather than one past the
last byte. This was because the last byte is 0xffffffff, and so one past gave
0x0, which screwed things up.
However, when this change was made, all the places where VG_(valgrind_end) is
used weren't adjusted appropriately. So this commit makes those adjustments.
It also renames the variable as VG_(valgrind_last), which makes the difference
between it and the other VG_(*_end) variables much clearer.
Tom Hughes [Mon, 30 Aug 2004 10:31:21 +0000 (10:31 +0000)]
Recognise X.Org servers and treat them the same as XFree86 4.x servers. This
avoids warnings from configure about an unknown X server type on recent Linux
distributions that use X.Org instead of XFree86.
Tom Hughes [Thu, 26 Aug 2004 23:09:26 +0000 (23:09 +0000)]
When delivering SIGFPE make sure we patch up si_addr in any siginfo
structure to match the address of the instruction in the client program
which caused the fault.
Tom Hughes [Wed, 25 Aug 2004 18:58:04 +0000 (18:58 +0000)]
If we return from a signal handler to a thread that was waiting to
rendezvous with another thread before the signal arrived then check
whether the rendezvous is now complete or we may deadlock.
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.
Tom Hughes [Wed, 25 Aug 2004 13:25:30 +0000 (13:25 +0000)]
Removed comma at the end of an enumerator list - this is allowed
in C99 but not in C89 except as a GNU extension so it's probably
best not to rely on it.
Fix symlinking -- the old code worked, but worked for the wrong reason; the
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.)
Minor fixups:
- 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.
Putting "dist_" in front of a "_DATA" variable means it is included in "make
dist". This avoids the need to put it in "EXTRA_DIST", and saves a few lines
in all the docs Makefile.am files.
Robert Walsh [Mon, 23 Aug 2004 18:13:16 +0000 (18:13 +0000)]
Fix to allow 32-bit Valgrind to run on AMD64 boxes. Note: this does
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.
Tom Hughes [Mon, 23 Aug 2004 18:05:51 +0000 (18:05 +0000)]
Don't version the sem_xxx symbols that have more than one version in
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.
Small step in factoring out arch-specific code: replace
__attribute((regparm(n))) with REGPARM(n) everywhere. REGPARM() is defined in
vg_skin.h, but will eventually be defined separately for each arch.
Tweak configure.in in preparation for arch and OS ports -- we now have
variables VG_ARCH, VG_OS and VG_PLATFORM (which equals ${VG_ARCH}-${VG_OS}).
Also added a check for the platform (arch/OS) combination.
Removing the example tool 'example' -- it's almost identical to Nulgrind,
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.
Make some changes to Nulgrind -- it looks like Jeremy made some changes to it
as part of FV, but then later these changes become unnecessary. Anyway, it now
looks more like the other tools again.
Fix bug, courtesy of Paul Mackerras: when giving find_map_space an address
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...?
Tom Hughes [Sun, 22 Aug 2004 22:56:25 +0000 (22:56 +0000)]
More fixes for the cancellation wrappers in libpthread - if looking
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.
Cleaned up the syscall wrappers a bit:
- 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()
Tom Hughes [Sun, 15 Aug 2004 14:11:12 +0000 (14:11 +0000)]
Back out yesterday's change to the symbol versioning in the pthread
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.
Tom Hughes [Sat, 14 Aug 2004 15:37:59 +0000 (15:37 +0000)]
Maek init_global_thread_specific_state as a constructor to try and ensure
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.
Tom Hughes [Fri, 13 Aug 2004 22:49:11 +0000 (22:49 +0000)]
Move __pthread_clock_gettime and __pthread_clock_settime back to
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.
Tom Hughes [Fri, 13 Aug 2004 22:21:51 +0000 (22:21 +0000)]
Improve handling of semctl, msgctl and shmctl so that all relevant
opcodes are properly validated. Using memcheck on ipcs now produces
no warnings on my machine.
Big overhaul of the allocator. Much of the structure is the same, but
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.
Put VALGRIND_INTERNAL_PRINTF and VALGRIND_INTERNAL_PRINTF_BACKTRACE back in
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.
Made cpu-feature detection simpler -- got rid of the confusing global state,
put it all into static state within a single function. Also, now the callers
of get_cpu_features() don't have to worry about whether it's been called
before.
projects / thirdparty / valgrind.git / log
