You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
|
2
|
|
3
|
4
|
5
|
6
|
7
(1) |
8
|
9
|
|
10
|
11
|
12
(6) |
13
(4) |
14
(3) |
15
(1) |
16
(2) |
|
17
(7) |
18
(1) |
19
(5) |
20
(3) |
21
(1) |
22
(5) |
23
|
|
24
(1) |
25
(3) |
26
(2) |
27
(1) |
28
(2) |
29
(1) |
30
|
|
31
|
|
|
|
|
|
|
|
From: Florian K. <fl...@ei...> - 2016-01-17 20:33:00
|
Hi Matthias,
thanks for your review.
On 17.01.2016 20:42, Matthias Schwarzott wrote:
>
> your commit does not fix all issues:
> 1. This is what I get (when compiling vgprintf.c with NVALGRIND):
>
> ../../include/valgrind.h: In function 'VALGRIND_PRINTF':
> ../../include/valgrind.h:6762:4: warning: type defaults to 'int' in type
> name [-Wimplicit-int]
> if (format) *(volatile const *)format; // avoid compiler warning
>
> To fix this I needed to modify the cast to (volatile const char*).
Yes, true. I forgot the type.
>
> Second: the comment must be c style instead of c++.
Right again.
>
> Third: The compiler is not allowed to optimize away the read access to
> format. so we should get rid of the volatile.
>
> The simpler solution to cast format to void works for me.
> I could today only check with gcc-5.3.0 and clang-3.7 but these two were
> happy about this solution:
>
> (void)format;
>
> I hope msvc will like it too.
Maybe msvc likes that. But static analysis tools may say that
(void)format; is a statement with no effect which are known to be
symptoms of bugs (sometimes).
I was tempted for a moment to use: if (format) return;
which would kill your warning as well, but then VALGRIND_PRINTF would be
a function without effect and I know at least one checker that would
complain about that.
So I'm leaving the volatile in there. It'll shut up any compiler for good.
Florian
|
|
From: Matthias S. <zz...@ge...> - 2016-01-17 19:42:43
|
Am 17.01.2016 um 17:20 schrieb Florian Krohm:
> On 17.01.2016 15:04, Matthias Schwarzott wrote:
>> I suggest to use "format = format". This compiles fine for MSVC and gcc.
>
> Yes but with clang 3.7 and -Wall you get warnings about self assignments.
>
> So what I'm going to do is to check in the change I suggested. That
> fixes your warning. For the cleanup stuff we need Bart's help.
>
Hi Florian,
your commit does not fix all issues:
1. This is what I get (when compiling vgprintf.c with NVALGRIND):
../../include/valgrind.h: In function 'VALGRIND_PRINTF':
../../include/valgrind.h:6762:4: warning: type defaults to 'int' in type
name [-Wimplicit-int]
if (format) *(volatile const *)format; // avoid compiler warning
To fix this I needed to modify the cast to (volatile const char*).
Second: the comment must be c style instead of c++.
Third: The compiler is not allowed to optimize away the read access to
format. so we should get rid of the volatile.
The simpler solution to cast format to void works for me.
I could today only check with gcc-5.3.0 and clang-3.7 but these two were
happy about this solution:
(void)format;
I hope msvc will like it too.
Regards
Matthias
|
|
From: Florian K. <fl...@ei...> - 2016-01-17 16:20:49
|
On 17.01.2016 15:04, Matthias Schwarzott wrote:
>>
>> uintptr_t:
>> I do not unerstand why this type is needed and we cannot use unsigned
>> long instead.
>
[ snip ]
> Could there be a static assert to check the correct size.
> I assume this must be valid for "unsigned long" to be usable:
> sizeof(unsigned long) == sizeof(void*)
We rely on this to be true all over the place and I'm sure it is
asserted somewhere.
>
>
>> svn archeology did not reveal anything except that Bart
>> might know.
>
> I found commit 11314 "Suppressed a few warnings reported by the
> Microsoft C Compiler." by Bart that started to switch from "unsigned
> long" to "ptrdiff_t" and some commit later later it was changed to
> "uintptr_t".
No. r11314 fixed the warning by adding __inline for MSVC and also added
a version of VALGRIND_DO_CLIENT_REQUEST for MSVC that was using
ptrdiff_t. That type being a signed type was clearly the wrong choice
and then corrected in r11317 to uintptr_t. I doubt that
VALGRIND_DO_CLIENT_REQUEST was added to fix a warning.
Perhaps Bart can double check and clean this up. That would be good.
>
>>
>> Your #define __VALGRIND_PRINTF_ARGLIST ... will cause warnings with
>> most compilers because C does not allow such parameter lists.
>>
> ok, then go for a different solution.
>
>> To suppress the warning about the unused parameter we could use:
>>
> I suggest to use "format = format". This compiles fine for MSVC and gcc.
Yes but with clang 3.7 and -Wall you get warnings about self assignments.
So what I'm going to do is to check in the change I suggested. That
fixes your warning. For the cleanup stuff we need Bart's help.
Florian
|
|
From: <sv...@va...> - 2016-01-17 16:20:21
|
Author: florian
Date: Sun Jan 17 16:20:14 2016
New Revision: 15762
Log:
Avoid an MSVC compiler warning about an unused function parameter.
Fixes BZ #356817
Modified:
trunk/NEWS
trunk/include/valgrind.h
Modified: trunk/NEWS
==============================================================================
--- trunk/NEWS (original)
+++ trunk/NEWS Sun Jan 17 16:20:14 2016
@@ -57,6 +57,7 @@
355455 stderr.exp of test cases wrapmalloc and wrapmallocstatic overconstrained
355454 do not intercept malloc related symbols from the runtime linker
356044 Dwarf line info reader misinterprets is_stmt register
+356817 valgrind.h triggers compiler errors on MSVC when defining NVALGRIND
357871 pthread_spin_destroy not properly wrapped
357887 Fix a file handle leak. VG_(fclose) did not close the file
Modified: trunk/include/valgrind.h
==============================================================================
--- trunk/include/valgrind.h (original)
+++ trunk/include/valgrind.h Sun Jan 17 16:20:14 2016
@@ -6759,6 +6759,7 @@
VALGRIND_PRINTF(const char *format, ...)
{
#if defined(NVALGRIND)
+ if (format) *(volatile const *)format; // avoid compiler warning
return 0;
#else /* NVALGRIND */
#if defined(_MSC_VER) || defined(__MINGW64__)
@@ -6797,6 +6798,7 @@
VALGRIND_PRINTF_BACKTRACE(const char *format, ...)
{
#if defined(NVALGRIND)
+ if (format) *(volatile const *)format; // avoid compiler warning
return 0;
#else /* NVALGRIND */
#if defined(_MSC_VER) || defined(__MINGW64__)
|
|
From: Matthias S. <zz...@ge...> - 2016-01-17 14:04:50
|
Am 14.01.2016 um 10:19 schrieb Florian Krohm: > On 13.01.2016 10:50, Matthias Schwarzott wrote: >> Am 13.01.2016 um 08:18 schrieb Florian Krohm: >>> Given that we already have some support for MSC_VER in valgrind.h it >>> would be good to sort this out. But that file is already quite messy >>> with all the ifdeffery that is going on in there so we should be careful >>> adding more.. >>> >> The attached patch is a draft version of a different way to cleanup >> VALGRIND_PRINTF. >> > > Thanks for the patch. > Simplifying that file is a good thing. But I'd like to understand > whether we can get rid of some of the special casing. > > __inline: > I presume this is needed to keep MSC_VER from complaining that the > function is possibly unused. Right? I don't know for sure, but testing shows it is needed. But when we are already defining some inline things for MSVC we could also use the __inline__ keyword for gcc. > > uintptr_t: > I do not unerstand why this type is needed and we cannot use unsigned > long instead. I also don't understand why it is uintptr_t and not unsigned long, but going through the file, each architecture seems to use a different type for the argument types of the client requests. Some other macros like CALL_FN_W_5W macro always use "unsigned long". I do not get the difference. Could there be a static assert to check the correct size. I assume this must be valid for "unsigned long" to be usable: sizeof(unsigned long) == sizeof(void*) > svn archeology did not reveal anything except that Bart > might know. I found commit 11314 "Suppressed a few warnings reported by the Microsoft C Compiler." by Bart that started to switch from "unsigned long" to "ptrdiff_t" and some commit later later it was changed to "uintptr_t". > > Your #define __VALGRIND_PRINTF_ARGLIST ... will cause warnings with > most compilers because C does not allow such parameter lists. > ok, then go for a different solution. > To suppress the warning about the unused parameter we could use: > I suggest to use "format = format". This compiles fine for MSVC and gcc. I retried the original file with gcc with -Wall -Wextra and then gcc also warns about unused variable format. Regards Matthias |
|
From: <sv...@va...> - 2016-01-16 21:44:38
|
Author: florian
Date: Sat Jan 16 21:44:31 2016
New Revision: 15761
Log:
In ML_(am_allocate_segname) do not set the reference count of the
slot to 1. Rather do that in add_segment which is where the segment
refering to that name actually comes into existence.
Properly handle the case in add_segment where the to-be-added segment
and one (or more) of the segments it replaces have the same name
This may occur when doing a mremap.
Modified:
trunk/coregrind/m_aspacemgr/aspacemgr-linux.c
trunk/coregrind/m_aspacemgr/aspacemgr-segnames.c
Modified: trunk/coregrind/m_aspacemgr/aspacemgr-linux.c
==============================================================================
--- trunk/coregrind/m_aspacemgr/aspacemgr-linux.c (original)
+++ trunk/coregrind/m_aspacemgr/aspacemgr-linux.c Sat Jan 16 21:44:31 2016
@@ -1445,6 +1445,15 @@
split_nsegments_lo_and_hi( sStart, sEnd, &iLo, &iHi );
+ /* Increase the reference count of SEG's name. We need to do this
+ *before* decreasing the reference count of the names of the replaced
+ segments. Consider the case where the segment name of SEG and one of
+ the replaced segments are the same. If the refcount of that name is 1,
+ then decrementing first would put the slot for that name on the free
+ list. Attempting to increment the refcount later would then fail
+ because the slot is no longer allocated. */
+ ML_(am_inc_refcount)(seg->fnIdx);
+
/* Now iLo .. iHi inclusive is the range of segment indices which
seg will replace. If we're replacing more than one segment,
slide those above the range down to fill the hole. Before doing
Modified: trunk/coregrind/m_aspacemgr/aspacemgr-segnames.c
==============================================================================
--- trunk/coregrind/m_aspacemgr/aspacemgr-segnames.c (original)
+++ trunk/coregrind/m_aspacemgr/aspacemgr-segnames.c Sat Jan 16 21:44:31 2016
@@ -309,7 +309,7 @@
freeslot_chain = next_freeslot;
else
put_slotindex(prev, next_freeslot);
- put_refcount(ix, 1);
+ put_refcount(ix, 0);
put_slotsize(ix, size);
VG_(strcpy)(segnames + ix, name);
++num_segnames;
@@ -336,7 +336,7 @@
/* copy it in */
ix = segnames_used;
- put_refcount(ix, 1);
+ put_refcount(ix, 0);
put_slotsize(ix, len + 1);
VG_(strcpy)(segnames + ix, name);
segnames_used += need;
|
|
From: <sv...@va...> - 2016-01-16 21:13:05
|
Author: florian
Date: Sat Jan 16 21:12:57 2016
New Revision: 15760
Log:
Remove code that has no effect. Looks like a leftover from early
debugging days.
Modified:
trunk/coregrind/m_aspacemgr/aspacemgr-segnames.c
Modified: trunk/coregrind/m_aspacemgr/aspacemgr-segnames.c
==============================================================================
--- trunk/coregrind/m_aspacemgr/aspacemgr-segnames.c (original)
+++ trunk/coregrind/m_aspacemgr/aspacemgr-segnames.c Sat Jan 16 21:12:57 2016
@@ -250,9 +250,7 @@
UInt size = get_slotsize(ix);
/* Chain this slot in the freelist */
put_slotindex(ix, freeslot_chain);
- get_slotindex(ix);
put_slotsize(ix + slotsize_size, size);
- get_slotindex(ix);
freeslot_chain = ix;
--num_segnames;
if (0) VG_(am_show_nsegments)(0, "AFTER DECREASE rc -> 0");
|
|
From: Ivo R. <iv...@iv...> - 2016-01-15 21:04:15
|
2016-01-14 18:18 GMT+01:00 Carl E. Love <ce...@us...>:
> Valgrind developers:
>
> I am working on support for the new Power instructions. There are some
> instructions that access the 64 128-bit Vector Scalar Register (VSR)
> file that I can't emulate with existing Valgrind Iops. So, I need to
> add a new Iop for these instructions. The issue is that currently the
> Power support in Valgrind only handles issuing instructions that access
> the general purpose registers, the 32 64-bit floating point (FPR)
> registers and the 32 128-bit Vector Registers (VR). Note, the hardware
> actually maps the FPRs and VRs into subsets of the 64 VSR registers.
>
> I am trying to figure out within Valgrind how the contents of a register
> in the guest state is "copied" into the physical register on the target
> register before executing the native instruction.
Let me chime in a bit...
So it starts in the instruction selector (isel) which selects instructions
specific
to an architecture. These instructions need to perform the work of the
corresponding Iops.
They typically work on virtual registers.
For accessing guest state, IR uses GET, PUT (and others).
So for GET, instructions which perform loading a value from guest state
to a virtual register need to be selected here.
VEX framework then, based on the architecture description
from LibVEX_Translate(),
maps the virtual registers to host ones via mapRegs().
The emitor then encodes the host register into the instruction(s) emitted.
> Similarly, how the
> contents of the physical register gets "copied" back to the guest state.
>
See also libvex_ir.h, a paragraph starting at line 76:
76 Storage of guest state
77 ~~~~~~~~~~~~~~~~~~~~~~
78 The "guest state" contains the guest registers of the guest machine
79 (ie. the machine that we are simulating). It is stored by default
80 in a block of memory supplied by the user of the VEX library,
81 generally referred to as the guest state (area). To operate on
82 these registers, one must first read ("Get") them from the guest
83 state into a temporary value. Afterwards, one can write ("Put")
84 them back into the guest state.
85
86 Get and Put are characterised by a byte offset into the guest
87 state, a small integer which effectively gives the identity of the
88 referenced guest register, and a type, which indicates the size of
89 the value to be transferred.
...
> I understand the details on Power of generating a native instruction to
> be executed, it is done in emit_PPCInstr (), host_ppc_defs.c. I think I
> understand the code for the register allocater that selects a register
> in Power register space. But I can't find where/how the contents of the
> Power Guest register gets put into the a physical register before
> executing the generated Power instruction.
>
> I was expecting to see something within VEX that would generate native
> loads of the arguments from the Guest register file into the host
> registers, then the generated instruction followed by the generation of
> a native store instruction from the register into the Guest register
> file. I don't see any native load/store instructions to handle the
> operands.
>
Search for Iex_Get and Ist_Put in the isel for Power arch.
> The other possibility is that the values for the registers is stored
> along with the generated instructions in VEX but then in coregrind the
> native instructions would be generated to load the registers and execute
> the generated instruction for the Iop. I haven't found anything like
> that either.
>
This is VEX's job. Coregrind and Valgrind's analysis tools work only with
IR.
HTH, I.
|
|
From: <sv...@va...> - 2016-01-14 20:23:19
|
Author: philippe
Date: Thu Jan 14 20:23:11 2016
New Revision: 15759
Log:
fix n-i-bz false positive leaks due to aspacemgr merging non heap segments with heap segments.
aspace mgr provides VG_(am_mmap_client_heap) that mmaps memory and
marks it as being client heap memory. Marking superblock segments used
for malloc/free as heap is critical for correct leak search: segments
mmap-ed for malloc/free cannot be considered as part of the root set.
On the other hand, other mmap-ed segments cannot be marked as client
heap, otherwise these segments will not be part of the root set, and
will not be scanned.
aspacemgr merges adjacent segments when they have the same characteristics
e.g. kind, RWX and isCH (is client heap) must be the same (see function
maybe_merge_nsegments).
However, VG_(am_mmap_client_heap) has a bug:
* it first mmaps a normal segment (not marked as heap) using
VG_(am_mmap_anon_float_client)
* it then searches the segment that contains the just mmap-ed address and
marks it as heap.
The problem is that VG_(am_mmap_anon_float_client) has already
possibly merged the new segment with a neighbour segment, without
taking the to be marked isCH into account, as the newly allocated memory
has not yet been marked as Client Heap. So, this results in some memory being
marked as client heap, while it in fact is not client heap. This
memory will then not be scanned by the leak search.
The fix consists in having VG_(am_mmap_anon_float_client) and
VG_(am_mmap_client_heap) calling a new function
am_mmap_anon_float_client, which will mark (or not) the new segment as
client heap *before* trying to merge it with neighbouring segments.
Then the new (heap) segment will only be merged with neighbours that are also
client heap segments.
Modified:
trunk/NEWS
trunk/coregrind/m_aspacemgr/aspacemgr-linux.c
trunk/coregrind/pub_core_aspacemgr.h
Modified: trunk/NEWS
==============================================================================
--- trunk/NEWS (original)
+++ trunk/NEWS Thu Jan 14 20:23:11 2016
@@ -62,6 +62,7 @@
n-i-bz Fix incorrect (or infinite loop) unwind on RHEL7 x86 32 bits
n-i-bz massif --pages-as-heap=yes does not report peak caused by mmap+munmap
+n-i-bz false positive leaks due to aspacemgr merging non heap segments with heap segments.
Release 3.11.0 (22 September 2015)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Modified: trunk/coregrind/m_aspacemgr/aspacemgr-linux.c
==============================================================================
--- trunk/coregrind/m_aspacemgr/aspacemgr-linux.c (original)
+++ trunk/coregrind/m_aspacemgr/aspacemgr-linux.c Thu Jan 14 20:23:11 2016
@@ -2476,7 +2476,7 @@
/* Map anonymously at an unconstrained address for the client, and
update the segment array accordingly. */
-SysRes VG_(am_mmap_anon_float_client) ( SizeT length, Int prot )
+static SysRes am_mmap_anon_float_client ( SizeT length, Int prot, Bool isCH )
{
SysRes sres;
NSegment seg;
@@ -2524,12 +2524,17 @@
seg.hasR = toBool(prot & VKI_PROT_READ);
seg.hasW = toBool(prot & VKI_PROT_WRITE);
seg.hasX = toBool(prot & VKI_PROT_EXEC);
+ seg.isCH = isCH;
add_segment( &seg );
AM_SANITY_CHECK;
return sres;
}
+SysRes VG_(am_mmap_anon_float_client) ( SizeT length, Int prot )
+{
+ return am_mmap_anon_float_client (length, prot, False /* isCH */);
+}
/* Map anonymously at an unconstrained address for V, and update the
segment array accordingly. This is fundamentally how V allocates
@@ -2738,21 +2743,13 @@
fd, offset );
}
-/* Convenience wrapper around VG_(am_mmap_anon_float_client) which also
+/* Similar to VG_(am_mmap_anon_float_client) but also
marks the segment as containing the client heap. This is for the benefit
of the leak checker which needs to be able to identify such segments
so as not to use them as sources of roots during leak checks. */
SysRes VG_(am_mmap_client_heap) ( SizeT length, Int prot )
{
- SysRes res = VG_(am_mmap_anon_float_client)(length, prot);
-
- if (! sr_isError(res)) {
- Addr addr = sr_Res(res);
- Int ix = find_nsegment_idx(addr);
-
- nsegments[ix].isCH = True;
- }
- return res;
+ return am_mmap_anon_float_client (length, prot, True /* isCH */);
}
/* --- --- munmap helper --- --- */
Modified: trunk/coregrind/pub_core_aspacemgr.h
==============================================================================
--- trunk/coregrind/pub_core_aspacemgr.h (original)
+++ trunk/coregrind/pub_core_aspacemgr.h Thu Jan 14 20:23:11 2016
@@ -254,7 +254,7 @@
extern SysRes VG_(am_shared_mmap_file_float_valgrind)
( SizeT length, UInt prot, Int fd, Off64T offset );
-/* Convenience wrapper around VG_(am_mmap_anon_float_client) which also
+/* Similar to VG_(am_mmap_anon_float_client) but also
marks the segment as containing the client heap. */
extern SysRes VG_(am_mmap_client_heap) ( SizeT length, Int prot );
|
|
From: Carl E. L. <ce...@us...> - 2016-01-14 17:18:41
|
Valgrind developers:
I am working on support for the new Power instructions. There are some
instructions that access the 64 128-bit Vector Scalar Register (VSR)
file that I can't emulate with existing Valgrind Iops. So, I need to
add a new Iop for these instructions. The issue is that currently the
Power support in Valgrind only handles issuing instructions that access
the general purpose registers, the 32 64-bit floating point (FPR)
registers and the 32 128-bit Vector Registers (VR). Note, the hardware
actually maps the FPRs and VRs into subsets of the 64 VSR registers.
I am trying to figure out within Valgrind how the contents of a register
in the guest state is "copied" into the physical register on the target
register before executing the native instruction. Similarly, how the
contents of the physical register gets "copied" back to the guest state.
I understand the details on Power of generating a native instruction to
be executed, it is done in emit_PPCInstr (), host_ppc_defs.c. I think I
understand the code for the register allocater that selects a register
in Power register space. But I can't find where/how the contents of the
Power Guest register gets put into the a physical register before
executing the generated Power instruction.
I was expecting to see something within VEX that would generate native
loads of the arguments from the Guest register file into the host
registers, then the generated instruction followed by the generation of
a native store instruction from the register into the Guest register
file. I don't see any native load/store instructions to handle the
operands.
The other possibility is that the values for the registers is stored
along with the generated instructions in VEX but then in coregrind the
native instructions would be generated to load the registers and execute
the generated instruction for the Iop. I haven't found anything like
that either.
I am not sure where in Valgrind the generated native instructions are
actually issued. Anyway, if someone can outline how all this works and
where some of these things occur it would be a big help so I can figure
out the specifics on Power of extending support to native instructions
that use the VSRs. Thanks for your time.
Carl Love
|
|
From: Florian K. <fl...@ei...> - 2016-01-14 09:19:37
|
On 13.01.2016 10:50, Matthias Schwarzott wrote:
> Am 13.01.2016 um 08:18 schrieb Florian Krohm:
>> Given that we already have some support for MSC_VER in valgrind.h it
>> would be good to sort this out. But that file is already quite messy
>> with all the ifdeffery that is going on in there so we should be careful
>> adding more..
>>
> The attached patch is a draft version of a different way to cleanup
> VALGRIND_PRINTF.
>
Thanks for the patch.
Simplifying that file is a good thing. But I'd like to understand
whether we can get rid of some of the special casing.
__inline:
I presume this is needed to keep MSC_VER from complaining that the
function is possibly unused. Right?
uintptr_t:
I do not unerstand why this type is needed and we cannot use unsigned
long instead. svn archeology did not reveal anything except that Bart
might know.
Your #define __VALGRIND_PRINTF_ARGLIST ... will cause warnings with
most compilers because C does not allow such parameter lists.
To suppress the warning about the unused parameter we could use:
Index: include/valgrind.h
===================================================================
--- include/valgrind.h (revision 15754)
+++ include/valgrind.h (working copy)
@@ -6759,6 +6759,7 @@
VALGRIND_PRINTF(const char *format, ...)
{
#if defined(NVALGRIND)
+ if (format) *(volatile const *)format; // avoid compiler warning
return 0;
#else /* NVALGRIND */
#if defined(_MSC_VER) || defined(__MINGW64__)
@@ -6797,6 +6798,7 @@
VALGRIND_PRINTF_BACKTRACE(const char *format, ...)
{
#if defined(NVALGRIND)
+ if (format) *(volatile const *)format; // avoid compiler warning
return 0;
#else /* NVALGRIND */
#if defined(_MSC_VER) || defined(__MINGW64__)
Florian
|
|
From: Matthias S. <zz...@ge...> - 2016-01-13 09:51:10
|
Am 13.01.2016 um 08:18 schrieb Florian Krohm: > Given that we already have some support for MSC_VER in valgrind.h it > would be good to sort this out. But that file is already quite messy > with all the ifdeffery that is going on in there so we should be careful > adding more.. > The attached patch is a draft version of a different way to cleanup VALGRIND_PRINTF. Regards Matthias |
|
From: Matthias S. <zz...@ge...> - 2016-01-13 08:12:00
|
Hi Florian!
Ok, the line numbers relate to an older copy of valgrind.h but the issue
still exists. The first error points exactly on the definition of
VALGRIND_PRINTF (line 6759 in the current version of the file, see
below, the second on the equivalent definition of
VALGRIND_PRINTF_BACKTRACE).
The format argument is not used if NVALGRIND is defined (obvious).
For gcc the warning is disabled by adding a declaration containing the
attribute __unused__ for the format argument.
But for sure this does not apply to Visual Studio compiler.
To silence this warning one either needs to not assign a name to the
argument (only possible in c++) or only have the "..." argument (for a
function or macro). But I guess for better error checking the argument
should stay for gcc (to make use of the attribute format...).
Here is the code of VALGRIND_PRINTF of the latest valgrind.h file:
> 6749: #if defined(__GNUC__) || defined(__INTEL_COMPILER) && !defined(_MSC_VER)
> 6750: /* Modern GCC will optimize the static routine out if unused,
> 6751: and unused attribute will shut down warnings about it. */
> 6752: static int VALGRIND_PRINTF(const char *format, ...)
> 6753: __attribute__((format(__printf__, 1, 2), __unused__));
> 6754: #endif
> 6755: static int
> 6756: #if defined(_MSC_VER)
> 6757: __inline
> 6758: #endif
> 6759: VALGRIND_PRINTF(const char *format, ...)
> 6760: {
> 6761: #if defined(NVALGRIND)
> 6762: return 0;
> 6763: #else /* NVALGRIND */
> 6764: #if defined(_MSC_VER) || defined(__MINGW64__)
> 6765: uintptr_t _qzz_res;
> 6766: #else
> 6767: unsigned long _qzz_res;
> 6768: #endif
> 6769: va_list vargs;
> 6770: va_start(vargs, format);
> 6771: #if defined(_MSC_VER) || defined(__MINGW64__)
> 6772: _qzz_res = VALGRIND_DO_CLIENT_REQUEST_EXPR(0,
> 6773: VG_USERREQ__PRINTF_VALIST_BY_REF,
> 6774: (uintptr_t)format,
> 6775: (uintptr_t)&vargs,
> 6776: 0, 0, 0);
> 6777: #else
> 6778: _qzz_res = VALGRIND_DO_CLIENT_REQUEST_EXPR(0,
> 6779: VG_USERREQ__PRINTF_VALIST_BY_REF,
> 6780: (unsigned long)format,
> 6781: (unsigned long)&vargs,
> 6782: 0, 0, 0);
> 6783: #endif
> 6784: va_end(vargs);
> 6785: return (int)_qzz_res;
> 6786: #endif /* NVALGRIND */
> 6787: }
Regards
Matthias
Am 13.01.2016 um 08:18 schrieb Florian Krohm:
> Given that we already have some support for MSC_VER in valgrind.h it
> would be good to sort this out. But that file is already quite messy
> with all the ifdeffery that is going on in there so we should be careful
> adding more..
>
> I do not understand what the issue really is. The lines mentioned in the
> errors point into macro definitions and offer no clue. They are
> unrelated to VALGRIND_PRINTF. Can you provide some context? Assume that
> none of us has access to that particular compiler to play around with.
>
> Florian
>
>
> On 12.01.2016 23:14, Matthias Schwarzott wrote:
>> When compiling code that includes valgrind.h on visual studio I get
>> compiler errors about VALGRIND_PRINTF:
>> 1>include\Valgrind/valgrind.h(4493) : error C2220: warning treated as
>> error - no 'object' file generated
>> 1>include\Valgrind/valgrind.h(4493) : warning C4100: 'format' :
>> unreferenced formal parameter
>> 1>include\Valgrind/valgrind.h(4531) : warning C4100: 'format' :
>> unreferenced formal parameter
>>
>> See https://bugs.kde.org/show_bug.cgi?id=356817
>>
>> There are multiple ways to fix this issue.
>> 1. Complicated one: extend the existing ifdef code with special
>> NVALGRIND function versions for gcc and MSVC, see
>> https://bugs.kde.org/attachment.cgi?id=96139
>>
>> 2. Simple one: have a function or macro with only "..." argument in the
>> NVALGRIND case that does nothing.
>>
>> --- a/include/valgrind.h
>> +++ b/include/valgrind.h
>> @@ -6746,6 +6746,18 @@ typedef
>> is the number of characters printed, excluding the "**<pid>** " part
>> at the
>> start and the backtrace (if present). */
>>
>> +#if defined(_MSC_VER) && defined(NVALGRIND)
>> +static int __inline VALGRIND_PRINTF(...)
>> +{
>> + return 0;
>> +}
>> +
>> +static int __inline VALGRIND_PRINTF_BACKTRACE(...)
>> +{
>> + return 0;
>> +}
>> +
>> +#else /* _MSC_VER && NVALGRIND */
>> #if defined(__GNUC__) || defined(__INTEL_COMPILER) && !defined(_MSC_VER)
>> /* Modern GCC will optimize the static routine out if unused,
>> and unused attribute will shut down warnings about it. */
>> @@ -6823,7 +6835,7 @@ VALGRIND_PRINTF_BACKTRACE(const char *format, ...)
>> return (int)_qzz_res;
>> #endif /* NVALGRIND */
>> }
>> -
>> +#endif /* _MSC_VER && NVALGRIND */
>>
>> /* These requests allow control to move from the simulated CPU to the
>> real CPU, calling an arbitary function.
>>
>>
>> What do you think about this?
>>
>> Regards
>> Matthias
>>
>> ------------------------------------------------------------------------------
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
>> _______________________________________________
>> Valgrind-developers mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>>
>
>
|
|
From: Florian K. <fl...@ei...> - 2016-01-13 07:43:52
|
Given that we already have some support for MSC_VER in valgrind.h it would be good to sort this out. But that file is already quite messy with all the ifdeffery that is going on in there so we should be careful adding more.. I do not understand what the issue really is. The lines mentioned in the errors point into macro definitions and offer no clue. They are unrelated to VALGRIND_PRINTF. Can you provide some context? Assume that none of us has access to that particular compiler to play around with. Florian On 12.01.2016 23:14, Matthias Schwarzott wrote: > When compiling code that includes valgrind.h on visual studio I get > compiler errors about VALGRIND_PRINTF: > 1>include\Valgrind/valgrind.h(4493) : error C2220: warning treated as > error - no 'object' file generated > 1>include\Valgrind/valgrind.h(4493) : warning C4100: 'format' : > unreferenced formal parameter > 1>include\Valgrind/valgrind.h(4531) : warning C4100: 'format' : > unreferenced formal parameter > > See https://bugs.kde.org/show_bug.cgi?id=356817 > > There are multiple ways to fix this issue. > 1. Complicated one: extend the existing ifdef code with special > NVALGRIND function versions for gcc and MSVC, see > https://bugs.kde.org/attachment.cgi?id=96139 > > 2. Simple one: have a function or macro with only "..." argument in the > NVALGRIND case that does nothing. > > --- a/include/valgrind.h > +++ b/include/valgrind.h > @@ -6746,6 +6746,18 @@ typedef > is the number of characters printed, excluding the "**<pid>** " part > at the > start and the backtrace (if present). */ > > +#if defined(_MSC_VER) && defined(NVALGRIND) > +static int __inline VALGRIND_PRINTF(...) > +{ > + return 0; > +} > + > +static int __inline VALGRIND_PRINTF_BACKTRACE(...) > +{ > + return 0; > +} > + > +#else /* _MSC_VER && NVALGRIND */ > #if defined(__GNUC__) || defined(__INTEL_COMPILER) && !defined(_MSC_VER) > /* Modern GCC will optimize the static routine out if unused, > and unused attribute will shut down warnings about it. */ > @@ -6823,7 +6835,7 @@ VALGRIND_PRINTF_BACKTRACE(const char *format, ...) > return (int)_qzz_res; > #endif /* NVALGRIND */ > } > - > +#endif /* _MSC_VER && NVALGRIND */ > > /* These requests allow control to move from the simulated CPU to the > real CPU, calling an arbitary function. > > > What do you think about this? > > Regards > Matthias > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: <sv...@va...> - 2016-01-13 05:37:45
|
Author: iraisr
Date: Wed Jan 13 05:37:36 2016
New Revision: 15758
Log:
Fix expected output of helgrind/tests/tc20_verifywrap on Solaris.
n-i-bz
Modified:
trunk/NEWS
trunk/helgrind/tests/tc20_verifywrap.stderr.exp-solaris
Modified: trunk/NEWS
==============================================================================
--- trunk/NEWS (original)
+++ trunk/NEWS Wed Jan 13 05:37:36 2016
@@ -57,8 +57,8 @@
355455 stderr.exp of test cases wrapmalloc and wrapmallocstatic overconstrained
355454 do not intercept malloc related symbols from the runtime linker
356044 Dwarf line info reader misinterprets is_stmt register
-357887 Fix a file handle leak. VG_(fclose) did not close the file
357871 pthread_spin_destroy not properly wrapped
+357887 Fix a file handle leak. VG_(fclose) did not close the file
n-i-bz Fix incorrect (or infinite loop) unwind on RHEL7 x86 32 bits
n-i-bz massif --pages-as-heap=yes does not report peak caused by mmap+munmap
Modified: trunk/helgrind/tests/tc20_verifywrap.stderr.exp-solaris
==============================================================================
--- trunk/helgrind/tests/tc20_verifywrap.stderr.exp-solaris (original)
+++ trunk/helgrind/tests/tc20_verifywrap.stderr.exp-solaris Wed Jan 13 05:37:36 2016
@@ -231,7 +231,6 @@
by 0x........: main (tc20_verifywrap.c:232)
-
---------------- pthread_spin_* ----------------
|
|
From: Matthias S. <zz...@ge...> - 2016-01-12 22:14:38
|
When compiling code that includes valgrind.h on visual studio I get compiler errors about VALGRIND_PRINTF: 1>include\Valgrind/valgrind.h(4493) : error C2220: warning treated as error - no 'object' file generated 1>include\Valgrind/valgrind.h(4493) : warning C4100: 'format' : unreferenced formal parameter 1>include\Valgrind/valgrind.h(4531) : warning C4100: 'format' : unreferenced formal parameter See https://bugs.kde.org/show_bug.cgi?id=356817 There are multiple ways to fix this issue. 1. Complicated one: extend the existing ifdef code with special NVALGRIND function versions for gcc and MSVC, see https://bugs.kde.org/attachment.cgi?id=96139 2. Simple one: have a function or macro with only "..." argument in the NVALGRIND case that does nothing. --- a/include/valgrind.h +++ b/include/valgrind.h @@ -6746,6 +6746,18 @@ typedef is the number of characters printed, excluding the "**<pid>** " part at the start and the backtrace (if present). */ +#if defined(_MSC_VER) && defined(NVALGRIND) +static int __inline VALGRIND_PRINTF(...) +{ + return 0; +} + +static int __inline VALGRIND_PRINTF_BACKTRACE(...) +{ + return 0; +} + +#else /* _MSC_VER && NVALGRIND */ #if defined(__GNUC__) || defined(__INTEL_COMPILER) && !defined(_MSC_VER) /* Modern GCC will optimize the static routine out if unused, and unused attribute will shut down warnings about it. */ @@ -6823,7 +6835,7 @@ VALGRIND_PRINTF_BACKTRACE(const char *format, ...) return (int)_qzz_res; #endif /* NVALGRIND */ } - +#endif /* _MSC_VER && NVALGRIND */ /* These requests allow control to move from the simulated CPU to the real CPU, calling an arbitary function. What do you think about this? Regards Matthias |
|
From: <sv...@va...> - 2016-01-12 20:32:38
|
Author: iraisr
Date: Tue Jan 12 20:32:31 2016
New Revision: 15757
Log:
Announce properly fix of:
357871 - pthread_spin_destroy not properly wrapped
Modified:
trunk/NEWS
Modified: trunk/NEWS
==============================================================================
--- trunk/NEWS (original)
+++ trunk/NEWS Tue Jan 12 20:32:31 2016
@@ -58,6 +58,7 @@
355454 do not intercept malloc related symbols from the runtime linker
356044 Dwarf line info reader misinterprets is_stmt register
357887 Fix a file handle leak. VG_(fclose) did not close the file
+357871 pthread_spin_destroy not properly wrapped
n-i-bz Fix incorrect (or infinite loop) unwind on RHEL7 x86 32 bits
n-i-bz massif --pages-as-heap=yes does not report peak caused by mmap+munmap
|
|
From: <sv...@va...> - 2016-01-12 20:31:27
|
Author: iraisr
Date: Tue Jan 12 20:31:15 2016
New Revision: 15756
Log:
Fix typo in Helgrind's wrapper of pthread_spin_destroy().
Patch provided by: Jason Dillaman <dil...@re...>.
Fixes BZ #357871.
Modified:
trunk/helgrind/hg_intercepts.c
trunk/helgrind/tests/tc20_verifywrap.c
trunk/helgrind/tests/tc20_verifywrap.stderr.exp
trunk/helgrind/tests/tc20_verifywrap.stderr.exp-glibc-2.18
trunk/helgrind/tests/tc20_verifywrap.stderr.exp-glibc-2.21
trunk/helgrind/tests/tc20_verifywrap.stderr.exp-mips32
trunk/helgrind/tests/tc20_verifywrap.stderr.exp-mips32-b
trunk/helgrind/tests/tc20_verifywrap.stderr.exp-s390x
trunk/helgrind/tests/tc20_verifywrap.stderr.exp-solaris
Modified: trunk/helgrind/hg_intercepts.c
==============================================================================
--- trunk/helgrind/hg_intercepts.c (original)
+++ trunk/helgrind/hg_intercepts.c Tue Jan 12 20:31:15 2016
@@ -1854,13 +1854,13 @@
return ret;
}
#if defined(VGO_linux)
- PTH_FUNC(int, pthreadZuspinZusdestroy, // pthread_spin_destroy
+ PTH_FUNC(int, pthreadZuspinZudestroy, // pthread_spin_destroy
pthread_spinlock_t *lock) {
return pthread_spin_destroy_WRK(lock);
}
#elif defined(VGO_darwin)
#elif defined(VGO_solaris)
- PTH_FUNC(int, pthreadZuspinZusdestroy, // pthread_spin_destroy
+ PTH_FUNC(int, pthreadZuspinZudestroy, // pthread_spin_destroy
pthread_spinlock_t *lock) {
return pthread_spin_destroy_WRK(lock);
}
Modified: trunk/helgrind/tests/tc20_verifywrap.c
==============================================================================
--- trunk/helgrind/tests/tc20_verifywrap.c (original)
+++ trunk/helgrind/tests/tc20_verifywrap.c Tue Jan 12 20:31:15 2016
@@ -29,6 +29,11 @@
#endif
#endif /* __sun__ */
+typedef union {
+ pthread_spinlock_t spinlock;
+ pthread_rwlock_t rwlock;
+} spin_rw_lock;
+
short unprotected = 0;
void* lazy_child ( void* v ) {
@@ -236,6 +241,20 @@
r= pthread_rwlock_init( &rwl3, NULL ); assert(!r);
r= pthread_rwlock_rdlock( &rwl3 ); assert(!r);
+ /* --------- pthread_spin_* --------- */
+
+ fprintf(stderr,
+ "\n---------------- pthread_spin_* ----------------\n\n");
+
+ /* The following sequence verifies correct wrapping of pthread_spin_init()
+ and pthread_spin_destroy(). */
+ spin_rw_lock srwl1;
+ pthread_spin_init(&srwl1.spinlock, PTHREAD_PROCESS_PRIVATE);
+ pthread_spin_destroy(&srwl1.spinlock);
+
+ pthread_rwlock_init(&srwl1.rwlock, NULL);
+ pthread_rwlock_destroy(&srwl1.rwlock);
+
/* ------------- sem_* ------------- */
/* This is pretty lame, and duplicates tc18_semabuse.c. */
Modified: trunk/helgrind/tests/tc20_verifywrap.stderr.exp
==============================================================================
--- trunk/helgrind/tests/tc20_verifywrap.stderr.exp (original)
+++ trunk/helgrind/tests/tc20_verifywrap.stderr.exp Tue Jan 12 20:31:15 2016
@@ -14,21 +14,21 @@
Thread #x was created
...
by 0x........: pthread_create@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:81)
+ by 0x........: main (tc20_verifywrap.c:86)
----------------------------------------------------------------
Possible data race during write of size 2 at 0x........ by thread #x
Locks held: none
- at 0x........: main (tc20_verifywrap.c:83)
+ at 0x........: main (tc20_verifywrap.c:88)
This conflicts with a previous write of size 2 by thread #x
Locks held: none
- at 0x........: racy_child (tc20_verifywrap.c:39)
+ at 0x........: racy_child (tc20_verifywrap.c:44)
by 0x........: mythread_wrapper (hg_intercepts.c:...)
...
Location 0x........ is 0 bytes inside global var "unprotected"
- declared at tc20_verifywrap.c:32
+ declared at tc20_verifywrap.c:37
----------------------------------------------------------------
@@ -36,7 +36,7 @@
with error code 35 (EDEADLK: Resource deadlock would occur)
at 0x........: pthread_join_WRK (hg_intercepts.c:...)
by 0x........: pthread_join (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:88)
+ by 0x........: main (tc20_verifywrap.c:93)
---------------- pthread_mutex_lock et al ----------------
@@ -46,14 +46,14 @@
Thread #x's call to pthread_mutex_init failed
with error code 95 (EOPNOTSUPP: Operation not supported on transport endpoint)
at 0x........: pthread_mutex_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:102)
+ by 0x........: main (tc20_verifywrap.c:107)
----------------------------------------------------------------
Thread #x: pthread_mutex_destroy of a locked mutex
at 0x........: mutex_destroy_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_destroy (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:112)
+ by 0x........: main (tc20_verifywrap.c:117)
----------------------------------------------------------------
@@ -61,7 +61,7 @@
with error code 16 (EBUSY: Device or resource busy)
at 0x........: mutex_destroy_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_destroy (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:112)
+ by 0x........: main (tc20_verifywrap.c:117)
----------------------------------------------------------------
@@ -69,7 +69,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_lock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_lock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:118)
+ by 0x........: main (tc20_verifywrap.c:123)
----------------------------------------------------------------
@@ -77,7 +77,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_trylock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_trylock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:126)
+ by 0x........: main (tc20_verifywrap.c:131)
----------------------------------------------------------------
@@ -85,14 +85,14 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_timedlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_timedlock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:131)
+ by 0x........: main (tc20_verifywrap.c:136)
----------------------------------------------------------------
Thread #x unlocked an invalid lock at 0x........
at 0x........: mutex_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:135)
+ by 0x........: main (tc20_verifywrap.c:140)
----------------------------------------------------------------
@@ -100,7 +100,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:135)
+ by 0x........: main (tc20_verifywrap.c:140)
---------------- pthread_cond_wait et al ----------------
@@ -110,7 +110,7 @@
Thread #x: pthread_cond_{timed}wait called with un-held mutex
at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:157)
+ by 0x........: main (tc20_verifywrap.c:162)
----------------------------------------------------------------
@@ -118,14 +118,14 @@
with error code 1 (EPERM: Operation not permitted)
at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:157)
+ by 0x........: main (tc20_verifywrap.c:162)
----------------------------------------------------------------
Thread #x: pthread_cond_{signal,broadcast}: dubious: associated lock is not held by any thread
at 0x........: pthread_cond_signal_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_signal@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:162)
+ by 0x........: main (tc20_verifywrap.c:167)
FIXME: can't figure out how to verify wrap of pthread_cond_signal
@@ -135,7 +135,7 @@
Thread #x: pthread_cond_{signal,broadcast}: dubious: associated lock is not held by any thread
at 0x........: pthread_cond_broadcast_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_broadcast@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:168)
+ by 0x........: main (tc20_verifywrap.c:173)
FIXME: can't figure out how to verify wrap of pthread_broadcast_signal
@@ -145,7 +145,7 @@
Thread #x: pthread_cond_{timed}wait called with un-held mutex
at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:175)
+ by 0x........: main (tc20_verifywrap.c:180)
----------------------------------------------------------------
@@ -153,7 +153,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:175)
+ by 0x........: main (tc20_verifywrap.c:180)
---------------- pthread_rwlock_* ----------------
@@ -164,13 +164,13 @@
at 0x........: pthread_rwlock_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_unlock (hg_intercepts.c:...)
...
- by 0x........: main (tc20_verifywrap.c:189)
+ by 0x........: main (tc20_verifywrap.c:194)
Lock at 0x........ was first observed
at 0x........: pthread_rwlock_init_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:188)
+ by 0x........: main (tc20_verifywrap.c:193)
Location 0x........ is 0 bytes inside local var "rwl"
- declared at tc20_verifywrap.c:52, in frame #x of thread x
+ declared at tc20_verifywrap.c:57, in frame #x of thread x
(1) no error on next line
@@ -182,13 +182,13 @@
at 0x........: pthread_rwlock_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_unlock (hg_intercepts.c:...)
...
- by 0x........: main (tc20_verifywrap.c:206)
+ by 0x........: main (tc20_verifywrap.c:211)
Lock at 0x........ was first observed
at 0x........: pthread_rwlock_init_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:196)
+ by 0x........: main (tc20_verifywrap.c:201)
Location 0x........ is 0 bytes inside local var "rwl2"
- declared at tc20_verifywrap.c:53, in frame #x of thread x
+ declared at tc20_verifywrap.c:58, in frame #x of thread x
(4) no error on next line
@@ -202,14 +202,17 @@
at 0x........: pthread_rwlock_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_unlock (hg_intercepts.c:...)
...
- by 0x........: main (tc20_verifywrap.c:227)
+ by 0x........: main (tc20_verifywrap.c:232)
Lock at 0x........ was first observed
at 0x........: pthread_rwlock_init_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:196)
+ by 0x........: main (tc20_verifywrap.c:201)
Location 0x........ is 0 bytes inside local var "rwl2"
- declared at tc20_verifywrap.c:53, in frame #x of thread x
+ declared at tc20_verifywrap.c:58, in frame #x of thread x
+
+
+---------------- pthread_spin_* ----------------
---------------- sem_* ----------------
@@ -220,7 +223,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: sem_init_WRK (hg_intercepts.c:...)
by 0x........: sem_init@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:248)
+ by 0x........: main (tc20_verifywrap.c:267)
FIXME: can't figure out how to verify wrap of sem_destroy
@@ -230,7 +233,7 @@
Thread #x: Bug in libpthread: sem_wait succeeded on semaphore without prior sem_post
at 0x........: sem_wait_WRK (hg_intercepts.c:...)
by 0x........: sem_wait (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:262)
+ by 0x........: main (tc20_verifywrap.c:281)
----------------------------------------------------------------
@@ -239,7 +242,7 @@
at 0x........: sem_post_WRK (hg_intercepts.c:...)
by 0x........: sem_post (hg_intercepts.c:...)
...
- by 0x........: main (tc20_verifywrap.c:265)
+ by 0x........: main (tc20_verifywrap.c:284)
FIXME: can't figure out how to verify wrap of sem_post
Modified: trunk/helgrind/tests/tc20_verifywrap.stderr.exp-glibc-2.18
==============================================================================
--- trunk/helgrind/tests/tc20_verifywrap.stderr.exp-glibc-2.18 (original)
+++ trunk/helgrind/tests/tc20_verifywrap.stderr.exp-glibc-2.18 Tue Jan 12 20:31:15 2016
@@ -14,21 +14,21 @@
Thread #x was created
...
by 0x........: pthread_create@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:81)
+ by 0x........: main (tc20_verifywrap.c:86)
----------------------------------------------------------------
Possible data race during write of size 2 at 0x........ by thread #x
Locks held: none
- at 0x........: main (tc20_verifywrap.c:83)
+ at 0x........: main (tc20_verifywrap.c:88)
This conflicts with a previous write of size 2 by thread #x
Locks held: none
- at 0x........: racy_child (tc20_verifywrap.c:39)
+ at 0x........: racy_child (tc20_verifywrap.c:44)
by 0x........: mythread_wrapper (hg_intercepts.c:...)
...
Location 0x........ is 0 bytes inside global var "unprotected"
- declared at tc20_verifywrap.c:32
+ declared at tc20_verifywrap.c:37
----------------------------------------------------------------
@@ -36,7 +36,7 @@
with error code 35 (EDEADLK: Resource deadlock would occur)
at 0x........: pthread_join_WRK (hg_intercepts.c:...)
by 0x........: pthread_join (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:88)
+ by 0x........: main (tc20_verifywrap.c:93)
---------------- pthread_mutex_lock et al ----------------
@@ -46,14 +46,14 @@
Thread #x's call to pthread_mutex_init failed
with error code 95 (EOPNOTSUPP: Operation not supported on transport endpoint)
at 0x........: pthread_mutex_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:102)
+ by 0x........: main (tc20_verifywrap.c:107)
----------------------------------------------------------------
Thread #x: pthread_mutex_destroy of a locked mutex
at 0x........: mutex_destroy_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_destroy (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:112)
+ by 0x........: main (tc20_verifywrap.c:117)
----------------------------------------------------------------
@@ -61,7 +61,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_lock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_lock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:118)
+ by 0x........: main (tc20_verifywrap.c:123)
----------------------------------------------------------------
@@ -69,7 +69,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_trylock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_trylock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:126)
+ by 0x........: main (tc20_verifywrap.c:131)
----------------------------------------------------------------
@@ -77,14 +77,14 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_timedlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_timedlock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:131)
+ by 0x........: main (tc20_verifywrap.c:136)
----------------------------------------------------------------
Thread #x unlocked an invalid lock at 0x........
at 0x........: mutex_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:135)
+ by 0x........: main (tc20_verifywrap.c:140)
----------------------------------------------------------------
@@ -92,7 +92,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:135)
+ by 0x........: main (tc20_verifywrap.c:140)
---------------- pthread_cond_wait et al ----------------
@@ -102,7 +102,7 @@
Thread #x: pthread_cond_{timed}wait called with un-held mutex
at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:157)
+ by 0x........: main (tc20_verifywrap.c:162)
----------------------------------------------------------------
@@ -110,14 +110,14 @@
with error code 1 (EPERM: Operation not permitted)
at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:157)
+ by 0x........: main (tc20_verifywrap.c:162)
----------------------------------------------------------------
Thread #x: pthread_cond_{signal,broadcast}: dubious: associated lock is not held by any thread
at 0x........: pthread_cond_signal_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_signal@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:162)
+ by 0x........: main (tc20_verifywrap.c:167)
FIXME: can't figure out how to verify wrap of pthread_cond_signal
@@ -127,7 +127,7 @@
Thread #x: pthread_cond_{signal,broadcast}: dubious: associated lock is not held by any thread
at 0x........: pthread_cond_broadcast_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_broadcast@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:168)
+ by 0x........: main (tc20_verifywrap.c:173)
FIXME: can't figure out how to verify wrap of pthread_broadcast_signal
@@ -137,7 +137,7 @@
Thread #x: pthread_cond_{timed}wait called with un-held mutex
at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:175)
+ by 0x........: main (tc20_verifywrap.c:180)
----------------------------------------------------------------
@@ -145,7 +145,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:175)
+ by 0x........: main (tc20_verifywrap.c:180)
---------------- pthread_rwlock_* ----------------
@@ -156,11 +156,11 @@
at 0x........: pthread_rwlock_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_unlock (hg_intercepts.c:...)
...
- by 0x........: main (tc20_verifywrap.c:189)
+ by 0x........: main (tc20_verifywrap.c:194)
Lock at 0x........ was first observed
at 0x........: pthread_rwlock_init_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:188)
+ by 0x........: main (tc20_verifywrap.c:193)
(1) no error on next line
(2) no error on next line
@@ -171,11 +171,11 @@
at 0x........: pthread_rwlock_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_unlock (hg_intercepts.c:...)
...
- by 0x........: main (tc20_verifywrap.c:206)
+ by 0x........: main (tc20_verifywrap.c:211)
Lock at 0x........ was first observed
at 0x........: pthread_rwlock_init_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:196)
+ by 0x........: main (tc20_verifywrap.c:201)
(4) no error on next line
(5) no error on next line
@@ -187,11 +187,15 @@
Thread #x unlocked a not-locked lock at 0x........
at 0x........: pthread_rwlock_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_unlock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:227)
+ by 0x........: main (tc20_verifywrap.c:232)
Lock at 0x........ was first observed
at 0x........: pthread_rwlock_init_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:196)
+ by 0x........: main (tc20_verifywrap.c:201)
+
+
+
+---------------- pthread_spin_* ----------------
---------------- sem_* ----------------
@@ -202,7 +206,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: sem_init_WRK (hg_intercepts.c:...)
by 0x........: sem_init@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:243)
+ by 0x........: main (tc20_verifywrap.c:267)
FIXME: can't figure out how to verify wrap of sem_destroy
@@ -212,7 +216,7 @@
Thread #x: Bug in libpthread: sem_wait succeeded on semaphore without prior sem_post
at 0x........: sem_wait_WRK (hg_intercepts.c:...)
by 0x........: sem_wait (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:257)
+ by 0x........: main (tc20_verifywrap.c:281)
----------------------------------------------------------------
@@ -220,7 +224,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: sem_post_WRK (hg_intercepts.c:...)
by 0x........: sem_post (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:260)
+ by 0x........: main (tc20_verifywrap.c:284)
FIXME: can't figure out how to verify wrap of sem_post
Modified: trunk/helgrind/tests/tc20_verifywrap.stderr.exp-glibc-2.21
==============================================================================
--- trunk/helgrind/tests/tc20_verifywrap.stderr.exp-glibc-2.21 (original)
+++ trunk/helgrind/tests/tc20_verifywrap.stderr.exp-glibc-2.21 Tue Jan 12 20:31:15 2016
@@ -14,21 +14,21 @@
Thread #x was created
...
by 0x........: pthread_create@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:81)
+ by 0x........: main (tc20_verifywrap.c:86)
----------------------------------------------------------------
Possible data race during write of size 2 at 0x........ by thread #x
Locks held: none
- at 0x........: main (tc20_verifywrap.c:83)
+ at 0x........: main (tc20_verifywrap.c:88)
This conflicts with a previous write of size 2 by thread #x
Locks held: none
- at 0x........: racy_child (tc20_verifywrap.c:39)
+ at 0x........: racy_child (tc20_verifywrap.c:44)
by 0x........: mythread_wrapper (hg_intercepts.c:...)
...
Location 0x........ is 0 bytes inside global var "unprotected"
- declared at tc20_verifywrap.c:32
+ declared at tc20_verifywrap.c:37
----------------------------------------------------------------
@@ -36,7 +36,7 @@
with error code 35 (EDEADLK: Resource deadlock would occur)
at 0x........: pthread_join_WRK (hg_intercepts.c:...)
by 0x........: pthread_join (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:88)
+ by 0x........: main (tc20_verifywrap.c:93)
---------------- pthread_mutex_lock et al ----------------
@@ -46,14 +46,14 @@
Thread #x's call to pthread_mutex_init failed
with error code 95 (EOPNOTSUPP: Operation not supported on transport endpoint)
at 0x........: pthread_mutex_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:102)
+ by 0x........: main (tc20_verifywrap.c:107)
----------------------------------------------------------------
Thread #x: pthread_mutex_destroy of a locked mutex
at 0x........: mutex_destroy_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_destroy (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:112)
+ by 0x........: main (tc20_verifywrap.c:117)
----------------------------------------------------------------
@@ -61,7 +61,7 @@
with error code 16 (EBUSY: Device or resource busy)
at 0x........: mutex_destroy_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_destroy (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:112)
+ by 0x........: main (tc20_verifywrap.c:117)
----------------------------------------------------------------
@@ -69,7 +69,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_lock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_lock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:118)
+ by 0x........: main (tc20_verifywrap.c:123)
----------------------------------------------------------------
@@ -77,7 +77,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_trylock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_trylock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:126)
+ by 0x........: main (tc20_verifywrap.c:131)
----------------------------------------------------------------
@@ -85,14 +85,14 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_timedlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_timedlock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:131)
+ by 0x........: main (tc20_verifywrap.c:136)
----------------------------------------------------------------
Thread #x unlocked an invalid lock at 0x........
at 0x........: mutex_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:135)
+ by 0x........: main (tc20_verifywrap.c:140)
----------------------------------------------------------------
@@ -100,7 +100,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:135)
+ by 0x........: main (tc20_verifywrap.c:140)
---------------- pthread_cond_wait et al ----------------
@@ -110,7 +110,7 @@
Thread #x: pthread_cond_{timed}wait called with un-held mutex
at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:157)
+ by 0x........: main (tc20_verifywrap.c:162)
----------------------------------------------------------------
@@ -118,14 +118,14 @@
with error code 1 (EPERM: Operation not permitted)
at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:157)
+ by 0x........: main (tc20_verifywrap.c:162)
----------------------------------------------------------------
Thread #x: pthread_cond_{signal,broadcast}: dubious: associated lock is not held by any thread
at 0x........: pthread_cond_signal_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_signal@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:162)
+ by 0x........: main (tc20_verifywrap.c:167)
FIXME: can't figure out how to verify wrap of pthread_cond_signal
@@ -135,7 +135,7 @@
Thread #x: pthread_cond_{signal,broadcast}: dubious: associated lock is not held by any thread
at 0x........: pthread_cond_broadcast_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_broadcast@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:168)
+ by 0x........: main (tc20_verifywrap.c:173)
FIXME: can't figure out how to verify wrap of pthread_broadcast_signal
@@ -145,7 +145,7 @@
Thread #x: pthread_cond_{timed}wait called with un-held mutex
at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:175)
+ by 0x........: main (tc20_verifywrap.c:180)
----------------------------------------------------------------
@@ -153,7 +153,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:175)
+ by 0x........: main (tc20_verifywrap.c:180)
---------------- pthread_rwlock_* ----------------
@@ -164,13 +164,13 @@
at 0x........: pthread_rwlock_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_unlock (hg_intercepts.c:...)
...
- by 0x........: main (tc20_verifywrap.c:189)
+ by 0x........: main (tc20_verifywrap.c:194)
Lock at 0x........ was first observed
at 0x........: pthread_rwlock_init_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:188)
+ by 0x........: main (tc20_verifywrap.c:193)
Location 0x........ is 0 bytes inside local var "rwl"
- declared at tc20_verifywrap.c:52, in frame #x of thread x
+ declared at tc20_verifywrap.c:57, in frame #x of thread x
(1) no error on next line
@@ -182,13 +182,13 @@
at 0x........: pthread_rwlock_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_unlock (hg_intercepts.c:...)
...
- by 0x........: main (tc20_verifywrap.c:206)
+ by 0x........: main (tc20_verifywrap.c:211)
Lock at 0x........ was first observed
at 0x........: pthread_rwlock_init_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:196)
+ by 0x........: main (tc20_verifywrap.c:201)
Location 0x........ is 0 bytes inside local var "rwl2"
- declared at tc20_verifywrap.c:53, in frame #x of thread x
+ declared at tc20_verifywrap.c:58, in frame #x of thread x
(4) no error on next line
@@ -202,14 +202,17 @@
at 0x........: pthread_rwlock_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_unlock (hg_intercepts.c:...)
...
- by 0x........: main (tc20_verifywrap.c:227)
+ by 0x........: main (tc20_verifywrap.c:232)
Lock at 0x........ was first observed
at 0x........: pthread_rwlock_init_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:196)
+ by 0x........: main (tc20_verifywrap.c:201)
Location 0x........ is 0 bytes inside local var "rwl2"
- declared at tc20_verifywrap.c:53, in frame #x of thread x
+ declared at tc20_verifywrap.c:58, in frame #x of thread x
+
+
+---------------- pthread_spin_* ----------------
---------------- sem_* ----------------
@@ -220,7 +223,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: sem_init_WRK (hg_intercepts.c:...)
by 0x........: sem_init@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:248)
+ by 0x........: main (tc20_verifywrap.c:267)
FIXME: can't figure out how to verify wrap of sem_destroy
@@ -230,7 +233,7 @@
Thread #x: Bug in libpthread: sem_wait succeeded on semaphore without prior sem_post
at 0x........: sem_wait_WRK (hg_intercepts.c:...)
by 0x........: sem_wait (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:262)
+ by 0x........: main (tc20_verifywrap.c:281)
FIXME: can't figure out how to verify wrap of sem_post
Modified: trunk/helgrind/tests/tc20_verifywrap.stderr.exp-mips32
==============================================================================
--- trunk/helgrind/tests/tc20_verifywrap.stderr.exp-mips32 (original)
+++ trunk/helgrind/tests/tc20_verifywrap.stderr.exp-mips32 Tue Jan 12 20:31:15 2016
@@ -14,21 +14,21 @@
Thread #x was created
...
by 0x........: pthread_create@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:81)
+ by 0x........: main (tc20_verifywrap.c:86)
----------------------------------------------------------------
Possible data race during write of size 2 at 0x........ by thread #x
Locks held: none
- at 0x........: main (tc20_verifywrap.c:83)
+ at 0x........: main (tc20_verifywrap.c:88)
This conflicts with a previous write of size 2 by thread #x
Locks held: none
- at 0x........: racy_child (tc20_verifywrap.c:39)
+ at 0x........: racy_child (tc20_verifywrap.c:44)
by 0x........: mythread_wrapper (hg_intercepts.c:...)
...
Location 0x........ is 0 bytes inside global var "unprotected"
- declared at tc20_verifywrap.c:32
+ declared at tc20_verifywrap.c:37
----------------------------------------------------------------
@@ -36,7 +36,7 @@
with error code 45 (EDEADLK: Resource deadlock would occur)
at 0x........: pthread_join_WRK (hg_intercepts.c:...)
by 0x........: pthread_join (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:88)
+ by 0x........: main (tc20_verifywrap.c:93)
---------------- pthread_mutex_lock et al ----------------
@@ -46,14 +46,14 @@
Thread #x's call to pthread_mutex_init failed
with error code 122 (EOPNOTSUPP: Operation not supported on transport endpoint)
at 0x........: pthread_mutex_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:102)
+ by 0x........: main (tc20_verifywrap.c:107)
----------------------------------------------------------------
Thread #x: pthread_mutex_destroy of a locked mutex
at 0x........: mutex_destroy_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_destroy (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:112)
+ by 0x........: main (tc20_verifywrap.c:117)
----------------------------------------------------------------
@@ -61,7 +61,7 @@
with error code 16 (EBUSY: Device or resource busy)
at 0x........: mutex_destroy_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_destroy (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:112)
+ by 0x........: main (tc20_verifywrap.c:117)
----------------------------------------------------------------
@@ -69,7 +69,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_lock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_lock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:118)
+ by 0x........: main (tc20_verifywrap.c:123)
----------------------------------------------------------------
@@ -77,7 +77,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_trylock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_trylock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:126)
+ by 0x........: main (tc20_verifywrap.c:131)
----------------------------------------------------------------
@@ -85,14 +85,14 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_timedlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_timedlock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:131)
+ by 0x........: main (tc20_verifywrap.c:136)
----------------------------------------------------------------
Thread #x unlocked an invalid lock at 0x........
at 0x........: mutex_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:135)
+ by 0x........: main (tc20_verifywrap.c:140)
----------------------------------------------------------------
@@ -100,7 +100,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:135)
+ by 0x........: main (tc20_verifywrap.c:140)
---------------- pthread_cond_wait et al ----------------
@@ -110,7 +110,7 @@
Thread #x: pthread_cond_{timed}wait called with un-held mutex
at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:157)
+ by 0x........: main (tc20_verifywrap.c:162)
----------------------------------------------------------------
@@ -118,14 +118,14 @@
with error code 1 (EPERM: Operation not permitted)
at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:157)
+ by 0x........: main (tc20_verifywrap.c:162)
----------------------------------------------------------------
Thread #x: pthread_cond_{signal,broadcast}: dubious: associated lock is not held by any thread
at 0x........: pthread_cond_signal_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_signal@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:162)
+ by 0x........: main (tc20_verifywrap.c:167)
FIXME: can't figure out how to verify wrap of pthread_cond_signal
@@ -135,7 +135,7 @@
Thread #x: pthread_cond_{signal,broadcast}: dubious: associated lock is not held by any thread
at 0x........: pthread_cond_broadcast_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_broadcast@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:168)
+ by 0x........: main (tc20_verifywrap.c:173)
FIXME: can't figure out how to verify wrap of pthread_broadcast_signal
@@ -145,7 +145,7 @@
Thread #x: pthread_cond_{timed}wait called with un-held mutex
at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:175)
+ by 0x........: main (tc20_verifywrap.c:180)
----------------------------------------------------------------
@@ -153,7 +153,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:175)
+ by 0x........: main (tc20_verifywrap.c:180)
---------------- pthread_rwlock_* ----------------
@@ -164,13 +164,13 @@
at 0x........: pthread_rwlock_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_unlock (hg_intercepts.c:...)
...
- by 0x........: main (tc20_verifywrap.c:189)
+ by 0x........: main (tc20_verifywrap.c:194)
Lock at 0x........ was first observed
at 0x........: pthread_rwlock_init_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:188)
+ by 0x........: main (tc20_verifywrap.c:193)
Location 0x........ is 0 bytes inside local var "rwl"
- declared at tc20_verifywrap.c:52, in frame #x of thread x
+ declared at tc20_verifywrap.c:57, in frame #x of thread x
(1) no error on next line
@@ -182,13 +182,13 @@
at 0x........: pthread_rwlock_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_unlock (hg_intercepts.c:...)
...
- by 0x........: main (tc20_verifywrap.c:206)
+ by 0x........: main (tc20_verifywrap.c:211)
Lock at 0x........ was first observed
at 0x........: pthread_rwlock_init_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:196)
+ by 0x........: main (tc20_verifywrap.c:201)
Location 0x........ is 0 bytes inside local var "rwl2"
- declared at tc20_verifywrap.c:53, in frame #x of thread x
+ declared at tc20_verifywrap.c:58, in frame #x of thread x
(4) no error on next line
@@ -202,14 +202,17 @@
at 0x........: pthread_rwlock_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_unlock (hg_intercepts.c:...)
...
- by 0x........: main (tc20_verifywrap.c:227)
+ by 0x........: main (tc20_verifywrap.c:232)
Lock at 0x........ was first observed
at 0x........: pthread_rwlock_init_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:196)
+ by 0x........: main (tc20_verifywrap.c:201)
Location 0x........ is 0 bytes inside local var "rwl2"
- declared at tc20_verifywrap.c:53, in frame #x of thread x
+ declared at tc20_verifywrap.c:58, in frame #x of thread x
+
+
+---------------- pthread_spin_* ----------------
---------------- sem_* ----------------
@@ -220,7 +223,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: sem_init_WRK (hg_intercepts.c:...)
by 0x........: sem_init@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:248)
+ by 0x........: main (tc20_verifywrap.c:267)
FIXME: can't figure out how to verify wrap of sem_destroy
@@ -230,7 +233,7 @@
Thread #x: Bug in libpthread: sem_wait succeeded on semaphore without prior sem_post
at 0x........: sem_wait_WRK (hg_intercepts.c:...)
by 0x........: sem_wait (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:262)
+ by 0x........: main (tc20_verifywrap.c:281)
FIXME: can't figure out how to verify wrap of sem_post
Modified: trunk/helgrind/tests/tc20_verifywrap.stderr.exp-mips32-b
==============================================================================
--- trunk/helgrind/tests/tc20_verifywrap.stderr.exp-mips32-b (original)
+++ trunk/helgrind/tests/tc20_verifywrap.stderr.exp-mips32-b Tue Jan 12 20:31:15 2016
@@ -14,21 +14,21 @@
Thread #x was created
...
by 0x........: pthread_create@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:81)
+ by 0x........: main (tc20_verifywrap.c:86)
----------------------------------------------------------------
Possible data race during write of size 2 at 0x........ by thread #x
Locks held: none
- at 0x........: main (tc20_verifywrap.c:83)
+ at 0x........: main (tc20_verifywrap.c:88)
This conflicts with a previous write of size 2 by thread #x
Locks held: none
- at 0x........: racy_child (tc20_verifywrap.c:39)
+ at 0x........: racy_child (tc20_verifywrap.c:44)
by 0x........: mythread_wrapper (hg_intercepts.c:...)
...
Location 0x........ is 0 bytes inside global var "unprotected"
- declared at tc20_verifywrap.c:32
+ declared at tc20_verifywrap.c:37
----------------------------------------------------------------
@@ -36,7 +36,7 @@
with error code 45 (EDEADLK: Resource deadlock would occur)
at 0x........: pthread_join_WRK (hg_intercepts.c:...)
by 0x........: pthread_join (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:88)
+ by 0x........: main (tc20_verifywrap.c:93)
---------------- pthread_mutex_lock et al ----------------
@@ -46,14 +46,14 @@
Thread #x's call to pthread_mutex_init failed
with error code 122 (EOPNOTSUPP: Operation not supported on transport endpoint)
at 0x........: pthread_mutex_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:102)
+ by 0x........: main (tc20_verifywrap.c:107)
----------------------------------------------------------------
Thread #x: pthread_mutex_destroy of a locked mutex
at 0x........: mutex_destroy_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_destroy (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:112)
+ by 0x........: main (tc20_verifywrap.c:117)
----------------------------------------------------------------
@@ -61,7 +61,7 @@
with error code 16 (EBUSY: Device or resource busy)
at 0x........: mutex_destroy_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_destroy (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:112)
+ by 0x........: main (tc20_verifywrap.c:117)
----------------------------------------------------------------
@@ -69,7 +69,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_lock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_lock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:118)
+ by 0x........: main (tc20_verifywrap.c:123)
----------------------------------------------------------------
@@ -77,7 +77,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_trylock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_trylock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:126)
+ by 0x........: main (tc20_verifywrap.c:131)
----------------------------------------------------------------
@@ -85,14 +85,14 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_timedlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_timedlock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:131)
+ by 0x........: main (tc20_verifywrap.c:136)
----------------------------------------------------------------
Thread #x unlocked an invalid lock at 0x........
at 0x........: mutex_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:135)
+ by 0x........: main (tc20_verifywrap.c:140)
----------------------------------------------------------------
@@ -100,7 +100,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:135)
+ by 0x........: main (tc20_verifywrap.c:140)
---------------- pthread_cond_wait et al ----------------
@@ -110,7 +110,7 @@
Thread #x: pthread_cond_{timed}wait called with un-held mutex
at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:157)
+ by 0x........: main (tc20_verifywrap.c:162)
----------------------------------------------------------------
@@ -118,14 +118,14 @@
with error code 1 (EPERM: Operation not permitted)
at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:157)
+ by 0x........: main (tc20_verifywrap.c:162)
----------------------------------------------------------------
Thread #x: pthread_cond_{signal,broadcast}: dubious: associated lock is not held by any thread
at 0x........: pthread_cond_signal_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_signal@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:162)
+ by 0x........: main (tc20_verifywrap.c:167)
FIXME: can't figure out how to verify wrap of pthread_cond_signal
@@ -135,7 +135,7 @@
Thread #x: pthread_cond_{signal,broadcast}: dubious: associated lock is not held by any thread
at 0x........: pthread_cond_broadcast_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_broadcast@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:168)
+ by 0x........: main (tc20_verifywrap.c:173)
FIXME: can't figure out how to verify wrap of pthread_broadcast_signal
@@ -145,7 +145,7 @@
Thread #x: pthread_cond_{timed}wait called with un-held mutex
at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:175)
+ by 0x........: main (tc20_verifywrap.c:180)
----------------------------------------------------------------
@@ -153,7 +153,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:175)
+ by 0x........: main (tc20_verifywrap.c:180)
---------------- pthread_rwlock_* ----------------
@@ -164,13 +164,13 @@
at 0x........: pthread_rwlock_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_unlock (hg_intercepts.c:...)
...
- by 0x........: main (tc20_verifywrap.c:189)
+ by 0x........: main (tc20_verifywrap.c:194)
Lock at 0x........ was first observed
at 0x........: pthread_rwlock_init_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:188)
+ by 0x........: main (tc20_verifywrap.c:193)
Location 0x........ is 0 bytes inside local var "rwl"
- declared at tc20_verifywrap.c:52, in frame #x of thread x
+ declared at tc20_verifywrap.c:57, in frame #x of thread x
(1) no error on next line
@@ -182,13 +182,13 @@
at 0x........: pthread_rwlock_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_unlock (hg_intercepts.c:...)
...
- by 0x........: main (tc20_verifywrap.c:206)
+ by 0x........: main (tc20_verifywrap.c:211)
Lock at 0x........ was first observed
at 0x........: pthread_rwlock_init_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:196)
+ by 0x........: main (tc20_verifywrap.c:201)
Location 0x........ is 0 bytes inside local var "rwl2"
- declared at tc20_verifywrap.c:53, in frame #x of thread x
+ declared at tc20_verifywrap.c:58, in frame #x of thread x
(4) no error on next line
@@ -202,14 +202,17 @@
at 0x........: pthread_rwlock_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_unlock (hg_intercepts.c:...)
...
- by 0x........: main (tc20_verifywrap.c:227)
+ by 0x........: main (tc20_verifywrap.c:232)
Lock at 0x........ was first observed
at 0x........: pthread_rwlock_init_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:196)
+ by 0x........: main (tc20_verifywrap.c:201)
Location 0x........ is 0 bytes inside local var "rwl2"
- declared at tc20_verifywrap.c:53, in frame #x of thread x
+ declared at tc20_verifywrap.c:58, in frame #x of thread x
+
+
+---------------- pthread_spin_* ----------------
---------------- sem_* ----------------
@@ -220,7 +223,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: sem_init_WRK (hg_intercepts.c:...)
by 0x........: sem_init@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:248)
+ by 0x........: main (tc20_verifywrap.c:267)
FIXME: can't figure out how to verify wrap of sem_destroy
@@ -230,7 +233,7 @@
Thread #x: Bug in libpthread: sem_wait succeeded on semaphore without prior sem_post
at 0x........: sem_wait_WRK (hg_intercepts.c:...)
by 0x........: sem_wait (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:262)
+ by 0x........: main (tc20_verifywrap.c:281)
----------------------------------------------------------------
@@ -239,7 +242,7 @@
at 0x........: sem_post_WRK (hg_intercepts.c:...)
by 0x........: sem_post (hg_intercepts.c:...)
...
- by 0x........: main (tc20_verifywrap.c:265)
+ by 0x........: main (tc20_verifywrap.c:284)
FIXME: can't figure out how to verify wrap of sem_post
Modified: trunk/helgrind/tests/tc20_verifywrap.stderr.exp-s390x
==============================================================================
--- trunk/helgrind/tests/tc20_verifywrap.stderr.exp-s390x (original)
+++ trunk/helgrind/tests/tc20_verifywrap.stderr.exp-s390x Tue Jan 12 20:31:15 2016
@@ -15,22 +15,22 @@
...
by 0x........: pthread_create_WRK (hg_intercepts.c:...)
by 0x........: pthread_create@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:81)
+ by 0x........: main (tc20_verifywrap.c:86)
----------------------------------------------------------------
Possible data race during write of size 2 at 0x........ by thread #x
Locks held: none
- at 0x........: main (tc20_verifywrap.c:83)
+ at 0x........: main (tc20_verifywrap.c:88)
This conflicts with a previous write of size 2 by thread #x
Locks held: none
- at 0x........: racy_child (tc20_verifywrap.c:39)
+ at 0x........: racy_child (tc20_verifywrap.c:44)
by 0x........: mythread_wrapper (hg_intercepts.c:...)
...
Location 0x........ is 0 bytes inside global var "unprotected"
-declared at tc20_verifywrap.c:32
+declared at tc20_verifywrap.c:37
----------------------------------------------------------------
@@ -38,7 +38,7 @@
with error code 35 (EDEADLK: Resource deadlock would occur)
at 0x........: pthread_join_WRK (hg_intercepts.c:...)
by 0x........: pthread_join (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:88)
+ by 0x........: main (tc20_verifywrap.c:93)
---------------- pthread_mutex_lock et al ----------------
@@ -48,14 +48,14 @@
Thread #x's call to pthread_mutex_init failed
with error code 95 (EOPNOTSUPP: Operation not supported on transport endpoint)
at 0x........: pthread_mutex_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:102)
+ by 0x........: main (tc20_verifywrap.c:107)
----------------------------------------------------------------
Thread #x: pthread_mutex_destroy of a locked mutex
at 0x........: mutex_destroy_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_destroy (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:112)
+ by 0x........: main (tc20_verifywrap.c:117)
----------------------------------------------------------------
@@ -63,7 +63,7 @@
with error code 16 (EBUSY: Device or resource busy)
at 0x........: mutex_destroy_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_destroy (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:112)
+ by 0x........: main (tc20_verifywrap.c:117)
----------------------------------------------------------------
@@ -71,7 +71,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_lock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_lock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:118)
+ by 0x........: main (tc20_verifywrap.c:123)
----------------------------------------------------------------
@@ -79,7 +79,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_trylock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_trylock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:126)
+ by 0x........: main (tc20_verifywrap.c:131)
----------------------------------------------------------------
@@ -87,14 +87,14 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_timedlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_timedlock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:131)
+ by 0x........: main (tc20_verifywrap.c:136)
----------------------------------------------------------------
Thread #x unlocked an invalid lock at 0x........
at 0x........: mutex_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:135)
+ by 0x........: main (tc20_verifywrap.c:140)
----------------------------------------------------------------
@@ -102,7 +102,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: mutex_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_mutex_unlock (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:135)
+ by 0x........: main (tc20_verifywrap.c:140)
---------------- pthread_cond_wait et al ----------------
@@ -112,7 +112,7 @@
Thread #x: pthread_cond_{timed}wait called with un-held mutex
at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:157)
+ by 0x........: main (tc20_verifywrap.c:162)
----------------------------------------------------------------
@@ -120,14 +120,14 @@
with error code 1 (EPERM: Operation not permitted)
at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:157)
+ by 0x........: main (tc20_verifywrap.c:162)
----------------------------------------------------------------
Thread #x: pthread_cond_{signal,broadcast}: dubious: associated lock is not held by any thread
at 0x........: pthread_cond_signal_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_signal@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:162)
+ by 0x........: main (tc20_verifywrap.c:167)
FIXME: can't figure out how to verify wrap of pthread_cond_signal
@@ -137,7 +137,7 @@
Thread #x: pthread_cond_{signal,broadcast}: dubious: associated lock is not held by any thread
at 0x........: pthread_cond_broadcast_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_broadcast@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:168)
+ by 0x........: main (tc20_verifywrap.c:173)
FIXME: can't figure out how to verify wrap of pthread_broadcast_signal
@@ -147,7 +147,7 @@
Thread #x: pthread_cond_{timed}wait called with un-held mutex
at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:175)
+ by 0x........: main (tc20_verifywrap.c:180)
----------------------------------------------------------------
@@ -155,7 +155,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...)
by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:175)
+ by 0x........: main (tc20_verifywrap.c:180)
---------------- pthread_rwlock_* ----------------
@@ -166,11 +166,11 @@
at 0x........: pthread_rwlock_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_unlock (hg_intercepts.c:...)
...
- by 0x........: main (tc20_verifywrap.c:189)
+ by 0x........: main (tc20_verifywrap.c:194)
Lock at 0x........ was first observed
at 0x........: pthread_rwlock_init_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:188)
+ by 0x........: main (tc20_verifywrap.c:193)
(1) no error on next line
(2) no error on next line
@@ -181,11 +181,11 @@
at 0x........: pthread_rwlock_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_unlock (hg_intercepts.c:...)
...
- by 0x........: main (tc20_verifywrap.c:206)
+ by 0x........: main (tc20_verifywrap.c:211)
Lock at 0x........ was first observed
at 0x........: pthread_rwlock_init_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:196)
+ by 0x........: main (tc20_verifywrap.c:201)
(4) no error on next line
(5) no error on next line
@@ -198,11 +198,15 @@
at 0x........: pthread_rwlock_unlock_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_unlock (hg_intercepts.c:...)
...
- by 0x........: main (tc20_verifywrap.c:227)
+ by 0x........: main (tc20_verifywrap.c:232)
Lock at 0x........ was first observed
at 0x........: pthread_rwlock_init_WRK (hg_intercepts.c:...)
by 0x........: pthread_rwlock_init (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:196)
+ by 0x........: main (tc20_verifywrap.c:201)
+
+
+
+---------------- pthread_spin_* ----------------
---------------- sem_* ----------------
@@ -213,7 +217,7 @@
with error code 22 (EINVAL: Invalid argument)
at 0x........: sem_init_WRK (hg_intercepts.c:...)
by 0x........: sem_init@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:243)
+ by 0x........: main (tc20_verifywrap.c:267)
FIXME: can't figure out how to verify wrap of sem_destroy
@@ -223,7 +227,7 @@
Thread #x: Bug in libpthread: sem_wait succeeded on semaphore without prior sem_post
at 0x........: sem_wait_WRK (hg_intercepts.c:...)
by 0x........: sem_wait (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:257)
+ by 0x........: main (tc20_verifywrap.c:281)
FIXME: can't figure out how to verify wrap of sem_post
Modified: trunk/helgrind/tests/tc20_verifywrap.stderr.exp-solaris
==============================================================================
--- trunk/helgrind/tests/tc20_verifywrap.stderr.exp-solaris (original)
+++ trunk/helgrind/tests/tc20_verifywrap.stderr.exp-solaris Tue Jan 12 20:31:15 2016
@@ -14,21 +14,21 @@
Thread #x was created
...
by 0x........: pthread_create@* (hg_intercepts.c:...)
- by 0x........: main (tc20_verifywrap.c:81)
+ by 0x........: main (tc20_verifywrap.c:86)
---------------...
[truncated message content] |
|
From: Josef W. <Jos...@gm...> - 2016-01-12 19:37:11
|
Am 12.01.2016 um 19:58 schrieb Matthias Schwarzott: > Am 12.01.2016 um 15:32 schrieb sv...@va...: > Wow, that could explain why callgrind did crash for me with > --separate-threads=yes and --dump-every-bb after some time. That also means that I should fix cg to print a meaningful message when an output file cannot be created due to running out of file descriptors :-) Josef |
|
From: Matthias S. <zz...@ge...> - 2016-01-12 18:59:16
|
Am 12.01.2016 um 15:32 schrieb sv...@va...: > Author: florian > Date: Tue Jan 12 14:32:05 2016 > New Revision: 15755 > > Log: > VG_(fclose) ought to close the file, you silly. Fixes BZ #357887. > Wow, that could explain why callgrind did crash for me with --separate-threads=yes and --dump-every-bb after some time. I thought it was caused by kcachegrind triggering snapshotting to often. Doing a quick check like the following shows that it was just running out of file descriptors: # strace -o vg.strace.log valgrind --tool=callgrind--separate-threads=yes --dump-every-bb=20 kate Thanks for fixing this one. Regards Matthias |
|
From: <sv...@va...> - 2016-01-12 14:32:13
|
Author: florian
Date: Tue Jan 12 14:32:05 2016
New Revision: 15755
Log:
VG_(fclose) ought to close the file, you silly. Fixes BZ #357887.
Modified:
trunk/NEWS
trunk/coregrind/m_libcprint.c
Modified: trunk/NEWS
==============================================================================
--- trunk/NEWS (original)
+++ trunk/NEWS Tue Jan 12 14:32:05 2016
@@ -57,6 +57,7 @@
355455 stderr.exp of test cases wrapmalloc and wrapmallocstatic overconstrained
355454 do not intercept malloc related symbols from the runtime linker
356044 Dwarf line info reader misinterprets is_stmt register
+357887 Fix a file handle leak. VG_(fclose) did not close the file
n-i-bz Fix incorrect (or infinite loop) unwind on RHEL7 x86 32 bits
n-i-bz massif --pages-as-heap=yes does not report peak caused by mmap+munmap
Modified: trunk/coregrind/m_libcprint.c
==============================================================================
--- trunk/coregrind/m_libcprint.c (original)
+++ trunk/coregrind/m_libcprint.c Tue Jan 12 14:32:05 2016
@@ -359,6 +359,7 @@
if (fp->num_chars)
VG_(write)(fp->fd, fp->buf, fp->num_chars);
+ VG_(close)(fp->fd);
VG_(free)(fp);
}
|
|
From: Patrick C. <psc...@go...> - 2016-01-07 20:13:55
|
In coregrind/m_debuginfo/debuginfo.c, within the function
VG_(di_notify_mmap), there is a comment that describes when Valgrind tries
to look up debug symbols for an mmaped region. It says:
/* Now we have to guess if this is a text-like mapping, a data-like
mapping, neither or both. The rules are:
text if: x86-linux r and x
other-linux r and x and not w
data if: x86-linux r and w
other-linux r and w and not x
.... */
and goes on to describe a number of edge cases when that isn't the case.
Why require that .text isn't writable on amd64 architecture? Although
unusual and not produced by most compilers, there is nothing in either the
ELF standard or the architecture that prevents executable sections from
being mmaped with write permission. It's a legal mapping, and GDB can
properly find debug symbols in this situation. It's possible to
accidentally end up with a .text section mmaped with rwx permission with
use of the __attribute__((section(....))) GCC annotation, and its debug
symbols end up being silently ignored by Valgrind.
Why was this decision made?
|