srt-test-relay usage

[lhh31]

I am testing out the srt-test-relay binary for testing of a bidirectional link.

Can someone confirm this is the correct usage:

./srt-test-relay srt://127.0.0.1:5071 -o udp://127.0.0.1:9999?port=6000 -i udp://:6000

./srt-test-relay srt://:5071 -o udp://127.0.0.1:6001?port=9999 -i udp://:9999

I can see that the connection is started (tcpdump I can see four packets exchanged) but then everything goes badly and crashes (segmentation fault). The line of code that appears to cause the issue is the srt_recvmsg2: [5003.0] Operation not supported: Bad parameters. I assume this is because the CLI arguments are incorrectly formatted in some way?

Print out from the trace below (using -v -ll debug -lf all)

SETTINGS:
SRT connection: srt://:5071
INPUT: udp://:9999
OUTPUT LIST:
        udp://127.0.0.1:6001?port=9999
Setting up output: udp://127.0.0.1:6001?port=9999
Establishing SRT connection: srt://:5071
Setting up listener: port=5071 backlog=5
15:26:08.957204/srt-test-relay D:SRT.sm: generateSocketID: : @105135158
Binding a server on :5071 ...
15:26:08.957347/srt-test-relay D:SRT.km: CHANNEL: Bound to local address: 0.0.0.0:5071
 listen... Accepting a client...
 accept...15:26:09.851044/SRT:RcvQ:w1.N:SRT.cn: PASSING request from: 127.0.0.1:55322 to agent:105135158
15:26:09.851216/SRT:RcvQ:w1.N:SRT.cn: Listener managed the connection request from: 127.0.0.1:55322 result:waveahand
15:26:09.902627/SRT:RcvQ:w1.N:SRT.cn: PASSING request from: 127.0.0.1:55322 to agent:105135158
15:26:09.902725/SRT:RcvQ:w1 D:SRT.sm: generateSocketID: : @105135157
15:26:09.903433/SRT:RcvQ:w1.N:SRT.cn: HSREQ/rcv: cmd=1(HSREQ) len=12 vers=0x10402 opts=0xbf delay=120
 connected [127.0.0.1:5071] <-- 127.0.0.1:55322
... GOT CLIENT for stream []
... Established. configuring other pipes:
DEFAULT CHUNKSIZE used: 1316
Setting up input: udp://:9999
MEDIA SUCCESSFULLY CREATED.
SrtCommon: DESTROYING SERVER, closing socket (ls%105135158)...
15:26:09.903732/SRT:RcvQ:w1.N:SRT.cn: listen ret: -1 - conclusion
SrtCommon: ... done.
STARTING OUTPUT threads:
STARTING SRT INPUT LOOP
Starting TargetMedium: 0x5572391ea710
STARTING INPUT
Starting SourceMedium: 0x7fff9b90d198
15:26:09.904021/SRT:RcvQ:w1.N:SRT.cn: Listener managed the connection request from: 127.0.0.1:55322 result:waveahand
Starting SourceMedium: 0x7fff9b90d240
RUNNING SRT MEDIA LOOP
RUNNING INPUT LOOP
Segmentation fault

and

SETTINGS:
SRT connection: srt://127.0.0.1:5071
INPUT: udp://:6000
OUTPUT LIST:
        udp://127.0.0.1:9999?port=6000
Setting up output: udp://127.0.0.1:9999?port=6000
Establishing SRT connection: srt://127.0.0.1:5071
15:26:09.799647/srt-test-relay D:SRT.sm: generateSocketID: : @238156947
NO STREAM ID for SRT connection
Connecting to 127.0.0.1:5071 ... 15:26:09.930182/srt-test-relay.N:SRT.cn: @238156947:Connection established to: 127.0.0.1:5071
 connected.
Extracted outgoing port: 55322
... Established. configuring other pipes:
DEFAULT CHUNKSIZE used: 1316
Setting up input: udp://:6000
MEDIA SUCCESSFULLY CREATED.
STARTING OUTPUT threads:
STARTING SRT INPUT LOOP
STARTING INPUT
RUNNING SRT MEDIA LOOP
Starting SourceMedium: 0x7ffc78873778
15:26:09.949626/SourceRN*E:SRT.ar: Length of '0' supplied to srt_recvmsg.
FAILURE
srt_recvmsg2: [5003.0] Operation not supported: Bad parameters
RUNNING INPUT LOOP
Starting SourceMedium: 0x7ffc78873820
Segmentation fault

[ethouris]

Ok, I've tried with slightly different parameters (I have two signal sources on UDP :9999 and :5555 and passed them as input respectively), but it doesn't reproduce on my machine (if I allow logs, they look ugly, but the transmission didn't break for at least 30 seconds as I ran the test). Can you describe what kind of signal you set up to UDP ports :9999 and :6000? If you could also somehow reach the backtrace at the crash, it would be most helpful.

[ethouris]

@lhh31 Please note that with no response more than 1 month the ticket will be closed soon (about 10 days).

[lhh31]

@ethouris - sorry for the delayed response. I have no signal transmitting on 9999 or 6000 when I start the two relay pipe lines.

What exact commands did you try? I can retry them.

Here is the backtraces

gdb -ex=r --args ./srt-test-relay srt://127.0.0.1:5071 -o udp://127.0.0.1:9999?port=6000 -i udp://:6000
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 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-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
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 ./srt-test-relay...done.
Starting program: /home/gcp-mptcp/srt/srt/testing/srt-test-relay srt://127.0.0.1:5071 -o udp://127.0.0.1:9999\?port=6000 -i udp://:6000
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff773c700 (LWP 31354)]
[New Thread 0x7ffff6f3b700 (LWP 31355)]
[New Thread 0x7ffff673a700 (LWP 31356)]
[New Thread 0x7ffff5ea3700 (LWP 31361)]
[New Thread 0x7ffff56a2700 (LWP 31362)]
[New Thread 0x7ffff4ea1700 (LWP 31363)]
[New Thread 0x7fffeffff700 (LWP 31364)]

Thread 8 "InputRN" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffeffff700 (LWP 31364)]
0x00005555555c9add in srt_logging::LogDispatcher::Proxy::Proxy(srt_logging::LogDispatcher&) ()
(gdb) bt
#0  0x00005555555c9add in srt_logging::LogDispatcher::Proxy::Proxy(srt_logging::LogDispatcher&) ()
#1  0x00005555555c9ba9 in srt_logging::LogDispatcher::operator()() ()
#2  0x000055555557238f in SrtMainLoop::InputRunner (this=0x7fffffffd760) at srt-test-relay.cpp:695
#3  0x0000555555572510 in SrtMainLoop::<lambda()>::operator()(void) const (__closure=0x5555556b0128)
    at srt-test-relay.cpp:733
#4  0x0000555555573541 in std::__invoke_impl<void, SrtMainLoop::run()::<lambda()> >(std::__invoke_other, SrtMainLoop::<lambda()> &&) (__f=...) at /usr/include/c++/8/bits/invoke.h:60
#5  0x000055555557329f in std::__invoke<SrtMainLoop::run()::<lambda()> >(SrtMainLoop::<lambda()> &&) (__fn=...)
    at /usr/include/c++/8/bits/invoke.h:95
#6  0x000055555557491e in std::thread::_Invoker<std::tuple<SrtMainLoop::run()::<lambda()> > >::_M_invoke<0>(std::_Index_tuple<0>) (this=0x5555556b0128) at /usr/include/c++/8/thread:244
#7  0x00005555555748f4 in std::thread::_Invoker<std::tuple<SrtMainLoop::run()::<lambda()> > >::operator()(void) (
    this=0x5555556b0128) at /usr/include/c++/8/thread:253
#8  0x00005555555748d8 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<SrtMainLoop::run()::<lambda()> > > >::_M_run(void) (this=0x5555556b0120) at /usr/include/c++/8/thread:196
#9  0x00007ffff7b61b2f in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#10 0x00007ffff7facfa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#11 0x00007ffff783f4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

and

gdb -ex=r --args ./srt-test-relay srt://:5071 -o udp://127.0.0.1:6001?port=9999 -i udp://:9999
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 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-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
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 ./srt-test-relay...done.
Starting program: /home/gcp-mptcp/srt/srt/testing/srt-test-relay srt://:5071 -o udp://127.0.0.1:6001\?port=9999 -i udp://:9999
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff773c700 (LWP 31345)]
[New Thread 0x7ffff6f3b700 (LWP 31346)]
[New Thread 0x7ffff673a700 (LWP 31347)]
[New Thread 0x7ffff5ea3700 (LWP 31357)]
[New Thread 0x7ffff56a2700 (LWP 31358)]
[New Thread 0x7ffff4ea1700 (LWP 31359)]
[New Thread 0x7fffeffff700 (LWP 31360)]

Thread 8 "InputRN" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffeffff700 (LWP 31360)]
0x00005555555c9add in srt_logging::LogDispatcher::Proxy::Proxy(srt_logging::LogDispatcher&) ()
(gdb) bt
#0  0x00005555555c9add in srt_logging::LogDispatcher::Proxy::Proxy(srt_logging::LogDispatcher&) ()
#1  0x00005555555c9ba9 in srt_logging::LogDispatcher::operator()() ()
#2  0x000055555557238f in SrtMainLoop::InputRunner (this=0x7fffffffd760) at srt-test-relay.cpp:695
#3  0x0000555555572510 in SrtMainLoop::<lambda()>::operator()(void) const (__closure=0x5555556b02e8)
    at srt-test-relay.cpp:733
#4  0x0000555555573541 in std::__invoke_impl<void, SrtMainLoop::run()::<lambda()> >(std::__invoke_other, SrtMainLoop::<lambda()> &&) (__f=...) at /usr/include/c++/8/bits/invoke.h:60
#5  0x000055555557329f in std::__invoke<SrtMainLoop::run()::<lambda()> >(SrtMainLoop::<lambda()> &&) (__fn=...)
    at /usr/include/c++/8/bits/invoke.h:95
#6  0x000055555557491e in std::thread::_Invoker<std::tuple<SrtMainLoop::run()::<lambda()> > >::_M_invoke<0>(std::_Index_tuple<0>) (this=0x5555556b02e8) at /usr/include/c++/8/thread:244
#7  0x00005555555748f4 in std::thread::_Invoker<std::tuple<SrtMainLoop::run()::<lambda()> > >::operator()(void) (
    this=0x5555556b02e8) at /usr/include/c++/8/thread:253
#8  0x00005555555748d8 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<SrtMainLoop::run()::<lambda()> > > >::_M_run(void) (this=0x5555556b02e0) at /usr/include/c++/8/thread:196
#9  0x00007ffff7b61b2f in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#10 0x00007ffff7facfa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#11 0x00007ffff783f4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

[ethouris]

Ok, sorry for the delay on my side this time.

There is one potential place that I can see might have caused this - the constructor that is on top refers to a pointer, but then, all of these refer to global variables.

I can see one possibility: you have the application and the library compiled with different build flags. Please make sure first that you have a clean build.

If that's not the case, please try to see at the place where it breaks what exactly is contained in the parameter passed to Proxy constructor (print guy inside gdb). I'm unable to reproduce it and I can only trace things theoretically.

[maxsharabayko]

Closing as inactive.