RustAudio
Occasional crashes using ALSA backend input stream via default input device with max channels
Sometimes it just exits with Command terminated, while other times crashing with an error that seems to originate from pulseaudio (perhaps pulseaudio is the default on my system):
Assertion 'p->write.current->type == PA_PSTREAM_ITEM_MEMBLOCK' failed at pulsecore/pstream.c:633, function prepare_next_write_item(). Aborting.
To be fair I'm trying to retrieve input from all available input channels (which in pulseaudio's case is 32) as i'm testing a spatial audio server for a large multi-channel installation. I can easily work around this by only working with stereo but it would be nice to investigate why this occurs and see if we can produce a more reasonable error message than a seemingly random segfault.
Managed to get a new error this time - just recording it here for the record:
Assertion '!e->next' failed at pulsecore/queue.c:104, function pa_queue_pop(). Aborting.
Another:
Assertion 'pa_atomic_load(&(p)->_ref) >= 1' failed at pulsecore/packet.c:95, function pa_packet_data(). Aborting.
This generally seems to be caused by some sort of race condition between CPAL's desire to use ALSA devices directly while pulseaudio is already running with exlcusive access to ALSA. Will try disabling pulseaudio next time I get the chance and testing if this stops all of these issues.
Hey, I think I have the same issue.
I don't have debug symbols for pulse on my system (damn ubuntu). I'll need to figure out how to setup the debugging environment and to not ruin my work setup. I can't go full on with debugging this on my main system, but I don't have other machines at hand currently. Any ideas?
For some reason I was thinking that even though cpal is trying to use ALSA it really talks to some kind of pulseaudio frontend that provides ALSA interface, instead of the real thing.
valgrind output
Linux mozgiii-pc 4.18.0-16-generic #17~18.04.1-Ubuntu SMP Tue Feb 12 13:35:51 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
==9314== Memcheck, a memory error detector
==9314== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9314== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==9314== Command: ./target/debug/examples/crash
==9314==
==9314== Invalid write of size 8
==9314== at 0x4C367E3: memmove (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9314== by 0x9684359: ??? (in /usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_pulse.so)
==9314== by 0x4ECF9F7: ??? (in /usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==9314== by 0x4E909C4: ??? (in /usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==9314== by 0x4ED06AA: ??? (in /usr/lib/x86_64-linux-gnu/libasound.so.2.0.0)
==9314== by 0x13876C: cpal::cpal_impl::EventLoop::run_inner (mod.rs:552)
==9314== by 0x1111F2: cpal::cpal_impl::EventLoop::run (mod.rs:408)
==9314== by 0x113590: cpal::EventLoop::run (lib.rs:495)
==9314== by 0x115FEC: crash::main (crash.rs:10)
==9314== by 0x1150BF: std::rt::lang_start::{{closure}} (rt.rs:64)
==9314== by 0x14A692: {{closure}} (rt.rs:49)
==9314== by 0x14A692: std::panicking::try::do_call (panicking.rs:297)
==9314== by 0x14C5E9: __rust_maybe_catch_panic (lib.rs:92)
==9314== Address 0x61d8408 is 0 bytes after a block of size 26,104 alloc'd
==9314== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9314== by 0x13A77B: alloc::alloc::alloc (alloc.rs:72)
==9314== by 0x13A561: <alloc::alloc::Global as core::alloc::Alloc>::alloc (alloc.rs:148)
==9314== by 0x12594B: <alloc::raw_vec::RawVec<T, A>>::reserve_internal (raw_vec.rs:669)
==9314== by 0x12AF31: <alloc::raw_vec::RawVec<T, A>>::reserve (raw_vec.rs:492)
==9314== by 0x12E071: <alloc::vec::Vec<T>>::reserve (vec.rs:460)
==9314== by 0x1308D1: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::spec_extend (vec.rs:1852)
==9314== by 0x131142: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::from_iter (vec.rs:1839)
==9314== by 0x131690: <alloc::vec::Vec<T> as core::iter::traits::FromIterator<T>>::from_iter (vec.rs:1725)
==9314== by 0x13BE36: core::iter::iterator::Iterator::collect (iterator.rs:1468)
==9314== by 0x1386D9: cpal::cpal_impl::EventLoop::run_inner (mod.rs:549)
==9314== by 0x1111F2: cpal::cpal_impl::EventLoop::run (mod.rs:408)
==9314==
valgrind: m_mallocfree.c:280 (mk_plain_bszB): Assertion 'bszB != 0' failed.
valgrind: This is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap metadata. If you fix any
invalid writes reported by Memcheck, this assertion failure will
probably go away. Please try that before reporting this as a bug.
host stacktrace:
==9314== at 0x580441BA: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==9314== by 0x580442D4: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==9314== by 0x58044459: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==9314== by 0x580531EC: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==9314== by 0x5800BA84: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==9314== by 0x5800BC66: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==9314== by 0x5809F785: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==9314== by 0x580AED50: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==9314== by 0x580AF03A: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==9314== by 0x580DA89D: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==9314== by 0xDEADBEEFDEADBEEE: ???
==9314== by 0xDEADBEEFDEADBEEE: ???
==9314== by 0xDEADBEEFDEADBEEE: ???
sched status:
running_tid=2
Thread 1: status = VgTs_WaitSys (lwpid 9314)
==9314== at 0x5A9ABF9: poll (poll.c:29)
==9314== by 0x13808D: cpal::cpal_impl::EventLoop::run_inner (mod.rs:470)
==9314== by 0x1111F2: cpal::cpal_impl::EventLoop::run (mod.rs:408)
==9314== by 0x113590: cpal::EventLoop::run (lib.rs:495)
==9314== by 0x115FEC: crash::main (crash.rs:10)
==9314== by 0x1150BF: std::rt::lang_start::{{closure}} (rt.rs:64)
==9314== by 0x14A692: {{closure}} (rt.rs:49)
==9314== by 0x14A692: std::panicking::try::do_call (panicking.rs:297)
==9314== by 0x14C5E9: __rust_maybe_catch_panic (lib.rs:92)
==9314== by 0x14B1E5: try<i32,closure> (panicking.rs:276)
==9314== by 0x14B1E5: catch_unwind<closure,i32> (panic.rs:388)
==9314== by 0x14B1E5: std::rt::lang_start_internal (rt.rs:48)
==9314== by 0x115098: std::rt::lang_start (rt.rs:64)
==9314== by 0x116049: main (in /home/mozgiii/Desktop/cpal/target/debug/examples/crash)
Thread 2: status = VgTs_Runnable (lwpid 9316)
==9314== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9314== by 0x59B2456: __gconv_lookup_cache (gconv_cache.c:366)
==9314== by 0x59A9AF1: __gconv_find_transform (gconv_db.c:737)
==9314== by 0x59A8657: __gconv_open (gconv_open.c:109)
==9314== by 0x59A815D: iconv_open (iconv_open.c:71)
==9314== by 0x697EB74: ??? (in /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-11.1.so)
==9314== by 0x6999019: pa_log_levelv_meta (in /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-11.1.so)
==9314== by 0x69986A4: pa_log_level_meta (in /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-11.1.so)
==9314== by 0x69A8CD0: pa_queue_push (in /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-11.1.so)
==9314== by 0x69A6879: pa_pstream_send_packet (in /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-11.1.so)
==9314== by 0x69A5136: ??? (in /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-11.1.so)
==9314== by 0x69A52BE: pa_pstream_send_tagstruct_with_creds (in /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-11.1.so)
==9314== by 0x6743B0B: pa_stream_update_timing_info (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.20.2)
==9314== by 0x6743D5D: ??? (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.20.2)
==9314== by 0x6744313: ??? (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.20.2)
==9314== by 0x673B23F: pa_mainloop_dispatch (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.20.2)
==9314== by 0x673B4DD: pa_mainloop_iterate (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.20.2)
==9314== by 0x673B55F: pa_mainloop_run (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.20.2)
==9314== by 0x67493C8: ??? (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.20.2)
==9314== by 0x69B9317: ??? (in /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-11.1.so)
==9314== by 0x55566DA: start_thread (pthread_create.c:463)
==9314== by 0x5AA788E: clone (clone.S:95)
Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.
If that doesn't help, please report this bug to: www.valgrind.org
In the bug report, send all the above text, the valgrind
version, and what OS and version you are using. Thanks.
valgrind with the debug symbols
https://gist.github.com/MOZGIII/ea171bdc707e0c4a464ca572c229a7cb
I think this is the commit to ALSA that fixes the issue: https://github.com/alsa-project/alsa-lib/commit/54931e5a5455ac681a32a673d4b360d43f34b6b5; because of this: https://github.com/alsa-project/alsa-lib/blame/3ec6dce5198f100fa8dd2abfc1258fa4138ceb1a/src/pcm/pcm.c#L7292
In Ubuntu 18.04 though, the libasound2 package versions is 1.1.3-5 (which is ok), but the libasound2-plugins version is 1.1.1-1ubuntu1 - and may be problematic, although I'm not sure.
After a bit more research, it looks like libasound2-plugins didn't have a 1.1.3 release, so must be ok too.
I'm stuck.
A bit more info:
- found this bug at debian bugtracker, seems to be related: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824850
I force-installed the libasound2 and libasound2-data from debian buster and it still crashes with the same error.
~I suspect it may actually be due to big buffers (Running out of memory even?): https://github.com/RustAudio/cpal/issues/264#issuecomment-646314801 That is certainly something that will compound with the number of channels~
I read that wrong. Sorry.
I'm starting to have this problem now, too.
I reinstalled OBS from flatpak and now I'm having issues with this exact problem:
Assertion 'pa_atomic_load(&(s)->_ref) >= 1' failed at ../src/pulse/stream.c:1644, function pa_stream_peek(). Aborting.
