[Live-devel] Crash in MPEG4/H264/H265 VideoFileServerMediaSubSession

[Robert Suijker]

Hi Ross,

Thanks for the input so far.

> By this I presume you meant that you ran the (unmodified) "LIVE555 Media Server" with a zero-length file named "media.264"

Yes, this is correct, unmodified live 555 code (latest version) and a zero length media.265 file. This was a typo on my side :(

> Also, at least one part of your explanation is wrong.  You said - in a couple of places - that "fDummyRTPSink" is a pointer to your own 'source filter' object that you freed.

I can't recall that I said that I freed the object myself, this is certainly not what I do. But I made an error saying it was the source filter, but I meant the RTPSink.


I've tested again with the DynamicRTSPServer (unmodified) and this time with the testRTSPClient (also unmodified). Running again I've the same *crash*. Tested on Window 7 and 8.
I've added the client output at the end of this mail. What I see is that the server does return a SDP, but I'm missing the a=fmtp line. Testing with the slamtv10.264 file everything works
as expected of course ;-)

I've followed program of the server execution in the Visual Studio 2013 debugger and I get an access violation accessing 0xfeeefeee which is an indication that the program is
accessing freed memory. I've traced method execution a little bit better this time and this is what I see executed (again, debugged compiled server from  unmodified source code):

When a DESCRIBE request is handled: generateSDPDescription() will be call which calls sdpLines() on the OnDemandServerMediaSubsession object.
sdpLines() will create a new streamSource (aka FramedSource) and a dummy RTPSink with this source. It will then call setSDPLinesFromRTPSink()
which will call getAuxSDPLine() which is implemented in H265/H265/MPEG4VideoFileServerMediaSubsession.

getAuxSDPLine() assigned a the passed rtpSink pointer to fDummyRTPSink. Then it will initiate startPlaying() which will eventually call into
ByteStreamFileSource::doGetNextFrame(). Since it is an zero length file the source will call handleClosure(). This eventually will trigger afterPlayingDummy1()
which set the done flag with setDoneFlag().

Then we end up after the next line after startPlaying() in getAuxSDPLine() which is checkForAuxSDPLine(), this will fail also to read bytes so it ends
up in the final else which will schedule a task checkForAuxSDPLine().

Again we end up in getAuxSDPLine() which execute the envir().taskScheduler().doEventLoop(&fDoneFlag) but will exit since the done flag was set.

Then we're back in OnDemandServerMediaSubsession::sdpLines() which will call Medium::close(dummyRTPSink) and closeStreamSource(inputSource) closing
the inputSource. Both will call the virtual destructors on Medium.

Since there is still one scheduled task left from the else in checkForAuxSDPLine1() it will (when entering the main loop) call back into
checkForAuxSDPLine1() which will crash on fDummRTPSink->auxSDPLine() which will access the rtpSink (and through it the source) which are already deleted.

So I do see an execution order that will eventual access a freed object (rtpSink). I hope this explains it a bit more clear.

Regards,
Robert Sujker


Output of the server/client:

Opening connection to 127.0.0.1, port 8554...
...remote connection opened
Sending request: DESCRIBE rtsp://localhost:8554/media.264 RTSP/1.0
CSeq: 2
User-Agent: rtsp_client.exe (LIVE555 Streaming Media v2014.02.26)
Accept: application/sdp


Received 562 new bytes of response data.
Received a complete DESCRIBE response:
RTSP/1.0 200 OK
CSeq: 2
Date: Fri, Mar 14 2014 13:30:59 GMT
Content-Base: rtsp://127.0.0.1:8554/media.264/
Content-Type: application/sdp
Content-Length: 397

v=0
o=- 1394803859323704 1 IN IP4 10.0.0.193
s=H.264 Video, streamed by the LIVE555 Media Server
i=media.264
t=0 0
a=tool:LIVE555 Streaming Media v2014.02.26
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:H.264 Video, streamed by the LIVE555 Media Server
a=x-qt-text-inf:media.264
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:500
a=rtpmap:96 H264/90000
a=control:track1

[URL:"rtsp://127.0.0.1:8554/media.264/"]: Got a SDP description:
v=0
o=- 1394803859323704 1 IN IP4 10.0.0.193
s=H.264 Video, streamed by the LIVE555 Media Server
i=media.264
t=0 0
a=tool:LIVE555 Streaming Media v2014.02.26
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:H.264 Video, streamed by the LIVE555 Media Server
a=x-qt-text-inf:media.264
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:500
a=rtpmap:96 H264/90000
a=control:track1

[URL:"rtsp://127.0.0.1:8554/media.264/"]: Initiated the "video/H264" subsession (client ports 58194-58195)
Sending request: SETUP rtsp://127.0.0.1:8554/media.264/track1 RTSP/1.0
CSeq: 3
User-Agent: rtsp_client.exe (LIVE555 Streaming Media v2014.02.26)
Transport: RTP/AVP;unicast;client_port=58194-58195


Received 208 new bytes of response data.
Received a complete SETUP response:
RTSP/1.0 200 OK
CSeq: 3
Date: Fri, Mar 14 2014 13:30:59 GMT
Transport: RTP/AVP;unicast;destination=127.0.0.1;source=127.0.0.1;client_port=58194-58195;server_port=6970-6971
Session: A2DE3417;timeout=65


[URL:"rtsp://127.0.0.1:8554/media.264/"]: Set up the "video/H264" subsession (client ports 58194-58195)
[URL:"rtsp://127.0.0.1:8554/media.264/"]: Created a data sink for the "video/H264" subsession
Sending request: PLAY rtsp://127.0.0.1:8554/media.264/ RTSP/1.0
CSeq: 4
User-Agent: rtsp_client.exe (LIVE555 Streaming Media v2014.02.26)
Session: A2DE3417
Range: npt=0.000-


[URL:"rtsp://127.0.0.1:8554/media.264/"]: Received RTCP "BYE" on "video/H264" subsession
[URL:"rtsp://127.0.0.1:8554/media.264/"]: Closing the stream.
This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.