#Handle SIG* and panic() for non-rust crashes
20 messages · Page 1 of 1 (latest)
I would love this, but I don't know how to achieve this
Somthing like this https://blog.logrocket.com/guide-signal-handling-rust/
We can hook SIGABRT, SIGTERM, SIGSEGV etc.. to call painc() in those handlers
unfortunately these libc calls are not available on windows
basically, signal handlers run in the kernel space, and so they don't have access to any usermode call. here it explains how to work around this by manipulating the stack but it's really hacky https://feepingcreature.github.io/handling.html
I wouldn't be surprised if I bluescreen my pc writing and debugging this lol
I just looked up the original "classic" ALVR code, ported back the crash handler code and it worked!
Classic? :o
yeah, polygraphene/ALVR
this is what I get:
can't seem to add file name and line info, but that's already quite useful
also this is windows only, linux needs to use some other code
I guess this suggestion can be marked as resolved 🙂 For the client we are going to remove all c++ code soon so no need to work on that I think. and for PhoneVR you can add support yourself, just take insporation from the last commit I pushed
oh btw,
panic() will print a good stacktrace of the crash :3
This not true if the crash happened on the C++ side, the symbols will be mangled in a way that Rust can't understand and so it will have <unknown> entries. So in the last commit I included a C++ stacktrace library.
think filename and line no is specifc to rust implementation (rustc ig)
looks good already, maybe those ?? are those symbols which are not there in libaries i guess
but i thought that mangling is same for both rust and c++, since on crash android/Tombstone crashes include both Rust and C++ very nicly
