mutex_unlock problem

[hp4]

Hi, i just succeeded in playing mp3-files to gmrender on Raspberry Pi via network. But gmrender crashes in many cases when handling events due to mutex-problems. Events maybe pausing/playing or stopping music as well as setting the speaker-volume:

---------- Console Output ------------------------------------------------------------------------------ [~]$ /home/pulse/opt/gmrender-resurrect/bin/gmediarender -u "68001818-e0c2-4df6-bd04-aa73f879fd9a" -f "Renderer" gmediarender 0.0.7-git started [ gmediarender 2013-10-29_e2eb785 (libupnp-1.6.19; glib-2.38.2; gstreamer-1.2.2) ]. Logging switched off. Enable with --logfile= (e.g. --logfile=/dev/stdout for console) Ready for rendering. Assertion 'pthread_mutex_unlock(&m->mutex) == 0' failed at pulsecore/mutex-posix.c:110, function pa_mutex_unlock(). Aborting.

Abgebrochen (Speicherabzug geschrieben)

my system:

OS : archlinuxarm for Raspberry Pi, most recent version 3.10.28-1-ARCH gstreamer 1.2.2-1 pulseaudio 4.0-6

gmrender has been compiled locally on the RaspPi from source without errors.

Are there any special flags or library settings related to mutex-handling in the archlinux environment?

BR Hans-Peter

[hzeller]

This looks like it happens inside 'pulsecore' which sounds like it is part of a gstreamer library not part of gmrender-resurrect. Maybe that gstreamer version (1.2.2) is problematic or not all gstreamer plugins are of the same version ?

[hp4]

thanks for your quick repsonse. Plugin versions are also the most recent versions from archlinux repository (I had to include even the bad- and ugly-plugins for networking and mp3):

gst-plugins-base 1.2.2-1 gst-plugins-good 1.2.2-2 gst-plugins-bad 1.2.2-2 gst-plugins-ugly 1.2.2-3

Do you think that falling back to the old legacy gstreamer0.10 is an option? Or is there any change of tracing/debugging calls from gmrender to gstreamer? Or activate any logging? Only the gmrender process crashes, the pulseaudio daemon continues to work correctly.

Thanks for your help

[hzeller]

Maybe not 0.10, but an earlier version of the 1 series. You can get detailed gstreamer debugging by setting GST_DEBUG GST_DEBUG=*:5 src/gmediarender

I'd probably run this in gdb and look at the backtrace when this assertion fires.

Anyway, I'd probably not go with pulseaudio in the first place (it sometimes does re-sampling without reason which only reduces sound quality) but simple ALSA output. See example in the README.md how to set it.

[hp4]

starting gmrender with alsasink seams to prevent gmrender-process from crashing, but when stopping the music with the controller (bubbleupnp on tablet) I get the console messages

ERROR [2014-01-29 18:38:39.149666 | upnp] upnp_set_error: Transition not allowed; allowed=PLAY,SEEK

But gmrender stays alive and I can start playing another file. But this may be an indication to what happens in the pulseaudio case ??

I'm not very experienced with this development environment. So what do you mean with setting GST_DEBUG? Somewhere in the configuration of gmrender before building?

[hzeller]

the 'transition not allowed' comes from gmediarender and says that bubbleupnp attempted a transition which is not possible (e.g. going to PAUSE while being stopped). This has nothing to do with the pulseaudio case, just a mismatch what bubbleupnp thinks is ok and what gmrender thinks is ok :) I haven't checked with a recent version of bubbleupnp, should try that again.

I have now updated the error message to qualify what transition it does; if you do 'git pull' again and recompile, we can see that.

The GST_DEBUG: just run the commandline I posted above - just prepending it to your execution of gmediarender GST_DEBUG=*:5 /home/pulse/opt/gmrender-resurrect/bin/gmediarender -u "68001818-e0c2-4df6-bd04-aa73f879fd9a" -f "Renderer"

[hzeller]

Also, please switch on gmrender logging as described in the INSTALL.md. It might show as well maybe interesting things.

[hp4]

ok, thanks very much. I'll try to debug the pulseaudio case tomorrow. For now the alsasink solution seems to work. Maybe the error messages only appear when pressing stop too fast after starting the file, so the state wasn't yet updated.

[hp4]

Hi, I've done 2 traces (one alsa, one pulseaudio) and as may be expected the behaviour changed a little bit probably due to changed dynamic properties.

How can I upload the logs (~2MB)? This comment window only seems to allow images?

1) alsa case : gmrender seems to run without problems. The error messages concerning invalid state transitions seem to have disappeared. At least "grep ERROR" doesn't find anything. I added the log file only in case you want to grep for anything else what might be of interest.

2) pulse case: the memory dump still occurs but you have to issue more events (volume control or start/stop/pause events) to trigger the fault. Are you able to analyze the log file or should I address a gstreamer-developer ?

Thanks for your help

[hzeller]

1) I assume this might have been before because you restated gmrender and bubbleupnp didn't notice that hence was in a 'wrong state'.

2) Maybe send them to the gstreamer developers. But it sounds even like a level deeper to be a problem in pulseaudio, so they might not be able to help either. But since they closely work with pulseaudio output they might be able to guess what is happening.

As for big files: the gstreamer bugtracker allows to upload files (make sure to gzip or bzip2 them before). Or there is always a service like 'pastebin' for that kind of stuff.

[hp4]

ok, thank you very much for your help