I can't reproduce the problem, so could you try doing a non-valgrind debug
build and seeing what pops out in the debugger (e.g. libtool --mode=execute
gdb ./arestest)? The stack makes it look like a null pointer is being
passed down, only it's for a C++ reference rather than a pointer so that
seems odd...
Thanks,
David
On Fri, Sep 23, 2016 at 9:38 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Fri, 23 Sep 2016, David Drysdale wrote:
>
> Is that just with valgrind, or are there problems with a normal run too?
>>
>
> Ah sorry for being unclear: no it crashes in normal runs as well which is
> why I decided to try valgrind on it to see what it says.
>
> When I run 'make test' the end of my test-suite.log contains:
>
> [ RUN ] Modes/DefaultChannelModeTest.LiveGetHostByAddrFailAlloc/2
> [ OK ] Modes/DefaultChannelModeTest.LiveGetHostByAddrFailAlloc/2 (0
> ms)
> [ RUN ] Modes/DefaultChannelModeTest.LiveGetHostByAddrFailAlloc/3
> [ OK ] Modes/DefaultChannelModeTest.LiveGetHostByAddrFailAlloc/3 (1
> ms)
> [----------] 40 tests from Modes/DefaultChannelModeTest (81 ms total)
>
> [----------] 112 tests from AddressFamilies/MockChannelTest
> [ RUN ] AddressFamilies/MockChannelTest.Basic/0
> FAIL arestest (exit status: 139)
>
> (The continuous builds were fine at commit a5b2e99207fd12 (
>> https://travis-ci.org/c-ares/c-ares/builds/153926206), but they use ASAN
>> for memory checking rather than valgrind.)
>>
>
> Yeah, that makes this even more curious as I don't think I run anything
> very special. I'm on 64bit Debian Linux unstable. kernel 4.5.0, glibc 2.24,
> gcc/g++ 6.20, valgrind-3.12.0.SVN
>
> And the gmock code is bundled in the source tree so it should be the same!
>
> --
>
> / daniel.haxx.se
>
Received on 2016-09-23