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
(1) |
|
2
|
3
(6) |
4
(5) |
5
|
6
(2) |
7
(1) |
8
|
|
9
|
10
(4) |
11
(2) |
12
(2) |
13
(3) |
14
(1) |
15
|
|
16
(4) |
17
|
18
(3) |
19
(3) |
20
(3) |
21
|
22
|
|
23
(1) |
24
(10) |
25
(13) |
26
(6) |
27
(2) |
28
(3) |
29
(5) |
|
30
(6) |
|
|
|
|
|
|
|
From: Patrick J. L. <lop...@gm...> - 2017-04-25 23:21:25
|
On Tue, Apr 25, 2017 at 12:22 PM, Carl E. Love <ce...@us...> wrote:
>
> I did try recompiling the test case with -fno-builtin-strcmp and running without any
> additional Valgrind flags and still got the issue.
Hm. You are sure the warning is still from the application code and
not the C library?
That is... strange. I thought the whole point of -fno-builtin-XXX was
to force the compiler to invoke the C library, forgetting whatever it
thinks it knows about the function. Is it possible strcmp() is
actually "inline" in your glibc headers?
Another idea: I suspect it would be pretty simple to hack the
partial-loads-ok logic to mark the "extra" bytes as defined rather
than undefined. Search memcheck/mc_main.c for "partial-loads-ok"; the
change should be just a line or two in mc_LOADV_128_or_256_slow().
...
Specifically, you can try commenting out this "for" loop on lines
1354-1355 of mc_main.c:
for (j = szL-1; j >= 0; j--)
res[j] |= pessim[j];
(Note: It has been a long time since I was in this code, so I could be
completely wrong. If so, hopefully Julian will correct me...)
Of course, this does risk masking real errors. But it should be a
quick way to move forward while exploring other options. And this sort
of partially-valid aligned load is probably not terribly common apart
from this sort of optimization.
That said, -fno-builtin-strcmp really should have caused GCC to emit a
call to the C library strcmp(). I suggest investigating why it didn't.
- Pat
|
|
From: Carl E. L. <ce...@us...> - 2017-04-25 19:22:45
|
> On Tue, 2017-04-25 at 11:19 -0700, Patrick J. LoPresti wrote:
>> This sort of code is supposed to be handled by
>> "--partial-loads-ok=yes". (Which should be made the default, in my
>> opinion.)
>>
>> If that does not work, it is a bug in the partial-loads-ok support.
On Tue, 2017-04-25 at 20:32 +0200, Julian Seward wrote:
> > The inlined code has two load double word instructions (ldbrx inst) that
> > are partially uninitialized. Following the two double word loads we do a
> > subf. instruction to subtract the values and set the condition code.
>
> Does it help to run with --expensive-definedness-checks=yes? That
> enables more accurate but more expensive definedness tracking for
> subtracts, among other things.
>
> J
>
Julian, Patrick:
So I tried the --partial-loads first. It didn't change things.
valgrind --partial-loads-ok=yes ./bug80497-gcc7 --track-origins=yes
==32322== Memcheck, a memory error detector
==32322== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==32322== Using Valgrind-3.13.0.SVN and LibVEX; rerun with -h for copyright info
==32322== Command: ./bug80497-gcc7 --track-origins=yes
==32322==
==32322== Conditional jump or move depends on uninitialised value(s)
==32322== at 0x100004C8: main (bug80497.c:9)
==32322==
==32322== Syscall param exit_group(status) contains uninitialised byte(s)
==32322== at 0x41BDEA4: _Exit (_exit.c:31)
==32322== by 0x411520B: __run_exit_handlers (exit.c:98)
==32322== by 0x40F29A3: generic_start_main.isra.0 (libc-start.c:323)
==32322== by 0x40F2BB7: (below main) (libc-start.c:102)
I then tried the expensive-definedness-checking
valgrind --partial-loads-ok=yes ./bug80497-gcc7 --track-origins=yes
==32322== Memcheck, a memory error detector
==32322== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==32322== Using Valgrind-3.13.0.SVN and LibVEX; rerun with -h for copyright info
==32322== Command: ./bug80497-gcc7 --track-origins=yes
==32322==
==32322== Conditional jump or move depends on uninitialised value(s)
==32322== at 0x100004C8: main (bug80497.c:9)
==32322==
==32322== Syscall param exit_group(status) contains uninitialised byte(s)
==32322== at 0x41BDEA4: _Exit (_exit.c:31)
==32322== by 0x411520B: __run_exit_handlers (exit.c:98)
==32322== by 0x40F29A3: generic_start_main.isra.0 (libc-start.c:323)
==32322== by 0x40F2BB7: (below main) (libc-start.c:102)
I did try recompiling the test case with -fno-builtin-strcmp and running without any
additional Valgrind flags and still got the issue. The option does not turn off the
optimization of the strcmp. Even if it did, I am not sure that would be a satisfactory
solution for the user in this case. I will have to check with them for sure.
Other ideas?
Carl Love
|
|
From: Patrick J. L. <lop...@gm...> - 2017-04-25 19:07:56
|
On Tue, Apr 25, 2017 at 11:42 AM, Julian Seward <js...@ac...> wrote: > > I thought it was the default now. Isn't it? It certainly should be. > > But I think that's not the issue. Memcheck isn't complaining about > bad addresses here. It's complaining that the resulting branch is > on undefined data -- and that undefined data exists exactly because > the partial-loads machinery paints the data acquired from the > invalid areas as undefined. So the partial-loads machinery is > working perfectly. IIUC, that is. Yes, my mistake. I should have read more carefully. This looks very hard to fix in general, since Valgrind is correct that the branch depends on invalid data. Setting partial-loads-ok=no would not help; it would just move the complaint to the memory access itself. Maybe try compiling the application with "-fno-builtin-strcmp"? - Pat |
|
From: Julian S. <js...@ac...> - 2017-04-25 18:42:54
|
On 25/04/17 20:19, Patrick J. LoPresti wrote: > This sort of code is supposed to be handled by > "--partial-loads-ok=yes". (Which should be made the default, in my > opinion.) I thought it was the default now. Isn't it? It certainly should be. But I think that's not the issue. Memcheck isn't complaining about bad addresses here. It's complaining that the resulting branch is on undefined data -- and that undefined data exists exactly because the partial-loads machinery paints the data acquired from the invalid areas as undefined. So the partial-loads machinery is working perfectly. IIUC, that is. J |
|
From: Mark W. <ma...@kl...> - 2017-04-25 18:36:27
|
On Tue, 2017-04-25 at 11:19 -0700, Patrick J. LoPresti wrote:
> This sort of code is supposed to be handled by
> "--partial-loads-ok=yes". (Which should be made the default, in my
> opinion.)
It already is, according to NEWS, since:
Release 3.11.0 (22 September 2015)
- The default value for --partial-loads-ok has been changed
from
"no" to "yes", so as to avoid false positive errors
resulting
from some kinds of vectorised loops.
Cheers,
Mark
|
|
From: Julian S. <js...@ac...> - 2017-04-25 18:32:54
|
> The inlined code has two load double word instructions (ldbrx inst) that > are partially uninitialized. Following the two double word loads we do a > subf. instruction to subtract the values and set the condition code. Does it help to run with --expensive-definedness-checks=yes? That enables more accurate but more expensive definedness tracking for subtracts, among other things. J |
|
From: Patrick J. L. <lop...@gm...> - 2017-04-25 18:19:34
|
This sort of code is supposed to be handled by "--partial-loads-ok=yes". (Which should be made the default, in my opinion.) If that does not work, it is a bug in the partial-loads-ok support. - Pat On Tue, Apr 25, 2017 at 10:36 AM, Carl E. Love <ce...@us...> wrote: > Valgrind developers: > > The GCC 7 compiler for power has a new optimization that is tripping up > Valgrind. Basically they are taking the strcmp() function and doing > some inlining of the code. Here is a snipit of the generated code > > return strcmp(str1, str2); > 100004bc: 28 4c 20 7d ldbrx r9,0,r9 > 100004c0: 28 54 40 7d ldbrx r10,0,r10 > 100004c4: 51 48 6a 7c subf. r3,r10,r9 > 100004c8: 1c 00 82 40 bne 100004e4 <main+0x84> > 100004cc: f8 1b 2a 7d cmpb r10,r9,r3 > 100004d0: 00 00 aa 2f cmpdi cr7,r10,0 > 100004d4: 38 00 9e 41 beq cr7,1000050c <main+0xac> > > The inlined code has two load double word instructions (ldbrx inst) that > are partially uninitialized. Following the two double word loads we do a > subf. instruction to subtract the values and set the condition code. > Then we get to the branch instruction (bne) and valgrind flags the > error: > > ==23948== Conditional jump or move depends on uninitialised value(s) > ==23948== at 0x100004C8: main (bug80497.c:9) > ==23948== > ==23948== Syscall param exit_group(status) contains uninitialised > byte(s) > ==23948== at 0x41BDEA4: _Exit (_exit.c:31) > > The code has some cmpb instructions to make sure they don't actually use > the uninitialized bytes but that doesn't really help Valgrind. I was > thinking of trying to create a rule to ignore the error but not sure I > can do this as it is inlined code. It isn't like trying to ignore > errors from a function. I have looked a little at the suppression rules > and from what I know of them it isn't clear how to write one for this > case were inlined code could show up anywhere. > > Wondering if anyone has thoughts on how to asddress fixing the issue or > how to suppress the issue? > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Carl E. L. <ce...@us...> - 2017-04-25 17:36:29
|
Valgrind developers:
The GCC 7 compiler for power has a new optimization that is tripping up
Valgrind. Basically they are taking the strcmp() function and doing
some inlining of the code. Here is a snipit of the generated code
return strcmp(str1, str2);
100004bc: 28 4c 20 7d ldbrx r9,0,r9
100004c0: 28 54 40 7d ldbrx r10,0,r10
100004c4: 51 48 6a 7c subf. r3,r10,r9
100004c8: 1c 00 82 40 bne 100004e4 <main+0x84>
100004cc: f8 1b 2a 7d cmpb r10,r9,r3
100004d0: 00 00 aa 2f cmpdi cr7,r10,0
100004d4: 38 00 9e 41 beq cr7,1000050c <main+0xac>
The inlined code has two load double word instructions (ldbrx inst) that
are partially uninitialized. Following the two double word loads we do a
subf. instruction to subtract the values and set the condition code.
Then we get to the branch instruction (bne) and valgrind flags the
error:
==23948== Conditional jump or move depends on uninitialised value(s)
==23948== at 0x100004C8: main (bug80497.c:9)
==23948==
==23948== Syscall param exit_group(status) contains uninitialised
byte(s)
==23948== at 0x41BDEA4: _Exit (_exit.c:31)
The code has some cmpb instructions to make sure they don't actually use
the uninitialized bytes but that doesn't really help Valgrind. I was
thinking of trying to create a rule to ignore the error but not sure I
can do this as it is inlined code. It isn't like trying to ignore
errors from a function. I have looked a little at the suppression rules
and from what I know of them it isn't clear how to write one for this
case were inlined code could show up anywhere.
Wondering if anyone has thoughts on how to asddress fixing the issue or
how to suppress the issue?
|
|
From: <sv...@va...> - 2017-04-25 17:28:08
|
Author: petarj
Date: Tue Apr 25 18:28:01 2017
New Revision: 3356
Log:
mips: add missing assembler directive to ASM_VOLATILE_UNARY64
Clang is picky and notices we have not explicitly set up fp64 mode.
This fixes issue with Clang build.
Modified:
trunk/priv/guest_mips_helpers.c
Modified: trunk/priv/guest_mips_helpers.c
==============================================================================
--- trunk/priv/guest_mips_helpers.c (original)
+++ trunk/priv/guest_mips_helpers.c Tue Apr 25 18:28:01 2017
@@ -497,6 +497,7 @@
#define ASM_VOLATILE_UNARY64(inst) \
__asm__ volatile(".set push" "\n\t" \
".set hardfloat" "\n\t" \
+ ".set fp=64" "\n\t" \
"cfc1 $t0, $31" "\n\t" \
"ctc1 %2, $31" "\n\t" \
"ldc1 $f24, 0(%1)" "\n\t" \
|
|
From: <sv...@va...> - 2017-04-25 16:37:24
|
Author: petarj
Date: Tue Apr 25 17:37:16 2017
New Revision: 3355
Log:
mips: remove unnecessary code from FCSR_fp32 dirty helper
These cases should never happen. Removing the code.
Modified:
trunk/priv/guest_mips_helpers.c
Modified: trunk/priv/guest_mips_helpers.c
==============================================================================
--- trunk/priv/guest_mips_helpers.c (original)
+++ trunk/priv/guest_mips_helpers.c Tue Apr 25 17:37:16 2017
@@ -625,45 +625,6 @@
case ROUNDWS:
ASM_VOLATILE_UNARY32(round.w.s)
break;
-#if ((__mips == 32) && defined(__mips_isa_rev) && (__mips_isa_rev >= 2)) \
- || (__mips == 64)
- case CEILLS:
- ASM_VOLATILE_UNARY32(ceil.l.s)
- break;
- case CEILLD:
- ASM_VOLATILE_UNARY32_DOUBLE(ceil.l.d)
- break;
- case CVTDL:
- ASM_VOLATILE_UNARY32_DOUBLE(cvt.d.l)
- break;
- case CVTLS:
- ASM_VOLATILE_UNARY32(cvt.l.s)
- break;
- case CVTLD:
- ASM_VOLATILE_UNARY32_DOUBLE(cvt.l.d)
- break;
- case CVTSL:
- ASM_VOLATILE_UNARY32_DOUBLE(cvt.s.l)
- break;
- case FLOORLS:
- ASM_VOLATILE_UNARY32(floor.l.s)
- break;
- case FLOORLD:
- ASM_VOLATILE_UNARY32_DOUBLE(floor.l.d)
- break;
- case ROUNDLS:
- ASM_VOLATILE_UNARY32(round.l.s)
- break;
- case ROUNDLD:
- ASM_VOLATILE_UNARY32_DOUBLE(round.l.d)
- break;
- case TRUNCLS:
- ASM_VOLATILE_UNARY32(trunc.l.s)
- break;
- case TRUNCLD:
- ASM_VOLATILE_UNARY32_DOUBLE(trunc.l.d)
- break;
-#endif
case ADDS:
ASM_VOLATILE_BINARY32(add.s)
break;
|
|
From: <sv...@va...> - 2017-04-25 14:41:06
|
Author: petarj
Date: Tue Apr 25 15:40:54 2017
New Revision: 3354
Log:
mips: limit cvt.s.l instruction translation to fp_mode64
The documentation says:
"For CVT.S.L, the result of this instruction is UNPREDICTABLE if the
processor is executing in the FR=0 32-bit FPU register model; it is
predictable if executing on a 64-bit FPU in the FR=1 mode, but not with
FR=0, and not on a 32-bit FPU."
Hence the fix.
Modified:
trunk/priv/guest_mips_toIR.c
Modified: trunk/priv/guest_mips_toIR.c
==============================================================================
--- trunk/priv/guest_mips_toIR.c (original)
+++ trunk/priv/guest_mips_toIR.c Tue Apr 25 15:40:54 2017
@@ -13090,12 +13090,16 @@
case 0x15: /* L */
DIP("cvt.s.l %u, %u", fd, fs);
- calculateFCSR(fs, 0, CVTSL, False, 1);
- t0 = newTemp(Ity_I64);
- assign(t0, unop(Iop_ReinterpF64asI64, getFReg(fs)));
+ if (fp_mode64) {
+ calculateFCSR(fs, 0, CVTSL, False, 1);
+ t0 = newTemp(Ity_I64);
+ assign(t0, unop(Iop_ReinterpF64asI64, getFReg(fs)));
- putFReg(fd, mkWidenFromF32(tyF, binop(Iop_I64StoF32,
- get_IR_roundingmode(), mkexpr(t0))));
+ putFReg(fd, mkWidenFromF32(tyF, binop(Iop_I64StoF32,
+ get_IR_roundingmode(), mkexpr(t0))));
+ } else {
+ ILLEGAL_INSTRUCTON;
+ }
break;
default:
|
|
From: <sv...@va...> - 2017-04-25 13:52:28
|
Author: petarj
Date: Tue Apr 25 14:52:21 2017
New Revision: 16312
Log:
make helgrind/tc23_bogus_condwait test deterministic
Using properly initialized mutex (instead of a dirty one) in case
"mx is not locked" makes behavior of this test deterministic.
Patch by Tamara Vlahovic.
Modified:
trunk/helgrind/tests/tc23_bogus_condwait.c
Modified: trunk/helgrind/tests/tc23_bogus_condwait.c
==============================================================================
--- trunk/helgrind/tests/tc23_bogus_condwait.c (original)
+++ trunk/helgrind/tests/tc23_bogus_condwait.c Tue Apr 25 14:52:21 2017
@@ -69,7 +69,7 @@
r= pthread_cond_wait(&cv, (pthread_mutex_t*)(4 + (char*)&mx[0]) );
/* mx is not locked */
- r= pthread_cond_wait(&cv, &mx[0]);
+ r= pthread_cond_wait(&cv, &mx[3]);
/* wrong flavour of lock */
r= pthread_cond_wait(&cv, (pthread_mutex_t*)&rwl );
|
Author: iraisr
Date: Tue Apr 25 07:44:28 2017
New Revision: 16311
Log:
Valgrind reports INTERNAL ERROR in rt_sigsuspend syscall wrapper.
Fixes BZ#379094.
Modified:
trunk/NEWS
trunk/coregrind/m_syswrap/syswrap-linux.c
trunk/memcheck/tests/x86-linux/scalar.c
trunk/memcheck/tests/x86-linux/scalar.stderr.exp
Modified: trunk/NEWS
==============================================================================
--- trunk/NEWS (original)
+++ trunk/NEWS Tue Apr 25 07:44:28 2017
@@ -156,6 +156,7 @@
377930 fcntl syscall wrapper is missing flock structure check
378535 Valgrind reports INTERNAL ERROR in execve syscall wrapper
378673 Update libiberty demangler
+379094 Valgrind reports INTERNAL ERROR in rt_sigsuspend syscall wrapper
Release 3.12.0 (20 October 2016)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Modified: trunk/coregrind/m_syswrap/syswrap-linux.c
==============================================================================
--- trunk/coregrind/m_syswrap/syswrap-linux.c (original)
+++ trunk/coregrind/m_syswrap/syswrap-linux.c Tue Apr 25 07:44:28 2017
@@ -3995,12 +3995,16 @@
PRE_REG_READ2(int, "rt_sigsuspend", vki_sigset_t *, mask, vki_size_t, size)
if (ARG1 != (Addr)NULL) {
PRE_MEM_READ( "rt_sigsuspend(mask)", ARG1, sizeof(vki_sigset_t) );
- VG_(sigdelset)((vki_sigset_t*)ARG1, VG_SIGVGKILL);
- /* We cannot mask VG_SIGVGKILL, as otherwise this thread would not
- be killable by VG_(nuke_all_threads_except).
- We thus silently ignore the user request to mask this signal.
- Note that this is similar to what is done for e.g.
- sigprocmask (see m_signals.c calculate_SKSS_from_SCSS). */
+ if (ML_(safe_to_deref)((vki_sigset_t *) ARG1, sizeof(vki_sigset_t))) {
+ VG_(sigdelset)((vki_sigset_t *) ARG1, VG_SIGVGKILL);
+ /* We cannot mask VG_SIGVGKILL, as otherwise this thread would not
+ be killable by VG_(nuke_all_threads_except).
+ We thus silently ignore the user request to mask this signal.
+ Note that this is similar to what is done for e.g.
+ sigprocmask (see m_signals.c calculate_SKSS_from_SCSS). */
+ } else {
+ SET_STATUS_Failure(VKI_EFAULT);
+ }
}
}
Modified: trunk/memcheck/tests/x86-linux/scalar.c
==============================================================================
--- trunk/memcheck/tests/x86-linux/scalar.c (original)
+++ trunk/memcheck/tests/x86-linux/scalar.c Tue Apr 25 07:44:28 2017
@@ -800,8 +800,8 @@
SY(__NR_rt_sigqueueinfo, x0, x0+1, x0); FAIL;
// __NR_rt_sigsuspend 179
- GO(__NR_rt_sigsuspend, "ignore");
- // (I don't know how to test this...)
+ GO(__NR_rt_sigsuspend, "2s 1m");
+ SY(__NR_rt_sigsuspend, x0 + 1, x0 + sizeof(sigset_t)); FAILx(EFAULT);
// __NR_pread64 180
GO(__NR_pread64, "5s 1m");
Modified: trunk/memcheck/tests/x86-linux/scalar.stderr.exp
==============================================================================
--- trunk/memcheck/tests/x86-linux/scalar.stderr.exp (original)
+++ trunk/memcheck/tests/x86-linux/scalar.stderr.exp Tue Apr 25 07:44:28 2017
@@ -2343,8 +2343,21 @@
Address 0x........ is not stack'd, malloc'd or (recently) free'd
-----------------------------------------------------
-179: __NR_rt_sigsuspend ignore
+179: __NR_rt_sigsuspend 2s 1m
-----------------------------------------------------
+Syscall param rt_sigsuspend(mask) contains uninitialised byte(s)
+ ...
+ by 0x........: main (scalar.c:804)
+
+Syscall param rt_sigsuspend(size) contains uninitialised byte(s)
+ ...
+ by 0x........: main (scalar.c:804)
+
+Syscall param rt_sigsuspend(mask) points to unaddressable byte(s)
+ ...
+ by 0x........: main (scalar.c:804)
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
+
-----------------------------------------------------
180: __NR_pread64 5s 1m
-----------------------------------------------------
|