¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. N2adr-Sdr
  2. Topics

Segmentation faults with remote mode

 

It's been a while since I've had time to mess with radio stuff that isn't work related. I thought over Christmas I'd dust off the old rig and give 'er a go.

Setup:
Radio = Softrock RXTx on remote side with RPI3 and HiFiBerry DAC/ADC
Control = Ubuntu 22.04 running in parallels on mac.

Things seem to start OK. I get audio and waterfall. However, after some random amount?of time, I'll get a segmentation?fault. If I had to guess, it seems to be related to when things lag on either the network or control side PC (i.e. starting another program) and a buffer overflows.

Tracebacks have not been much help. So far, I've gotten a couple different ones that are pasted below. The only common?point is the line number has something to do with a cw key, which I'm not even utilizing. Could be random though.

Possibly related note: I am running the remote headless, which means I have to pipe the X11 session back to my PC for the quisk window. This alone causes a lot of network overhead. I have been trying to minimize this by changing the remote window over to the "config" screen, but I may need to figure out a way to run the remote quisk instance without GUI feedback.

-Eric
WW4ET (formerly KM4DSJ)


Fatal Python error: Segmentation fault

Thread 0x677ff440 (most recent call first):
? File "/home/ewthornton/.local/lib/python3.9/site-packages/quisk/quisk.py", line 1224 in run
? File "/usr/lib/python3.9/threading.py", line 954 in _bootstrap_inner
? File "/usr/lib/python3.9/threading.py", line 912 in _bootstrap

Current thread 0x76f31980 (most recent call first):
? File "/home/ewthornton/.local/lib/python3.9/site-packages/quisk/quisk.py", line 6266 in OnReadSound
? File "/home/ewthornton/.local/lib/python3.9/site-packages/wx/core.py", line 3407 in <lambda>
? File "/home/ewthornton/.local/lib/python3.9/site-packages/wx/core.py", line 2237 in MainLoop
? File "/home/ewthornton/.local/lib/python3.9/site-packages/quisk/quisk.py", line 6442 in main
? File "/home/ewthornton/.local/bin/quisk", line 8 in <module>
Segmentation fault

----------------------------------------
Fatal Python error: Segmentation fault

Current thread 0x677ff440 (most recent call first):
? File "/home/ewthornton/.local/lib/python3.9/site-packages/quisk/quisk.py", line 1219 in run
? File "/usr/lib/python3.9/threading.py", line 954 in _bootstrap_inner
? File "/usr/lib/python3.9/threading.py", line 912 in _bootstrap

Thread 0x76f7f980 (most recent call first):
? File "/home/ewthornton/.local/lib/python3.9/site-packages/quisk/quisk.py", line 1356 in OnPaint
? File "/home/ewthornton/.local/lib/python3.9/site-packages/wx/core.py", line 2237 in MainLoop
? File "/home/ewthornton/.local/lib/python3.9/site-packages/quisk/quisk.py", line 6442 in main
? File "/home/ewthornton/.local/bin/quisk", line 8 in <module>
Segmentation fault
 

Hello Eric,

I have been running my remote on an Rpi4 with python 3.9.2 and using ssh in a terminal on the local end, invoke it with "DISPLAY=:0 nohup ~/quisk/quisk &" which runs a graphical version. I have no issues with the connection and can run it over the internet with a 50ish ksps

73, Graeme ZL2APV
 

Graeme,

Thanks for the reply. I started with a fresh install of the latest Raspbian (bullseye) and tried running with DISPLAY=:0. That trick does in fact help network congestion, but I can't seem to get more than a few minutes without a segmentation?fault on the remote side. It always?seems to occur when changing?filter widths or clicking on a different part of the spectrum.

The backtraces seem to be all over the place. I don't think python's built-in faulthandler is giving me the correct line. It changes every time, which makes me think it's the sound thread that is really crashing and the python line is whatever the main loop happens to be at that moment.

I'll need to try running inside of GDB to catch a real backtrace, and I'm a little rusty with that.

-73
Eric

On Wed, Dec 28, 2022 at 9:43 PM Graeme Jury <gvjury@...> wrote:
Hello Eric,

I have been running my remote on an Rpi4 with python 3.9.2 and using ssh in a terminal on the local end, invoke it with "DISPLAY=:0 nohup ~/quisk/quisk &" which runs a graphical version. I have no issues with the connection and can run it over the internet with a 50ish ksps

73, Graeme ZL2APV

 

I am worried about these segmentation faults. Eric and Ben see them. But Graeme and I do not. I can't fix it if I can't produce the fault. My remote is on the LAN, not WiFi so maybe that is a problem. It does seem that gdb is the best tool.

It would help if I knew the hardware used (SoftRock, HL2,...) and the OS (Linux, Windows), and the network (LAN or WiFi). Ben is local, so if he can reliably see the fault maybe I can come over and have a look.

Jim
N2ADR
 

Not sure it's related, but one cause of crash on Windows, was this illegal ptr to free():

--- orig-quisk-4.2.15/quisk.c 2022-12-20 22:26:07
+++ quisk.c                   2023-01-05 07:16:17
@@ -3101,7 +3101,7 @@
                return NULL;
        wisdom = fftw_export_wisdom_to_string();
        pyBytes = PyByteArray_FromStringAndSize(wisdom, strlen(wisdom));
-       free(wisdom);
+       fftw_free(wisdom);
        return pyBytes;
 }

(I hope groups.io does not massacre the above Markdown).
 

The remote segfaults are definitely network or cpu lag related. Since I'm running quisk in an ubuntu VM on my control laptop, sometimes it will struggle when plugged into my huge monitor and it's drawing a ton of pixels. This lag will crash the remote. Also when my daughter decides she wants to play minecraft while watching a 4k movie and the wife is using SMB over a VPN while on a work video conference... ?well?you get the picture.

I also found that although the remote was set-up to sample at 96khz bandwidth, the audio was garbled and unintelligible. Switching the audio card on the remote to 48khz fixed that and helped tremendously with the seg faults. I have been able to run for up to an hour without a crash. I'd definitely?like to get it back to 96khz or the full 192khz eventually, so I may dig into understanding the remote/control buffers at some point. I also may put a network switch in my garage eventually, even though the remote is 5ft from a ubiquity WAP.

-Eric
WW4ET



On Thu, Jan 5, 2023 at 2:17 AM Gisle Vanem <gvanem@...> wrote:

Not sure it's related, but one cause of crash on Windows, was this illegal ptr to free():

--- orig-quisk-4.2.15/quisk.c 2022-12-20 22:26:07
+++ quisk.c                   2023-01-05 07:16:17
@@ -3101,7 +3101,7 @@
                return NULL;
        wisdom = fftw_export_wisdom_to_string();
        pyBytes = PyByteArray_FromStringAndSize(wisdom, strlen(wisdom));
-       free(wisdom);
+       fftw_free(wisdom);
        return pyBytes;
 }

(I hope does not massacre the above Markdown).

1 - 6 of 6