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) |
2
(4) |
3
(1) |
4
(7) |
5
|
|
6
|
7
(4) |
8
|
9
(3) |
10
(6) |
11
(13) |
12
(6) |
|
13
(1) |
14
|
15
(1) |
16
|
17
(4) |
18
(3) |
19
(5) |
|
20
(5) |
21
(5) |
22
(5) |
23
(6) |
24
|
25
(1) |
26
(1) |
|
27
(1) |
28
(4) |
29
(5) |
30
|
|
|
|
|
From: Andrew C. M. <and...@gm...> - 2016-11-10 18:27:33
|
OK, up and running with 3.12. Thanks again. Andrew On Thu, Nov 10, 2016 at 11:03 AM, Andrew C. Morrow < and...@gm...> wrote: > >> >> > However, we have now encountered the following error: >> > [..] >> > Are the socket syscalls somehow not implemented in valgrind for ppc64le? >> >> That's such basic functionality that it merely confirms my suspicion >> that you're not running the latest (3.12.0). >> >> J >> >> > Indeed we are not. Looks like Ubuntu 16.04 bundles 3.11.0: > > $ valgrind --version > valgrind-3.11.0 > > I'll get 3.12 built from source and give it a try. > > Thanks for your help, > Andrew > > > |
|
From: Petar J. <mip...@gm...> - 2016-11-10 17:17:17
|
On Sat, Sep 24, 2016 at 2:04 PM, Philippe Waroquiers <phi...@sk...> wrote: > Mark/Ivo, > > I am (now?) seeing random failures of helgrind|drd/tests/bar_bad* > (also now seeing failures in nightly builds). > > I have encountered such failures on amd64/debian 8, and on ppc64/gcc110. > Hi Philippe, Can you check if the following patch helps with those failures? https://bugsfiles.kde.org/attachment.cgi?id=102144 Regards, Petar |
|
From: Andrew C. M. <and...@gm...> - 2016-11-10 16:03:38
|
> > > > > However, we have now encountered the following error: > > [..] > > Are the socket syscalls somehow not implemented in valgrind for ppc64le? > > That's such basic functionality that it merely confirms my suspicion > that you're not running the latest (3.12.0). > > J > > Indeed we are not. Looks like Ubuntu 16.04 bundles 3.11.0: $ valgrind --version valgrind-3.11.0 I'll get 3.12 built from source and give it a try. Thanks for your help, Andrew |
|
From: Julian S. <js...@ac...> - 2016-11-10 15:01:56
|
On 10/11/16 15:34, Andrew C. Morrow wrote:
Your message was timely; I was just about to reply to and it showed up
seconds before.
> [mismatched alloc/free messages]
> is --show-mismatched-frees=no, which will work fine for us as a workaround
> now, but would be not generally a good idea since it could mask real user
> errors. In any event, we have a workaround for this.
I've seen this a lot running Firefox on Valgrind. My impression is that it
is due to what you could call "differential inlining". Imagine that we have
this:
operator new (size_t size) { ... return malloc(size) ... }
operator delete ( void* p) { ... free(p) ... }
If both |new| and |delete| are inlined, then Memcheck only ever sees calls
to |malloc| and |free|, and there's no problem (and no mismatch checking).
If neither are inlined, then there's no problem and everything works as
originally designed. The problem occurs when one but not the other
is inlined. Then Memcheck observes, for example, allocations from
|new| (which is not inlined) being returned to |free| (because |delete|
got inlined).
I don't have a good fix for this, so I always just run with
--show-mismatched-frees=no.
> For the other issue about the __lll_lock_elision error, that was
> encountered running valgrind on a ppc64le POWER8 machine running Ubuntu
> 16.04. The compiler was the system GCC, version 5.4.0. I've just tried
> again today without the --track-origins=yes flag, and I can confirm that
> I'm able to get the process running under valgrind if I omit the
> --track-origins=yes flag. This is unfortunate too, because if valgrind does
> report an error, I've found that almost always you need --track-origins=yes
> to really sort it out.
Fixing this is a 1-liner if we can figure out what is at the given offset
of the ppc64le guest state. Which we could do if we can see the instruction
it's failing at. Ah, so it's failing at the basic block that starts here:
==19834== at 0x4F3AC14: __lll_lock_elision (elision-lock.c:60)
Can you objdump -d libpthread (I think it's that) and show the block
that follows? We're probably looking for an instruction that pokes
some very obscure system status register or something like that; we're
not looking for vanilla integer arithmetic or anything ordinary.
But first -- before you do *any* of that -- can you try with V 3.12.0
(or make sure you're using it)? I say that because Carl fixed a exactly
that stuff earlier this year.
r15895 | carll | 2016-06-27 17:50:29 +0200 (Mon, 27 Jun 2016) | 3 lines
Add the HW register support for missing registers in
get_otrack_shadow_offset_wrk(). The registers are: NRADDR, NRADDR_GPR2,
(REDIR_STACK, TFHAR, TEXASR, TEXASRU, TFIAR, PPR, PSPB.
> However, we have now encountered the following error:
> [..]
> Are the socket syscalls somehow not implemented in valgrind for ppc64le?
That's such basic functionality that it merely confirms my suspicion
that you're not running the latest (3.12.0).
J
|
|
From: Andrew C. M. <and...@gm...> - 2016-11-10 14:35:04
|
On Thu, Nov 10, 2016 at 2:03 AM, Paul Floyd <pa...@fr...> wrote:
>
> On 9 Nov 2016, at 23:25, Carl E. Love wrote:
>
> > Julian, Valgrind developers:
> >
> > We have some people on the compiler team trying to help out on a
> > customer issue. The customer tried to use valgrind memcheck and got
> > several errors that we would like help understanding. In the first
> > experiment, they get messages about mismatched free() / delete /
> > delete[]. They had valgrind ignore those issues and then see erorrs on
> > "get_otrack_shadow_offset_wrk".
> >
> > Here is the valgrind output from the experiments from the bugzilla
> > report:
> >
> > valgrind --soname-synonyms=somalloc=NONE --track-origins=yes
> --leak-check=no ./mongos
> > ==17387== Memcheck, a memory error detector
> > ==17387== Copyright (C) 2002-2015, and GNU GPL'd, by Julian
> Seward et al.
> > ==17387== Using Valgrind-3.11.0 and LibVEX; rerun with -h for
> copyright info
> > ==17387== Command: ./mongos
> > ==17387==
> > ==17387== Mismatched free() / delete / delete []
>
> Hi Carl
>
> I'd like to add a little to what Philippe wrote for this case. There are
> two kind-of 'false positive' situations that I've encountered. Firstly, as
> already mentioned, if operator new/operator delete is inlined. In
> particular I see this in class overloads of the operators, which tend to be
> inlined more often e.g.,
>
> class MyClass
> {
> public:
> void* operator new(std::size_t count); // out of line
> void operator delete(void* ptr) { myFree(ptr); } // inline
> };
>
> The second situation that I've encountered is if you use an overload that
> uses a non-standard signature, Valgrind won't see it as a new or delete but
> will probably still see the underlying call to malloc/free and so will flag
> a mismatched free/delete.
>
> Looking at your callstack you seem to be using a
>
> std::unordered_map<std::string, std::pair<std::string, mongo::
> InitializerDependencyGraph::NodeData>
>
> and the error occurs during rehashing. So I doubt that it is a
> non-standard overload.
>
> Which compiler and standard library are you using?
>
> A+
> Paul
>
>
>
Hi -
As it happens, I'm both a lurker on this list from some long ago dev work
on valgrind, and I'm the customer referenced in the original email, so I
can answer questions directly.
We run our code under ASAN, which does detect mismatched free/delete, and
we are fairly certain that we don't have any instances of that problem. So
this is almost certainly due to the inlining issue as described above, and
all of the stacks do look like they reach into the std library headers.
That is sort of unfortunate, because it appears to mean that if you are
using a modern libstdc++ and an aggressive optimization level, you are
going to get a ton of false positives that would need to be suppressed
since they aren't under the control of the developer. Writing suppressions
for std library headers is going to be tricky and fragile. The alternative
is --show-mismatched-frees=no, which will work fine for us as a workaround
now, but would be not generally a good idea since it could mask real user
errors. In any event, we have a workaround for this.
For the other issue about the __lll_lock_elision error, that was
encountered running valgrind on a ppc64le POWER8 machine running Ubuntu
16.04. The compiler was the system GCC, version 5.4.0. I've just tried
again today without the --track-origins=yes flag, and I can confirm that
I'm able to get the process running under valgrind if I omit the
--track-origins=yes flag. This is unfortunate too, because if valgrind does
report an error, I've found that almost always you need --track-origins=yes
to really sort it out.
However, we have now encountered the following error:
[js_test:fsm_all_sharded_replication] 2016-11-10T14:24:04.496+0000 s40019|
--17827-- WARNING: unhandled ppc64le-linux syscall: 326
[js_test:fsm_all_sharded_replication] 2016-11-10T14:24:04.496+0000 s40019|
--17827-- You may be able to write your own handler.
[js_test:fsm_all_sharded_replication] 2016-11-10T14:24:04.496+0000 s40019|
--17827-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
[js_test:fsm_all_sharded_replication] 2016-11-10T14:24:04.497+0000 s40019|
--17827-- Nevertheless we consider this a bug. Please report
[js_test:fsm_all_sharded_replication] 2016-11-10T14:24:04.497+0000 s40019|
--17827-- it at http://valgrind.org/support/bug_reports.html.
[js_test:fsm_all_sharded_replication] 2016-11-10T14:24:04.509+0000 s40019|
2016-11-10T14:24:04.509+0000 I - [mongosMain] Assertion:
15863:listen(): invalid socket? Function not implemented src/mon
go/util/net/listen.cpp 184
Looking at listen.cpp:
182 SOCKET sock = ::socket(me.getType(), SOCK_STREAM, 0);
183 ScopeGuard socketGuard = MakeGuard(&closesocket, sock);
184 massert(15863,
185 str::stream() << "listen(): invalid socket? " <<
errnoWithDescription(),
186 sock >= 0);
The process ends up terminating after this because it can't open its
listening socket.
Are the socket syscalls somehow not implemented in valgrind for ppc64le?
Thanks,
Andrew
|
|
From: Paul F. <pa...@fr...> - 2016-11-10 07:03:38
|
On 9 Nov 2016, at 23:25, Carl E. Love wrote:
> Julian, Valgrind developers:
>
> We have some people on the compiler team trying to help out on a
> customer issue. The customer tried to use valgrind memcheck and got
> several errors that we would like help understanding. In the first
> experiment, they get messages about mismatched free() / delete /
> delete[]. They had valgrind ignore those issues and then see erorrs on
> "get_otrack_shadow_offset_wrk".
>
> Here is the valgrind output from the experiments from the bugzilla
> report:
>
> valgrind --soname-synonyms=somalloc=NONE --track-origins=yes --leak-check=no ./mongos
> ==17387== Memcheck, a memory error detector
> ==17387== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==17387== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
> ==17387== Command: ./mongos
> ==17387==
> ==17387== Mismatched free() / delete / delete []
Hi Carl
I'd like to add a little to what Philippe wrote for this case. There are two kind-of 'false positive' situations that I've encountered. Firstly, as already mentioned, if operator new/operator delete is inlined. In particular I see this in class overloads of the operators, which tend to be inlined more often e.g.,
class MyClass
{
public:
void* operator new(std::size_t count); // out of line
void operator delete(void* ptr) { myFree(ptr); } // inline
};
The second situation that I've encountered is if you use an overload that uses a non-standard signature, Valgrind won't see it as a new or delete but will probably still see the underlying call to malloc/free and so will flag a mismatched free/delete.
Looking at your callstack you seem to be using a
std::unordered_map<std::string, std::pair<std::string, mongo::InitializerDependencyGraph::NodeData>
and the error occurs during rehashing. So I doubt that it is a non-standard overload.
Which compiler and standard library are you using?
A+
Paul
|