App crashing when re-opening fast

Lex · October 20, 2021, 11:10am

Hello,
Using Defold 1.2.188-beta, iOS 14.7.1

Encountering a weird issue:

Open app
Close it 1 second after open
Re-open app
App crashes with logs:

Thread 0 Crashed:
0   libsystem_kernel.dylib        	0x00000001c3051b54 __semwait_signal + 8
1   libsystem_c.dylib             	0x000000019fe1fab4 nanosleep + 212
2   libsystem_c.dylib             	0x000000019fe1f98c usleep + 64
3   Mygame                  		dmDeviceOpenAL::DeviceOpenALClose(void*) (in Mygame) (device_openal.cpp:137)
4   Mygame                  		dmSound::Finalize() (in Mygame) (sound.cpp:450)
5   Mygame                  		dmEngine::Delete(dmEngine::Engine*) (in Mygame) (engine.cpp:289)
6   Mygame                  		ShutdownEngine (in Mygame) (AppDelegate.m:133)
7   CoreFoundation                	0x00000001971efa10 __invoking___ + 144
8   CoreFoundation                	0x00000001970d1720 -[NSInvocation invoke] + 300
9   CoreFoundation                	0x00000001970d1c84 -[NSInvocation invokeWithTarget:] + 76

Strange thing is, it doesn’t happen when re-open the app after a longer time (~10 seconds). It seems that sounds are not closing properly when closing the app quickly after open.

Has anyone encountered this?

britzl · October 20, 2021, 11:59am

Interesting. We did make a few changes recently to avoid crashes if the sound device failed to creation, but I believe this is something else.

Thank you for also creating an issue on GH (https://github.com/defold/defold/issues/6116). I asked a follow-up question there.

Lex · October 20, 2021, 8:08pm

OK I’m experimenting this exactly:

Some asynchronous activity is not being properly terminated in the backrgound. I suspect it has to do with the sound but I could be wrong.

Here is the complete crashlog:

My guess (but I could be wrong) is this sleep() function hanging up the app:

github.com

defold/defold/blob/1ae302ec33d4514408c04ad3ae5d3c1efe2057bd/engine/sound/src/devices/device_openal.cpp#L135

    
      
                  alSourceUnqueueBuffers(openal->m_Source, 1, &buffer);
                  CheckAndPrintError();
                  openal->m_Buffers.Push(buffer);
                  --processed;
              }
          
          
    if ((iter + 1) % 10 == 0) {
                  dmLogInfo("Waiting for OpenAL device to complete");
              }
              ++iter;
              dmTime::Sleep(10 * 1000);
          
          
    if (iter > 1000) {
                  dmLogError("Still buffers in OpenAL. Bailing.");
              }
          }
          
          
alSourceStop(openal->m_Source);
          alDeleteSources(1, &openal->m_Source);
          
          
alDeleteBuffers(openal->m_Buffers.Size(), openal->m_Buffers.Begin());

Lex · October 20, 2021, 7:16pm

OK it gets even weirder:
In my current app, I get this problem only when downloaded from testflight.
If I build the app in debug OR in release, with a developer identity:

I open the app
After 1s I close it and kill it
I open it back, everything works

On my testflight app:

I open the app
After 1s I close it and kill it
I open it back, 0x"badfood" 0x8BADF00D crash (see blog article above).

Any pointer? I’m slowly losing my mind here

britzl · October 20, 2021, 8:53pm

No idea really. Is TestFlight modifying the app somehow?

In any case, we’ll look into this ourselves as well.

Lex · October 20, 2021, 8:55pm

I’m thinking, maybe if the app is from the store/testflight, the watchdog (the one mentioned related to the “badfood” crash) gets activated. I’m only guessing though.

Lex · October 23, 2021, 10:48am

OK, turns out my app does crash also locally (ie. not from TestFlight). The crash happens when opening back the app, and the app restarts automatically, so it just looks like the app takes longer to open, whereas it’s actually crashing (I can see from the device logs).