<div dir="ltr">It turns out that I had no heap corruption, but at least I learned how to use valgrind and google sanitizers.<div><br></div><div>I messed up the way Gstreamer logs were grafted into my logging system.  (I failed to realized that Gstreamer has a custom sprintf function.)</div><div><br></div><div>But the core issue remains.  I am going to start a new email thread to re-describe the issue from scratch.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 24, 2019 at 9:58 AM Mathieu Duponchelle <<a href="mailto:mathieu@centricular.com">mathieu@centricular.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    valgrind comes to mind, though you'll need to use the appropriate
    suppression files to get<br>
    a sensible result, see the commands used for example by
    gst-validate-launcher when running<br>
    a test with the -vg switch.<br>
    <br>
    <div class="gmail-m_-3503779519641637652moz-cite-prefix">On 7/24/19 6:55 PM, David Ing wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div>Can anyone recommend some techniques for diagnosing heap
          corruption issues on Linux (Fedora 30)?</div>
        <div><br>
        </div>
        <div>If I were on Windows I would use gflags (to set up guard
          pages) and windbg (for kernel-level debugging) but I don't
          know what is available on Linux.</div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Wed, Jul 24, 2019 at 9:35
          AM Mathieu Duponchelle <<a href="mailto:mathieu@centricular.com" target="_blank">mathieu@centricular.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <div bgcolor="#FFFFFF"> Regarding your first question, yes it
            is fortunately completely acceptable for caps to be<br>
            (re)negotiated in a PLAYING pipeline, if it was not then you
            could not dynamically update<br>
            pipelines, which is a feature GES obviously heavily relies
            on.<br>
            <br>
            Regarding your second question, it looks like there might be
            some memory corruption going<br>
            on, as the expected format for the log message is:<br>
            <br>
                if (!gst_qtmux_caps_is_subset_full (qtmux, current_caps,
            caps)) {<br>
                  gst_caps_unref (current_caps);<br>
                  GST_WARNING_OBJECT (qtmux,<br>
                      "pad %s refused renegotiation to %"
            GST_PTR_FORMAT,<br>
                      GST_PAD_NAME (pad), caps);<br>
                  gst_object_unref (qtmux);<br>
                  return FALSE;<br>
                }<br>
            <br>
            Caps here are supposed to be displayed as a string, if
            they're not that means GST_IS_CAPS (caps)<br>
            failed, which is odd. More generally, qtmux only seems to
            support renegotiating the caps for an<br>
            input stream if the new caps are not a subset of the older
            ones, however I can't tell if the check<br>
            genuinely fails here because the new caps don't fulfill that
            condition, or because of the apparent<br>
            memory corruption.<br>
            <br>
            <div class="gmail-m_-3503779519641637652gmail-m_8846287712392109001moz-cite-prefix">On
              7/24/19 5:56 PM, David Ing wrote:<br>
            </div>
            <blockquote type="cite">
              <div dir="ltr">I am running a GESTimeline inside of a
                GstPipeline.  I am attaching an SVG file which
                illustrates the pipeline when it enters it's READY
                state.
                <div><br>
                </div>
                <div>
                  <div>
                    <div>Soon after the the pipeline begins PLAYING, the
                      muxers receive a request to re-negotiate the caps.</div>
                    <div><br>
                    </div>
                    <div><b>My first question is:</b>  Is it normal to
                      re-negotiate caps after a pipeline is already
                      playing?  (This doesn't seem right to me.)<br>
                    </div>
                    <div><br>
                    </div>
                    <div><b>My second question is:</b>  How can I
                      determine which element is trying to renegotiate
                      the caps after the pipeline is already PLAYING?</div>
                    <div><br>
                    </div>
                    <div>BTW:  Here are the logs I see as it relates to
                      the caps re-negotation error.</div>
                    <div>
                      <pre style="color:rgb(0,0,0);font-family:"DejaVu Sans Mono";font-size:7.5pt">19-07-24T15:44:36.530562 INFO    pan CompositionJob.cpp:123 Pipeline state changed from PAUSED to PLAYING in 0.000 seconds.
19-07-24T15:44:36.925546 WARNING qtmux gstqtmux.c:5118 pad video_0 refused renegotiation to 0x7f7080003000 A
19-07-24T15:44:36.925673 WARNING qtmux gstqtmux.c:5118 pad video_0 refused renegotiation to 0x7f7080003000 A
19-07-24T15:44:36.925725 WARNING GST_PADS gstpad.c:4230 could not send sticky events
19-07-24T15:44:36.927847 WARNING qtmux gstqtmux.c:5118 pad video_0 refused renegotiation to 0x7f7080003000 A
19-07-24T15:44:36.927973 WARNING qtmux gstqtmux.c:5118 pad video_0 refused renegotiation to 0x7f7080003000 A
19-07-24T15:44:36.928039 WARNING qtmux gstqtmux.c:5118 pad video_0 refused renegotiation to 0x7f7080003000 A
19-07-24T15:44:36.932935 WARNING qtdemux qtdemux.c:6607 error: Internal data stream error.
19-07-24T15:44:36.933041 WARNING qtdemux qtdemux.c:6607 error: streaming stopped, reason not-negotiated (-4)
19-07-24T15:44:36.934955 ERROR   pan CompositionJob.cpp:282 GST_MESSAGE_ERROR received from element qtdemux5 at position 5465466666: Internal data stream error.
../gst-plugins-good/gst/isomp4/qtdemux.c(6607): gst_qtdemux_loop (): /GstPipeline:pipeline/GESTimeline:gestimeline0/GESVideoTrack:gesvideotrack0/NleComposition:video_nlecomposition1/GstBin:current-bin/NleSource:GESVideoUriSource:nlesource4/GstBin:videosrcbin/GstURIDecodeBin:uridecodebin2/GstDecodeBin:decodebin9/GstQTDemux:qtdemux5:
streaming stopped, reason not-negotiated (-4)</pre>
                    </div>
                    <div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                    </div>
                  </div>
                </div>
              </div>
              <br>
              <fieldset class="gmail-m_-3503779519641637652gmail-m_8846287712392109001mimeAttachmentHeader"></fieldset>
              <pre class="gmail-m_-3503779519641637652gmail-m_8846287712392109001moz-quote-pre">_______________________________________________
gstreamer-devel mailing list
<a class="gmail-m_-3503779519641637652gmail-m_8846287712392109001moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a>
<a class="gmail-m_-3503779519641637652gmail-m_8846287712392109001moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></pre>
            </blockquote>
          </div>
        </blockquote>
      </div>
    </blockquote>
  </div>

</blockquote></div>