Googletest: ASSERT_EQ segfault with two boost::filesystem::path

Created on 26 May 2018  路  11Comments  路  Source: google/googletest

ASSERT_EQ segfaults while trying to print in case of not equal if you use two instances for boost::filesystem::path. Minimal example:

TEST(a, b) {
    ASSERT_EQ(boost::filesystem::path("a"), boost::filesystem::path("b"));
}

when ran under gdb gives you:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff68f50e4 in std::__ostream_insert<char, std::char_traits<char> > (__out=..., __s=__s@entry=0x7fffff7ff06c "{", __n=__n@entry=1)
    at /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/ostream_insert.h:76
76  /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/ostream_insert.h: No such file or directory.

Stacktrace is 116468 levels deep, so attached as attachement (25MB):
gdb.txt

Most helpful comment

This issue is not a duplicate because the original issue was fixed (I don't understand why you didn't close #521 ?). Later in this commit the issue was brought up again but with different cause. In the aforementioned commit the following code has been added:
```template
struct VoidT {
typedef void value_type;
};

template
struct HasValueType : false_type {};
template
struct HasValueType > : true_type {
};

Which is totally wrong. I do not know why it was added in the first place, but to at least making it working it should be changed to something like this:

template
struct Void {
typedef void type;
};

template
using VoidT = typename Void::type;

template
struct HasValueType: false_type {};
template
struct HasValueType>: true_type {
};
```

Otherwise the IsRecursiveContainer trait will always return false which breaks std::filesystem::path usage in GTest (the same goes to boost::fs).

All 11 comments

Duplicate of #521.

I would think so, but the fix was merged into master and yet this still happend to me. So maybe the fix is not complete?

Anyway #521 is still open, why? Wasn't https://github.com/google/googletest/pull/1186 supposed to fix it?

This issue is not a duplicate because the original issue was fixed (I don't understand why you didn't close #521 ?). Later in this commit the issue was brought up again but with different cause. In the aforementioned commit the following code has been added:
```template
struct VoidT {
typedef void value_type;
};

template
struct HasValueType : false_type {};
template
struct HasValueType > : true_type {
};

Which is totally wrong. I do not know why it was added in the first place, but to at least making it working it should be changed to something like this:

template
struct Void {
typedef void type;
};

template
using VoidT = typename Void::type;

template
struct HasValueType: false_type {};
template
struct HasValueType>: true_type {
};
```

Otherwise the IsRecursiveContainer trait will always return false which breaks std::filesystem::path usage in GTest (the same goes to boost::fs).

+1. Happens to me as well with std::filesystem::path

Occurs for me with both std::filesystem::path and boost::filesystem::path. gtest 1.8.0 on Ubuntu 18.10 with GCC 8.2.0.

Otherwise the IsRecursiveContainer trait will always return false which breaks std::filesystem::path usage in GTest (the same goes to boost::fs).

Work with boost::filesystem::path (1.68.0) on GCC 6.3 and MSVC 14.16.27023

I've retested with current master (fe14e30307) and GCC 8.2 on Linux with -std=gnu++17. It's still segfaulting here.

@rleigh-codelibre , @GTValentine , @dvetutnev , @ixSci , @graywolf , @pepsiman
Thank you very much for this discussion. The best way to approach this would be to create a proper PR and submit it for consideration. In addition proper unit test would ensure that this wont happen again. There should be enough expertise in this discussion for this to happen.
Thanks again

Should be good now

Are there any plans to do a proper release with these fixes?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

cyberdecker picture cyberdecker  路  3Comments

agirault picture agirault  路  5Comments

pepe82sh picture pepe82sh  路  5Comments

Joebeazelman picture Joebeazelman  路  5Comments

kdawgwilk picture kdawgwilk  路  3Comments