GNOME Bugzilla – Bug 696885
gst printf specifier extensions can conflict with other libraries 'Q' modifier
Last modified: 2013-04-05 09:27:25 UTC
Created attachment 240147 [details] testcase that reproduce pitivi use case with gst debug on - segfault eglibc was segfaulting when gst debug printing segments in pitivi ... turns out pitivi import numpy which register a printf modifier 'Q' .. As libc6 treats modifiers first, with 'send segment %Q to pad %P", "%Q " becomes '% ' after modifier processing and as there are not '% ' registered printf extension, the segment is sent to next qualifier '%P' segfault happens when the gst extension to handle '%P' attempt to make a gst object from the gst segment. one hack to fix the issue: to avoid the (numpy/quadmath) 'Q' modifier from breaking gst 'Q' specifier ... using "send segment %hQ to pad %P" fixes the issue (note the spurious valid 'h' modifier which prevent 'Q' from possible processing as a modifier as we do not handle 'h' in our specifier handler it has no effect. The eglibc 2.17 treats modifiers first, with 'send segment %Q to pad %P", "%Q " becomes '% ' after modifier processing and as there are not '% ' registered printf extension, the segment is sent to next qualifier '%P' segfault happens when the gst extension to handle '%P' attempt to make a gst object from the gst segment. ... turns out pitivi import numpy which register a printf modifier 'Q' .
Created attachment 240148 [details] testcase that reproduce pitivi use case with gst debug on - with hack - success
Created attachment 240159 [details] [review] prevent a 'Q' modifier from breaking our 'Q' specifier by using a dummy 'h' specifier
I'm not quite sure what to do about this other than advise application authors not to use libraries that register modifiers that conflict with ours. We could add this as another consideration to bug #613081 - I think there was talk about having our own printf implementation for debug logging, so we can support printing caps etc. on windows/OSX and embedded systems that don't use glibc.
Doesn't the patch break ABI compatibility? (What about plugins using the older %Q modifier - what will happen if just libgstreamer-1.0 gets updated now?)
I mentioned changing away from %Q on IRC without thinking it through, and yes, it is an ABI break. The best solution, IMO, is to add our own printf implementation for debugging OR do the same in GLib. GLib's printf implementation is small in the grand scheme of things. A really cool solution would be to make %P work for any GType, with libraries adding a debug serialization to the type if they wish. Gst would do that for GstCaps, GLib would do an generic one for GObjects. A generic solution for glib-based printf extension would require registering a 4-char code with the printf extension, in order to avoid conflicts. Thus, for segments, we'd register %Qgst1, %Qgst2 for GstClockTime, etc.
I'm currently looking in adding our own printf implementation for debugging purposes, see bug #613081. Some work in progress can be found in http://cgit.freedesktop.org/~tpm/gstreamer/log/?h=gnulib-printf GLib will use the system printf if it's usable enough, otherwise the internal one, and I would be surprised if GLib people were keen to add support for this on their side (but if they ever do, we can still replace our stuff and use that).
*** This bug has been marked as a duplicate of bug 613081 ***