Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uncaught exception during init() when running a script through pycharm #2690

Closed
Tracked by #2779
jleibs opened this issue Jul 13, 2023 · 0 comments · Fixed by #2804
Closed
Tracked by #2779

Uncaught exception during init() when running a script through pycharm #2690

jleibs opened this issue Jul 13, 2023 · 0 comments · Fixed by #2804
Assignees
Labels
🪳 bug Something isn't working 🐍 Python API Python logging API
Milestone

Comments

@jleibs
Copy link
Member

jleibs commented Jul 13, 2023

It appears that certain invocation of pycharm can throw an exception during rr.init() while we are using authkey to generate the recording ID.

I strongly suspect the failure is coming from here:

fn authkey(py: Python<'_>) -> Vec<u8> {
let locals = PyDict::new(py);
py.run(
r#"
import multiprocessing
# authkey is the same for child and parent processes, so this is how we know we're the same
authkey = multiprocessing.current_process().authkey
"#,
None,
Some(locals),
)
.unwrap();
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:

import uuid
rr.init("myapp", recording_id=str(uuid.uuid4()))

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)
@jleibs jleibs added 🪳 bug Something isn't working 🐍 Python API Python logging API labels Jul 13, 2023
@jleibs jleibs mentioned this issue Jul 24, 2023
11 tasks
@jleibs jleibs self-assigned this Jul 24, 2023
teh-cmc pushed a commit that referenced this issue Jul 25, 2023
Fixes: #2690

### What
In some situations the authkey generation fails. Change the
implementation to avoid unwrap and fallback on a rand if all else fails.

### Checklist
* [x] I have read and agree to [Contributor
Guide](https://github.com/rerun-io/rerun/blob/main/CONTRIBUTING.md) and
the [Code of
Conduct](https://github.com/rerun-io/rerun/blob/main/CODE_OF_CONDUCT.md)
* [x] I've included a screenshot or gif (if applicable)
* [x] I have tested [demo.rerun.io](https://demo.rerun.io/pr/2804) (if
applicable)

- [PR Build Summary](https://build.rerun.io/pr/2804)
- [Docs
preview](https://rerun.io/preview/pr%3Ajleibs%2Fdont_unwrap_authkey/docs)
- [Examples
preview](https://rerun.io/preview/pr%3Ajleibs%2Fdont_unwrap_authkey/examples)
@abey79 abey79 added this to the 0.8 milestone Jul 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🪳 bug Something isn't working 🐍 Python API Python logging API
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants