- Why this is related to pcm_buf?
- I don't understand why the stack has "byte_buffer.h:41 close_dev". I cannot find close_dev in byte_buffer.h. Which close_dev is that?


Thread 0 (id: 23155) CRASHED [SIGABRT @ 0x00000000 ] MAGIC SIGNATURE THREAD
Stack Quality88%Show frame trust levels
0x00007ca666eb6dd2	(libc-2.23.so -raise.c:54 )	raise
0x00007ca666eb8bf5	(libc-2.23.so -abort.c:89 )	abort
0x00007ca666ef8496	(libc-2.23.so -libc_fatal.c:175 )	__libc_message
0x00007ca666efe610	(libc-2.23.so -malloc.c:5004 )	malloc_printerr
0x00007ca666efef14	(libc-2.23.so -malloc.c:3865 )	_int_free
0x0000016a798c6218	(cras -byte_buffer.h:41 )	close_dev
0x0000016a798bf417	(cras -cras_bt_io.c:216 )	close_dev
0x0000016a798e7895	(cras -cras_iodev.c )	cras_iodev_open
0x0000016a798e8db9	(cras -cras_iodev_list.c:427 )	stream_added_cb
0x0000016a798f4aa1	(cras -stream_list.c:88 )	stream_list_add
0x0000016a798ed2d1	(cras -cras_rclient.c:69 )	cras_rclient_message_from_client
0x0000016a798ef0ba	(cras -cras_server.c:129 )	cras_server_run
0x0000016a798d20cf	(cras -cras.c:118 )	main
0x00007ca666ea3735	(libc-2.23.so -libc-start.c:289 )	__libc_start_main
0x0000016a798b99a8	(cras + 0x000089a8 )	_start
0x00007ffd786f67b7		
0x0000016a798b997f	(cras + 0x0000897f )	_init

bt_io use a2dp or hfp device, depending on the active profile:

https://cs.corp.google.com/chromeos_public/src/third_party/adhd/cras/src/server/cras_bt_io.c?q=cras_bt_io.c+package:%5Echromeos_public$&dr=CSs&l=221

It seems that it was using a2dp device, since hfp device does not have byte buffer.

https://cs.corp.google.com/chromeos_public/src/third_party/adhd/cras/src/server/cras_a2dp_iodev.c?dr=CSs&l=217

I don't understand why it shows file name and function name not right either...

Re #1, I guess that's because the byte_buffer_destroy is an inline function so it prints the close_dev as function name.

Played with BT output/input with some bad behaviors and was unable to kill cras.
The problem might be when cras was unable to open a BT device and crashed when closing it. I'll look into the code in close path and see if there's something we didn't catched.

Turns out the use-after-free is when using HFP profile.
hfp_info_destroy calls byte_buffer_destroy, and is called by destroy_audio_gateway which is called in many places.

I'm going to add some logs to catch the bad uses.

I was able to trigger cras hang with the following steps, but it's quite hard to re-pro.

1. Playback youtube to BT headset
2. Select BT headset as input device
3. Use chrome "search by voice" to start BT capture
4. Power off BT headset

This might cause hfp read error in hfp_info_callback, which should stop and close the hfp device. However cras hang there.

I'm wondering it might be a deadlock when hfp_info_stop calls audio_thread_rm_callback_sync while audio thread is executing the hfp_info_callback. But this is so hard to re-pro so it might take some more time to figure out.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/adhd/+/857fac3ed37254e4e90afbd93210c7d1a0f37c75

commit 857fac3ed37254e4e90afbd93210c7d1a0f37c75
Author: Chinyue Chen <chinyue@google.com>
Date: Wed Nov 01 04:49:22 2017

CRAS: byte_buffer - Set buffer pointer to NULL when destroy

There are reports that CRAS crashed in byte_buffer_destroy due to double
free. This patch sets buffer pointer to NULL when byte buffer is
destroyed so it will be easier to detect use-after-free cases.

BUG=chromium:777812
TEST=Tested BT playback/capture on eve.

Change-Id: Icdba45ce321f42987b930ca77d55dd2953671bb7
Reviewed-on: https://chromium-review.googlesource.com/739062
Commit-Ready: Chinyue Chen <chinyue@chromium.org>
Tested-by: Chinyue Chen <chinyue@chromium.org>
Reviewed-by: Wu-Cheng Li <wuchengli@chromium.org>

[modify] https://crrev.com/857fac3ed37254e4e90afbd93210c7d1a0f37c75/cras/src/server/cras_a2dp_iodev.c
[modify] https://crrev.com/857fac3ed37254e4e90afbd93210c7d1a0f37c75/cras/src/server/test_iodev.c
[modify] https://crrev.com/857fac3ed37254e4e90afbd93210c7d1a0f37c75/cras/src/common/byte_buffer.h
[modify] https://crrev.com/857fac3ed37254e4e90afbd93210c7d1a0f37c75/cras/src/server/cras_hfp_info.c
[modify] https://crrev.com/857fac3ed37254e4e90afbd93210c7d1a0f37c75/cras/src/server/dev_stream.c
[modify] https://crrev.com/857fac3ed37254e4e90afbd93210c7d1a0f37c75/cras/src/tests/byte_buffer_unittest.cc
[modify] https://crrev.com/857fac3ed37254e4e90afbd93210c7d1a0f37c75/cras/src/server/cras_loopback_iodev.c