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 697970 - info: glibc "%n in writable segment detected" with new printf implementation
info: glibc "%n in writable segment detected" with new printf implementation
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal major
: 1.1.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2013-04-13 21:55 UTC by David Schleef
Modified: 2013-04-14 10:41 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description David Schleef 2013-04-13 21:55:42 UTC
I didn't spend the time to look what's going on here.  But you can reproduce it with "gst-launch-1.0 fakesrc moo=goo ! fakesink"

  • #0 __GI_raise
    at ../nptl/sysdeps/unix/sysv/linux/raise.c line 64
  • #1 __GI_abort
    at abort.c line 91
  • #2 __libc_message
    at ../sysdeps/unix/sysv/linux/libc_fatal.c line 201
  • #3 __GI___libc_fatal
    at ../sysdeps/unix/sysv/linux/libc_fatal.c line 212
  • #4 _IO_vfprintf_internal
    at vfprintf.c line 2007
  • #5 ___vsnprintf_chk
    at vsnprintf_chk.c line 65
  • #6 ___snprintf_chk
    at snprintf_chk.c line 36
  • #7 snprintf
    at /usr/include/x86_64-linux-gnu/bits/stdio2.h line 65
  • #8 __gst_vasnprintf
    at vasnprintf.c line 785
  • #9 __gst_vasprintf
    at printf.c line 152
  • #10 gst_debug_message_get
    at gstinfo.c line 531
  • #11 gst_debug_log_default
    at gstinfo.c line 1005
  • #12 gst_debug_log_default
    at gstinfo.c line 966
  • #13 gst_debug_log_valist
    at gstinfo.c line 509
  • #14 gst_debug_log
    at gstinfo.c line 436
  • #15 gst_parse_element_set
    at ./grammar.y line 430
  • #16 priv_gst_parse_yyparse
    at ./grammar.y line 681
  • #17 priv_gst_parse_launch
    at ./grammar.y line 938
  • #18 gst_parse_launch_full
    at gstparse.c line 324
  • #19 gst_parse_launchv_full
    at gstparse.c line 262
  • #20 gst_parse_launchv
    at gstparse.c line 215
  • #21 main
    at gst-launch.c line 944

Comment 1 Tim-Philipp Müller 2013-04-13 23:04:09 UTC
<tim> hrm, it seems related to glibc having been compiled with _FORTIFY_SOURCE=2 or something
<tim> you could try modifying gst/printf/gst-printf.h to #undef HAVE_SNPRINTF then it might take a different code path
<ds> hrm, ok
<tim> not sure I understand the complaint yet
<ds> that does work around the problem
<tim> not sure if there's anything else we can do
<ds> I can't see how any libc function is called with %n
<tim> vasnprintf.c line 662
<tim> aiui it will do "%whatever%n", arg, &len  to determine the length
<tim> if HAVE_SNPRINTF is not defined, it will do a home-grown method to determine the max length
Comment 2 Tim-Philipp Müller 2013-04-14 10:41:56 UTC
Well, let's do this then. I don't think there's much else we can do:

 commit 91c42b938001bfd68acb6af951603cebc1bea75b
 Author: Tim-Philipp Müller <>
 Date:   Sun Apr 14 11:23:10 2013 +0100

    printf: use sprintf() to work around glibc complaining about %n in a writable format string
    Don't use snprintf(), but use sprintf instead and do our own
    length calculations, because glibc may complain about us passing
    %n in a format string if the string is in writable memory, and
    here the format string is always in writable memory since we
    construct it on the fly. This happens if glibc has been compiled
    with _FORTIFY_SOURCE=2, which seems to be the case on some
    distros/systems). On the upside, we now use the sprintf code path
    on all systems which should be better from a maintenance point
    of view.