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
(9) |
2
(2) |
3
(9) |
4
(19) |
5
(4) |
6
(1) |
7
(6) |
|
8
(11) |
9
(30) |
10
(12) |
11
(25) |
12
(7) |
13
(5) |
14
|
|
15
(17) |
16
(15) |
17
(20) |
18
(17) |
19
(5) |
20
(4) |
21
|
|
22
|
23
|
24
|
25
|
26
|
27
(4) |
28
(15) |
|
29
(10) |
30
(9) |
31
(11) |
|
|
|
|
|
From: Christian B. <bor...@de...> - 2011-05-03 20:34:14
|
Nightly build on fedora390 ( Fedora 13/14/15 mix with gcc 3.5.3 on z196 (s390x) ) Started at 2011-05-03 22:10:01 CEST Ended at 2011-05-03 22:33:21 CEST 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 == 460 tests, 6 stderr failures, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/tc04_free_lock (stderr) drd/tests/tc09_bad_unlock (stderr) drd/tests/tc23_bogus_condwait (stderr) |
|
From: Christian B. <bor...@de...> - 2011-05-03 20:29:06
|
Nightly build on sless390 ( SUSE Linux Enterprise Server 11 SP1 gcc 4.3.4 on z196 (s390x) ) Started at 2011-05-03 22:10:01 CEST Ended at 2011-05-03 22:28:49 CEST 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 == 461 tests, 6 stderr failures, 0 stdout failures, 0 post failures == none/tests/faultstatus (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/tc04_free_lock (stderr) drd/tests/tc09_bad_unlock (stderr) drd/tests/tc23_bogus_condwait (stderr) |
|
From: <sv...@va...> - 2011-05-03 14:58:07
|
Author: sewardj
Date: 2011-05-03 15:57:59 +0100 (Tue, 03 May 2011)
New Revision: 2143
Log:
Support DMB and DSB variants on ARM. Bug 266035 comment 3.
(Jeff Brown, jef...@go...)
Modified:
trunk/priv/guest_arm_toIR.c
Modified: trunk/priv/guest_arm_toIR.c
===================================================================
--- trunk/priv/guest_arm_toIR.c 2011-05-03 11:08:39 UTC (rev 2142)
+++ trunk/priv/guest_arm_toIR.c 2011-05-03 14:57:59 UTC (rev 2143)
@@ -11942,11 +11942,25 @@
stmt( IRStmt_MBE(Imbe_Fence) );
DIP("ISB\n");
return True;
- case 0xF57FF04F: /* DSB */
+ case 0xF57FF04F: /* DSB sy */
+ case 0xF57FF04E: /* DSB st */
+ case 0xF57FF04B: /* DSB ish */
+ case 0xF57FF04A: /* DSB ishst */
+ case 0xF57FF047: /* DSB nsh */
+ case 0xF57FF046: /* DSB nshst */
+ case 0xF57FF043: /* DSB osh */
+ case 0xF57FF042: /* DSB oshst */
stmt( IRStmt_MBE(Imbe_Fence) );
DIP("DSB\n");
return True;
- case 0xF57FF05F: /* DMB */
+ case 0xF57FF05F: /* DMB sy */
+ case 0xF57FF05E: /* DMB st */
+ case 0xF57FF05B: /* DMB ish */
+ case 0xF57FF05A: /* DMB ishst */
+ case 0xF57FF057: /* DMB nsh */
+ case 0xF57FF056: /* DMB nshst */
+ case 0xF57FF053: /* DMB osh */
+ case 0xF57FF052: /* DMB oshst */
stmt( IRStmt_MBE(Imbe_Fence) );
DIP("DMB\n");
return True;
|
|
From: <sv...@va...> - 2011-05-03 14:24:19
|
Author: sewardj
Date: 2011-05-03 15:24:11 +0100 (Tue, 03 May 2011)
New Revision: 11720
Log:
arm-linux: Set _start symbol alignment and type. Bug 266035 comment 1.
(Jeff Brown, jef...@go...)
Modified:
trunk/coregrind/m_main.c
Modified: trunk/coregrind/m_main.c
===================================================================
--- trunk/coregrind/m_main.c 2011-04-30 07:27:41 UTC (rev 11719)
+++ trunk/coregrind/m_main.c 2011-05-03 14:24:11 UTC (rev 11720)
@@ -2823,7 +2823,9 @@
);
#elif defined(VGP_arm_linux)
asm("\n"
- "\t.align 2\n"
+ "\t.text\n"
+ "\t.align 4\n"
+ "\t.type _start,#function\n"
"\t.global _start\n"
"_start:\n"
"\tldr r0, [pc, #36]\n"
|
|
From: Florian K. <br...@ac...> - 2011-05-03 14:05:59
|
On 05/03/2011 04:26 AM, Julian Seward wrote: > > Does this analyser have a name? Having to refer to it as "the IBM > checker" in email etc is a bit lame. > The term "IBM checker" used to be a pun on the "Stanford checker" from long time ago which now is Coverity. It is a bit lame I agree. The internal name is BEAM which stands for Bugs, Errors, and Mistakes. https://researcher.ibm.com/researcher/view_project.php?id=1628 Perhaps we can refer to it as "IBM checker BEAM" or "IBM's BEAM checker". It's probably fair to give IBM some credit for letting us use the tool. > What's the scope of the checker? Does it operate only within > compilation units, or can it analyse across compilation units? > Analysis is across compilation units. > >> Attached (so the mail transfer won't garble it) are some results from >> a run that happened last night on VGP_x86_linux. > > Does that mean that the run happened on a 32-bit x86 Linux box, or that > V was configured that for the analysis run? Valgrind was configured such that VGP_x86_linux is defined. The analysis was done assuming an ILP32 target which is consistent. > If the latter, is it possible > to do analysis runs for other popular configurations (amd64-linux, > arm-linux) ? I presume you can't analyse the Darwin ports since > they require Darwin headers. > We'll have weekly runs s390x for sure :). I see whether I can arrange for x86 or amd64. The exposure of missing some defects is probably not that large. BEAM did analyse all those files that were compiled during a build. ARM is definitely not an option. If Maynard is interested in setting up runs on ppc I'd be happy to point him to the people to talk to. > Some comments on the errors follow. > [snip] > > > -- MISTAKE5 /*constant condition*/ >>>> MISTAKE5_mkLazyN_ab34cd99c4fb48ec > "memcheck/mc_translate.c", line 1588: The expression `mergeTy64' is true > whenever evaluated > > COMMENT: The checker assumes (by default) that a variable of enumerated type > can only assume the value of any of the enumerators defined for its > type. > The enumerators for IRType all have values > 0; Hence the complaint. > I believe the fix here is to declare mergeTy64 as Bool. > > > Trivial to fix (as you say); what is difficult is to figure out / verify > if the fix affects the performance or accuracy of Memcheck on floating > point code, since afaics the fix will change the instrumentation code > Memcheck generates. > I do not think memcheck instrumentation will be affected. There are two variables: mergeTy and mergeTy64. The former affects memcheck because it is passed to mkPCastTo. The latter is the one whose type should be changed to Bool. And that won't affect memcheck as far as I can see. > ----- > > -- ERROR9 /*passing null object*/ >>>> ERROR9_handle_maybe_load_notifier_e2c77f1b1505 > "coregrind/m_redir.c", line 1190: passing NULL to argument 1 of > `vgPlain_strncmp' > ONE POSSIBLE PATH LEADING TO THE ERROR: > "coregrind/m_redir.c", line 1180: conjunct is false (used as evidence that > error is possible) > "coregrind/m_redir.c", line 1180: the if-condition is false > "coregrind/m_redir.c", line 1190: calling `vgPlain_strncmp' > > I didn't understand this. Where does it think the NULL comes from? > I don't see it. > Line 1180: if (symbol && symbol[0] == '_' In other words: if (symbol != NULL && symbol[0] == '_' So you're considering the case that symbol could be NULL. Then it's passed to vgPlain_strncmp unguarded. > ----- > > -- ERROR2 /*operating on NULL*/ >>>> ERROR2_alloc_client_block_6975911e2b60e > "memcheck/mc_main.c", line 4955: invalid operation involving NULL pointer > ONE POSSIBLE PATH LEADING TO THE ERROR: > "memcheck/mc_main.c", line 4937: assuming `i == cgb_used - 1' > "memcheck/mc_main.c", line 4937: loop entry condition is true > "memcheck/mc_main.c", line 4939: the if-condition is false > "memcheck/mc_main.c", line 4937: going around the loop again > "memcheck/mc_main.c", line 4937: loop entry condition is false, therefore > exiting from the loop started on line 4937 > "memcheck/mc_main.c", line 4944: assuming `cgb_used == cgb_size' > "memcheck/mc_main.c", line 4944: the if-condition is false > "memcheck/mc_main.c", line 4951: the ?-condition is true (used as evidence > that error is possible) > "memcheck/mc_main.c", line 4954: loop entry condition is true > "memcheck/mc_main.c", line 4955: using operation `[]' to dereference NULL > pointer `cgbs' > > VALUES AT THE END OF THE PATH: > cgbs = 0 > i = 0 > > > This seems bogus to me, because > "memcheck/mc_main.c", line 4939: the if-condition is false > means that this ?-condition can't be true > "memcheck/mc_main.c", line 4951: the ?-condition is true (used as evidence > that error is possible) > > If cgbs == NULL at line 4951 then we would have segfaulted at 4939. > I think the reason why the report is for line 4955 and not for 4939 is that on line 4939 there is no evidence that cgbs could be NULL. That is only established on line 4951. > > -- ERROR5 /*dereferencing NULL*/ >>>> ERROR5_vgPlain_env_unsetenv_dfc79f795979a8 > "coregrind/m_libcproc.c", line 104: dereferencing NULL pointer `to' > > Yeah, I guess this could fault if the supplied 'env' is NULL. > We should assert against it. Yep, I agree, that would be good. Florian |
|
From: <sv...@va...> - 2011-05-03 11:08:48
|
Author: sewardj
Date: 2011-05-03 12:08:39 +0100 (Tue, 03 May 2011)
New Revision: 2142
Log:
Fix a bogus assertion observed by Florian Krohm.
Modified:
trunk/priv/guest_arm_toIR.c
Modified: trunk/priv/guest_arm_toIR.c
===================================================================
--- trunk/priv/guest_arm_toIR.c 2011-05-03 07:51:49 UTC (rev 2141)
+++ trunk/priv/guest_arm_toIR.c 2011-05-03 11:08:39 UTC (rev 2142)
@@ -14027,7 +14027,7 @@
assert here. */
vassert(dres.whatNext == Dis_Continue);
vassert(irsb->next == NULL);
- vassert(irsb->jumpkind = Ijk_Boring);
+ vassert(irsb->jumpkind == Ijk_Boring);
/* If r15 is unconditionally written, terminate the block by
jumping to it. If it's conditionally written, still
terminate the block (a shame, but we can't do side exits to
@@ -17864,7 +17864,7 @@
assert here. */
vassert(dres.whatNext == Dis_Continue);
vassert(irsb->next == NULL);
- vassert(irsb->jumpkind = Ijk_Boring);
+ vassert(irsb->jumpkind == Ijk_Boring);
/* If r15 is unconditionally written, terminate the block by
jumping to it. If it's conditionally written, still
terminate the block (a shame, but we can't do side exits to
|
|
From: Bart V. A. <bva...@ac...> - 2011-05-03 10:38:12
|
On Tue, May 3, 2011 at 10:26 AM, Julian Seward <js...@ac...> wrote: > > There's some good stuff here, which I'm in a way disappointed that > neither gcc nor clang found. Although I guess that's not fair to > clang; I merely tried clang, not the clang static analyser. > It will take some time to fix and verify some of them. So weekly > re-runs would be good. The false error rate looks tolerable > (so far I can only see one false error) so whatever > settings you have seem to me to be OK. > > Does this analyser have a name? Having to refer to it as "the IBM > checker" in email etc is a bit lame. > > What's the scope of the checker? Does it operate only within > compilation units, or can it analyse across compilation units? > > > > Attached (so the mail transfer won't garble it) are some results from > > a run that happened last night on VGP_x86_linux. > > Does that mean that the run happened on a 32-bit x86 Linux box, or that > V was configured that for the analysis run? If the latter, is it possible > to do analysis runs for other popular configurations (amd64-linux, > arm-linux) ? I presume you can't analyse the Darwin ports since > they require Darwin headers. > > Some comments on the errors follow. > > ----- > > I only looked at a few so far. I think Bart fixed the DRD ones; > Bart, is that so? > Yes, that's correct. Bart. |
|
From: Julian S. <js...@ac...> - 2011-05-03 08:28:42
|
There's some good stuff here, which I'm in a way disappointed that
neither gcc nor clang found. Although I guess that's not fair to
clang; I merely tried clang, not the clang static analyser.
It will take some time to fix and verify some of them. So weekly
re-runs would be good. The false error rate looks tolerable
(so far I can only see one false error) so whatever
settings you have seem to me to be OK.
Does this analyser have a name? Having to refer to it as "the IBM
checker" in email etc is a bit lame.
What's the scope of the checker? Does it operate only within
compilation units, or can it analyse across compilation units?
> Attached (so the mail transfer won't garble it) are some results from
> a run that happened last night on VGP_x86_linux.
Does that mean that the run happened on a 32-bit x86 Linux box, or that
V was configured that for the analysis run? If the latter, is it possible
to do analysis runs for other popular configurations (amd64-linux,
arm-linux) ? I presume you can't analyse the Darwin ports since
they require Darwin headers.
Some comments on the errors follow.
-----
I only looked at a few so far. I think Bart fixed the DRD ones;
Bart, is that so?
-- WARNING5 /*assignment in condition*/
>>>WARNING5_disInstr_ARM_WRK_14bf2881505
"VEX/priv/guest_arm_toIR.c", line 14013: operator = in the boolean expression
should possibly be ==
Urr. That might have to do with why Callgrind gets confused about
calls/returns when running ARM code.
-----
-- MISTAKE5 /*constant condition*/
>>>MISTAKE5_iselIntExpr_R_wrk_1f6612751505
"VEX/priv/host_amd64_isel.c", line 866: The expression `(int)Ity_I16' is true
whenever evaluated
You Typed: vassert(ty == Ity_I32 || Ity_I16 || Ity_I8)
This is a stupid copy-n-paste gone wrong from the x86 equivalent.
Because Ity_I16 and Ity_I8 are nonzero, this is equivalent to
vassert(True). Fixed in r2141.
-----
-- MISTAKE5 /*constant condition*/
>>>MISTAKE5_mkLazyN_ab34cd99c4fb48ec
"memcheck/mc_translate.c", line 1588: The expression `mergeTy64' is true
whenever evaluated
COMMENT: The checker assumes (by default) that a variable of enumerated type
can only assume the value of any of the enumerators defined for its
type.
The enumerators for IRType all have values > 0; Hence the complaint.
I believe the fix here is to declare mergeTy64 as Bool.
Trivial to fix (as you say); what is difficult is to figure out / verify
if the fix affects the performance or accuracy of Memcheck on floating
point code, since afaics the fix will change the instrumentation code
Memcheck generates.
-----
-- ERROR9 /*passing null object*/
>>>ERROR9_handle_maybe_load_notifier_e2c77f1b1505
"coregrind/m_redir.c", line 1190: passing NULL to argument 1 of
`vgPlain_strncmp'
ONE POSSIBLE PATH LEADING TO THE ERROR:
"coregrind/m_redir.c", line 1180: conjunct is false (used as evidence that
error is possible)
"coregrind/m_redir.c", line 1180: the if-condition is false
"coregrind/m_redir.c", line 1190: calling `vgPlain_strncmp'
I didn't understand this. Where does it think the NULL comes from?
I don't see it.
-----
-- ERROR2 /*operating on NULL*/
>>>ERROR2_alloc_client_block_6975911e2b60e
"memcheck/mc_main.c", line 4955: invalid operation involving NULL pointer
ONE POSSIBLE PATH LEADING TO THE ERROR:
"memcheck/mc_main.c", line 4937: assuming `i == cgb_used - 1'
"memcheck/mc_main.c", line 4937: loop entry condition is true
"memcheck/mc_main.c", line 4939: the if-condition is false
"memcheck/mc_main.c", line 4937: going around the loop again
"memcheck/mc_main.c", line 4937: loop entry condition is false, therefore
exiting from the loop started on line 4937
"memcheck/mc_main.c", line 4944: assuming `cgb_used == cgb_size'
"memcheck/mc_main.c", line 4944: the if-condition is false
"memcheck/mc_main.c", line 4951: the ?-condition is true (used as evidence
that error is possible)
"memcheck/mc_main.c", line 4954: loop entry condition is true
"memcheck/mc_main.c", line 4955: using operation `[]' to dereference NULL
pointer `cgbs'
VALUES AT THE END OF THE PATH:
cgbs = 0
i = 0
This seems bogus to me, because
"memcheck/mc_main.c", line 4939: the if-condition is false
means that this ?-condition can't be true
"memcheck/mc_main.c", line 4951: the ?-condition is true (used as evidence
that error is possible)
If cgbs == NULL at line 4951 then we would have segfaulted at 4939.
-----
-- ERROR9 /*passing null object*/
>>>ERROR9_setup_client_stack_39174a691505
"coregrind/m_initimg/initimg-linux.c", line 460: passing NULL to argument 1 of
`vgPlain_strlen'
ONE POSSIBLE PATH LEADING TO THE ERROR:
"coregrind/m_initimg/initimg-linux.c", line 434: the if-condition is false
(used as evidence that error is possible)
The extensive path it mentions doesn't seem helpful. It is clear however
that the argument to VG_(strlen) -- that is, VG_(args_the_exename)
is passed without a NULL check, whereas above in the same function, it is
NULL checked before use.
-----
-- ERROR5 /*dereferencing NULL*/
>>>ERROR5_vgPlain_env_unsetenv_dfc79f795979a8
"coregrind/m_libcproc.c", line 104: dereferencing NULL pointer `to'
Yeah, I guess this could fault if the supplied 'env' is NULL.
We should assert against it.
-----
-- ERROR5 /*dereferencing NULL*/
>>>ERROR5_vgPlain_env_clone_5c0c0e06777f13d
"coregrind/m_libcproc.c", line 319: dereferencing NULL pointer `oldenvp'
Probably could fault if the supplied 'oldenv' is NULL.
|
|
From: <sv...@va...> - 2011-05-03 07:51:58
|
Author: sewardj
Date: 2011-05-03 08:51:49 +0100 (Tue, 03 May 2011)
New Revision: 2141
Log:
Fix a nonsensical assertion observed by Florian Krohm.
Modified:
trunk/priv/host_amd64_isel.c
Modified: trunk/priv/host_amd64_isel.c
===================================================================
--- trunk/priv/host_amd64_isel.c 2011-05-02 18:57:56 UTC (rev 2140)
+++ trunk/priv/host_amd64_isel.c 2011-05-03 07:51:49 UTC (rev 2141)
@@ -863,7 +863,10 @@
DECLARE_PATTERN(p_LDle16_then_16Uto64);
IRType ty = typeOfIRExpr(env->type_env,e);
- vassert(ty == Ity_I32 || Ity_I16 || Ity_I8);
+ switch (ty) {
+ case Ity_I64: case Ity_I32: case Ity_I16: case Ity_I8: break;
+ default: vassert(0);
+ }
switch (e->tag) {
|