Memory corruption crash

Question

fury_ivan OP

Created May ’24

Replies 2

Boosts 0

Participants 2

Hello!

We are experiencing crashes on iOS both in debug and release builds in a game made in Godot 3.5.1. The main problem is that we don’t know where exactly the problem is and cannot understand how could we find a way to fix it. We don't expect that someone here will know how to fix this on Godot's side, but we would appreciate some help on how to get more info about the problem and potentially fix it.

Debug builds:

It is way more frequent in debug builds when we make a build, open it in Xcode, and install it directly on an iOS device. The first type of the crash in debug build is occurring like 70% of the time when the game is loading and trying to get into its main menu. The thing we are getting in Xcode looks like on first image below. Another type of crash happens when we open some save files and start the actual playable part of the game. It happens just after moving the character a few steps and it looks like on second image below. We are aware that the log recommends using breakpoints to find where exactly the problem is, but the thing is that we don’t know where we could do that in Xcode. We are not sure if we are missing something in Xcode or if we cannot do that when opening a project made in Godot.

We tried many different builds with removed shader files, and scenes and changed different kinds of settings. We would get the same crash every time. When we made a new build, we cleared the build’s folder. Also, we occasionally deleted the .import folder of the project during development and reimported it. The problem occurred on many different iOS devices with more than 4GB of RAM.

Release builds:

These builds are uploaded on TestFlight. In release builds crashes wouldn’t occur like in debug builds. They would happen like totally randomly. In some testing sessions, it would happen like 10 minutes in the game, and in others in a few hours. Some testers couldn’t get the crash and altogether and we couldn’t find some repro steps to produce these crashes. In the attached files, you can find logs that we managed to collect from TestFlight. The most frequent type of the crash that we got, is following:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS

Additional info:

From reading Apple’s documentation Investigating memory access crashes, we got it that the problem is in “Invalid memory fetch”, but we couldn’t find how this could help us with further investigation. When we used Address Sanitizer tool and made a build, suddently the game stopped crashing in debug builds like it did before. Also we then didn't receive logs in Xcode that would hint us that something is going on.

Tried to build our project in newer version of Godot, but the problem still persisted.

Used software and hardware:

Godot 3.5.1
macOS, Ventura, 13.5
Xcode, 15.2
iPad Air (5th generation), 17.4.1
MacBook Pro, Apple M1

If you have some clues or ideas on how to fix this problem, please write it, it would mean us a lot. Don’t hesitate to ask questions if something is unclear.

Thank you very much in advance!

Boost

Answer 1

fury_ivan OP

May ’24

I couldn't add any attachments in main post because they were labeled as they contain sensitive language...

Image 1.png

Image 2.png

0

Answer 2

DTS Engineer OP

Apple

May ’24

My general advice on this front is in Standard Memory Debugging Tools, but I suspect you’ve found that already, or most of the docs it links to. So, let’s start with this:

We are aware that the log recommends using breakpoints to find where exactly the problem is, but the thing is that we don’t know where we could do that in Xcode.

Do this:

Choose View > Navigators > Breakspoints.
At the bottom left, from the add (+) menu, choose Symbolic Breakpoint.
In the Symbol field, enter the symbol name, for example, malloc_error_break.
Run your program and reproduce the problem. It should stop it the debugger at malloc_error_break. You can then look at the backtrace to see how you got there.

For example, this program:

import Darwin

func main() {
    let m = malloc(1024)
    free(m)
    free(m)
}

main()

stops with this message:

xxst(85000,0x2047bbac0) malloc: double free for ptr 0x13300c000
xxst(85000,0x2047bbac0) malloc: *** set a breakpoint in malloc_error_break to debug

and a backtrace reveals:

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: … libsystem_malloc.dylib`malloc_error_break
    frame #1: … libsystem_malloc.dylib`malloc_vreport + 748
    frame #2: … libsystem_malloc.dylib`malloc_zone_error + 104
    frame #3: … libsystem_malloc.dylib`free_small_botch + 40
    frame #4: … xxst`main() at main.swift:6:5
    frame #5: … xxst`main at main.swift:9:1
    frame #6: … dyld`start + 2360```

ps You wrote:

I couldn't add any attachments in main post because they were labeled as they contain sensitive language

Hmmm, I’ve been search for an explanation of that message recently — see here — and that might be a useful clue. Thanks!

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0