twistedfall / opencv-rust

Rust bindings for OpenCV 3 & 4
MIT License
1.86k stars 144 forks source link

On rust nightly: 0.88.8 build fails on macOS: Generator process panicked: Any { .. } #548

Closed k-bx closed 2 months ago

k-bx commented 4 months ago
...
  === Running: "/Users/kon/workspace/echo/wdintel-rs/target/debug/build/opencv-b224ca34520015eb/build-script-build" "/opt/homebrew/opt/opencv/include/opencv4" "/Users/kon/.cargo/registry/src/index.crates.io-6
f17d22bba15001f/opencv-0.88.8/src_cpp" "/Users/kon/workspace/echo/wdintel-rs/target/debug/build/opencv-2e96f3a51d5dd3cb/out" "wechat_qrcode" ""
  === Generated: tracking in 1.467822375s
  === Running: "/Users/kon/workspace/echo/wdintel-rs/target/debug/build/opencv-b224ca34520015eb/build-script-build" "/opt/homebrew/opt/opencv/include/opencv4" "/Users/kon/.cargo/registry/src/index.crates.io-6
f17d22bba15001f/opencv-0.88.8/src_cpp" "/Users/kon/workspace/echo/wdintel-rs/target/debug/build/opencv-2e96f3a51d5dd3cb/out" "xfeatures2d" ""
  === Generated: text in 2.056710875s
  === Running: "/Users/kon/workspace/echo/wdintel-rs/target/debug/build/opencv-b224ca34520015eb/build-script-build" "/opt/homebrew/opt/opencv/include/opencv4" "/Users/kon/.cargo/registry/src/index.crates.io-6f17d22bba15001f/opencv-0.88.8/src_cpp" "/Users/kon/workspace/echo/wdintel-rs/target/debug/build/opencv-2e96f3a51d5dd3cb/out" "ximgproc" ""
  === Generated: video in 2.024388042s
  === Running: "/Users/kon/workspace/echo/wdintel-rs/target/debug/build/opencv-b224ca34520015eb/build-script-build" "/opt/homebrew/opt/opencv/include/opencv4" "/Users/kon/.cargo/registry/src/index.crates.io-6f17d22bba15001f/opencv-0.88.8/src_cpp" "/Users/kon/workspace/echo/wdintel-rs/target/debug/build/opencv-2e96f3a51d5dd3cb/out" "xobjdetect" ""
  === Generated: videoio in 1.492691958s
  === Running: "/Users/kon/workspace/echo/wdintel-rs/target/debug/build/opencv-b224ca34520015eb/build-script-build" "/opt/homebrew/opt/opencv/include/opencv4" "/Users/kon/.cargo/registry/src/index.crates.io-6f17d22bba15001f/opencv-0.88.8/src_cpp" "/Users/kon/workspace/echo/wdintel-rs/target/debug/build/opencv-2e96f3a51d5dd3cb/out" "xphoto" ""
  thread 'main' panicked at /Users/kon/.cargo/registry/src/index.crates.io-6f17d22bba15001f/opencv-0.88.8/build/generator.rs:119:36:
  Generator process panicked: Any { .. }
  stack backtrace:
     0: rust_begin_unwind
               at /rustc/c475e2303b551d726307c646181e0677af1e0069/library/std/src/panicking.rs:645:5
     1: core::panicking::panic_fmt
               at /rustc/c475e2303b551d726307c646181e0677af1e0069/library/core/src/panicking.rs:72:14
     2: core::result::unwrap_failed
               at /rustc/c475e2303b551d726307c646181e0677af1e0069/library/core/src/result.rs:1654:5
     3: core::result::Result<T,E>::expect
     4: build_script_build::generator::BindingGenerator::run::{{closure}}
     5: std::thread::scoped::scope::{{closure}}
     6: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
     7: std::panicking::try::do_call
     8: ___rust_try
     9: std::panicking::try
    10: std::thread::scoped::scope
    11: build_script_build::generator::BindingGenerator::run
    12: build_script_build::generator::BindingGenerator::generate_wrapper
    13: build_script_build::main
    14: core::ops::function::FnOnce::call_once
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
  === Generated: wechat_qrcode in 1.301045375s
  === Generated: stitching in 3.436243708s
  === Generated: videostab in 2.156585167s
  === Generated: viz in 2.238548833s
  === Generated: xobjdetect in 1.068759875s
...
twistedfall commented 4 months ago

Please attach a full build log as produced by cargo build -vv

k-bx commented 4 months ago

opencv-log-err-29feb24.txt

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" ] }
cl0vrfi3ld commented 4 months ago

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.

Here's my setup info: ```bash ➜ NoCashMoCap git:(main) ✗ rustc -V --verbose rustc 1.78.0-nightly (d18480b84 2024-03-04) binary: rustc commit-hash: d18480b84fdbf1efc34f62070951334aa833d761 commit-date: 2024-03-04 host: x86_64-apple-darwin release: 1.78.0-nightly LLVM version: 18.1.0 ➜ NoCashMoCap git:(main) ✗ sw_vers ProductName: macOS ProductVersion: 14.3.1 BuildVersion: 23D60 ➜ NoCashMoCap git:(main) ✗ brew info opencv ==> opencv: stable 4.9.0 (bottled) Open source computer vision library https://opencv.org/ /usr/local/Cellar/opencv/4.9.0_4 (971 files, 258.7MB) * Poured from bottle using the formulae.brew.sh API on 2024-03-05 at 02:00:23 From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/o/opencv.rb License: Apache-2.0 ==> Dependencies Build: cmake ✘, pkg-config ✔, python-setuptools ✔ Required: ceres-solver ✔, eigen ✔, ffmpeg ✔, glog ✔, harfbuzz ✔, jpeg-turbo ✔, libpng ✔, libtiff ✔, numpy ✔, openblas ✔, openexr ✔, openjpeg ✔, openvino ✔, protobuf ✔, python@3.12 ✔, tbb ✔, vtk ✔, webp ✔ ==> Analytics install: 11,236 (30 days), 30,599 (90 days), 126,105 (365 days) install-on-request: 10,434 (30 days), 28,308 (90 days), 117,814 (365 days) build-error: 37 (30 days) ➜ NoCashMoCap git:(main) ✗ echo $DYLD_FALLBACK_LIBRARY_PATH /Library/Developer/CommandLineTools/usr/lib/ ```
Here's my project's `Cargo.toml`: ```toml [package] name = "ncmcap" version = "0.1.0" edition = "2021" # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html [dependencies] opencv = { version = "0.88.8", features = ["clang-runtime"] } nalgebra = "0.32.4" apriltag = "0.4.0" ```

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.

cl0vrfi3ld commented 4 months ago

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.

twistedfall commented 4 months ago

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!

TDiblik commented 2 months ago

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!

twistedfall commented 2 months ago

@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.

onkoe commented 2 months ago

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... 😅

https://github.com/KyleMayes/clang-rs/pull/58

twistedfall commented 2 months ago

While we wait for the new clang release there is now v0.91.3 with the workaround for this bug.