Godot: Crash on exit iOS application when using iOS 13

Created on 6 Mar 2017  Â·  28Comments  Â·  Source: godotengine/godot

iPhone 5( 32bit) - Godot version: 2.1.2

Crash on exit application in godot/servers/audio/audio_server_sw.cpp on line 774:

void AudioServerSW::_thread_func(void *self) {

    Thread::set_name("AudioServerSW");

    AudioServerSW *as=(AudioServerSW *)self;

    while (!as->exit_update_thread) {
        as->_update_streams(true);
        OS::get_singleton()->delay_usec(5000); <<--  Crash here
    }

}

Resume: OS::get_singleton() -- not thread save (maybe do "delay_usec" as static) and not correct finalize class.
In my case OS::get_singleton() === NULL.

bug confirmed discussion ios core

Most helpful comment

Follow #32194 remove [self drawView] in layoutSubviews and re-compile can fix crashes when switching to the background (press Home button), but it still crashes when closing in the app switcher.

All 28 comments

It seems to me that this can be the same issue as (see the last comment) https://github.com/godotengine/godot/issues/5426

It looks like the crash occurs in different places when exit the application. It looks like a memory leak somewhere. Only iOS version. It takes more time to search for a leak.

First of all thank you for your report and sorry for the delay.

We released Godot 3.0 in January 2018 after 18 months of work, fixing many old issues either directly, or by obsoleting/replacing the features they were referring to.

We still have hundreds of issues whose relevance/reproducibility needs to be checked against the current stable version, and that's where you can help us.
Could you check if the issue that you described initially is still relevant/reproducible in Godot 3.0 or any newer version, and comment about its current status here?

For bug reports, please also make sure that the issue contains detailed steps to reproduce the bug and, if possible, a zipped project that can be used to reproduce it right away. This greatly speeds up debugging and bugfixing tasks for our contributors.

Our Bugsquad will review this issue more in-depth in 15 days, and potentially close it if its relevance could not be confirmed.

Thanks in advance.

Note: This message is being copy-pasted to many "stale" issues (90+ days without activity). It might happen that it is not meaningful for this specific issue or appears oblivious of the issue's context, if so please comment to notify the Bugsquad about it.

I cannot test it in Godot 3.0 version, because in this case i must rewrite all project code for Godot 3.0, but it's cannot be done in this time point. Godot 3.0 is slower than 2.1.4 and I'm waiting 3.1 with Vulcan version. Android version (Adreno GPU) very slowely and crossplatform developing in this case breaked.

Oh ok I see. Will need to test in 3.1 in such case

Godot 3.1 will not have Vulkan support, you will have to wait for 4.0 for that.

You should update your project for Godot 3.x to confirm if the issue still exists. If Godot is slower for you then that's another issue that should be addressed. But if you are not willing to test it in the latest releases I'm not sure how much we can help you.

On a related note, do we want to keep supporting 32-bit iPhones? Apple killed off 32-bit iPhone apps this year with the release of iOS 11. Even if we drop support for 32-bit iPhone apps in master, 2.1 and 3.0 would still support it.

I have this issue in 3.1.1. I've only recently gotten the error message after adding low processor mode. I can look into this further but it might stem from there.

Did some tests and I discovered it was not due to the low processor mode but due to the ios13 beta. When not on a beta firmware for iOS I'm not having any crashes on exit.

I just upgraded to official iOS 13. It crashed when killing the app.

2.1.2 only or 3.1.1 as well?

Godot 3.1.1

Previously, I tested on my iPad (with iOS 13 beta). It crashed when killing the app but it works fine on my iPhone iOS 12. After upgrading my iPhone to official iOS 13, I receive the same crash. :)

Noticed that when I just open the app, at the home screen, killing it has no crash. But when I open the app then change to another screen. Then it crashed when I kill the app.

According to the verge (https://www.theverge.com/2019/9/19/20874293/apple-ios-13-1-ipados-september-24th-early-release-date-update-bug-fixes-features) ios 13.1 will be out on the 24th. This bug doesn't exist on the 13.1 beta that I'm currently in but did in a previous 13 beta. Maybe the issue will be patched in 13.1?

"More importantly, Apple promises that 13.1 will bring general bug fixes to iOS 13, which the current software could definitely benefit from. (Our review of the current 13.0 software notes a litany of issues we encountered while testing the new update.)"

Godot 3.1.1

Confirmed crashes on iOS 13.0 simulator and 13.1 iPhone XR when switching the game to the background (press device Home button). GLES2/GLES3 driver same. Crash logs attached.

Cannot reproduce on previous iOS versions.

gles2.txt
gles3.txt

Follow #32194 remove [self drawView] in layoutSubviews and re-compile can fix crashes when switching to the background (press Home button), but it still crashes when closing in the app switcher.

Hi all. I removed duplicated drawView and moving this part of code
from

- (void)drawView {
    if (useCADisplayLink) {
        // Pause the CADisplayLink to avoid recursion
        [displayLink setPaused:YES];

        // Process all input events
        while (CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.01, TRUE) == kCFRunLoopRunHandledSource)
            ;

        // We are good to go, resume the CADisplayLink
        [displayLink setPaused:NO];
    }

    if (!active) {
        printf("draw view not active!\n");
        return;
    };

to

- (void)drawView {

    if (!active) {
        printf("draw view not active!\n");
        return;
    };

    if (useCADisplayLink) {
        // Pause the CADisplayLink to avoid recursion
        [displayLink setPaused:YES];

        // Process all input events
        while (CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.01, TRUE) == kCFRunLoopRunHandledSource)
            ;

        // We are good to go, resume the CADisplayLink
        [displayLink setPaused:NO];
    }

And crashes is gone. Tested many time and not catched yet.

@ealataur would you make a PR? 😄

@ealataur could you post your diff? It's @justinngdev's patch plus the change you describe here?

Not fixed in the published 3.2 alpha 3 export template.

@gerald1248
This patch for 3.1.1 stable [66baa3b63]
But I think it usable for master too..

patch.diff.zip

@ealataur awesome, thanks!

@ealataur can confirm your patch fixes the issue. Uploading to App Store Connect now. Thanks again! (BTW I could swear I see dropped frames where previously I didn't. Am I missing optimisation flags I should pass to scons when compiling? I simply used scons p=iphone tools=no target=release arch=amd64 and the matching 32-bit variant before creating the universal library.)

A pull request would be welcome so that we can review and hopefully merge the fix.

@ealataur I have rebuilt using optimize=speed but I still observe a serious performance degradation. Happy to believe that I'm not building for iOS correctly, but do you think it's worth checking if the modified CFRunLoopRunInMode call has an impact on frame rate?

@gerald1248
please try change back this
while (CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.01, TRUE) == kCFRunLoopRunHandledSource)
to this
while (CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.0, TRUE) == kCFRunLoopRunHandledSource)

I don't have measurements, but switching back seems to have brought
performance back to a normal level.

On Wed, 30 Oct 2019, 09:21 Max Pestov, notifications@github.com wrote:

@gerald1248 https://github.com/gerald1248
please try change back this
while (CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.01, TRUE) ==
kCFRunLoopRunHandledSource)
to this
while (CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.0, TRUE) ==
kCFRunLoopRunHandledSource)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7966?email_source=notifications&email_token=AAFWFQBYJDXXNYKZTBVLM73QRFGZLA5CNFSM4DCPOT32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECTON6Q#issuecomment-547809018,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFWFQCE5XFYLT2GYVLG6JTQRFGZLANCNFSM4DCPOT3Q
.

@gerald1248
Ok. I will make a commit and pull request

@gerald1248
Ok. I will make a commit and pull request

I have this problem with my game. Is this fix on version 3.2 stable? or do I have to recompile from the latest master? (I actually tried, but the export templates I got gave me errors when exporting).

@ealataur can you please share which export templates you used after you recompiled godot with the fix?

Use one of the later betas: I'm using 3.2b3 and it works fine. Avoid
3.2b1-2 as performance was much worse then. The betas are useful as they
come with precompiled templates.

On Mon, 30 Dec 2019, 05:22 jeudy-ua, notifications@github.com wrote:

@gerald1248 https://github.com/gerald1248
Ok. I will make a commit and pull request

I have this problem with my game. Is this fix on version 3.2 stable? or do
I have to recompile from the latest master? (I actually tried, but the
export templates I got gave me errors when exporting).

@ealataur https://github.com/ealataur can you please share which export
templates you used after you recompiled godot with the fix?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7966?email_source=notifications&email_token=AAFWFQGABAG3YVEOHAOIJSDQ3GAR3A5CNFSM4DCPOT32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHZTMFQ#issuecomment-569587222,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFWFQCLZGDHZIW3QVLHBC3Q3GAR3ANCNFSM4DCPOT3Q
.

Was this page helpful?
0 / 5 - 0 ratings