<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">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_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_8846287712392109001mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_8846287712392109001moz-quote-pre">_______________________________________________
gstreamer-devel mailing list
<a class="gmail-m_8846287712392109001moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a>
<a class="gmail-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>