Fatal crash executing run-tests.

[c0yote]

Get this when running the tests.

[----------] 3 tests from HandlerTest
[ RUN      ] HandlerTest.NoEndOfMapFlow

[ FATAL ] C:/[...]/yaml-cpp/test/GMOCK-~1.0/gtest/include/gtest/internal/gtest-port.h:1358:: Condition has_owner_ && pthread_equal(owner_, pthread_self()) failed. The current thread is not holding the mutex @0x6fc0c0

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Windows 7 x64 using MinGW-W64; compiler info:

version : MinGW-W64-builds-4.2.0
user    : nixman
date    : 12.21.2014-10:30:49 PM
args    : --mode=gcc-4.9.2 --buildroot=/c/mingw492 --rt-version=v3 --rev=1 --bootstrap --jobs=2 --threads=posix --exceptions=seh --arch=x86_64 --bin-compress --mingw-upload --sf-user=nixmann --sf-pass=odnajdilebedrakomshiuku

[jbeder]

Can you post the stack trace?

[c0yote]

Well, after some further investigation, this seems to be a MinGW + Google Test + pthread problem.

A similar more commonly reported problem occurs on EXPECT_CALL executions returning a pthread error 22, and there seems to be a number of poorly defined problems surrounding the combination. I bypassed the original trouble spot, and when I hit an EXPECT_CALL received this error 22 as well.

Fortunately, building with Google Test CMake flag -Dgtest_disable_pthreads=ON makes the test run.

Since the support seems iffy with regard to gtest's pthread usage in MinGW, may I suggest a default setting of this flag as ON when CMake detects MinGW builds? I put in a pull request if you find this acceptable.

[jbeder]

Have you filed/found a bug with gtest?

If they're nonresponsive, then this seems reasonable. But the best place to handle this would be with them, I think.

[c0yote]

I'm working on a concise failing example to report to them. I just offered this as a work around since it's the test (not the library proper) and the turn around on gtest tends to be pretty slow.

Another option might be to move the conditional to the gtest CMakeList.txt so that when the next gtest version (which might have a fix) gets integrated, this hackish fix is overwritten?

Otherwise, I'll just remember to add the flag myself. I tried on a few mingw distros with same effect, so it looks like I'm probably the only one effected by virtue of the fact I appear to be the only one using mingw and running the tests, lol.

[c0yote]

Not sure I understand the question. I think the flag will only effect the gtest build. I don't think that yaml-cpp is multi-threaded anyway so it shouldn't matter in any case.

[jbeder]

@harrish27, is this related to yaml-cpp? Sounds like a question for the gmock team.

[c0yote]

Apart from the fact that you haven't supplied enough information for anyone to resolve the problem, this really isn't the forum for this type of question.

Try www.stackoverflow.com and see if they can address your issue.

[theNerd247]

It may be unrelated however the current pull from master gives me a SEGFAULT when running the testing suite (I'm on Arch Linux btw):

Running tests...
Test project /home/noah/src/com/yaml-cpp/build
    Start 1: yaml-test
1/1 Test #1: yaml-test ........................***Exception: SegFault  0.15 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.15 sec

The following tests FAILED:
      1 - yaml-test (SEGFAULT)
Errors while running CTest
Makefile:105: recipe for target 'test' failed
make: *** [test] Error 8

$g++ --version
g++ (GCC) 6.1.1 20160501
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

How do I go about getting a stack trace? running make test in gdb gives nothing (after the backtrace command in gdb).

[jbeder]

@theNerd247 try just make and then explicitly running gdb test/run_tests.

[johu]

Reported in Gentoo as well:
https://bugs.gentoo.org/show_bug.cgi?id=609176

Info provided by reporter:
The tests pass if I add '-fno-delete-null-pointer-checks' to C{,XX}FLAGS.