As tim said on irc, "gconf does the parsing only when going from NULL => READY I believe, so it probably doesn't run into this problem" And tim is right, you won't see the problem :) You have to know that the most difficult case is when you are parsing the same string recursively: $ gst-launch element adescription="anotherelement !..." ... And for the moment, gst-launch (the parsing) crash when you do that.   Cheers, <div>On 7/30/06, Zaheer Merali <<a href="mailto:zaheermerali@gmail.com">zaheermerali@gmail.com</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi Having spoken in the channel, this re-entrancy issue could potentially be a problem for the gconf plugins, gconfaudiosrc, gconfaudiosink etc. It would howver be nice to be shown valgrind output of a gst-launch line with gconfaudiosink in for example. Zaheer On 7/30/06, Stefan Kost <<a href="mailto:ensonic@hora-obscura.de">ensonic@hora-obscura.de</a>> wrote: > hi, > > This weekend Marc-Andre has provided a patch in > <a href="http://bugzilla.gnome.org/show_bug.cgi?id=349180">http://bugzilla.gnome.org/show_bug.cgi?id=349180</a> > to make the gst_parse_launch reentrant. > > Unfortunately Fedora core 4/5 ships an ancient version of flex which > can't do the reentrancy. As this is only a build dependency, what do you > think about bumping the requirement. Just for your information flext > 2.5.4.a ist from 1997. The release from 2003 would do it. So we would > not require anything bleeding edge. > > Stefan & Marc-Andre </blockquote></div> -- Marc-André Lureau, GSmartMix