Re: rtpjitterbuffer segfault after repeated RTSP start/stop in same process
Nicolas Dufresne via gstreamer-devel <[email protected]> Wed, 07 Jan 2026 09:27:24 -0500
| Newsgroups | gmane.comp.video.gstreamer.devel |
|---|---|
| Message-ID | <[email protected]> |
--=-UG51i0WVQuTZhL/7oR8A
Content-Type: multipart/alternative; boundary="=-2o2hqH+7Qc/m0MZID0VB"
--=-2o2hqH+7Qc/m0MZID0VB
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi,
Le mardi 06 janvier 2026 =C3=A0 19:30 +0300, bunyamin kirmizi via gstreamer=
-devel a
=C3=A9crit=C2=A0:
> Hello,
>=20
> I am experiencing a segmentation fault inside rtpjitterbuffer and wanted =
to
> ask whether anyone has encountered a similar issue before.
Most of the support have moved to=C2=A0https://discourse.gstreamer.org=C2=
=A0so I would
suggest to move your request there.
>=20
> The crash happens when I repeatedly start and stop an RTSP stream from th=
e
> same application/process. The first runs work fine, but after several RTS=
P
> open/close cycles, a segfault occurs inside rtpjitterbuffer. This is not =
a
> fork/exec case; the pipeline is created and torn down multiple times with=
in a
> single process.
>=20
> The issue becomes more reproducible under unstable network conditions (ji=
tter,
> packet reordering, burst loss), but the repeated RTSP usage itself seems =
to be
> a key factor.
>=20
> I am trying to understand:
>=20
> - Has anyone seen segfaults in rtpjitterbuffer related to repeated pipeli=
ne
> setup/teardown?
> - Are there known assumptions about jitterbuffer internal state (latency,=
pt-
> map, reordering window, timers, etc.) that could be violated in this scen=
ario?
> - Is there a recommended way to properly reset or flush rtpjitterbuffer s=
tate
> when stopping an RTSP stream?
> - Any advice on where to instrument or add sanity checks while debugging =
this
> would be very helpful.
>=20
> If needed, I can share a backtrace, pipeline description, or more details
> about the RTP stream characteristics.
Yes, provide as much useful information as you have, backtrace are the most
important, some context of what may trigger the issue too.
cheers,
Nicolas
--=-2o2hqH+7Qc/m0MZID0VB
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
<html><head><style>pre,code,address {
margin: 0px;
}
h1,h2,h3,h4,h5,h6 {
margin-top: 0.2em;
margin-bottom: 0.2em;
}
ol,ul {
margin-top: 0em;
margin-bottom: 0em;
}
blockquote {
margin-top: 0em;
margin-bottom: 0em;
}
</style></head><body><div>Hi,</div><div><br></div><div>Le mardi 06 janvier =
2026 =C3=A0 19:30 +0300, bunyamin kirmizi via gstreamer-devel a =C3=A9crit&=
nbsp;:</div><blockquote type=3D"cite" style=3D"margin:0 0 0 .8ex; border-le=
ft:2px #729fcf solid;padding-left:1ex"><div dir=3D"ltr">Hello,<br><br>I am =
experiencing a segmentation fault inside rtpjitterbuffer and wanted to ask =
whether anyone has encountered a similar issue before.</div></blockquote><d=
iv><br></div><div>Most of the support have moved to <a href=3D"https:/=
/discourse.gstreamer.org/">https://discourse.gstreamer.org</a> so I wo=
uld suggest to move your request there.</div><div><br></div><blockquote typ=
e=3D"cite" style=3D"margin:0 0 0 .8ex; border-left:2px #729fcf solid;paddin=
g-left:1ex"><div dir=3D"ltr"><br>The crash happens when I repeatedly start =
and stop an RTSP stream from the same application/process. The first runs w=
ork fine, but after several RTSP open/close cycles, a segfault occurs insid=
e rtpjitterbuffer. This is not a fork/exec case; the pipeline is created an=
d torn down multiple times within a single process.<br><br>The issue become=
s more reproducible under unstable network conditions (jitter, packet reord=
ering, burst loss), but the repeated RTSP usage itself seems to be a key fa=
ctor.<br><br>I am trying to understand:<br><br>- Has anyone seen segfaults =
in rtpjitterbuffer related to repeated pipeline setup/teardown?<br>- Are th=
ere known assumptions about jitterbuffer internal state (latency, pt-map, r=
eordering window, timers, etc.) that could be violated in this scenario?<br=
>- Is there a recommended way to properly reset or flush rtpjitterbuffer st=
ate when stopping an RTSP stream?<br>- Any advice on where to instrument or=
add sanity checks while debugging this would be very helpful.<br><br>If ne=
eded, I can share a backtrace, pipeline description, or more details about =
the RTP stream characteristics.<br></div></blockquote><div><br></div><div>Y=
es, provide as much useful information as you have, backtrace are the most =
important, some context of what may trigger the issue too.</div><div><br></=
div><div>cheers,</div><div>Nicolas</div><blockquote type=3D"cite" style=3D"=
margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"></blockq=
uote><div><br></div><div><span></span></div></body></html>
--=-2o2hqH+7Qc/m0MZID0VB--
--=-UG51i0WVQuTZhL/7oR8A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQTvDVKBFcTDwhoEbxLZQZRRKWBy9AUCaV5tTAAKCRDZQZRRKWBy
9H1iAP9L5S1tyA0unLZiqvDMb+D5cRcR6Ih+qAJ9r69s+0a9DgEAk8a9MGHdJrIs
XBQYi9KXy20me25lIzXe1BHoMLoLcAw=
=2TiC
-----END PGP SIGNATURE-----
--=-UG51i0WVQuTZhL/7oR8A--