crash in a2dp_suspend_complete() - bluez 5.71

[mdontu]

The following crash happens every few hours with bluez 5.71 while using my Bose QuietComfort 35:

#0  0x0000556a694b2fd7 in a2dp_suspend_complete (session=0x556a69e2d1b0, err=0, user_data=0x556a69de4460) at profiles/audio/transport.c:427
#1  0x0000556a69498866 in finalize_suspend (data=0x556a69e2bdb0) at profiles/audio/a2dp.c:376
#2  0x0000556a6949afb5 in suspend_cfm (session=0x556a69e2d1b0, sep=0x556a69e12910, stream=0x556a69e06950, err=0x0, user_data=0x556a69e128b0) at profiles/audio/a2dp.c:1276
#3  0x0000556a694a7312 in avdtp_suspend_resp (session=0x556a69e2d1b0, stream=0x556a69e06950, data=0x556a69e2d223, size=0) at profiles/audio/avdtp.c:2900
#4  0x0000556a694a7794 in avdtp_parse_resp (session=0x556a69e2d1b0, stream=0x556a69e06950, transaction=10 '\n', signal_id=9 '\t', buf=0x556a69e2d223, size=0) at profiles/audio/avdtp.c:2985
#5  0x0000556a694a58e8 in session_cb (chan=0x556a69e06e90, cond=G_IO_IN, data=0x556a69e2d1b0) at profiles/audio/avdtp.c:2286
#6  0x00007f7e2a0c50ac in g_io_unix_dispatch (source=0x556a69e44dc0, callback=0x556a694a54ef <session_cb>, user_data=0x556a69e2d1b0) at ../glib-2.78.3/glib/giounix.c:170
#7  0x00007f7e2a042729 in g_main_dispatch (context=0x556a69dcf800) at ../glib-2.78.3/glib/gmain.c:3476
#8  0x00007f7e2a043871 in g_main_context_dispatch_unlocked (context=0x556a69dcf800) at ../glib-2.78.3/glib/gmain.c:4284
#9  0x00007f7e2a043a1f in g_main_context_iterate_unlocked (context=0x556a69dcf800, block=1, dispatch=1, self=0x556a69dd6160) at ../glib-2.78.3/glib/gmain.c:4349
#10 0x00007f7e2a043f25 in g_main_loop_run (loop=0x556a69dcf9e0) at ../glib-2.78.3/glib/gmain.c:4551
#11 0x0000556a695b1266 in mainloop_run () at src/shared/mainloop-glib.c:66
#12 0x0000556a695b1852 in mainloop_run_with_signal (func=0x556a694f77bd <signal_callback>, user_data=0x0) at src/shared/mainloop-notify.c:188
#13 0x0000556a694f7deb in main (argc=1, argv=0x7ffcb6286f38) at src/main.c:1452
(gdb) p transport
$2 = (struct media_transport *) 0x556f3f4567e4
(gdb) p *transport
Cannot access memory at address 0x556f3f4567e4

I have not seen these with bluez 5.70 and there is no indication of a problem in syslog.
OS: Gentoo ~amd64 (glibc 2.38, glib 2.78.3, gcc 13.2.1).

[mdontu]

I also have a Fedora 39 with bluez bluez-5.71-2.fc39.x86_64 and just found this issue on Red Hat's bugzilla.

[mdontu]

Here is the debug log from another crash, as extracted from journald.

[Vudentz]

@mdontu could you please check if the above changes does fixes the problem? @silviubarbulescu could also verify if these changes don't break BAP broadcast support in the process?

[silviubarbulescu]

Hi all, we already submitted a patch for this problem. https://patchwork.kernel.org/project/bluetooth/patch/20231219124916.44173-2-vlad.pruteanu@nxp.com/

This patch was already test with broadcast.

[jonas2515]

A bit sad that this made it into the release, I reported it on the mailing list in october (guess I CCed the wrong people though) :/

https://lore.kernel.org/linux-bluetooth/59f3df96-3972-4266-a9ff-14c21af15c47@v0yd.nl/

[Vudentz]

Hi all, we already submitted a patch for this problem. https://patchwork.kernel.org/project/bluetooth/patch/20231219124916.44173-2-vlad.pruteanu@nxp.com/

This patch was already test with

Release is not meant to check the type of the stream, thus why Ive made it into the suspend_bap, but we might as well have proper callbacks for broadcast instead.

[mdontu-bd]

The above patch (link) appears to resolve the issue.

[ainxp]

@Vudentz I confirm the updates in https://github.com/BluezTestBot/bluez/commits/814200 do no break BAP broadcast (tested both source and sink). As a side note, the tests were performed on 81420 branch + multiple BISes patch (this will be submitted today) on top.
@mdontu the updates in https://github.com/BluezTestBot/bluez/commits/814200 also should include a fix for this issue. The patch you tested (link) is obsoleted.