`thread panicked while panicking` issue in PyO3 project

[max-sixty]

What happened?

Running cargo test with an assert_snapshot in a project that uses PyO3 causes a thread panicked while panicking error.

cargo test
   Compiling pyo3-build-config v0.16.5
   Compiling pyo3-ffi v0.16.5
   Compiling pyo3 v0.16.5
   Compiling prql-python v0.0.3 (/Users/maximilian/workspace/prql/prql-python)
    Finished test [unoptimized + debuginfo] target(s) in 4.59s
     Running unittests src/lib.rs (/Users/maximilian/workspace/prql/target/debug/deps/prql_python-d1ec131f5b2ac499)

running 1 test
thread panicked while panicking. aborting.
error: test failed, to rerun pass '--lib'

Caused by:
  process didn't exit successfully: `/Users/maximilian/workspace/prql/target/debug/deps/prql_python-d1ec131f5b2ac499` (signal: 6, SIGABRT: process abort signal)

I'm happy to do more investigation here, though I'm not sure exactly what to do — this was already on the edge of my rust knowledge tbh.

It's not personally a big issue — we don't need many tests here and can do the standard copy paste for snapshots for those. So logging in case it's helpful more generally.

Reproduction steps

I created a branch to show this: https://github.com/prql/prql/tree/insta-python

cd prql-python; cargo test demonstrates it. Currently the commit hash is 6b157e7

Insta Version

1.14.0

rustc Version

1.61.0

What did you expect?

No response

[mitsuhiko]

Unfortunately I cannot build your example repo on my mac:

dyld[25760]: symbol not found in flat namespace '_libintl_bind_textdomain_codeset'
error: test failed, to rerun pass '--lib'

Caused by:
  process didn't exit successfully: `/private/tmp/prql/target/debug/deps/prql_python-f3040ca7efef00a4` (signal: 6, SIGABRT: process abort signal)

[max-sixty]

OK, given how niche this is, and how prickly the build issues with linking to Python are (despite great work from PyO3!) — it may not be worth exploring more.

I did push the branch such that it built in GHA with the same error message: https://github.com/prql/prql/runs/6616180905?check_suite_focus=true#step:3:544

But I'm fine with closing this given the above. Thanks as ever @mitsuhiko

[mitsuhiko]

I think one way to figure this out would be to run this whole thing through lldb/gdb and have it print out a stacktrace on crash.

[max-sixty]

This no longer occurs on upgrading from 1.14 to 1.26!

[mitsuhiko]

Yay! :D (i have no idea why that would be)