Cmus hangs when paused for a long time #6
Comments
|
Are you using USB audio? Perhaps it's caused by USB autosuspend? |
Thanks for the suggestion, but no, I also tested it with the regular jack output and the same happens. From what discussions I could find online, it may have to do with something called "stream drain", I saw two versions (pull requests) for a fix, but It seems they haven't made their way into the repo we're installing from, or that wasn't the issue. |
|
Do you have links to those pull requests? |
|
Yes, here you go: |
mmstick
pushed a commit
that referenced
this issue
Jun 9, 2022
… is destroyed
Previously, the resource listener was not removed when
the `node_data` object was freed, which could lead to
a use-after-free when the resource emitted an event
later.
==2787072==ERROR: AddressSanitizer: heap-use-after-free on address 0x61d000016728 at pc 0x7ffff7175b52 bp 0x7fffffffb930 sp 0x7fffffffb920
WRITE of size 8 at 0x61d000016728 thread T0
#0 0x7ffff7175b51 in spa_list_remove ../spa/include/spa/utils/list.h:77
#1 0x7ffff717cb5a in pw_resource_destroy ../src/pipewire/resource.c:335
#2 0x7ffff7051c56 in pw_global_destroy ../src/pipewire/global.c:417
#3 0x7ffff6f82a68 in registry_destroy ../src/pipewire/impl-core.c:130
#4 0x7ffff3a5f349 in registry_demarshal_destroy ../src/modules/module-protocol-native/protocol-native.c:784
#5 0x7ffff3a2c9ed in process_messages ../src/modules/module-protocol-native.c:352
#6 0x7ffff3a2e2ea in connection_data ../src/modules/module-protocol-native.c:423
#7 0x7ffff3e09402 in source_io_func ../spa/plugins/support/loop.c:427
#8 0x7ffff3e0851d in loop_iterate ../spa/plugins/support/loop.c:409
#9 0x7ffff709c21d in pw_main_loop_run ../src/pipewire/main-loop.c:148
#10 0x555555559722 in main ../src/daemon/pipewire.c:131
#11 0x7ffff62a528f (/usr/lib/libc.so.6+0x2928f)
#12 0x7ffff62a5349 in __libc_start_main (/usr/lib/libc.so.6+0x29349)
#13 0x5555555582a4 in _start (./src/daemon/pipewire+0x42a4)
0x61d000016728 is located 2216 bytes inside of 2264-byte region [0x61d000015e80,0x61d000016758)
freed by thread T0 here:
#0 0x7ffff798c672 in __interceptor_free /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:52
#1 0x7ffff70f9bc3 in pw_impl_node_destroy ../src/pipewire/impl-node.c:1880
#2 0x7ffff70d1d57 in global_destroy ../src/pipewire/impl-node.c:638
#3 0x7ffff7051a4f in pw_global_destroy ../src/pipewire/global.c:414
#4 0x7ffff6f82a68 in registry_destroy ../src/pipewire/impl-core.c:130
#5 0x7ffff3a5f349 in registry_demarshal_destroy ../src/modules/module-protocol-native/protocol-native.c:784
#6 0x7ffff3a2c9ed in process_messages ../src/modules/module-protocol-native.c:352
#7 0x7ffff3a2e2ea in connection_data ../src/modules/module-protocol-native.c:423
#8 0x7ffff3e09402 in source_io_func ../spa/plugins/support/loop.c:427
#9 0x7ffff3e0851d in loop_iterate ../spa/plugins/support/loop.c:409
#10 0x7ffff709c21d in pw_main_loop_run ../src/pipewire/main-loop.c:148
#11 0x555555559722 in main ../src/daemon/pipewire.c:131
#12 0x7ffff62a528f (/usr/lib/libc.so.6+0x2928f)
previously allocated by thread T0 here:
#0 0x7ffff798d411 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77
#1 0x7ffff70e5bb7 in pw_context_create_node ../src/pipewire/impl-node.c:1192
#2 0x7ffff28c748e in pw_spa_node_new ../src/modules/spa/spa-node.c:112
#3 0x7ffff28c9a9f in pw_spa_node_load ../src/modules/spa/spa-node.c:276
#4 0x7ffff28c1618 in create_object ../src/modules/spa/module-node-factory.c:134
#5 0x7ffff7106c4e in pw_impl_factory_create_object ../src/pipewire/impl-factory.c:273
#6 0x7ffff6f86dd7 in core_create_object ../src/pipewire/impl-core.c:349
#7 0x7ffff3a5cba9 in core_method_demarshal_create_object ../src/modules/module-protocol-native/protocol-native.c:680
#8 0x7ffff3a2c9ed in process_messages ../src/modules/module-protocol-native.c:352
#9 0x7ffff3a2e2ea in connection_data ../src/modules/module-protocol-native.c:423
#10 0x7ffff3e09402 in source_io_func ../spa/plugins/support/loop.c:427
#11 0x7ffff3e0851d in loop_iterate ../spa/plugins/support/loop.c:409
#12 0x7ffff709c21d in pw_main_loop_run ../src/pipewire/main-loop.c:148
#13 0x555555559722 in main ../src/daemon/pipewire.c:131
#14 0x7ffff62a528f (/usr/lib/libc.so.6+0x2928f)
SUMMARY: AddressSanitizer: heap-use-after-free ../spa/include/spa/utils/list.h:77 in spa_list_remove
mmstick
pushed a commit
that referenced
this issue
Jun 9, 2022
Register a pthread cleanup handler to guarantee
that `spa_source::{priv, rmask}` are cleared even
if the thread is cancelled while the loop is dispatching.
This is necessary, otherwise `spa_source::priv` could point
to the stack of the cancelled thread, which will lead to
problems like this later:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f846b025be2 in detach_source (source=0x7f845f435f60) at ../spa/plugins/support/loop.c:144
144 e->data = NULL;
[Current thread is 1 (LWP 5274)]
(gdb) p e
$1 = (struct spa_poll_event *) 0x7f845e297820
(gdb) bt
#0 0x00007f846b025be2 in detach_source (source=0x7f845f435f60) at ../spa/plugins/support/loop.c:144
#1 0x00007f846b0276ad in free_source (s=0x7f845f435f60) at ../spa/plugins/support/loop.c:359
#2 0x00007f846b02a453 in loop_destroy_source (object=0x7f845f3af478, source=0x7f845f435f60) at ../spa/plugins/support/loop.c:786
#3 0x00007f846b02a886 in impl_clear (handle=0x7f845f3af478) at ../spa/plugins/support/loop.c:859
#4 0x00007f846b172f40 in unref_handle (handle=0x7f845f3af450) at ../src/pipewire/pipewire.c:211
#5 0x00007f846b173579 in pw_unload_spa_handle (handle=0x7f845f3af478) at ../src/pipewire/pipewire.c:346
#6 0x00007f846b15a761 in pw_loop_destroy (loop=0x7f845f434e30) at ../src/pipewire/loop.c:159
#7 0x00007f846b135d8e in pw_data_loop_destroy (loop=0x7f845f434cb0) at ../src/pipewire/data-loop.c:166
#8 0x00007f846b12c31c in pw_context_destroy (context=0x7f845f41c690) at ../src/pipewire/context.c:485
#9 0x00007f846b3ddf9e in jack_client_close (client=0x7f845f3c1030) at ../pipewire-jack/src/pipewire-jack.c:3481
...
mmstick
pushed a commit
that referenced
this issue
Jul 1, 2022
`client::name` points to a string that is owned by `client::props`,
so when the property list is updated, it needs to be refreshed as well.
Otherwise, various use-after-frees can be triggered, for example:
==1471586==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200007e7d0 at pc 0x7f14390755d0 bp 0x7ffe23edee30 sp 0x7ffe23ede5a8
READ of size 3 at 0x60200007e7d0 thread T0
#0 0x7f14390755cf in printf_common /usr/src/debug/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:553
#1 0x7f1439077215 in __interceptor_vsnprintf /usr/src/debug/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1665
#2 0x7f1434ead47d in spa_vscnprintf ../spa/include/spa/utils/string.h:239
#3 0x7f1434eae2ae in impl_log_logtv ../spa/plugins/support/logger.c:138
#4 0x7f14385cacc7 in pw_log_logt ../src/pipewire/log.c:135
#5 0x7f1433aef8e9 in do_set_profile ../src/modules/module-protocol-pulse/pulse-server.c:4656
#6 0x7f1433b0af4d in handle_packet ../src/modules/module-protocol-pulse/server.c:109
#7 0x7f1433b0e747 in do_read ../src/modules/module-protocol-pulse/server.c:276
#8 0x7f1433b0eb04 in on_client_data ../src/modules/module-protocol-pulse/server.c:306
#9 0x7f1434ec56a0 in source_io_func ../spa/plugins/support/loop.c:442
#10 0x7f1434ec4a21 in loop_iterate ../spa/plugins/support/loop.c:430
#11 0x7f14385dc23d in pw_main_loop_run ../src/pipewire/main-loop.c:148
#12 0x55b065d73722 in main ../src/daemon/pipewire.c:131
#13 0x7f143742928f (/usr/lib/libc.so.6+0x2928f)
#14 0x7f1437429349 in __libc_start_main (/usr/lib/libc.so.6+0x29349)
#15 0x55b065d722a4 in _start (./src/daemon/pipewire-pulse+0x42a4)
0x60200007e7d0 is located 0 bytes inside of 16-byte region [0x60200007e7d0,0x60200007e7e0)
freed by thread T0 here:
#0 0x7f14390be672 in __interceptor_free /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:52
#1 0x7f14386a775a in do_replace ../src/pipewire/properties.c:414
#2 0x7f14386a785e in pw_properties_set ../src/pipewire/properties.c:441
#3 0x7f14386a658b in pw_properties_update ../src/pipewire/properties.c:309
#4 0x7f1433adb055 in do_update_proplist ../src/modules/module-protocol-pulse/pulse-server.c:3246
#5 0x7f1433b0af4d in handle_packet ../src/modules/module-protocol-pulse/server.c:109
#6 0x7f1433b0e747 in do_read ../src/modules/module-protocol-pulse/server.c:276
#7 0x7f1433b0eb04 in on_client_data ../src/modules/module-protocol-pulse/server.c:306
#8 0x7f1434ec56a0 in source_io_func ../spa/plugins/support/loop.c:442
#9 0x7f1434ec4a21 in loop_iterate ../spa/plugins/support/loop.c:430
#10 0x7f14385dc23d in pw_main_loop_run ../src/pipewire/main-loop.c:148
#11 0x55b065d73722 in main ../src/daemon/pipewire.c:131
#12 0x7f143742928f (/usr/lib/libc.so.6+0x2928f)
previously allocated by thread T0 here:
#0 0x7f1439072faa in __interceptor_strdup /usr/src/debug/gcc/libsanitizer/asan/asan_interceptors.cpp:439
#1 0x7f14386a6fe2 in do_replace ../src/pipewire/properties.c:394
#2 0x7f14386a785e in pw_properties_set ../src/pipewire/properties.c:441
#3 0x7f1433a6c52d in read_props ../src/modules/module-protocol-pulse/message.c:147
#4 0x7f1433a6f467 in message_get ../src/modules/module-protocol-pulse/message.c:359
#5 0x7f1433ab3191 in do_set_client_name ../src/modules/module-protocol-pulse/pulse-server.c:1030
#6 0x7f1433b0af4d in handle_packet ../src/modules/module-protocol-pulse/server.c:109
#7 0x7f1433b0e747 in do_read ../src/modules/module-protocol-pulse/server.c:276
#8 0x7f1433b0eb04 in on_client_data ../src/modules/module-protocol-pulse/server.c:306
#9 0x7f1434ec56a0 in source_io_func ../spa/plugins/support/loop.c:442
#10 0x7f1434ec4a21 in loop_iterate ../spa/plugins/support/loop.c:430
#11 0x7f14385dc23d in pw_main_loop_run ../src/pipewire/main-loop.c:148
#12 0x55b065d73722 in main ../src/daemon/pipewire.c:131
#13 0x7f143742928f (/usr/lib/libc.so.6+0x2928f)
mmstick
pushed a commit
that referenced
this issue
Dec 30, 2022
It is not enough for `buffer` to be alive in its current
scope because when execution enters that branch, `format`
will be set to `fmt`, which points inside `buffer`. And
since `format` is used outside that scope, `buffer` must
live longer.
This was detected by ASAN when Audacity was starting up.
==25007==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffdbcfef560 at pc 0x7fe44ca95db3 bp 0x7ffdbcfeeda0 sp 0x7ffdbcfeed90
READ of size 4 at 0x7ffdbcfef560 thread T0
#0 0x7fe44ca95db2 in spa_pod_parser_pod ../spa/include/spa/pod/parser.h:67
#1 0x7fe44ca9a805 in spa_format_parse ../spa/include/spa/param/format-utils.h:44
#2 0x7fe44cad293a in port_set_format ../spa/plugins/audioconvert/audioconvert.c:1934
#3 0x7fe44cadad14 in impl_node_port_set_param ../spa/plugins/audioconvert/audioconvert.c:2038
#4 0x7fe44ca587e2 in configure_format ../spa/plugins/audioconvert/audioadapter.c:509
#5 0x7fe44ca60dff in negotiate_format ../spa/plugins/audioconvert/audioadapter.c:822
#6 0x7fe44ca62bbf in impl_node_send_command ../spa/plugins/audioconvert/audioadapter.c:846
#7 0x7fe45ea1c2f1 in node_update_state ../src/pipewire/impl-node.c:407
#8 0x7fe45ea5137e in pw_impl_node_set_state ../src/pipewire/impl-node.c:2251
#9 0x7fe45eb3355f in pw_work_queue_destroy ../src/pipewire/work-queue.c:142
#10 0x7fe45b2cd6f4 in source_event_func ../spa/plugins/support/loop.c:615
#11 0x7fe45b2c634f in loop_iterate ../spa/plugins/support/loop.c:452
#12 0x7fe45e9ebebc in spa_hook_list_clean ../spa/include/spa/utils/hook.h:395
#13 0x5561e03dc722 in main ../src/daemon/pipewire.c:131
#14 0x7fe45da3c28f (/usr/lib/libc.so.6+0x2328f)
#15 0x7fe45da3c349 in __libc_start_main (/usr/lib/libc.so.6+0x23349)
#16 0x5561e03db2a4 in _start ../sysdeps/x86_64/start.S:115
Address 0x7ffdbcfef560 is located in stack of thread T0 at offset 160 in frame
#0 0x7fe44ca56fa9 in configure_format ../spa/plugins/audioconvert/audioadapter.c:475
This frame has 4 object(s):
[32, 36) 'state' (line 493)
[48, 56) 'fmt' (line 494)
[80, 128) 'b' (line 492)
[160, 4256) 'buffer' (line 491) <== Memory access at offset 160 is inside this variable
mmstick
pushed a commit
that referenced
this issue
Aug 9, 2023
Fix the following misaligned access that happens when `pw-top` is started:
../src/modules/module-profiler.c:144:5: runtime error: member access within misaligned address 0x7f7fa11fe8d9 for type 'struct spa_pod_struct', which requires 4 byte alignment
0x7f7fa11fe8d9: note: pointer points here
60 00 00 01 00 00 00 00 00 00 00 00 88 02 00 00 0f 00 00 00 0a 00 04 00 00 00 00 00 01 00 01 00
^
#0 0x7f7fa64a65e1 in do_flush_event ../src/modules/module-profiler.c:144
#1 0x7f7fa36d658e in source_event_func ../spa/plugins/support/loop.c:650
#2 0x7f7fa36cfbab in loop_iterate ../spa/plugins/support/loop.c:483
#3 0x7f7fa80a71cd in pw_main_loop_run ../src/pipewire/main-loop.c:128
#4 0x55af46ff4722 in main ../src/daemon/pipewire.c:111
#5 0x7f7fa8a3984f (/usr/lib/libc.so.6+0x2384f) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e)
#6 0x7f7fa8a39909 in __libc_start_main (/usr/lib/libc.so.6+0x23909) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e)
#7 0x55af46ff32a4 in _start (src/daemon/pipewire+0x42a4) (BuildId: 2d6250e405f52fb86992fef8584ccfdfdb85569f)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/modules/module-profiler.c:144:5 in
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Since pop! os 22.04, if you pause cmus, exiting takes a long time. Also, if cmus stays paused for a long time, it hangs if you want to resume playing or skip directly to the next song. This seems to be a pipewire isssue.
The text was updated successfully, but these errors were encountered: