History log of /external/valgrind/helgrind/hg_errors.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
328d6627c26471332610da3f5a0b9cc3cdd410c7 25-May-2015 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> This patch decreases significantly the memory needed for OldRef and
slightly increases the performance. It also moderately improves
the nr of cases where helgrind can provide the stack trace of the old
access (when using the same amount of memory for the OldRef entries).
The patch also provides a new helgrind monitor command to show
the recorded accesses for an address+len, and adds an optional argument
lock_address to the monitor command 'info locks', to show the info
about just this lock.

Currently, oldref are maintained in a sparse WA, that points to N
entries, as specified by --conflict-cache-size=N.
For each entry (associated to an address), we have the last 5 accesses.

Old entries are recycled in an exact LRU order.
But inside an entry, we could have a recent access, and 4 very
old accesses that are kept 'alive' by a single thread accessing
repetitively the address shared with the 4 other old entries.


The attached patch replaces the sparse WA that maintains the OldREf
by an hash table.
Each OldRef now also only maintains one single access for an address.
As an OldRef now maintains only one access, all the entries are now
strictly in LRU mode.

Memory used for OldRef
-----------------------
For the trunk, an OldRef has a size of 72 bytes (on 32 bits archs)
maintaining up to 5 accesses to the same address.
On 64 bits arch, an OldRef is 104 bytes.

With the patch, an OldRef has a size of 32 bytes (on 32 bits archs)
or 56 bytes (on 64 bits archs).

So, for one single access, the new code needs (on 32 bits)
32 bytes, while the trunk needs only 14.4 bytes.
However, that is the worst case, assuming that the 5 entries in the
accs array are all used.
Looking on 2 big apps (one of them being firefox), we see that
we have very few OldRef entries that have the 5 entries occupied.
On a firefox startup, of the 5x1,000,000 accesses, we only have
1,406,939 accesses that are used.
So, in average, the trunk uses in reality around 52 bytes per access.

The default value for --conflict-cache-size has been doubled to 2000000.
This ensures that the memory used for the OldRef is more or less the
same as the trunk (104Mb for OldRef entries).

Memory used for sparseWA versus hashtable
-----------------------------------------
Looking on 2 big apps (one of them being firefox), we see that
there are big variations on the size of the WA : it can go in a few
seconds from 10MB to 250MB, or can decrease back to 10 MB.
This all depends where the last N accesses were done: if well localised,
the WA will be small.
If the last N accesses were distributed over a big address space,
then the WA will be big: the last level of WA (the biggest memory consumer)
uses slightly more than 1KB (2KB on 64 bits) for each '256 bytes' memory
zone where there is an oldref. So, in the worst case, on 32 bits, we
need > 1_000_000_000 sparseWA memory to keep 1_000_000 OldRef.

The hash table has between 1 to 2 Word overhead per OldRef
(as the chain array is +- doubled each time the hash table is full).
So, unless the OldRef are extremely localised, the overhead of the
hash table will be significantly less.

With the patch, the core arena total alloc is:
5299535/1201448632 totalloc-blocks/bytes
The trunk is
6693111/3959050280 totalloc-blocks/bytes
(so, around 1.20Gb versus 3.95Gb).
This big difference is due to the fact that the sparseWA repetitively
allocates then frees Level0 or LevelN when OldRef in the region covered
by the Level0/N have all been recycled.

In terms of CPU
---------------
With the patch, on amd64, a firefox startup seems slightly faster (around 1%).
The peak memory mmaped/used decreases by 200Mb.
For a libreoffice test, the memory decreases by 230Mb. CPU also decreases
slightly (1%).


In terms of correctness:
-----------------------
The trunk could potentially show not the most recent access
to the memory of a race : the first OldRef entry matching the raced upon
address was used, while we could have a more recent access in a following
OldRef entry. In other words, the trunk only guaranteed to find the
most recent access in an OldRef, but not between the several OldRef that
could cover the raced upon address.
So, assuming it is important to show the most recent access, this patch
ensures we really show the most recent access, even in presence of overlapping
accesses.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15289 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
f631b021ceaf3a2fd3908a413255c3d82b88dea5 13-Mar-2015 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Sort locks by their guestaddr to make the error output independent
of the dynamically allocated Lock addresses.
This restores helgrind/tests/locked_vs_unlocked2.stderr.exp
from r14931.

While regtesting the patch I've observed intermittent failures
of helgrind/tests/hg05_race2 like so:

--- ../../helgrind/tests/hg05_race2.stderr.exp (revision 15001)
+++ ../../helgrind/tests/hg05_race2.stderr.exp (working copy)
@@ -26,8 +26,7 @@
at 0x........: th (hg05_race2.c:17)
by 0x........: mythread_wrapper (hg_intercepts.c:...)
...
- Location 0x........ is 0 bytes inside foo.poot[5].plop[11],
- declared at hg05_race2.c:24, in frame #x of thread x
+ Address 0x........ is on thread #x's stack

----------------------------------------------------------------

@@ -42,8 +41,7 @@
at 0x........: th (hg05_race2.c:17)
by 0x........: mythread_wrapper (hg_intercepts.c:...)
...
- Location 0x........ is 0 bytes inside foo.poot[5].plop[11],
- declared at hg05_race2.c:24, in frame #x of thread x
+ Address 0x........ is on thread #x's stack

Surely, that's something else.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15009 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
f7ec77f53fd09a5682dbe6db049efe0746df7948 24-Nov-2014 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> Change pub_tool_addrinfo.h AddrInfo and VG_(describe_addr) so as to describe
anonymous or file mmap-ed segments and shared memory segments.

* pub_tool_addrinfo.h:
new AddrTag Addr_SegmentKind // Client segment (mapped memory)
new struct SegmentKind in AddrInfo

* m_addrinfo.c:
If address is still undescribed, try to describe by findinf a client segment.

* update various tests

* mc_errors.c:
add a call to VG_(clear_addrinfo) in MC_(pp_describe_addr)
as the memory allocated in the local AddrInfo has to be cleared once
info is printed.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14779 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
e08950b4ce5a3f5d75a7279548f975cd6207dc74 13-Nov-2014 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Merge revisions 14445 and 14446 from the BUF_REMOVAL branch to trunk.
Two things:
- remove the buffer argument from VG_(DebugInfo_sect_kind)
- allocate AddrInfo::SectKind::objname dynamically


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14719 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
8e3fbb5cd8276a7d07d5712bc05f9b3376d81a6a 20-Oct-2014 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Constify the tool interface.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14642 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
3e81b8bed1f7ab6848a83f5507487131a6f9d778 07-Oct-2014 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Merge revisions 14230, 14602, and 14604 from the BUF_REMOVAL branch to trunk.
The change eliminates the fixed size buffers in gen_suppression and
show_used_suppressions. This is achieved by changing the return type from
VG_TDICT_CALL(tool_get_extra_suppression_info and
VG_TDICT_CALL(tool_print_extra_suppression_use from Bool to SizeT.
A return value of 0 indicates that nothing (except the terminating '\0'
which is always inserted) was written to the buffer. This corresponds to the
previous False return value. A return value which is equal to the buffer
size (that was passed in as function argument) indicates that the buffer was
not large enough. The caller then resizes the buffer and retries.
Otherwise, the buffer was large enough.
Regtested with a resize value of 1.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14606 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
6aa8bd03abedae0a3d210eaaf76b2f25775b731a 15-Sep-2014 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Tidy up m_wordfm.
First, as the allocator function does not fail, there is no need
to assert its return value.
Second, remove commented out (since r8765) function VG_(isEmptyFM).
Third, remove VG_(getNodeSizeFM) from the API. The details of the
implementation do not need to be exposed.
Fourth, for consistency require that the copy functions for keys and
values in VG_(dopyFM) (which are essentially like allocators) return
non-NULL values for non-NULL arguments if they return.
Fifth, document NULL-ness of return values for VG_(newFM), VG_(dopyFM),
and VG_(newBag). Remove pointless asserts at call sites.
Six, change avl_dopy to assert that the node the function is
supposed to copy is not NULL. It is called that way anyhow. With
that change the function never returns NULL which allows us to
simplify the call sites. Checking the return value is no longer needed.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14535 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
68790a73bcb290746a5b34c44538c3b2728eaaec 13-Sep-2014 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> VG_(malloc/calloc/strdup) never return NULL (and never will).
So it's pointless to test or assert their return values.
Remove code doing so.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14528 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
4fa71081858358c26ad182b82d2ddc305b2e72f1 01-Sep-2014 mjw <mjw@a5019735-40e9-0310-863c-91ae7b9d1cf9> Bug 338703 helgrind on arm-linux gets false positives in dynamic loader.

There are a couple of issues with helgrind on arm-linux with glibc:

- Thread creation stack traces cannot unwind through clone
(cfi ends right after syscall)
- ld.so has a special "hard float" name that isn't recognized as special
(ld-linux-armhf.so.3)
- Races are found when manipulating GOT sections.

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14407 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
46daf0d598c38c9251964712d894f0fcd3cc4143 29-Jul-2014 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> Helgrind lock related error msg improvements.

* Add lock announcements in various helgrind errors that were not
announcing the locks
* ensure locks are also announced in xml (note that this is compatible
with xml protocol version 4, so no impact on GUI which properly
implement the protocol)

Changes done:
* Like other HG record_error functions, HG_(record_error_LockOrder) is
now passing Lock* rather than lock guest addresses.
* update exp files for tests that were showing locks without announcing them
* change tc14_laog_dinphils.c and tc15_laog_lockdel.c so as to
have same sizes on 32 and 64 bits systems for allocated or symbol sizes.
* factorise all code that was announcing first lock observation
* enable xml lock announcement





git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14204 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
dbacc09bbfff05b4bf2c2f88a0f087420c76c779 25-Jul-2014 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> Small follow up to lock address description: now that we describe
lock address, we can print something even if the lock observation
has no stacktrace.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14190 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
8061201f9eaaf2fc6a672f631310662749a6527f 24-Jul-2014 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> Describe the lock address in a lock announcement message.

(note that some error messages are not announcing the lock,
which is not that nice).
At least the lock order violation message do not announce locks.
That should be improved/fixed



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14188 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
0c9ac8d0deca2f2a552fb2b0cab24efe6191bac7 18-Jul-2014 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> Patch adding (or showing the proper/not confusing) helgrind thread nr for block
and stack address description.

* A race condition on an allocated block shows the stacktrace, but
does not show the thread # that allocated the block.
This patch adds the output of the thread # that allocated the block.

* The patch also fixes the confusion that might appear between
the core threadid and the helgrind thread nr in Stack address description:
A printed stack addrinfo was containing a thread id, while all other helgrind
messages are using (supposed to use) an 'helgrind thread #' which
is used in the thread announcement.

Basically, the idea is to let a tool set a "tool specific thread nr'
in an addrinfo.
The pretty printing of the addrinfo is then by preference showing this
thread nr (if it was set, i.e. different of 0).
Currently, only helgrind uses this addrinfo tnr.

Note: in xml mode, the output is matching the protocol description.
I.e., GUI should not be impacted by this change, if they properly implement
the xml protocol.


* Also, make the output produced by m_addrinfo consistent:
The message 'block was alloc'd at' is changed to be like all other
output : one character indent, and starting with an uppercase



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14175 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
07c08527f05caeb0062b42ca9a58ee774ec5fba1 14-May-2014 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> Factorises the address code description and printing
of memcheck and helgrind in a common module:
pub_tool_addrinfo.h pub_core_addrinfo.h m_addrinfo.c

At the same time, the factorised code is made usable by other
tools also (and is used by the gdbserver command 'v.info location'
which replaces the helgrind 'describe addr' introduced 1 week ago
and which is now callable by all tools).

The new address description code can describe more addresses
(e.g. for memcheck, if the block is not on the free list anymore,
but is in an arena free list, this will also be described).

Similarly, helgrind address description can now describe more addresses
when --read-var-info=no is given (e.g. global symbols are
described, or addresses on the stack are described as
being on the stack, freed blocks in the arena free list are
described, ...).
See e.g. the change in helgrind/tests/annotate_rwlock.stderr.exp
or locked_vs_unlocked2.stderr.exp

The patch touches many files, but is basically a lot of improvements
in helgrind output files.
The code changes are mostly refactorisation of existing code.




git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13965 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
f57743408d27fedf60a7b48d25339d51b1f8a055 03-May-2014 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> Helgrind : two new gdbserver commands 'describe address' and 'info locks'
- Helgrind GDB server monitor command 'describe <address>'
allowing to describe an address (e.g. where it was allocated).
- Helgrind GDB server monitor command 'info locks' giving
the list of locks, their location, and their status.

In a further patch, it is intended to
1. factorise the describe address code between memcheck and helgrind
2. generalise the describe address gdbsrv command so as to make
it usable for all tools.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13930 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
0f157ddb404bcde7815a1c5bf2d7e41c114f3d73 18-Oct-2013 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Update copyright dates (20XY-2012 ==> 20XY-2013)


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13658 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
4e32d67a5b880bf1d871c5141822078d4dcdc3ac 18-Oct-2013 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> Allow tools to provide some statistics in suppression list produced at the end

Option -v outputs a list of used suppressions. This only gives
the nr of times a suppression was used.
For a leak search, this only gives the nr of loss records that
have been suppressed, but it does not give additional needed details
to understand more precisely what has been suppressed
(i.e. nr of blocks and nr of bytes).

=> Add in the tool interface update_extra_suppression_use and
print_extra_suppression_info functions to allow the tool to record
additioonal use statistics for a suppression. These statistics
can be done depending on the error (and its data) which is suppressed.

Use this in memcheck for the leak suppressions, to maintain and output
the nr of blocks and bytes suppressed by a suppression during
the last leak search.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13651 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
362441db825242200142a91bb07c4a0300b36a3e 23-Jul-2013 philippe <philippe@a5019735-40e9-0310-863c-91ae7b9d1cf9> fix incorrect lineno in supp error msgs+ -v give filename+lineno of used supp.

If a suppression file contains an error, the lineno reported could be wrong.
Also, give filename and lineno of the used suppressions in -v debugging output.

The fix consists in ensuring that tool specific read_extra function gets
the Int* lineno pointer, together with other VG_(get_line) parameters.






git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13469 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
6bd9dc18c043927c1196caba20a327238a179c42 23-Nov-2012 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Changes to allow compilation with -Wwrite-strings. That compiler option
is not used for testcases, just for valgrind proper.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13137 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
19f91bbaedb4caef8a60ce94b0f507193cc0bc10 10-Nov-2012 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Fix more Char/HChar mixups. Closing in...


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13119 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
dbb3584f591710a15a437918c0fc27e300993566 27-Oct-2012 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> More Char/HChar fixes and constification.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13088 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
e543f3024ace2925a0fb81985e9fcfc95b8c555a 21-Oct-2012 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> First round of Char/HChar fixups for coregrind and memcheck.
Little bit of ripple in tools, too.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13074 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
6bf3726ebf7a04ca48a5e6cb1ad7a3065054e54e 21-Oct-2012 florian <florian@a5019735-40e9-0310-863c-91ae7b9d1cf9> Fix Char/HChar mixups in helgrind and then some.
Also fix all usages of the wordFM data structure. Once upon a time
wordFM used Words but now it uses UWords.
Likewise for WordBag.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13070 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
03f8d3fc25f5a45c5826259d1b33b7f310117279 05-Aug-2012 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Update copyright dates to include 2012.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12843 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
ec062e8d96a361af9905b5447027819dfbfee01a 23-Oct-2011 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Update all copyright dates, from 20xy-2010 to 20xy-2011.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12206 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
b3af9cf0b234d0d188347d92944e04ac9c8fbcd0 06-Oct-2011 bart <bart@a5019735-40e9-0310-863c-91ae7b9d1cf9> Format functions: change format specifier %t into %pS. Remove the _no_f_c formatting function variants.

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12108 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
2fa18d9ea5474392ec055e8e553a409ae36719ce 04-Oct-2011 bart <bart@a5019735-40e9-0310-863c-91ae7b9d1cf9> Helgrind and exp-sgcheck, XML error reporting: move the code printing <kind>...</kind> out of a switch statement.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12095 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
ffce8159a95134f0a2bc1cea3c3e6e265f096d9f 24-Jun-2011 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Merge the contents of the HGDEV2 branch into trunk:
* performance and scalability improvements
* show locks held by both threads in a race
* show all 4 locks involved in a lock order violation
* better delimited error messages



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11824 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
60626649e5fa6cd21af377fde5e83803fc136f61 10-Mar-2011 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Minor cleanup (no functional change): rename 'struct _Thr :: opaque'
to 'hgthread', since that's what it is really.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11619 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
1d7c3322207f80d9a962a402a171a14e4d628a77 28-Feb-2011 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Fix sanity check crash in Helgrind. Partial fix for #255353.
(Philippe Waroquiers, philippe.waroquiers@skynet.be)



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11575 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
c1fb9d265a0d64216d387684a425125af4aca557 28-Feb-2011 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Don't construct the LAOG at all when --track-lockorders=no (as opposed
to previous behaviour, in which it was constructed but any resulting
errors were not shown, hence wasting CPU and memory.) Partial fix
for #255353. (Philippe Waroquiers, philippe.waroquiers@skynet.be)



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11574 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
8fef62537fc0bcc0903d5be3080152f0e0b3979d 29-Jul-2010 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> When reporting an error about an attempt to re-lock an already-locked
lock, also report the stack where the lock was previously locked.
This makes it easier to diagnose deadlocks.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11234 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
c8028add6294793dfc80a80d920c7dba3a89f312 05-May-2010 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Rollup changes for Helgrind:

* Add new client request VALGRIND_HG_CLEAN_MEMORY_HEAPBLOCK. This is
like VALGRIND_HG_CLEAN_MEMORY but doesn't take an address range.
Instead it takes a single argument which is supposed to be a pointer
to the start of, or anywhere within, a heap allocated block.
Helgrind then finds the block and paints it as belonging to the
calling thread. This is needed for correctly describing the
behaviour of threadsafe reference counting when applied to classes
involving inheritance of release methods or involving multiple
inheritance.

* Add statistics counters for all basic VTS operations (tick, join,
cmpLEQ, cmp_structural).

* Rewrite VTS__cmp_structural to be much faster.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11123 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
9eecbbb9a9cbbd30b903c09a9e04d8efc20bda33 03-May-2010 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Update copyright dates to 2010.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11121 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
095d61eef541731e77e2c648983aee9ea2bf5e59 11-Mar-2010 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> If a race error is detected, check to see whether the raced-on address
is inside a heap block, and if so, print the allocation point of the
heap block. It's stupid not to do this considering that the
implementation already keeps track of all mallocs and frees.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11089 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
11b5c6d24609d9b75aa15f0a6dfb2b207136de60 03-Sep-2009 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Fix inconsistent closing of an <hthreadid> tag (Ashley Pittman).


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10881 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
588adeffafa8102adcfa7a1c035ae272b35cf86d 16-Aug-2009 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> When generating XML output for suppressions, print the suppression
both wrapped up in XML tags (as before) but also in plain text in a
sequence of CDATA blocks. Normally only one, but in the worst case
the raw data will have ]]> in it, in which case it needs to be split
across two CDATA blocks.

This apparently simple change involved a lot of refactoring of the
suppression printing machinery:

* in the core-tool iface, change "print_extra_suppression_info" (which
prints any auxiliary info) to "get_extra_suppression_info", which
parks the text in a caller-supplied buffer. Adjust tools to match.

* VG_(apply_StackTrace): accept a void* argument, which is passed to
each invokation of the functional parameter (a poor man's closure
implementation).

* move PRINTF_CHECK into put_tool_basics.h, where it should have been
all along

* move private printf-into-an-XArray-of-character functions from
m_debuginfo into m_xarray, and make them public

* gen_suppression itself: use all the above changes. Basically we
always generate the plaintext version into an XArray. In text mode
that's just printed. In XML mode, we print the XMLery as before,
but the plaintext version is dumped into a CDATA block too.

* update the Protocol 4 specification to match all this.

This still isn't 100% right in the sense that the CDATA block data
needs to be split across multiple blocks if it should ever contain the
CDATA end mark "]]>". The Protocol 4 spec has this right even though
the implementation currently doesn't.

Fixes #191189.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10822 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
e3f1e5988a94af9230f67273ca9236c4d7e8b8da 31-Jul-2009 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> (almost completely just function renaming):

* VG_(find_seginfo): incrementally rearrange the DebugInfo list, like
most of the other list-searching functions do.

* rename all VG_(*seginfo*) functions exported from m_debuginfo to
VG_(*DebugInfo*). "seginfo" was a historical name which was mostly
but not completely, done away with some time back.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10678 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
23f1200ba3aa3d8dbb484626ba1bdb7cfcf3b3a9 24-Jul-2009 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Various improvements:

* rename many functions to do with shadow memory handling, to
more clearly differentiate reads and writes directly of the
shadow state from client reads and writes, each of which
generate both a read and a write of the client state. It was
getting confusing (== hard to verify) in there.

* use idempotency of memory state machine transition rules to
speed up long sequential sections, speedups in range 0% to 28%

* remove 4-way Pord (EQ, LT, GT, UN) and associated machinery,
and replace it with something that merely computes LEQ in the
partial ordering, since that's all that is necessary, and
this simplifies some fast-case paths.

* add optional approx history mechanism a la DRD (start/end stack
of conflicting segment), much faster if you don't need exact
conflicting-access details

* libhb_so_recv: tick the VTS in the receiving thread; don't just
join with the VC in the SO. It's probably correct without this
modification, but that correctness is fragile and depends on
complex properties of how SOs are used/created. Much better to
be completely safe. (Needs cache-isation).

* get rid of unnecessary shadow memory state "SVal_NOACCESS"
and simplify associated fast-case paths in msmc{read,write}



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10589 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
35db56c19847654f22b62da059083d41ff4258c5 24-Jul-2009 njn <njn@a5019735-40e9-0310-863c-91ae7b9d1cf9> A fix for bug 186796: suppression symbol names were being truncated if they
were longer than 200 chars. Now dynamic memory is used and so they can be
arbitrarily long in theory, although in practice it bombs out at 100,000 for
sanity purposes. This required adjusting the core/tool interface for
read_extra_suppression_info().


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10581 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
24118491f347852bc311069a273fce13608dd531 15-Jul-2009 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Merge helgrind/ changes from branches/MESSAGING_TIDYUP r10464.
See trunk r10465 commit message for details.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10468 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
9f207460d70d38c46c9e81996a3dcdf90961c6db 10-Mar-2009 njn <njn@a5019735-40e9-0310-863c-91ae7b9d1cf9> Updated copyright years.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9344 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
5210413b79e93b660f5fd16dfb319237858835f5 23-Dec-2008 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Ignore races that occur on data in .plt sections, as well as those
that occur on data in .got.plt sections.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8866 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
a781be6728a28c94aec57f793f4d084456e93684 08-Dec-2008 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> event_map_lookup: when looking for a previous access to an address,
find conflicting accesses that overlap the current access in any way,
rather than just match at the addresses. This allows reporting of
conflicts between accesses which overlap but are not the same
size/alignment.

Doesn't seem to always work reliably, for reasons I don't understand,
but I so far failed to make a small test case.




git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8811 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
c5ea9961f9705b956742ae8c553c76caa2da8c29 07-Dec-2008 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> * In the conflicting-event mechanism, also record the size and
read-or-writeness of each access, so that these can be displayed in
error messages.

* Use recorded read-or-writeness info to avoid producing error
messages that claim claim two reads race against each other -- this
is clearly silly. For each pair of racing accesses now reported, at
least one of them will (should!) always now be a write, and (as
previously ensured) they will be from different threads.

* Lookups in the conflicting-access map is expensive, so don't do that
as soon as a race is detected. Instead wait until the update_extra
method is called.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8809 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c
f98e1c03ce4bea1fb092cdea5571c41f29f6df9b 25-Oct-2008 sewardj <sewardj@a5019735-40e9-0310-863c-91ae7b9d1cf9> Merge Helgrind from branches/YARD into the trunk. Also includes some
minor changes to make stack unwinding on amd64-linux approximately
twice as fast as it was before.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8707 a5019735-40e9-0310-863c-91ae7b9d1cf9
/external/valgrind/helgrind/hg_errors.c