Closed k-bx closed 2 months ago
Please attach a full build log as produced by cargo build -vv
I also can confirm this fails on "hello world" app with this Cargo.toml:
[package]
name = "opencv-play"
version = "0.1.0"
edition = "2021"
[dependencies]
opencv = { version = "0.88.8", features = [ "clang-runtime" ] }
I'm having this issue as well, seems like macOS devs have been running into similar problems a lot recently. I'm not a C/C++ dev, so there's a good chance that my environment is just borked, though the numerous thread panics are quite conspicuous.
I've looked through the troubleshooting guide and applied some of the pointers there to the best of my knowledge, unfortunately to no avail, so I'll post my diagnostics/logs here to help narrow down the cause.
And here's my build log, exported via RUST_BACKTRACE=full cargo build -vv
:
build-log.txt
Since this is a CV project, I'd rather not have to use a container (performance, camera binding, etc.) but for now I think that's the best way to go. If I make any headway with this, I'll update this with my findings should anyone be interested.
Following the updated macOS install tips found in #494 allowed me to compile the package with a reduced scope. At the moment, I only need the videoio
, calib3d
, and highgui
modules, so I adjusted my [dependencies]
section accordingly.
[dependencies]
opencv = { version = "0.88.8", default-features = false, features = [
"clang-runtime",
"highgui",
"videoio",
"calib3d",
] }
I've been able to successfully open a VideoCapture
session, read frames, and display them in a highgui
window.
Looks like at least "xphoto" and "face" modules are affected. The exact error produced is:
unsafe precondition(s) violated: slice::from_raw_parts requires the pointer to be aligned and non-null, and the total size of the slice not to exceed `isize::MAX`
which happens in clang::source::SourceRange::tokenize
after we call it from opencv_binding_generator::field::Field::default_value
. I'll try to investigate, thanks for the report!
Hey, for those who want a quick-n-dirty fix, I've created a fork that can be compiled with the nightly version. The instructions on usage are inside the README.
You can use it like so:
[dependencies]
opencv = { git = "https://github.com/TDiblik/opencv-rust-nightly-compilation.git" }
TLDR for @twistedfall;
As mentioned, this bug is NOT produced by opencv-rust, instead it's produced by clang-rs inside the tokenize
function which is called from field.rs at line 153. There is a PR opened in clang-rs addressing this issue, however it's not merged and shipped yet. Once that's done, opencv-rust will be compileable with nightly once again. That means that coding a fix around the newly added checks inside opencv-rust is kinda pointless, since clang-rs will handle this by itself in the future.
My fork only "merges" the fix to clang-rs and includes this fixed clang-rs as a dependency of opencv-binding-generator
.
The main goal of this fork is to be a temporary drop-in replacement for opencv until the mentioned clang-rs PR gets merged and opencv-rust "fixes itself", so that those who need to compile under nightly ASAP (my case) can. Hence, I will try to keep this fork up-to-date, until then.
Are you ok with that?
Alternatively, if you want to keep people from pointing to my fork, you could take the fork changes and drop them into some branch called "nightly-fix" (or something like that) so that people can refer to this repo instead of mine.
Awesome project btw, keep it up!
@TDiblik Thanks a lot for your work and investigation! Let's hope that the fix in clang will land before the the rust changes land in stable otherwise vendoring would be the only option however I'd like to avoid it.
Small update: the PR in clang-rs
has been merged and is ready for a new release. I'm not sure what their release schedule is, but I hope to see them make a new one soon!
It's been on 2.0.0 for years now... 😅
While we wait for the new clang
release there is now v0.91.3 with the workaround for this bug.