libc++abi: terminating due to uncaught exception of type std::bad_any_cast: bad any cast

[btc]

libc++abi: terminating due to uncaught exception of type std::bad_any_cast: bad any cast

I see this error on occasion. e.g. here

I'm wondering if you have an idea of what causes it? It's not a big deal, as a retry usually addresses the issue. Yet, I'm curious.

Thanks again for creating this wrapper. We are making good use of it.

[ankane]

Hi @btc, it means there's an issue with the bindings, but haven't been able to narrow it down. What OS and full version of Ruby are you on?

[btc]

@ankane

macOS Sonoma 14.4.1
Ruby 3.3.0

GIT
  remote: https://github.com/ankane/or-tools-ruby.git
  revision: 0376b08b58c38118704c96b85d3e47a8faf94129
  ref: 0376b08b58c38118704c96b85d3e47a8faf94129
  specs:
    or-tools (0.11.1)
      rice (>= 4.3)

I'm happy to collect more diagnostic information when I encounter this type of crash again.

[ankane]

Thanks. The thread backtrace from Crash Reports would be most helpful.

[cfranklin11]

I've run into this error as well, so far only in specs running in our CI, but I was able to recreate it, and capture and log the core dump using logbt.

Gem info:

GEM
  remote: https://rubygems.org/
  specs:
    or-tools (0.11.1)
      rice (>= 4.1)

The code was running in a Docker container from an image based on the ruby:3.2-bullseye image (as far as I can tell, we don't do anything with the C++ version or compiler, so whatever is the default for Debian bullseye should apply). I've attached the output from logbt below. Let me know if you prefer a different format (with explicit instructions for how to generate it, because C++ is well beyond my ken) or need a reproducible example to tinker with.

or-tools-core-dump.txt

[ankane]

@cfranklin11 Thanks for sharing. Unfortunately, I'm still having trouble finding the exact issue.

I was also able to get a crash report locally, but it's for a different spot.

Rice::detail::NativeFunction<operations_research::sat::BoolVar, operations_research::sat::BoolVar (operations_research::sat::BoolVar::*)() const, true>* Rice::detail::NativeRegistry::lookup<Rice::detail::NativeFunction<operations_research::sat::BoolVar, operations_research::sat::BoolVar (operations_research::sat::BoolVar::*)() const, true>*>(unsigned long, unsigned long)

[cfranklin11]

I've been looking into this off and on as time permits in order to send you a minimal reproducible example, but I've gotten stuck. Every time I try to simplify some of the code from my work codebase, it fails to trigger the std::bad_any_cast error. Since I can only get the error in the context of a Rails app running Rspec tests that exercise our optimizer module exactly as written, I'm chalking this up to being an extreme edge case and am looking into ways to work around it.

For anyone else who runs into this error, I was able to narrow down the cause to be, at least in part, due to having the georuby and dbf gems installed (I have no idea what the mechanism is for this, but the results of my experiments were consistent). georuby is an abandoned project, with a viable alternative, so my work-around is to just replace it with a gem that's still maintained. So, one thing for others to try is gradually deleting gems from their codebases to see if the std::bad_any_cast stops appearing, because some other gem is interacting with or-tools in a way the raises this error.

[ankane]

@btc and @cfranklin11 What ORTools model / solver classes are you using?

Just found and fixed a memory issue in RoutingModel: e0b9f3b

[cfranklin11]

I'm using a GLOP solver for a linear optimization problem.