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
(2) |
3
(2) |
4
|
5
|
6
|
7
|
|
8
|
9
(5) |
10
(3) |
11
|
12
(3) |
13
(1) |
14
|
|
15
|
16
(3) |
17
|
18
(1) |
19
(1) |
20
|
21
|
|
22
|
23
|
24
|
25
|
26
|
27
(2) |
28
(1) |
|
29
|
30
|
|
|
|
|
|
|
From: Mike C. <ma...@mc...> - 2019-09-12 11:00:58
|
On Thursday 12 September 2019 at 11:40:22 +0200, Mark Wielaard wrote:
> On Thu, Sep 12, 2019 at 11:21:05AM +0200, Mark Wielaard wrote:
> > > > - How did you observe it? Do you have a replicator?
> > > > Interested in the call chain, to make sure that this is
> > > > enough, or whether we might need a "hard-wire" instead
> > > > ld.so intercepts might be called "too early" in some
> > > > cases, before we had a chance to setup the full intercept
> > > > mechanism. (When is is_dst () called?)
> > >
> > > It happened when iconv tried to dlopen a code page file. Here's my test
> > > case:
> > >
> > > --8<--
> > > #include <iconv.h>
> > > #include <stdio.h>
> > >
> > > int main()
> > > {
> > > iconv_t descriptor = iconv_open("UCS-4BE", "euc-kr");
> > > if (descriptor == (iconv_t)(-1)) {
> > > fprintf(stderr, "Failed to get iconv\n");
> > > return 1;
> > > }
> > >
> > > fprintf(stderr, "Got iconv\n");
> > >
> > > return 0;
> > > }
> > > -->8--
[snip]
> > Would you be able to provide more information on your setup?
I initially ran into the problem with OpenEmbedded running our unit tests
"cross-compiled" to x86_64 in a separate rootfs. I then switched to a
Fedora 29 Docker image with a self-built glibc 2.30 hacked into it. I'd
forgotten that whilst I could easily reproduce the problem with Fedora's
valgrind, I could not when using my own valgrind built from source. After a
bit of digging I discovered that default.supp for the Fedora valgrind was
different to the one being used when I built from source. Sorry that I
forgot to mention that.
[snip]
> When running with valgrind --default-suppressions=no I do get:
>
> ==27438== Invalid read of size 8
> ==27438== at 0x401DA70: strncmp (in /usr/lib64/ld-2.29.so)
> ==27438== by 0x4005D9D: is_dst (in /usr/lib64/ld-2.29.so)
> ==27438== by 0x40086C6: _dl_dst_count (in /usr/lib64/ld-2.29.so)
> ==27438== by 0x40088B7: expand_dynamic_string_token (in /usr/lib64/ld-2.29.so)
> ==27438== by 0x4008A21: fillin_rpath (in /usr/lib64/ld-2.29.so)
> ==27438== by 0x4008D33: decompose_rpath.isra.0 (in /usr/lib64/ld-2.29.so)
> ==27438== by 0x4009718: _dl_map_object (in /usr/lib64/ld-2.29.so)
> ==27438== by 0x400DC54: openaux (in /usr/lib64/ld-2.29.so)
> ==27438== by 0x49941F8: _dl_catch_exception (in /usr/lib64/libc-2.29.so)
> ==27438== by 0x400E09A: _dl_map_object_deps (in /usr/lib64/ld-2.29.so)
> ==27438== by 0x4013BF3: dl_open_worker (in /usr/lib64/ld-2.29.so)
> ==27438== by 0x49941F8: _dl_catch_exception (in /usr/lib64/libc-2.29.so)
>
> I think your intercept is still a good idea. But it would be good to
> see why you don't get the default suppression for this. And maybe
> these default suppressions are really too broad and maybe should be
> removed?
I didn't investigate why the Fedora default.supp files end up being
different to the one used when I built from source, but it is certainly
confusing.
Thanks.
Mike.
|
|
From: Mark W. <ma...@kl...> - 2019-09-12 09:40:40
|
On Thu, Sep 12, 2019 at 11:21:05AM +0200, Mark Wielaard wrote:
> > > - How did you observe it? Do you have a replicator?
> > > Interested in the call chain, to make sure that this is
> > > enough, or whether we might need a "hard-wire" instead
> > > ld.so intercepts might be called "too early" in some
> > > cases, before we had a chance to setup the full intercept
> > > mechanism. (When is is_dst () called?)
> >
> > It happened when iconv tried to dlopen a code page file. Here's my test
> > case:
> >
> > --8<--
> > #include <iconv.h>
> > #include <stdio.h>
> >
> > int main()
> > {
> > iconv_t descriptor = iconv_open("UCS-4BE", "euc-kr");
> > if (descriptor == (iconv_t)(-1)) {
> > fprintf(stderr, "Failed to get iconv\n");
> > return 1;
> > }
> >
> > fprintf(stderr, "Got iconv\n");
> >
> > return 0;
> > }
> > -->8--
>
> Would you be able to provide more information on your setup? I tried
> with a Fedora x86_64 glibc 2.29 and Debian x86_64 glibc 2.28 (both
> with avx and avx2), but couldn't trigger it. What does the
> valgrind/memcheck error look like?
O, I see what is going on.
In both cases, on my setup, the error is there, but suppressed.
There are various default suppresses in glibc-2.X.supp.in that cover
this. In particular:
{
dl-hack4-64bit-addr-1
Memcheck:Addr8
obj:*/lib*/ld-@GLIBC_VERSION@*.so*
obj:*/lib*/ld-@GLIBC_VERSION@*.so*
obj:*/lib*/ld-@GLIBC_VERSION@*.so*
}
When running with valgrind --default-suppressions=no I do get:
==27438== Invalid read of size 8
==27438== at 0x401DA70: strncmp (in /usr/lib64/ld-2.29.so)
==27438== by 0x4005D9D: is_dst (in /usr/lib64/ld-2.29.so)
==27438== by 0x40086C6: _dl_dst_count (in /usr/lib64/ld-2.29.so)
==27438== by 0x40088B7: expand_dynamic_string_token (in /usr/lib64/ld-2.29.so)
==27438== by 0x4008A21: fillin_rpath (in /usr/lib64/ld-2.29.so)
==27438== by 0x4008D33: decompose_rpath.isra.0 (in /usr/lib64/ld-2.29.so)
==27438== by 0x4009718: _dl_map_object (in /usr/lib64/ld-2.29.so)
==27438== by 0x400DC54: openaux (in /usr/lib64/ld-2.29.so)
==27438== by 0x49941F8: _dl_catch_exception (in /usr/lib64/libc-2.29.so)
==27438== by 0x400E09A: _dl_map_object_deps (in /usr/lib64/ld-2.29.so)
==27438== by 0x4013BF3: dl_open_worker (in /usr/lib64/ld-2.29.so)
==27438== by 0x49941F8: _dl_catch_exception (in /usr/lib64/libc-2.29.so)
I think your intercept is still a good idea. But it would be good to
see why you don't get the default suppression for this. And maybe
these default suppressions are really too broad and maybe should be
removed?
Cheers,
Mark
|
|
From: Mark W. <ma...@kl...> - 2019-09-12 09:21:24
|
Hi Mike,
On Tue, Sep 10, 2019 at 06:02:40PM +0100, Mike Crowe wrote:
> On Tuesday 10 September 2019 at 13:26:20 +0200, Mark Wielaard wrote:
> > On Mon, 2019-09-09 at 14:16 +0100, Mike Crowe wrote:
> > > In glibc 5aad5f617892e75d91d4c8fb7594ff35b610c042 (first released in
> > > v2.28) a call to strncmp was added to dl-load.c:is_dst. This causes
> > > valgrind to complain about glibc's highly-optimised strncmp performing
> > > sixteen-byte reads on short strings in ld.so. Let's intercept strncmp in
> > > ld.so too so we use valgrind's simple version to avoid this problem.
> > > ---
> > > shared/vg_replace_strmem.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/shared/vg_replace_strmem.c b/shared/vg_replace_strmem.c
> > > index 87a4bcc55..5c05644fe 100644
> > > --- a/shared/vg_replace_strmem.c
> > > +++ b/shared/vg_replace_strmem.c
> > > @@ -648,6 +648,8 @@ static inline void my_exit ( int x )
> > > STRNCMP(VG_Z_LIBC_SONAME, __GI_strncmp)
> > > STRNCMP(VG_Z_LIBC_SONAME, __strncmp_sse2)
> > > STRNCMP(VG_Z_LIBC_SONAME, __strncmp_sse42)
> > > + STRNCMP(VG_Z_LD_LINUX_SO_2, strncmp)
> > > + STRNCMP(VG_Z_LD_LINUX_X86_64_SO_2, strncmp)
> > >
> > > #elif defined(VGO_darwin)
> > > STRNCMP(VG_Z_LIBC_SONAME, strncmp)
> >
> > I think this correct, but two questions:
> >
> > - You add it for ld-linux.so.2 (the x86 dynamic linker)
> > and ld-linux-x86-64.so.2 (the amd64 dynamic linker).
> > Did you observe it on both arches? Even if you didn't
> > it might be a good idea anyway, just in case.
>
> I tested on x86-64 (with AVX) and core-i7 (with SSE4.2 I think) and could
> reproduce the problem on both. The glibc code is used on all architectures,
> but not all of them have an optimised strncmp that confuses valgrind. In
> particular, mere i686 does not.
>
> It looks like glibc also has optimised strncmp implementations for AArch64
> and powerpc32/64 at least. I've not tested these (although I could probably
> test AArch64 later this week.) So, it looks like I should probably add a
> line for VG_Z_LD_LINUX_AARCH64_SO_1.
>
> Lines for VG_Z_LD_LINUX_SO_3, VG_Z_LD64_SO_1 and VG_Z_LD_SO_1 may also be
> necessary.
>
> I can submit a new patch to add all of these if you agree.
Probably, yes, but even with your reproducer I have been unable to
replicate on any of my setups.
> > - How did you observe it? Do you have a replicator?
> > Interested in the call chain, to make sure that this is
> > enough, or whether we might need a "hard-wire" instead
> > ld.so intercepts might be called "too early" in some
> > cases, before we had a chance to setup the full intercept
> > mechanism. (When is is_dst () called?)
>
> It happened when iconv tried to dlopen a code page file. Here's my test
> case:
>
> --8<--
> #include <iconv.h>
> #include <stdio.h>
>
> int main()
> {
> iconv_t descriptor = iconv_open("UCS-4BE", "euc-kr");
> if (descriptor == (iconv_t)(-1)) {
> fprintf(stderr, "Failed to get iconv\n");
> return 1;
> }
>
> fprintf(stderr, "Got iconv\n");
>
> return 0;
> }
> -->8--
Would you be able to provide more information on your setup? I tried
with a Fedora x86_64 glibc 2.29 and Debian x86_64 glibc 2.28 (both
with avx and avx2), but couldn't trigger it. What does the
valgrind/memcheck error look like?
Thanks,
Mark
|