Sorry to bump up such an old thread, but I think it's important.
On Sat, 2005-05-14 at 15:45 +0200, Matthias Bläsing wrote:
> use utf8;
> use GStreamer -init;
> my $thread1 = GStreamer::Thread->new("thread1");
> my $thread2 = GStreamer::Thread->new("thread2");
> my $audiosink = GStreamer::ElementFactory->make("alsasink", "alsa");
> my $source = GStreamer::ElementFactory->make("filesrc", "file");
> my $mad = GStreamer::ElementFactory->make("mad", "mad");
> my $queue = GStreamer::ElementFactory->make("queue", "queue");
> GStreamer::Element::link_many($source, $mad, $queue);
> $thread1->add_many($source, $mad, $queue);
> $source->set("location", "/home/mblaesing/musik/musik/Pur -
> When running this small example it just segfaults (when calling the
> mainloop) and I don't now why. Am I right if I asume, that perl messes
> with the thread handling?
It looks like this was due to a Glib bug I'm about to commit a fix for.
It basically occured whenever a log message was initiated by a thread:
Glib's default log handler would be invoked in that thread's context,
and then call Perl_form, which accesses a memory pool that is
"thread-local". So without setting perl's thread context to a sane one
first, it always segfaults right there.
For those of you who don't want to wait for anoncvs to catch up, the
patch is also attached.
With the fix applied, the above example works nearly unaltered for me.
(I replaced "mad" with "spider" and changed the filename.)