After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 696885 - gst printf specifier extensions can conflict with other libraries 'Q' modifier
gst printf specifier extensions can conflict with other libraries 'Q' modifier
Status: RESOLVED DUPLICATE of bug 613081
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
1.x
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-03-30 01:34 UTC by Alban Browaeys
Modified: 2013-04-05 09:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
testcase that reproduce pitivi use case with gst debug on - segfault (2.26 KB, application/octet-stream)
2013-03-30 01:34 UTC, Alban Browaeys
  Details
testcase that reproduce pitivi use case with gst debug on - with hack - success (2.26 KB, application/octet-stream)
2013-03-30 01:37 UTC, Alban Browaeys
  Details
prevent a 'Q' modifier from breaking our 'Q' specifier by using a dummy 'h' specifier (2.81 KB, patch)
2013-03-30 11:10 UTC, Alban Browaeys
none Details | Review

Description Alban Browaeys 2013-03-30 01:34:39 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' .
Comment 1 Alban Browaeys 2013-03-30 01:37:04 UTC
Created attachment 240148 [details]
testcase that reproduce pitivi use case with gst debug on - with hack - success
Comment 2 Alban Browaeys 2013-03-30 11:10:49 UTC
Created attachment 240159 [details] [review]
prevent a 'Q' modifier from breaking our 'Q' specifier by using a dummy 'h' specifier
Comment 3 Tim-Philipp Müller 2013-03-30 11:17:52 UTC
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.
Comment 4 Tim-Philipp Müller 2013-03-30 11:18:42 UTC
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?)
Comment 5 David Schleef 2013-03-30 20:42:05 UTC
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.
Comment 6 Tim-Philipp Müller 2013-03-31 10:03:28 UTC
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).
Comment 7 Tim-Philipp Müller 2013-04-05 09:27:25 UTC

*** This bug has been marked as a duplicate of bug 613081 ***