You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
let authkey = locals.get_item("authkey").unwrap();
let authkey:&PyBytes = authkey.downcast().unwrap();
authkey.as_bytes().to_vec()
}
Something about the pycharm context causes the import to fail.
At a minimum these unwrap() calls need to be removed and we should warn, then use a random recording-id in the event that authkey fails. This means multiprocessing won't work correctly, but that's still better than crashing.
Know work-arounds
The issue can be avoided by manually setting the recording_id:
This supports the theory that the authkey code-path is the culprit since manually setting the recording_id bypasses this code-path.
Additional details
A user reported:
We use rerun-sdk in our own python library for data visualization. When I write and run scripts that use our library (and subsequently tries to launch and log to rerun), I get the following error:
thread '' panicked at 'called Result::unwrap() on an Err value: PyErr { type: <class 'ImportError'>, value: ImportError('import not found')
This only happens when I run the script using the default "Run" method in PyCharm Professional. Looking at it, it seems to run som ipython kernel, and then calls the script using runfile() method, but I can't find docs on it.
If I use the "Debug" method or change the run configuration from the default "Run with Python Console" to "Emulate terminal in output console", it works.
The stack-trace is as follows:
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: PyErr { type: <class 'ImportError'>, value: ImportError('__import__ not found'), traceback: Some(<traceback object at 0x150373a00>) }', rerun_py/src/python_bridge.rs:1180:6
stack backtrace:
0: 0x1463efb9c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h105074e3d85f800b
1: 0x14640f498 - core::fmt::write::h34766cf8fff7af1e
2: 0x1463eba10 - std::io::Write::write_fmt::hd64c4cf6e7adea59
3: 0x1463ef9b0 - std::sys_common::backtrace::print::h2a6828a537036cf9
4: 0x1463f10ec - std::panicking::default_hook::{{closure}}::h4e82ce6ccef941b2
5: 0x1463f0e44 - std::panicking::default_hook::h29f62f8795c5cb00
6: 0x1463f15fc - std::panicking::rust_panic_with_hook::h19862cbd0fbda7ba
7: 0x1463f1530 - std::panicking::begin_panic_handler::{{closure}}::h3f3626935e1669fe
8: 0x1463effbc - std::sys_common::backtrace::__rust_end_short_backtrace::h5054ef52bd507d0a
9: 0x1463f128c - _rust_begin_unwind
10: 0x1464947e0 - core::panicking::panic_fmt::h7e47e10600a90221
11: 0x146494b18 - core::result::unwrap_failed::h6a1757e313e2d291
12: 0x1455267c0 - rerun_bindings::python_bridge::new_recording::hed38aea6ac7fe8ae
Process finished with exit code 134 (interrupted by signal 6: SIGABRT)
The text was updated successfully, but these errors were encountered:
It appears that certain invocation of pycharm can throw an exception during
rr.init()
while we are usingauthkey
to generate the recording ID.I strongly suspect the failure is coming from here:
rerun/rerun_py/src/python_bridge.rs
Lines 1353 to 1368 in 18e2475
Something about the pycharm context causes the import to fail.
At a minimum these
unwrap()
calls need to be removed and we should warn, then use a random recording-id in the event that authkey fails. This means multiprocessing won't work correctly, but that's still better than crashing.Know work-arounds
The issue can be avoided by manually setting the recording_id:
This supports the theory that the
authkey
code-path is the culprit since manually setting therecording_id
bypasses this code-path.Additional details
A user reported:
The stack-trace is as follows:
The text was updated successfully, but these errors were encountered: