[Live-devel] openRTSP crash when receiving stream via https

Gajdosik Johannes j.gajdosik at pke.at
Wed Nov 30 05:32:28 PST 2022


Hello Ross,

Now I use the new version live.2022.11.29.tar.gz. And still get the same SIGSEGV:


gaj at gajdosik /sdb3/JohannesGajdosikPKE/live.2022.11.29/testProgs $ gdb ./openRTSP
GNU gdb (Gentoo 8.3.1 vanilla) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./openRTSP...
(gdb) r -T 8880 rtsps://localhost:5554/h265
Starting program: /sdb3/JohannesGajdosikPKE/live.2022.11.29/testProgs/openRTSP -T 8880 rtsps://localhost:5554/h265
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Created new TCP socket 3 for connection
Connecting to 127.0.0.1, port 8880 on socket 3...
...TLS connection completed
...remote connection opened
Requesting RTSP-over-HTTP tunneling (on port 8880)

Sending request: GET /h265 HTTP/1.0
CSeq: 1
User-Agent: /sdb3/JohannesGajdosikPKE/live.2022.11.29/testProgs/openRTSP (LIVE555 Streaming Media v2022.11.29)
Host: 127.0.0.1
x-sessioncookie: e0d2b3517a29121835e3e7c
Accept: application/x-rtsp-tunnelled
Pragma: no-cache
Cache-Control: no-cache


Received 143 new bytes of response data.
Received a complete GET response:
HTTP/1.0 200 OK
Date: Wed, Nov 30 2022 12:19:45 GMT
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/x-rtsp-tunnelled


Connecting to 127.0.0.1, port 8880 on socket 4...
Sending request: POST /h265 HTTP/1.0
CSeq: 1
User-Agent: /sdb3/JohannesGajdosikPKE/live.2022.11.29/testProgs/openRTSP (LIVE555 Streaming Media v2022.11.29)
Host: 127.0.0.1
x-sessioncookie: e0d2b3517a29121835e3e7c
Content-Type: application/x-rtsp-tunnelled
Pragma: no-cache
Cache-Control: no-cache
Content-Length: 32767
Expires: Sun, 9 Jan 1972 00:00:00 GMT


Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7f3380c in ssl_write_internal () from /usr/lib64/libssl.so.1.1
(gdb) bt
#0  0x00007ffff7f3380c in ssl_write_internal () from /usr/lib64/libssl.so.1.1
#1  0x00007ffff7f339a3 in SSL_write () from /usr/lib64/libssl.so.1.1
#2  0x000055555559cc13 in TLSState::write (this=0x55555562d958,
    data=0x55555566ae40 "POST /h265 HTTP/1.0\r\nCSeq: 1\r\nUser-Agent: /sdb3/JohannesGajdosikPKE/live.2022.11.29/testProgs/openRTSP (LIVE555 Streaming Media v2022.11.29)\r\nHost: 127.0.0.1\r\nx-sessioncookie: e0d2b3517a29121835e3e7c\r"..., count=352) at TLSState.cpp:45
#3  0x0000555555589084 in RTSPClient::write (this=0x55555562d760,
    data=0x55555566ae40 "POST /h265 HTTP/1.0\r\nCSeq: 1\r\nUser-Agent: /sdb3/JohannesGajdosikPKE/live.2022.11.29/testProgs/openRTSP (LIVE555 Streaming Media v2022.11.29)\r\nHost: 127.0.0.1\r\nx-sessioncookie: e0d2b3517a29121835e3e7c\r"..., count=352) at RTSPClient.cpp:2028
#4  0x000055555558330c in RTSPClient::sendRequest (this=0x55555562d760, request=0x555555658a40) at RTSPClient.cpp:581
#5  0x0000555555587480 in RTSPClient::setupHTTPTunneling2 (this=0x55555562d760) at RTSPClient.cpp:1615
#6  0x0000555555587683 in RTSPClient::connectionHandler1 (this=0x55555562d760) at RTSPClient.cpp:1647
#7  0x00005555555874cd in RTSPClient::connectionHandler (instance=0x55555562d760) at RTSPClient.cpp:1620
#8  0x00005555555e1ab4 in BasicTaskScheduler::SingleStep (this=0x55555562ceb0, maxDelayTime=0) at BasicTaskScheduler.cpp:171
#9  0x00005555555e41f8 in BasicTaskScheduler0::doEventLoop (this=0x55555562ceb0, watchVariable=0x0) at BasicTaskScheduler0.cpp:80
#10 0x000055555556e10c in main (argc=2, argv=0x7fffffffdfc8) at playCommon.cpp:654
(gdb) f 2
#2  0x000055555559cc13 in TLSState::write (this=0x55555562d958,
    data=0x55555566ae40 "POST /h265 HTTP/1.0\r\nCSeq: 1\r\nUser-Agent: /sdb3/JohannesGajdosikPKE/live.2022.11.29/testProgs/openRTSP (LIVE555 Streaming Media v2022.11.29)\r\nHost: 127.0.0.1\r\nx-sessioncookie: e0d2b3517a29121835e3e7c\r"..., count=352) at TLSState.cpp:45
45        return SSL_write(fCon, data, count);
(gdb) p *this
$1 = {_vptr.TLSState = 0x55555560c620 <vtable for ClientTLSState+16>, isNeeded = 1 '\001', fHasBeenSetup = 0 '\000', fCtx = 0x0, fCon = 0x0}
(gdb) f 3
#3  0x0000555555589084 in RTSPClient::write (this=0x55555562d760,
    data=0x55555566ae40 "POST /h265 HTTP/1.0\r\nCSeq: 1\r\nUser-Agent: /sdb3/JohannesGajdosikPKE/live.2022.11.29/testProgs/openRTSP (LIVE555 Streaming Media v2022.11.29)\r\nHost: 127.0.0.1\r\nx-sessioncookie: e0d2b3517a29121835e3e7c\r"..., count=352) at RTSPClient.cpp:2028
2028            return fOutputTLS->write(data, count);
(gdb) p *this
$2 = {<Medium> = {_vptr.Medium = 0x55555560dcb8 <vtable for RTSPClient+16>, fEnviron = @0x55555562d340, fMediumName = "liveMedia0", '\000' <repeats 19 times>, fNextTask = 0x0},
  static responseBufferSize = 20000, desiredMaxIncomingPacketSize = 0, fVerbosityLevel = 1, fCSeq = 2, fCurrentAuthenticator = {_vptr.Authenticator = 0x55555560c6c0 <vtable for Authenticator+16>,
    fRealm = 0x0, fNonce = 0x0, fUsername = 0x55555562da90 "", fPassword = 0x55555562dab0 "", fPasswordIsMD5 = 0 '\000'}, fAllowBasicAuthentication = 1 '\001', fServerAddress = {ss_family = 2,
    __ss_padding = "\"\260\177\000\000\001", '\000' <repeats 111 times>, __ss_align = 0}, fTunnelOverHTTPPortNum = 8880,
  fUserAgentHeaderStr = 0x5555556329c0 "User-Agent: /sdb3/JohannesGajdosikPKE/live.2022.11.29/testProgs/openRTSP (LIVE555 Streaming Media v2022.11.29)\r\n", fUserAgentHeaderStrLen = 112,
  fInputSocketNum = 3, fOutputSocketNum = 4, fBaseURL = 0x55555562dad0 "rtsps://localhost:5554/h265", fTCPStreamIdCount = 0 '\000', fLastSessionId = 0x0, fSessionTimeoutParameter = 0,
  fResponseBuffer = 0x55555562db00 "HTTP/1.0 200 OK\r\nDate: Wed, Nov 30 2022 12:19:45 GMT\r\nCache-Control: no-cache\r\nPragma: no-cache\r\nContent-Type: application/x-rtsp-tunnelled\r\n\r\n",
  fResponseBytesAlreadySeen = 0, fResponseBufferBytesLeft = 20000, fRequestsAwaitingConnection = {_vptr.RequestQueue = 0x55555560c4d0 <vtable for RTSPClient::RequestQueue+16>, fHead = 0x0,
    fTail = 0x0}, fRequestsAwaitingHTTPTunneling = {_vptr.RequestQueue = 0x55555560c4d0 <vtable for RTSPClient::RequestQueue+16>, fHead = 0x0, fTail = 0x0}, fRequestsAwaitingResponse = {
    _vptr.RequestQueue = 0x55555560c4d0 <vtable for RTSPClient::RequestQueue+16>, fHead = 0x0, fTail = 0x0}, fRequireStr = 0x555555632930 "",
  fSessionCookie = "e0d2b3517a29121835e3e7c\000\064d6f90eb", fSessionCookieCounter = 1, fHTTPTunnelingConnectionIsPending = 0 '\000', fTLS = {<TLSState> = {
      _vptr.TLSState = 0x55555560c620 <vtable for ClientTLSState+16>, isNeeded = 1 '\001', fHasBeenSetup = 1 '\001', fCtx = 0x55555563a370, fCon = 0x555555659170}, fClient = @0x55555562d760},
  fPOSTSocketTLS = {<TLSState> = {_vptr.TLSState = 0x55555560c620 <vtable for ClientTLSState+16>, isNeeded = 1 '\001', fHasBeenSetup = 0 '\000', fCtx = 0x0, fCon = 0x0}, fClient = @0x55555562d760},
  fInputTLS = 0x55555562d930, fOutputTLS = 0x55555562d958}
(gdb) p &fPOSTSocketTLS
$3 = (ClientTLSState *) 0x55555562d958
(gdb) p *fInputTLS
$4 = {<TLSState> = {_vptr.TLSState = 0x55555560c620 <vtable for ClientTLSState+16>, isNeeded = 1 '\001', fHasBeenSetup = 1 '\001', fCtx = 0x55555563a370, fCon = 0x555555659170},
  fClient = @0x55555562d760}
(gdb) p *fOutputTLS
$5 = {<TLSState> = {_vptr.TLSState = 0x55555560c620 <vtable for ClientTLSState+16>, isNeeded = 1 '\001', fHasBeenSetup = 0 '\000', fCtx = 0x0, fCon = 0x0}, fClient = @0x55555562d760}


In the debugger I see 2 different TLSState objects: *fInputTLS (at 0x55555562d930), which is initialized.
and fPOSTSocketTLS (at 0x55555562d958), which fOutputTLS is pointing to, and which is uninitialized.
Using the uninitialized fPOSTSocketTLS aka *fOutputTLS in frame #2: TLSState::write (this=0x55555562d958,...) gives SIGSEGV

I am new to the code, but this is my analysis:

fOutputTLS can only be initialized in RTSPClient::responseHandlerForHTTP_GET1.

In this function connectResult is set:

int connectResult = connectToServer(...)

On my computer connectResult is always 0, because connect returns EINPROGRESS.
Therefore fOutputTLS->connect can never be called and fOutputTLS is always uninitialized.

Later, when the connection is established, connectionHander1 is called, which initializes fInputTLS, but fOutputTLS remains uninitialized.


Yours,

Johannes

________________________________
Von: live-devel <live-devel-bounces at us.live555.com> im Auftrag von Ross Finlayson <finlayson at live555.com>
Gesendet: Dienstag, 29. November 2022 23:24:12
An: LIVE555 Streaming Media - development & use
Betreff: Re: [Live-devel] openRTSP crash when receiving stream via https

Johannes,

Thanks for the report.

Yes, there was a bug in the RTSP client’s implementation of RTSP-over-HTTP streaming, when done over TLS.  I have just installed a new version (2022.11.29) of the code that should fix this.  (But should you still encounter problems, let us know.)


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/


_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel



More information about the live-devel mailing list