How to debug SIGSEGV in unity?
I’m far from an expert in these matters but I have implemented handlers in the past (but not for a Unity app). But anyway… it sounds very much like you have a misbehaving library that is trying to access memory it shouldn’t. What I would do copy to project folder so you have an untouched backup.
Then comment / remove most things that seem out of the ordinary (use your own definition but I don’t mean the floor game object or something you use all the time.
Get it to build and run successfully without error. Restore the things you removed incrementally, testing each time until it once again breaks.
Also not an expert.
But a SIGSEGV can also occure when you run out of memory. This can be caused by a memory leak.
So, the first thing I would find out is if you acrually have a memory leak.
Just run your game with Unity’s profiler attached and see if the memory is more or less constantly increasing.
If so, you could use Unity’s experimental Memory Profiler package to get an idea what causes the leak.
If it is not a memory leak, it is most likely caused by unmanaged code.
If you can reproduce the crash:
- Check if you have plugins that are not written in C# and disable / remove them for testing if possible.
- If you know that the crash was recently introduced and you are using git, find the commit that introduced the faulty code by using gits bisect feature.
If you cannot reproduce it:
- see if you can see something in the log file (probably not)
- look into the crash dump file and hope you get a clue
- pray that you can find the cause just by staring at your code and plugins or that somebody else knows better what to do with dumb dump files.
SIGSEGV is caused by an invalid memory access, which can happen in a variety of ways including running out of memory or faulty code that generates an invalid memory access and attempts to dereference it. It’s usually not C# that triggers a SIGSEGV due to the design of the language.
The devil here is in the details but the first step is to check the log and look for exception information related to the crash. It will usually tell you the faulting address and where in code the instruction that failed was, which may be a clue to fixing it. The process generally involves a bit of sleuthing, good luck!
The problem turned out to be in a long recursion (that is, not infinite, but simply long), so as I understood, a stack clearing error occurred, leading to SIGSEGV. Well, it’s pretty strange, but that’s exactly it
More accurately you most likely pushed more onto the stack than fit on the stack memory block, which causes the CPU to execute …
Maximum recursion depth is governed by remaining stack memory divided by stack usage per call. Stack usage is aggravated by local variables and arguments passed within the functions involved. When you call a method, the params are pushed (including this), the return address is pushed, a jump happens and then the stack pointer is moved down to accommodate all local variables. More args and more locals means you gobble up the stack faster.
To understand recursion you must first understand recursion.