Hello Ross, Now I use the new version live.2022.11.29.tar.gz. And still get the same SIGSEGV:
gaj@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-boun...@us.live555.com> im Auftrag von Ross Finlayson <finlay...@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@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
