Hi,
On Tue, Jun 07, 2016 at 07:29:35PM +0200, Baptiste Jonglez wrote:
When using Ring [1], an audio-video application, it sometimes crashes because of an assertion in libasound.so:
pcm.c:2758: snd_pcm_area_copy: Assertion `dst < src || dst >= src + bytes' failed.
The complete upstream bug report is at [2]. The (not-so-useful) stack trace is the following:
<snip>
The next time it crashes, I will have debug symbols in dring. I can also recompile alsa-lib with debug symbols, what is the best way to do that?
As promised, here is a new stack trace with debug symbols:
#0 0x00007f899af94295 in raise () from /usr/lib/libc.so.6 #1 0x00007f899af956da in abort () from /usr/lib/libc.so.6 #2 0x00007f899af8d297 in __assert_fail_base () from /usr/lib/libc.so.6 #3 0x00007f899af8d342 in __assert_fail () from /usr/lib/libc.so.6 #4 0x00007f89a003b04d in snd_pcm_area_copy (dst_area=0x7f89847f3360, dst_offset=<optimized out>, src_area=0x7f89847f3350, src_offset=<optimized out>, samples=<optimized out>, format=<optimized out>) at pcm.c:2758 #5 0x00007f89a003b27c in snd_pcm_areas_copy (dst_areas=0x7f896c002dd0, dst_areas@entry=0x7f896c002db0, dst_offset=248, src_areas=0x7f896c002dd0, src_areas@entry=0x610, src_offset=0, channels=2, channels@entry=0, frames=1552, frames@entry=0, format=SND_PCM_FORMAT_S32_LE) at pcm.c:2904 #6 0x00007f89a007c2d9 in softvol_convert_stereo_vol (svol=svol@entry=0x7f896c0013c0, dst_areas=dst_areas@entry=0x7f896c002db0, dst_offset=dst_offset@entry=248, src_areas=0x610, src_areas@entry=0x7f896c002db0, src_offset=src_offset@entry=0, channels=0, frames=<optimized out>) at pcm_softvol.c:291 #7 0x00007f89a007c3f6 in snd_pcm_softvol_read_areas (pcm=0x7f896c001b10, areas=0x7f896c002db0, offset=248, size=1552, slave_areas=0x7f896c002db0, slave_offset=0, slave_sizep=0x7f89847f3480) at pcm_softvol.c:630 #8 0x00007f89a004d0e1 in snd_pcm_plugin_avail_update (pcm=0x7f896c001b10) at pcm_plugin.c:490 #9 0x00007f89a004cf19 in snd_pcm_plugin_avail_update (pcm=0x7f896c001eb0) at pcm_plugin.c:460 #10 0x00000000005486d4 in ring::AlsaLayer::capture (this=0x1a9ef00) at alsalayer.cpp:694 #11 0x0000000000545de4 in ring::AlsaThread::run (this=0x1b00500) at alsalayer.cpp:137 <snip> (horrible C++ stack trace from the application itself)
Is there anything in there that could explain the assertion failure? Perhaps a wrong API usage?
Thanks, Baptiste
Looking around, it seems other projects have run into the same issue:
https://aur.archlinux.org/packages/ultrastardx-git/?comments=all#comment-435458 https://aur.archlinux.org/packages/zoom/#comment-544696 http://ubuntuforums.org/showthread.php?t=2248373 https://github.com/js-platform/node-webrtc/issues/110 https://fedorahosted.org/fldigi/ticket/70
The output of the alsa-info.sh script on my system is at [3]. What else can I provide to debug this issue further?
Thanks, Baptiste
[1] https://ring.cx [2] https://tuleap.ring.cx/plugins/tracker/?aid=502 [3] http://www.alsa-project.org/db/?f=0dd2ba1021b3d535f30f07c55dc18e2ef60db26d
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel