Test failure in release mode about opm-output

[jokva]

Interesting, but I'm not able to reproduce. Do you have a gdb trace for me?

[atgeirr]

(lldb) bt
* thread #1: tid = 0xabc3f, 0x000000010000d790 test_EclipseWriter`Opm::EclipseState::EclipseState(Opm::EclipseState&&) + 784, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x000000010000d790 test_EclipseWriter`Opm::EclipseState::EclipseState(Opm::EclipseState&&) + 784
    frame #1: 0x0000000100007e36 test_EclipseWriter`EclipseWriterIntegration::test_method() + 326
    frame #2: 0x00000001005ec4c1 libboost_unit_test_framework-mt.dylib`boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >::invoke() + 17
    frame #3: 0x00000001005d5a60 libboost_unit_test_framework-mt.dylib`boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) + 160
    frame #4: 0x00000001005d5b07 libboost_unit_test_framework-mt.dylib`boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) + 39
    frame #5: 0x00000001005ec21f libboost_unit_test_framework-mt.dylib`boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) + 159
    frame #6: 0x00000001005dc3a8 libboost_unit_test_framework-mt.dylib`boost::unit_test::framework_impl::visit(boost::unit_test::test_case const&) + 168
    frame #7: 0x0000000100616e47 libboost_unit_test_framework-mt.dylib`boost::unit_test::traverse_test_tree(boost::unit_test::test_suite const&, boost::unit_test::test_tree_visitor&) + 327
    frame #8: 0x00000001005d9377 libboost_unit_test_framework-mt.dylib`boost::unit_test::framework::run(unsigned long, bool) + 4183
    frame #9: 0x00000001005ea3a3 libboost_unit_test_framework-mt.dylib`boost::unit_test::unit_test_main(bool (*)(), int, char**) + 211
    frame #10: 0x00007fff9f07f5ad libdyld.dylib`start + 1

[jokva]

Does it also spit out something about where it goes wrong? I'm looking through and all, but more information is always good.

[atgeirr]

Not any more than I have posted already....

[bska]

Does it also spit out something about where it goes wrong?

Not any more than I have posted already....

If you have addr2line you can possibly get some more information out of

$ addr2line -f -e test_EclipseWriter 0x000000010000d790

[atgeirr]

If you have addr2line

Can't find it, unfortunately.

[jokva]

Just compiled it with clang, still can't reproduce.

clang version 3.4.2 (tags/RELEASE_34/dot2-final)
Target: x86_64-redhat-linux-gnu
Thread model: posix

[jokva]

Can you compile parser in release mode with debug symbols enabled, and then run the same trace? Should give some more information.

-DCMAKE_CXX_FLAGS_RELEASE="-g" should do the trick.

[bska]

If you have addr2line

Can't find it, unfortunately.

Ah, okay. There is apparently an OS X utility called atos that does something similar to GNU's addr2line, but I have no experience with it.

[bska]

If your compiler supports the sanitizers then you could also try recompiling the modules with -fsanitize=address and rerunning the test.

[atgeirr]

Tried atos, but it only gives the same string as the line from the backtrace above. Will try release with debug and address-sanitizer on Monday.

[atgeirr]

This failure seems to have gone away in the last week or so. Not sure why, but I can no longer reproduce it. Will therefore close this issue.

Do you have an idea which change might have fixed it? In particular, did you fix any potential memory corrupting bugs?