Closed AdrianLC closed 2 years ago
Also is there any way to recover from the panic? I tried except symbolic.Panic but we still lose the parent process with a core dump
We noticed the wheel on pip is built with python2.7 and we managed to fix this by building everything ourselves for python3.7 with rust 1.34. So at least it doesn't crash with a core dump now
@AdrianLC would it be possible to share the dSYM with me (via email to jan.auer@sentry.io, for instance)? I'm curious what might cause this panic -- especially since there shouldn't be a large difference between our binary wheels and a custom build.
Also, I'm curious as to why there is a core dump. The library catches the panic down, which is why you can see it along with the Python stack trace.
Would love to take a detailled look at a repro case or the affected file.
Thank you @jan-auer. I just sent you the dSYM by email.
We generally cannot see the panic when it crashes. But for some reason I managed to see it when running the code from a shell. Also, it sort of seems to be fixed with our build and we get an exception instead. (Sort of, because we suspect it still might be happening with other zips)
Hi, with the 7.1.0 release our regression test has changed from symbolic.Panic
to this
symbolic.ObjectErrorBadMachOobject: failed to process macho file
caused by: invalid MachO file
caused by: type is too big (3074949) for 754944
stacktrace: stack backtrace:
0: failure::backtrace::Backtrace::new
at /root/.cargo/registry/src/github.com-1ecc6299db9ec823/failure-0.1.5/src/backtrace/internal.rs:44
<failure::backtrace::Backtrace as core::default::Default>::default
at /root/.cargo/registry/src/github.com-1ecc6299db9ec823/failure-0.1.5/src/backtrace/mod.rs:125
1: symbolic_archive_get_object
at /root/.cargo/registry/src/github.com-1ecc6299db9ec823/failure-0.1.5/src/error/error_impl.rs:19
I guess the change comes from https://github.com/getsentry/symbolic/pull/169/files maybe it's enough to close this issue.
Looking at the original stack trace, I have the assumption this was an wrapping arithmetic problem that I found and fixed some time ago both coming from another customer issue, as well as using fuzzing.
The second stack trace reported later on looks different.
Since this issue is already over 2 years old, I will close this for now, and ask you to reopen if this is still a problem, preferably with a failing testcase that we can look at.
Hi, we are having a rust panic crash with one of our binary files. It happens with symbolic 6.1.3 and 6.1.4 and we are calling this from python with:
Sharing the panic message below. I do not know any Rust so if you are missing any other info please say so and I will try to help.
Also is there any way to recover from the panic? I tried
except symbolic.Panic
but we still lose the parent process with a core dump.