<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" 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="moz-cite-prefix">On 7/24/19 6:55 PM, David Ing wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAKF2gC_jNJOfwFJ6LR47U9xK1ND5DBjEjFgQiUX7M4tetzVYjg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></pre>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>