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
(5) |
2
(15) |
3
(20) |
|
4
(4) |
5
(11) |
6
(8) |
7
(36) |
8
(23) |
9
(6) |
10
(4) |
|
11
(4) |
12
(19) |
13
(17) |
14
(33) |
15
(16) |
16
(17) |
17
(4) |
|
18
(4) |
19
(30) |
20
(22) |
21
(23) |
22
(29) |
23
(20) |
24
(12) |
|
25
(7) |
26
(33) |
27
(10) |
28
(12) |
29
(19) |
30
(15) |
31
(8) |
|
From: <sv...@va...> - 2009-01-25 23:50:42
|
Author: sewardj
Date: 2009-01-25 23:50:32 +0000 (Sun, 25 Jan 2009)
New Revision: 9058
Log:
Handle a couple of artefacts produced by icc11: DW_TAG_reference_type
that doesn't have a size, and DW_FORM_ref_addr (assuming my
interpretation of the standard is correct.)
Modified:
trunk/coregrind/m_debuginfo/readdwarf3.c
Modified: trunk/coregrind/m_debuginfo/readdwarf3.c
===================================================================
--- trunk/coregrind/m_debuginfo/readdwarf3.c 2009-01-25 23:48:31 UTC (rev 9057)
+++ trunk/coregrind/m_debuginfo/readdwarf3.c 2009-01-25 23:50:32 UTC (rev 9058)
@@ -418,6 +418,9 @@
/* Where is .debug_line? */
UChar* debug_line_img;
UWord debug_line_sz;
+ /* Where is .debug_info? */
+ UChar* debug_info_img;
+ UWord debug_info_sz;
/* --- Needed so we can add stuff to the string table. --- */
struct _DebugInfo* di;
/* --- a cache for set_abbv_Cursor --- */
@@ -901,7 +904,8 @@
/* address size. If this isn't equal to the host word size, just
give up. This makes it safe to assume elsewhere that
- DW_FORM_addr can be treated as a host word. */
+ DW_FORM_addr and DW_FORM_ref_addr can be treated as a host
+ word. */
address_size = get_UChar( c );
if (address_size != sizeof(void*))
cc->barf( "parse_CU_Header: invalid address_size" );
@@ -1083,12 +1087,43 @@
*ctsSzB = sizeof(UWord);
TRACE_D3("0x%lx", (UWord)*cts);
break;
+
+ case DW_FORM_ref_addr:
+ /* We make the same word-size assumption as DW_FORM_addr. */
+ /* What does this really mean? From D3 Sec 7.5.4,
+ description of "reference", it would appear to reference
+ some other DIE, by specifying the offset from the
+ beginning of a .debug_info section. The D3 spec mentions
+ that this might be in some other shared object and
+ executable. But I don't see how the name of the other
+ object/exe is specified.
+
+ At least for the DW_FORM_ref_addrs created by icc11, the
+ references seem to be within the same object/executable.
+ So for the moment we merely range-check, to see that they
+ actually do specify a plausible offset within this
+ object's .debug_info, and return the value unchanged.
+ */
+ *cts = (ULong)(UWord)get_UWord(c);
+ *ctsSzB = sizeof(UWord);
+ TRACE_D3("0x%lx", (UWord)*cts);
+ if (0) VG_(printf)("DW_FORM_ref_addr 0x%lx\n", (UWord)*cts);
+ if (/* the following 2 are surely impossible, but ... */
+ cc->debug_info_img == NULL || cc->debug_info_sz == 0
+ || *cts >= (ULong)cc->debug_info_sz) {
+ /* Hmm. Offset is nonsensical for this object's .debug_info
+ section. Be safe and reject it. */
+ cc->barf("get_Form_contents: DW_FORM_ref_addr points "
+ "outside .debug_info");
+ }
+ break;
+
case DW_FORM_strp: {
/* this is an offset into .debug_str */
UChar* str;
UWord uw = (UWord)get_Dwarfish_UWord( c, cc->is_dw64 );
if (cc->debug_str_img == NULL || uw >= cc->debug_str_sz)
- cc->barf("read_and_show_Form: DW_FORM_strp "
+ cc->barf("get_Form_contents: DW_FORM_strp "
"points outside .debug_str");
/* FIXME: check the entire string lies inside debug_str,
not just the first byte of it. */
@@ -1149,8 +1184,9 @@
break;
}
default:
- VG_(printf)("get_Form_contents: unhandled %d (%s)\n",
- form, ML_(pp_DW_FORM)(form));
+ VG_(printf)(
+ "get_Form_contents: unhandled %d (%s) at <%lx>\n",
+ form, ML_(pp_DW_FORM)(form), get_position_of_Cursor(c));
c->barf("get_Form_contents: unhandled DW_FORM");
}
}
@@ -2184,14 +2220,13 @@
typeE.Te.TyPorR.typeR = D3_FAKEVOID_CUOFF;
typeE.Te.TyPorR.isPtr = dtag == DW_TAG_pointer_type
|| dtag == DW_TAG_ptr_to_member_type;
- /* Pointer types don't *have* to specify their size, in which
- case we assume it's a machine word. But if they do specify
- it, it must be a machine word :-) This probably assumes that
- the word size of the Dwarf3 we're reading is the same size as
- that on the machine. gcc appears to give a size whereas icc9
- doesn't. */
- if (typeE.Te.TyPorR.isPtr)
- typeE.Te.TyPorR.szB = sizeof(Word);
+ /* These three type kinds don't *have* to specify their size, in
+ which case we assume it's a machine word. But if they do
+ specify it, it must be a machine word :-) This probably
+ assumes that the word size of the Dwarf3 we're reading is the
+ same size as that on the machine. gcc appears to give a size
+ whereas icc9 doesn't. */
+ typeE.Te.TyPorR.szB = sizeof(UWord);
while (True) {
DW_AT attr = (DW_AT) get_ULEB128( c_abbv );
DW_FORM form = (DW_FORM)get_ULEB128( c_abbv );
@@ -2206,7 +2241,7 @@
}
}
/* Do we have something that looks sane? */
- if (typeE.Te.TyPorR.szB != sizeof(Word))
+ if (typeE.Te.TyPorR.szB != sizeof(UWord))
goto bad_DIE;
else
goto acquire_Type;
@@ -3437,6 +3472,8 @@
cc.debug_loc_sz = debug_loc_sz;
cc.debug_line_img = debug_line_img;
cc.debug_line_sz = debug_line_sz;
+ cc.debug_info_img = debug_info_img;
+ cc.debug_info_sz = debug_info_sz;
cc.cu_start_offset = cu_start_offset;
cc.di = di;
/* The CU's svma can be deduced by looking at the AT_low_pc
|
|
From: <sv...@va...> - 2009-01-25 23:48:38
|
Author: sewardj
Date: 2009-01-25 23:48:31 +0000 (Sun, 25 Jan 2009)
New Revision: 9057
Log:
Handle a couple of artefacts generated by gcc-4.4: DW_OP_reg{0..31}
and DW_OP_const1s.
--> 3_4_BRANCH
Modified:
trunk/coregrind/m_debuginfo/readdwarf.c
Modified: trunk/coregrind/m_debuginfo/readdwarf.c
===================================================================
--- trunk/coregrind/m_debuginfo/readdwarf.c 2009-01-24 10:52:32 UTC (rev 9056)
+++ trunk/coregrind/m_debuginfo/readdwarf.c 2009-01-25 23:48:31 UTC (rev 9057)
@@ -2555,6 +2555,16 @@
VG_(printf)("DW_OP_breg%d: %ld", reg, sw);
break;
+ case DW_OP_reg0 ... DW_OP_reg31:
+ /* push: reg */
+ reg = (Int)opcode - (Int)DW_OP_reg0;
+ vg_assert(reg >= 0 && reg <= 31);
+ ix = ML_(CfiExpr_DwReg)( dst, reg );
+ PUSH(ix);
+ if (ddump_frames)
+ VG_(printf)("DW_OP_reg%d", reg);
+ break;
+
case DW_OP_plus_uconst:
uw = read_leb128U( &expr );
PUSH( ML_(CfiExpr_Const)( dst, uw ) );
@@ -2574,6 +2584,15 @@
VG_(printf)("DW_OP_const4s: %ld", sw);
break;
+ case DW_OP_const1s:
+ /* push: 8-bit signed immediate */
+ sw = read_le_s_encoded_literal( expr, 1 );
+ expr += 1;
+ PUSH( ML_(CfiExpr_Const)( dst, (UWord)sw ) );
+ if (ddump_frames)
+ VG_(printf)("DW_OP_const1s: %ld", sw);
+ break;
+
case DW_OP_minus:
op = Cop_Sub; opname = "minus"; goto binop;
case DW_OP_plus:
|
|
From: Ali J. <a.j...@gm...> - 2009-01-25 22:15:40
|
Sorry, we used a very old revision of unittest. The bug can be reproduced
until revision 382.
Since revision 383, every printf is synchronized via mutex and helgrind's
loag gets initialized in every case.
The following simple program also triggers the described behaviour:
#include <pthread.h>
pthread_mutex_t mutex;
int main(int argc, char* argv[])
{
pthread_mutex_init(&mutex, NULL);
pthread_mutex_destroy(&mutex);
return 0;
}
Ali
> -----Original Message-----
> From: Julian Seward [mailto:js...@ac...]
> Sent: Samstag, 24. Januar 2009 21:30
> To: val...@li...
> Cc: Ali Jannesari
> Subject: Re: [Valgrind-developers] Bug in Helgrind
>
>
> > test00: negative
> > GLOB=0
> > --22433-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11
> (SIGSEGV)
> > - exiting
> > --22433-- si_code=1; Faulting address: 0x10; sp: 0x62e67e88
>
> > Test 0's destructor is trying to delete a mutex, but the whole
> program
> > never used mutexes.
> > So, Helgrind's loag is not initialized and trying to delete the mutex
> > faults.
>
> I understand what you're saying, but I can't reproduce this failure:
>
> sewardj@zazenhausen:~/DaRaT/unittest$
> valgrind-3.4.0 --tool=helgrind ./racecheck_unittest 0
> ==24354== Helgrind, a thread error detector.
> ==24354== Copyright (C) 2007-2008, and GNU GPL'd, by OpenWorks LLP et
> al.
> ==24354== Using LibVEX rev 1878, a library for dynamic binary
> translation.
> ==24354== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
> ==24354== Using valgrind-3.4.0, a dynamic binary instrumentation
> framework.
> ==24354== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et
> al.
> ==24354== For more details, rerun with: -v
> ==24354==
> test00: negative
> GLOB=0
> ==24354==
> ==24354== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from
> 0)
>
> Do I need to build racecheck_unittest in some special way? I simply
> checked out the sources and did 'make' in the unittest directory;
> maybe there is some other config option needed? I believe there are
> some magic configuration options for racecheck_unittest, but I don't
> know what they are.
>
> J
|
|
From: Tom H. <th...@cy...> - 2009-01-25 03:48:15
|
Nightly build on vauxhall ( x86_64, Fedora 10 ) started at 2009-01-25 03:20:05 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 481 tests, 2 stderr failures, 0 stdout failures, 0 post failures == drd/tests/qt4_mutex (stderr) memcheck/tests/x86-linux/scalar (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 481 tests, 1 stderr failure, 0 stdout failures, 0 post failures == memcheck/tests/x86-linux/scalar (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Jan 25 03:34:04 2009 --- new.short Sun Jan 25 03:47:58 2009 *************** *** 8,10 **** ! == 481 tests, 1 stderr failure, 0 stdout failures, 0 post failures == memcheck/tests/x86-linux/scalar (stderr) --- 8,11 ---- ! == 481 tests, 2 stderr failures, 0 stdout failures, 0 post failures == ! drd/tests/qt4_mutex (stderr) memcheck/tests/x86-linux/scalar (stderr) |
|
From: Tom H. <th...@cy...> - 2009-01-25 03:47:46
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2009-01-25 03:05:07 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 472 tests, 6 stderr failures, 0 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/tc20_verifywrap (stderr) memcheck/tests/x86-linux/scalar (stderr) |
|
From: Tom H. <th...@cy...> - 2009-01-25 03:33:16
|
Nightly build on mg ( x86_64, Fedora 9 ) started at 2009-01-25 03:10:03 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 478 tests, 5 stderr failures, 2 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) memcheck/tests/linux/timerfd-syscall (stdout) memcheck/tests/x86-linux/scalar (stderr) none/tests/mremap2 (stdout) |