Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crash in audio.c #26

Closed
juha-h opened this issue Aug 21, 2018 · 2 comments
Closed

crash in audio.c #26

juha-h opened this issue Aug 21, 2018 · 2 comments
Labels

Comments

@juha-h
Copy link
Collaborator

juha-h commented Aug 21, 2018

Sometimes upon call close, I get crash in aurx_stream_decode() function of audio.c:

********** Crash dump: **********
Build fingerprint: 'motorola/harpia/harpia:7.1.1/NPIS26.48-43-2/3:user/release-keys'
pid: 9475, tid: 9516, name: Thread-2  >>> com.tutpro.baresip <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xb5b5b5c1
Stack frame #00 pc 00074808  /data/app/com.tutpro.baresip-2/lib/arm/libbaresip.so: Routine aurx_stream_decode at /usr/src/baresip-android/baresip/src/audio.c:787

The line in question is the last one here:

	/* Process exactly one audio-frame in reverse list order */
	for (le = rx->filtl.tail; le; le = le->prev) {
		struct aufilt_dec_st *st = le->data;

I wonder if the location really is the one shown, but if it is, any idea why the crash might happen?

@juha-h
Copy link
Collaborator Author

juha-h commented Aug 22, 2018

Forgot to mention that the crash happens after the call has been closed:

08-22 07:35:06.899 32601 32601 D Baresip : ua event (CALL_CLOSED) OK
08-22 07:35:06.904 32601 32619 D Baresip : sip:jh@test.tutpro.com: Call with sip:test@test.tutpro.com terminated (duration: 4 sec)
08-22 07:35:06.907 32601 32618 F libc    : Fatal signal 11 (SIGSEGV), code 1, fault addr 0xb5b5b5c1 in tid 32618 (Thread-2)

and does not happen with all calls. I have not seen it with calls over the same LAN, but only with some "long distance" calls that have longer delays and where signaling and audio go over different paths (audio involves media relay). This may mean that some audio packets arrive after the call has been closed and cause the crash.

@juha-h
Copy link
Collaborator Author

juha-h commented Aug 23, 2018

I found from stackoverflow a function that can be used to test (on Android) if pointer is valid. I added the function (isValidPtr) to audio.c and used it to test le in audio.c/ aurx_stream_decode():

	/* Process exactly one audio-frame in reverse list order */
	for (le = rx->filtl.tail; le; le = le->prev) {
		struct aufilt_dec_st *st;
		if (isValidPtr(le, 4) == 0) {
			warning("audio: le is NOT valid pointer\n");
		} else {
			info("audio: le is valid pointer\n");
		}
		st = le->data;

And yes, when crash happens the pointer test fails:

08-23 10:26:09.945  3334  3361 D Baresip : sip:jh@test.tutpro.com: Call with sip:test@test.tutpro.com terminated (duration: 1 sec)
08-23 10:26:09.950  3334  3361 D Baresip : audio: le is NOT valid pointer
08-23 10:26:09.951  3334  3360 F libc    : Fatal signal 11 (SIGSEGV), code 1, fault addr 0xb5b5b5c1 in tid 3360 (Thread-2)

This seems to prove that the crash really happens in audio.c and that there is a bug somewhere in baresip code. I'll move this to issue to baresip-android to baresip, since I don't think that the bug is android specific.

@juha-h juha-h closed this as completed Aug 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant