GNOME Bugzilla – Bug 148721
entrygthread fail on SMP systems
Last modified: 2005-06-30 15:14:47 UTC
Running gstreamer-0.8.4 on an Sun system (2 Sparc processors running SunOS 5.8), gst-launch fails with the following assert: ** ERROR **: file entryscheduler.c: line 405 (gst_entry_scheduler_get_wrapper): assertion failed: (PAD_PRIVATE (pad)->bufpen == NULL) The problem doesn't happen very often. To reproduce it, I call gst-launch many times with pipelines such as this one: wavenc name=sink ! filesink location="test.wav" { filesrc location="input.mp3" ! spider ! audioconvert ! queue block_timeout=100000 max-size-time=0 max-size-buffers=0 max-size-bytes=0 } !sink.sink To me, it looks like gst_entry_scheduler_iterate() is called and it schedules the gst_entry_scheduler_get_wrapper() from the queue, which runs in a different thread. Before this functions gets to complete, gst_entry_scheduler_iterate() is called again from the main thread and schedules the same link. I could be wrong, but I think that when a link is selected for scheduling, it should be removed from the can_schedulle() list before being run. This would make sure it won't be called again before it completes.
Seems my assumptions were wrong. When it asserts, all the cothreads for the pipeline have been created. The get_wrapper for the queue that asserts has called schedule_next_element() three times already. So this clearly doesn't happen at creation time. Also, when it happens, no cothread has been destroyed yet. Sorry if I cannot provide more details, I couldn't reproduce the bug with logging enabled.
Ok, maybe this is not related to the entrygthread scheduler after all, but to bug 111146. By multiplying the block_timeout of the queue by 10, things run for much longer before getting in trouble. I still get the assertion, but sometimes I see the following warning: (process:19852): GStreamer-WARNING **: inconsistent state information, fix threading please And sometimes, it just crashes: GThread-ERROR **: file gthread-posix.c: line 369 (): error 'No such process' during 'pthread_join (*(pthread_t*)thread, &ignore)' backtrace:
+ Trace 49068
I don't have access to a Solaris box anymore so I cannot reproduce this bug. I guess it can be closed.