Open bobaoapae opened 1 week ago
First and third issues there are the same but are very odd - within a core run function, there's a dynamic branch, and the value that it's branching to is wrong (f374b1
is not within the libCore program data, and is not even a valid address for arm64 code!). But very tricky to work out which actual bit of code this is referring to as it's a massive function, I'll see if we can get some extra debug/disassembly data for that...
Second issue is a Loader object that is adding a child, and we're queuing up the child object to be decoded into a bitmap in the background, and there's a crash that looks to be caused by a null argument to this method: we can work backwards to see if there's an error condition we're missing, and at least it should be possible to add null-checks to prevent the crash.
Fourth and fifth issues are in the addition and removal (respectively) of an input device. This should be something we can address but can I check whether this was running in a background thread i.e. do you have the Android
thanks
Running in background is set to false
Thanks So I think we can add protection for 2, 4 and 5.
Issues 1 and 3 are where it's calling a virtual method and something seems to have corrupted the virtual method table, it should call to 0x285428 but instead is hitting 0xf374b1 (well, if there's any register information available in the dump, we can check that for sure: all we see is the crash location here, it would be nice to know values of x0, x8 and x9). Would be great if we could get a way to reproduce this one!
AIRSDK: 51.1.1.5 (happens on old versions too).
Those crash reports get more than 5% rate on play reports. And this it's a lot more than the threshold, so my app get penalized.