segfault for lua tests about catch2 HOT 10 CLOSED

That doesn't sound good.

I think the most important question is: are you using the "master" branch, or "SingleEvaluation" ?

If the former I suspect it may be due to the multiple evaluations of the arguments (most likely in the last assertion - looks like it has side-effects?)

If the latter then it may be due to how the arguments are held in template deduced types.

I think the first case sounds more likely - so I'm guessing you're on master?
If so could you try the SingleEvaluation branch and let me know of that solves it for you?
If not please let me know ASAP. I'm hoping to merge SingleEvaluation back into master quite soon so would really like to know if there are serious issues of this nature with it!
Could you also try and pin down (through a process of elimination) which line is causing the issue. I'm guessing that if you replace the REQUIRE()'s with assert()s in the first case it works too?

Thanks

from catch2.

The segfault happens on the lua_next line, which is the only REQUIRE statement that does stack manipulations.

I'm indeed on master, so double evaluation is a likely factor. To test this hypothesis I changed my catch-less version to do the assert(lua_next(lua, -2)==0); twice and that indeed makes it segfault as well.

I'll try the SingleEvaluation branch to see if that helps.

from catch2.

The SingleEvaluation branch currently results in a compile error:

../../src/tests/catalog.cc:345: error: no matching function for call to 'Catch::IResultCapture::acceptExpression(Catch::PtrExpression)'
../../catch/internal/catch_interfaces_capture.h:61: note: candidates are: virtual Catch::ResultAction::Value Catch::IResultCapture::acceptExpression(const Catch::MutableResultInfo&)

from catch2.

d'oh.
This is the sort of thing that's stopping me merging SingleEvaluation back.
Which line is that complaining about (ie which is line 345)?
Thanks for the feedback.

from catch2.

REQUIRE(catalog.called)

called is a boolean attribute.

from catch2.

Could you be more specific about what you mean by "boolean attribute"?

Ideally if you can reproduce the issue in a boiled down case (that doesn't depend on Lua) it would be perfect :-)

from catch2.

Actually I think I know what it is.

It looks like catalog.called is a pointer - is that so?

At least I was able to reproduce the issue by evaluating a pointer in a boolean context.
I've just pushed a fix up. Please let me know if it addresses your issue.

from catch2.

You are correct. The class looks a bit like this:

class MockGenericSearchCatalog : public Catalog {
public:
    bool *called;
};

I'll test if your change improves things.

from catch2.

It does indeed! All tests are running correctly now.

from catch2.

Excellent news! Thanks for reporting this and trying it out

from catch2.