Android crash

Questions
#1

My game is having intermittent crashes on Android, seemingly unrelated to anything specific in the game. I haven’t been able to get a logcat of these, until just now.

Unfortunately the errors are not making much sense to me. Possible culprits are:

2020-10-21 19:41:14.631 26207-26272/com.winkelgames.juump A/libc: ../src/sound.cpp:938: void dmSound::MixResampleUpStereo(const dmSound::MixContext *, dmSound::SoundInstance *, uint32_t, uint32_t, float *, uint32_t) [T = short, offset = 0, scale = 1]: assertion "prev_index <= instance->m_FrameCount" failed

And:

2020-10-21 19:41:15.117 26207-26272/com.winkelgames.juump I/defold: INFO:CRASH: Successfully wrote Crashdump to file: /data/user/0/com.winkelgames.juump/files/_crash
2020-10-21 19:41:15.117 26207-26272/com.winkelgames.juump E/defold: ERROR:CRASH: CALL STACK:
    
    # 0 pc        0x5bc [vdso] <unknown>+0
    # 1 pc      0x13174 ...oid.runtime/lib64/bionic/libc.so abort+164
2020-10-21 19:41:15.188 880-976/? D/VSC: @ 180661.246: [WO] tilt angle 89
2020-10-21 19:41:15.189 1530-1965/? W/InputDispatcher: channel '991dbd2 com.winkelgames.juump/com.dynamo.android.DefoldActivity (server)' ~ Consumer closed input channel or an error occurred.  events=0xd
2020-10-21 19:41:15.189 1530-1965/? E/InputDispatcher: channel '991dbd2 com.winkelgames.juump/com.dynamo.android.DefoldActivity (server)' ~ Channel is unrecoverably broken and will be disposed!

A more extensive log: logcat debug crash.txt (238.9 KB)

Could anything be gleaned from these messages? I would be very grateful for any help that can bring me closer to a fix. :pray:

#2

When do the crashes happen? At startup? Completely at random? Can something be linked to the crashes in some way? Incoming push/local notification? System callback of some kind?

#3

Unfortunately it appears randomly, but always when in game. Nothing unusual appears to be happening that triggers it, just a sudden force close without a warning. We haven’t seen this on iOS.

#4

The first crash mentions sounds. Try running the game with the sounds disabled (either don’t play them or use the app manifest to exclude the sounds system).

2 Likes
#5

Good plan, will try that. I forgot to post a video of the crash above:

ps. I’m using this code to catch crashes:

local function handle_previous_session_crash()

	local handle = crash.load_previous()
	if handle then

		local str = ""

		-- Backtrace
		local backtrace = crash.get_backtrace(handle)
		if backtrace then
			for k,v in pairs(backtrace) do
				str = str .. tostring(k) .. ": " .. tostring(v) .. "\n"
			end
		end

		-- Extra data
		local extra_data = crash.get_extra_data(handle)
		if extra_data then
			str = str .. extra_data
		end
		
		if gameanalytics then
			gameanalytics.addErrorEvent {
				severity = "Critical",
				message = str
			}
		end
		
		crash.release(handle)

	end

end

In case of the crash above, it results in this:

56
Screenshot 2020-10-22 at 08.56.56.png1338×216 15.2 KB

Is there a way to squeeze more information out somehow? Maybe by iterating through the 0x784[…], if they are actually tables?

#6

It only lists the main thread there. I would recommend looking at the logcat.
And when I look through your logcat, I see this:

2020-10-21 19:41:14.631 26207-26272/com.winkelgames.juump A/libc: …/src/sound.cpp:938: void dmSound::MixResampleUpStereo(const dmSound::MixContext *, dmSound::SoundInstance *, uint32_t, uint32_t, float *, uint32_t) [T = short, offset = 0, scale = 1]: assertion “prev_index <= instance->m_FrameCount” failed

I’m not really sure why that would fail.
Recent changes are ofc adding support for sound speed, and threading.
Are you using sound speeds other than 1?

The other thing I can think of is that if the sound data somehow isn’t thread safe. Are the crashes occurring while some collection proxy is unloaded?

1 Like
#7

No, all sounds are played as is.

The crashes only seem to happen in game, and during gameplay no collection proxies are loaded/unloaded.

My first thought was a memory leak, but I haven’t been able to produce any every increasing numbers when testing.

I’ll do a sound stress test to see if that can nudge us closer to that holy grail that is a repro project.

Update: A stress test playing playing all sounds in the game at random (up to 32 simultaneous sounds) at the same time as continuously loading/unloading a collection proxy (using Monarch, like the game) doesn’t cause a crash.

It throws this warning every now and then, though:
ERROR:DLIB: …/src/dlib/socket.cpp( 109 ): SOCKET: Unknown result code 1
WARNING:DLIB: Failed to send announce message (-1000)

1 Like
#8

Please also test without sound in the game and see if you can get it to crash. Create an app manifest with sound excluded: https://britzl.github.io/manifestation/

1 Like
#9

I built two versions of the game; one excluding sound in the manifest and one with sound kept in. Same code base - the manifest was the only difference.

After, literally, hours worth of playing I was not able to crash the one without sound. I was able to crash the one with sound after 20 minutes or so: logcat.txt

Both builds were tested on the same phone, Pixel 5.

2 Likes
#10

And the same assert is triggered in the sound.cpp:

2020-10-22 14:19:14.831 21658-21727/com.winkelgames.juump A/libc: …/src/sound.cpp:938: void dmSound::MixResampleUpStereo(const dmSound::MixContext *, dmSound::SoundInstance *, uint32_t, uint32_t, float *, uint32_t) [T = short, offset = 0, scale = 1]: assertion “prev_index <= instance->m_FrameCount” failed

It’s unfortunate that it’s so hard to reproduce though.
But please register this as a bug in the issue github repo!

2 Likes
#11

Done! https://github.com/defold/defold/issues/5289

Update: I found the cause of the crash! Please see updated Github issue above.

2 Likes
#12

Is there a planned fix for this crash bug?

It affects the Android build of our game, because all players risk getting a crash when a sound is stopped. If you play for long enough, a crash is virtually guaranteed, which is not ideal.

#13

Yes, it is planned but not implemented yet. We’re delaying the stable release by one day to verify a fix for an Android lifecycle crash (https://github.com/defold/defold/issues/5279). BUT we will not have time to also fix this issue. It will unfortunately have to wait until 1.2.176.

1 Like
#14

@totebo a possible solution for now is to use the new option in 1.2.175 to disable the sound thread (if that is what is causing the problem you are experiencing):

1 Like
#15

Okay. It’s still great to know it will be fixed!

Nice one, will try this and report back!

Defold 1.2.176 has been released