Bug: Conjure Oxide crashes with `RuleSetNotFound` in release mode

[niklasdewally]

Running Conjure Oxide in release mode (with --release) gives a RuleSetNotFound error. This is not present if ran in debug mode.

Environment

This bug is present with the following setup:

• M1 MacOS
• Rust version 1.8.6
• Latest main branch of conjure oxide (at time of writing e0ad0d0)

Steps to Reproduce

This bug is present both in the tester and the executable:

Tester

• Run ACCEPT=true cargo test --release. All integration tests fail with the error message Error: RuleSetNotFound. As ACCEPT=true is given, all tests should pass.
• If ACCEPT=true cargo test is ran instead, all integration tests pass as expected.

Executable

• Run cargo run --release -- test-solve conjure_oxide/tests/integration/basic/pow/03-negative-exponent/input.eprime. The executable exits with the error Error resolving rule sets: Rule set not found.. The expected output is Success: solutions match!.

• If ran without --release, cargo run -- test-solve conjure_oxide/tests/integration/basic/pow/03-negative-exponent/input.eprime returns Success: solutions match!

Details

According to git bisect, this bug was introduced in commit 0539467.

[niklasdewally]

@ozgurakgun @gskorokhod

[ozgurakgun]

Thanks for the excellent bug report @niklasdewally

In addition to investigating the bug, this means we should run the tests with --release as well in CI.

[niklasdewally]

We have had some issues linkme and --release before, e.g in. b9f77ea. The fix was to change some compilation and linker settings.

This might be related...

[niklasdewally]

CC @lixitrixi

[lixitrixi]

After playing around a bit with the release profile I've found that this issue is likely caused by compiler optimisation, specifically O3. I'm on Intel MacOS.

I believe this may just be a case of aggressive dead code elimination. Apparently there's a #[used] macro which preserves static variables? I will try it out and report back :)

[lixitrixi]

The #[used] attribute is actually already used (haha) by linkme, so I doubt it's that. It may be linker issues, for which the used_linker feature of the crate might be useful. Unfortunately this is unstable and I haven't been able to figure out how to get it to work with `#![allow(unstable_features)].

This issue should be resolved by simply using opt-level=2 in the release profile. I doubt the impact is that noticeable? @ozgurakgun @niklasdewally would appreciate any insights

[ChrisJefferson]

While this might be a good short-term fix, in my past experience, these kind of "breaks at a different optimisation level" bugs will usually come back and bite you later on -- if changing the optimisation breaks your code, either there is a compiler bug (not impossible!), or your code is doing that it really shouldn't be!

I'm guessing the issue is with 'linkme' (I'm just guessing). Could someone try to make a minimal example which shows the problem, which we could then try to debug, or submit to linkme's github (assuming that is the source of the issue).

I realise this is some annoying work, but writing little examples to submit bugs upstream is part of writing any large enough software package :)

[ChrisJefferson]

I don't have a mac to test at the moment, but could this be related to this issue (following some linkme issues):

rust-lang/rust#133491

This suggests the problem is nothing in the rules crate is ever (obviously) called, so it doesn't get linked in.

Just putting in a 'do nothing' function probably wouldn't work, as it would get optimised away.

One suggestion -- could RULES_DISTRIBUTED_SLICE / all_rules() be moved over to the conjure_rules repository? Then we'd have a function that definately needs calling?

Also, maybe in all_rules, put an assert that the rules set isn't empty, and if it is print out "Something went wrong -- the list of rules is empty", and link to this issue (or somewhere similar), so future people who hit the same issue have some idea what's going on? (Note: I am currently guessing by reading the code what's going on and what the problem is, I might be way off, sorry if I am!)

[niklasdewally]

RUSTFLAGS='-Clink-dead-code=yes', suggested by the issue linked, does not work.

[niklasdewally]

I don't have a mac to test at the moment, but could this be related to this issue (following some linkme issues):

rust-lang/rust#133491

I think that is the issue we are having here.

The PR that fixes it (rust-lang/rust#133832) is currently in Rust beta. It seems to fix this bug: running Conjure Oxide in release mode with the Rust beta works as expected:

 cargo +beta run --release -- test-solve conjure_oxide/tests/integration/basic/div/05/div-05.essence

Linkme adds the #[used] attributes for us, so no change to the code should be needed.

rust-lang/rust#133832 is due to be stabilized in 1.87 on the 15th May, so I think the best course of action is to wait until then and see if this bug is still present on 1.87.