Re: [Valgrind-developers] Need help with Memcheck issues

[Andrew C. M. <and...@gm...>]

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