-
-
Notifications
You must be signed in to change notification settings - Fork 554
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
api_test failure #532
Comments
Wow, no, that wasn't intentional. Thanks for catching that. I can reproduce locally with:
@nwellnhof maybe the easiest approach would be to change the default build type, but this might break or silently change some existing builds, so maybe better to change the Makefile and CI to ensure that Debug builds are used for routine testing. Thoughts? |
I wouldn't change the default build type. CI should obviously run with a debug build. We already have a "debug" target in the Makefile that produces a debug build. |
But for local testing, too, it would be nice if |
The assertions we're talking about aren't in the test executable but in the libcmark binary (blocks.c in this case). So you have to build the library in debug mode. It doesn't matter in which mode api_test is built.
|
Oh, I see. I thought these were in api_test. |
I shouldn't have closed this until that is fixed. |
@nwellnhof now we're getting a new error: |
clang 14 (used in that run) defaults to -gdwarf-5 which that older (pre- 3.20) version of valgrind can't understand. see llvm/llvm-project#56550 for a few more details you can manually pass -gdwarf-4, or find a way to upgrade valgrind in the ci |
When building the same way the CI seems to do, and not passing
CMAKE_BUILD_TYPE
so it defaults to Release (at the bottom ofCMakeLists.txt
), cmake adds-DNDEBUG
(it also does this forMinSizeRel
, for trivia). This makes allassert()
s do nothing, and the tests pass.When explicitly passing another type like
=Debug
or=None
, so-DNDEBUG
is not present, the asserts are active, so this test fails:I think this is not caught in CI because nothing explicitly sets another type so the asserts are not checked. Or is that intentional?
I can reproduce this with a basic
on debian/arch at the time of writing, on db0da21.
The text was updated successfully, but these errors were encountered: