Refactor stream locking

[catalinii]

No description provided.

[VizDock]

I started it yesterday when I got email notification about your PR
Watched TV until evening and fell asleep with TV on. I just woke up and it doesn't work. So I don't know exactly when it stopped.
Here is the log
minisatip.zip

[catalinii]

@VizDock can u try now ?

[VizDock]

@VizDock can u try now ?

Of course, started it. I'll let you know if/when it stucks..

[VizDock]

This time it was not stuck in the middle of the watching of some channel. Instead it was working fine until I switched channel to some other.. here is the log

minisatip.zip

[catalinii]

@VizDock can u try again ?

[VizDock]

yes, downloaded, started.. will report back

[VizDock]

Its still working..but just a funny thing I noticed right now while testing.
Was watching dvbt channel and switched to CNN on dvbs, while waiting for channel to show, minisatip went to 100% CPU. When it showed, it was working normally, below 1%. Managed to replicate

But on this replicating issue by switching to HBO, it didn't start stream. Got

After that I switched to DVBT and it showed channel fast, but CPU stayed at 100%

After 2 minutes of watching, it went back to 1%
When it went to 1% I tried again switching to HBO, and it switched fast.

Not sure if this is relevant, just observation

[catalinii]

Do u have the log and provide the exact timestamp when it was 100% ? in one of the screenshots you have for how long is the system up, maybe you can use that to get the TS, or try to reproduce

[Jalle19]

@catalinii should we revert the changes for now so master works for users? We can figure out how to replace the old mutex locks at a later stage

[Jalle19]

I'm reluctant to upgrade myself because I've just found a version that works for me needs (2.0.26) :D

[VizDock]

I didn't had time today to reproduce, but this version works stable for 3 days almost. Which is amazing. (except the stuff which I mentioned above.. I consider it a hiccup)

[catalinii]

@VizDock can you try the latest diff?

[VizDock]

Sure, started it now, will report if something happens.
But the previous version worked without restart until now. Multiple TV's in house watching different channels, except occasional stuff I mentioned above, never hanged..

[VizDock]

minisatip.log

CPU at 100% with this version..
Log is small

[VizDock]

Now after 10 minutes CPU went below 1%
Didn't switch channel (kids were watching nickelodeon whole time)
minisatip.log

[catalinii]

Can you run gdb —args ./minisatip …

when the cpu is 100% run
thread apply all bt

and provide the output

[VizDock]

Nothing is shown when I type that. Anything else I can try?

[VizDock]

I just noticed after I posted that even if all Kodi clients to tvheadend are closed (turned off), minisatip still consumes 100% for some time

[VizDock]

I think I screwed up, seems I forgot to stop minisatip service (main one) b4 starting it with debugger :)
Will retry later

[catalinii]

After you start in the debigger type “run” without quotes to start minisatip in the debugger

[catalinii]

If it stops before 100% cpu usage type “continue”

[VizDock]

huh, now I made sure minisatip is not running b4 I started it in debugger, but same, no output on command you wrote

[VizDock]

I started it in foreground mode now, switched channels until CPU went to 100%, pressed ctrl+c at that time and wrote your command
This is output
Thread 1 "minisatip" received signal SIGINT, Interrupt.
0x0000000000872fca in __memset_avx2_unaligned_erms ()
(gdb) thread apply all bt

Thread 10 (LWP 22837 "AD6"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=34, __fds=0x7fffd77f9980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 9 (LWP 22836 "AD5"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=34, __fds=0x7fffd7ffa980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 8 (LWP 22834 "AD4"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=34, __fds=0x7ffff4d69980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 7 (LWP 22832 "AD3"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=34, __fds=0x7ffff556a980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 6 (LWP 22830 "AD2"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=34, __fds=0x7ffff5d6b980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 5 (LWP 22828 "AD1"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=34, __fds=0x7ffff656c980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 4 (LWP 22826 "AD0"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=34, __fds=0x7ffff6d6d980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 3 (LWP 22824 "CA_poll"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=34, __fds=0x7ffff77f2980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 2 (LWP 22823 "signal"):
#0 0x00000000008a527d in ioctl ()
#1 0x000000000045436f in get_signal_new (ad=ad@entry=0xb2e320, status=status@entry=0x7ffff7ff3810, ber=ber@entry=0x7ffff7ff3814, strength=strength@entry=0x7ffff7ff380a, snr=snr@entry=0x7ffff7ff380c, db=db@entry=0x7ffff7ff380e) at dvb.cpp:1886
#2 0x0000000000454875 in dvb_get_signal (ad=0xb2e320) at dvb.cpp:1935
#3 0x00000000004219e5 in signal_thread (s=) at adapter.cpp:2064
#4 0x00000000004131d6 in select_and_execute (arg=) at socketworks.cpp:904
#5 0x000000000085ba1c in start_thread ()
#6 0x00000000008a78dc in clone3 ()

Thread 1 (LWP 22817 "minisatip"):
#0 0x0000000000872fca in __memset_avx2_unaligned_erms ()
#1 0x0000000000410657 in memset (__len=65536, __ch=0, __dest=0x7ffffffe9670) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:59
#2 writev_udp (rsock=22, iov=0x7fffffff9750, iiov=1) at socketworks.cpp:1169
#3 0x0000000000411465 in my_writev (s=s@entry=0xb42010, iov=iov@entry=0x7fffffff9750, iiov=1) at socketworks.cpp:1213
#4 0x0000000000411940 in flush_socket_all (s=s@entry=0xb42010, used=1770732) at socketworks.cpp:1424
#5 0x0000000000411dc5 in flush_socket (s=s@entry=0xb42010) at socketworks.cpp:1483
#6 0x000000000041331a in select_and_execute (arg=arg@entry=0x0) at socketworks.cpp:739
#7 0x0000000000406b6d in main (argc=, argv=) at minisatip.cpp:1914

[VizDock]

I didn't know if ctrl-c exits minisatip before gdb pauses it, so I tried continue after ctrl+c and it continued. Playing of channel resumed on TV

But here is once more (second time)
Thread 10 (LWP 22837 "AD6"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=29, __fds=0x7fffd77f9980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 9 (LWP 22836 "AD5"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=29, __fds=0x7fffd7ffa980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 8 (LWP 22834 "AD4"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=29, __fds=0x7ffff4d69980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 7 (LWP 22832 "AD3"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=29, __fds=0x7ffff556a980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 6 (LWP 22830 "AD2"):
#0 0x000000000085b1f0 in __lll_lock_wait ()
#1 0x000000000085d997 in pthread_mutex_lock ()
#2 0x0000000000418f12 in __gthread_mutex_lock (__mutex=0xb2b3a8) at /usr/include/x86_64-linux-gnu/c++/13/bits/gthr-default.h:749
#3 __gthread_recursive_mutex_lock (__mutex=0xb2b3a8) at /usr/include/x86_64-linux-gnu/c++/13/bits/gthr-default.h:811
#4 std::recursive_mutex::lock (this=0xb2b3a8) at /usr/include/c++/13/mutex:120
#5 read_dmx (s=0xb3a600) at stream.cpp:1136
#6 0x0000000000412d77 in select_and_execute (arg=) at socketworks.cpp:835
#7 0x000000000085ba1c in start_thread ()
#8 0x00000000008a78dc in clone3 ()

Thread 5 (LWP 22828 "AD1"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=29, __fds=0x7ffff656c980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 4 (LWP 22826 "AD0"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=29, __fds=0x7ffff6d6d980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 3 (LWP 22824 "CA_poll"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=29, __fds=0x7ffff77f2980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 2 (LWP 22823 "signal"):
#0 0x00000000008a527d in ioctl ()
#1 0x000000000045436f in get_signal_new (ad=ad@entry=0xb2b3a0, status=status@entry=0x7ffff7ff3810, ber=ber@entry=0x7ffff7ff3814, strength=strength@entry=0x7ffff7ff380a, snr=snr@entry=0x7ffff7ff380c, db=db@entry=0x7ffff7ff380e) at dvb.cpp:1886
#2 0x0000000000454875 in dvb_get_signal (ad=0xb2b3a0) at dvb.cpp:1935
#3 0x00000000004219e5 in signal_thread (s=) at adapter.cpp:2064
#4 0x00000000004131d6 in select_and_execute (arg=) at socketworks.cpp:904
#5 0x000000000085ba1c in start_thread ()
#6 0x00000000008a78dc in clone3 ()

Thread 1 (LWP 22817 "minisatip"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=29, __fds=0x7fffffff98b0) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=arg@entry=0x0) at socketworks.cpp:710
#3 0x0000000000406b6d in main (argc=, argv=) at minisatip.cpp:1914

[Jalle19]

Thanks @VizDock for helping to debug this, it's very much appreciated!

[VizDock]

Np
I just wish I know more about debugging in linux

[Jalle19]

I don't really see anything that could explain the 100% CPU usage. @catalinii ?

[catalinii]

There are 2 options: 1) mutexes, but I see pthread_mutex_lock is used which is unlikely to cause cpu usage, also does not appear on all traces
2)ioctl while getting the signal, which is more frequent

@VizDock can u provide more traces? Also provide the top -H screenshot + trace more or less at the same time, maybe we can identity the thread that causes cpu usage

[VizDock]

This is screenshot with top -H at the time it went to 100%
Can't run in debug mode at the moment cos everyone at home is watching tv :)
I couldn't reproduce 100% by switching to channels I normally watch, max I got was 40% of cpu. But when I accidently picked channel that is scrambled and I dont have a way to unscramble it (CAM card doesn't support it), it went to 100% immediatelly

Also, I remembered that sometimes even when I didn't watch anything, it went to 100% and after some minutes it went to 0,7. Maybe TV Headend is doing background scans and get to some scrambled channels? Just an idea

I will definately send you gdb details of threads when get to 100% just when kids go to bed or somewhere..

[VizDock]

I called them at home and told them to go out and play :)
This time I couldn't just choose scrambled channel and go to 100%
had to switch channels alot
When it happened, I pressed ctrl+c in debugger and wrote that command of yours.

Thread 10 (LWP 31193 "AD6"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=32, __fds=0x7fffd77f9980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 9 (LWP 31192 "AD5"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=32, __fds=0x7fffd7ffa980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 8 (LWP 31190 "AD4"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=32, __fds=0x7ffff4d69980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 7 (LWP 31188 "AD3"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=32, __fds=0x7ffff556a980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 6 (LWP 31186 "AD2"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=32, __fds=0x7ffff5d6b980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 5 (LWP 31184 "AD1"):
#0 0x00000000008a433d in poll ()
--Type for more, q to quit, c to continue without paging--
#1 0x00000000004127c7 in poll (__timeout=, __nfds=32, __fds=0x7ffff656c980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 4 (LWP 31182 "AD0"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=32, __fds=0x7ffff6d6d980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 3 (LWP 31180 "CA_poll"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=32, __fds=0x7ffff77f2980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 2 (LWP 31179 "signal"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=32, __fds=0x7ffff7ff3980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 1 (LWP 31173 "minisatip"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=32, __fds=0x7fffffff98b0) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=arg@entry=0x0) at socketworks.cpp:710
#3 0x0000000000406b6d in main (argc=, argv=) at minisatip.cpp:1914

[VizDock]

This is second time.
I just wrote "continue" in debugger and had to switch alot of channels to get to 100% again

Thread 10 (LWP 31193 "AD6"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=27, __fds=0x7fffd77f9980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 9 (LWP 31192 "AD5"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=27, __fds=0x7fffd7ffa980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 8 (LWP 31190 "AD4"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=27, __fds=0x7ffff4d69980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 7 (LWP 31188 "AD3"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=27, __fds=0x7ffff556a980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 6 (LWP 31186 "AD2"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=27, __fds=0x7ffff5d6b980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 5 (LWP 31184 "AD1"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=27, __fds=0x7ffff656c980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 4 (LWP 31182 "AD0"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=27, __fds=0x7ffff6d6d980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 3 (LWP 31180 "CA_poll"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=27, __fds=0x7ffff77f2980) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=) at socketworks.cpp:710
#3 0x000000000085ba1c in start_thread ()
#4 0x00000000008a78dc in clone3 ()

Thread 2 (LWP 31179 "signal"):
#0 0x00000000008a527d in ioctl ()
#1 0x000000000045436f in get_signal_new (ad=ad@entry=0xb2e320, status=status@entry=0x7ffff7ff3810, ber=ber@entry=0x7ffff7ff3814, strength=strength@entry=0x7ffff7ff380a, snr=snr@entry=0x7ffff7ff380c, db=db@entry=0x7ffff7ff380e) at dvb.cpp:1886
#2 0x0000000000454875 in dvb_get_signal (ad=0xb2e320) at dvb.cpp:1935
#3 0x00000000004219e5 in signal_thread (s=) at adapter.cpp:2064
#4 0x00000000004131d6 in select_and_execute (arg=) at socketworks.cpp:904
#5 0x000000000085ba1c in start_thread ()
#6 0x00000000008a78dc in clone3 ()

Thread 1 (LWP 31173 "minisatip"):
#0 0x00000000008a433d in poll ()
#1 0x00000000004127c7 in poll (__timeout=, __nfds=27, __fds=0x7fffffff98b0) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
#2 select_and_execute (arg=arg@entry=0x0) at socketworks.cpp:710
#3 0x0000000000406b6d in main (argc=, argv=) at minisatip.cpp:1914

[VizDock]

I am just wondering if thread with name "minisatip" catches ctrl+c and stops doing what is doing b4 I press ctrl+c so output of command is maybe not relevant..
Asking because I see this below when I press ctrl+c. And obviously, that is the thread that causes 100% of cpu

[08/10 17:25:25.162 AD4]: sockets_del: sock 25 Last open socket is at index 26 current_handle -2
^C
Thread 1 "minisatip" received signal SIGINT, Interrupt.
0x00000000008a433d in poll ()
(gdb) thread apply all bt

Thread 10 (LWP 31193 "AD6"):

[catalinii]

@catalinii should we revert the changes for now so master works for users? We can figure out how to replace the old mutex locks at a later stage

To revert the entire locking changes?

this diff should fix the issue, just the cpu usage but not sure if related to the locking

[catalinii]

This was the only place where we still kept the old locks in place but wanted to convince myself the behavior with c++ locks still holds in place and it does.

ideally want to merge this and see how it goes after

[Jalle19]

@catalinii ignore my previous comment about reverting 👍 we can merge this and go from there, the deadlocking seems to be fixed