Double free exception during pa_context_connect()

[philn]

Hi,

I reported this in GStreamer bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=624338

As I'm not sure this is really a gst pulsesink issue I report here too ;) The crash happens during pa_context_connect(). Relevant extract of the stacktrace (also posted in bug above):

Thread 4 (Thread 0x7fffebfff710 (LWP 2100)):
#0  0x00007ffff69fe175 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff6a00f80 in *__GI_abort () at abort.c:92
#2  0x00007ffff6a342bb in __libc_message (do_abort=<value optimized out>, fmt=<value optimized out>)
    at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#3  0x00007ffff6a3db16 in malloc_printerr (action=3, str=0x7ffff6af4a60 "double free or corruption (fasttop)", 
    ptr=<value optimized out>) at malloc.c:6267
#4  0x00007ffff6a4288c in *__GI___libc_free (mem=<value optimized out>) at malloc.c:3739
#5  0x00007fffe0aefb2e in pa_xfree (p=0x7fffe401c8d0) at pulse/xmalloc.c:131
#6  0x00007fffe0680b5a in pa_get_runtime_dir () at pulsecore/core-util.c:1506
#7  0x00007fffe0680ec6 in get_path (fn=0x7fffe0af0e95 "native", prependmid=false, rt=6) at pulsecore/core-util.c:1911
#8  0x00007fffe0acc9c3 in prepend_per_user (l=0x7fffe401c460) at pulse/context.c:661
#9  0x00007fffe0ace7fb in pa_context_connect (c=0x7fffe4015000, server=0x7fffe401c4f0 "", 
    flags=PA_CONTEXT_NOAUTOSPAWN, api=0x0) at pulse/context.c:1007
---Type <return> to continue, or q <return> to quit---
#10 0x00007fffe0d0a9ea in gst_pulseringbuffer_open_device (buf=0xd76790) at pulsesink.c:430

[philn]

I use libpulse 0.9.21-3 from Debian unstable btw.

[philn]

Had some success by protecting pa_context_connect with a mutex. So multiple threads wouldn't call it at the same time. Would someone review such a patch? Am I alone on this trac? Anyone doing bug triaging here?

[coling]

You are not alone here (although considering the bug is only 2 days old, it's not really realistic to presume anyone has looked at it properly yet).

I do think you're the only one with this problem tho'. Why would multiple threads ever try to call pa_context_connect at the same time? Are two independent connections being established here or am I missing something? I would have thought that most applications only have one context anyway and lock the use of it in different threads.

[philn]

Replying to coling:

You are not alone here (although considering the bug is only 2 days old, it's not really realistic to presume anyone has looked at it properly yet).

Sorry, no pun intended ;)

I do think you're the only one with this problem tho'. Why would multiple threads ever try to call pa_context_connect at the same time? Are two independent connections being established here or am I missing something? I would have thought that most applications only have one context anyway and lock the use of it in different threads.

Well in my case I have 2 threads creating their own context. It's done in the gst pulsesink. You can try the test-case attached in the GStreamer bug, it's fairly simple.

[philn]

So yeah, it's 2 independant connections, as far as I can tell.

[coling]

See also https://bugs.kde.org/show_bug.cgi?id=246141

[coling]

This so far appears to be an upstream thread-safety issue in gstreamer. The upstream bug report (see description) appears to be resolved (although awaiting official confirmation of that). The test case on the above bug appears seems fixed with the patch applied for me.

I've applied the fix to Mandriva Gst packages in Cooker and put an update candidate into main/testing repo for the 2010.1 for anyone that wants to test.

I'll therefore close this bug for now, but if any PA specific problem is found, please feel free to reopen with additional details/debug.