Segmentation error on Ubuntu wirh Soapy device #87
Comments
|
I don't have an SDRPlay device to test with. If someone wants to loan me one I can take a look to see what the problem is;) A back trace of the core dump would help to locate of the error. -- John |
|
I have done all mods suggested by fventuri in pull request #84 and now segmentation error on startup is gone. full_rx_buffer: channel=0 fexchange0: error=-2 a segmentation fault. Now output on console window is: adding sdrplay Please show me how can I obtain a back trace of core dump. I don't have a "core" file. Regards |
|
Sorry, I was responding to the segmentation fault which should give a core dump provided that "ulimit -c" is set to unlimited. There is no close button on the receiver window, it is on the radio window. This application is really designed for working with HPSDR devices (and Apache Labs radios) which support multiple receivers. The first receiver (RX-0) does not have a close button, but additional receivers do. As for the choppy audio, again I cannot really help without the device to test with. As I already have 7 other SDR radios I cannot afford to keep buying more. -- John -- John |
|
Ulimit -c give me 0 as response. In the meantime how can I close program without a in console window where was started? Regards Franco Spinelli |
|
After some work with fventuri now some problems are gone. Any change from USB to any other mode crash program with segmentation violation. gdb command "where" on core show: (gdb) where Regards |
|
Just received an RSP1A so I shall start looking at better support for it. -- John g0orx/n6lyt |
|
I have made some progress with my RSP1A. The main problem is that WDSP is designed to work with the HPSDR radios that have sample rates 48K, 96K,192K, 384K, 768K and 1536K, The RSP1A does not support these rates so a sample rate conversion is required. Below is a screen dump receiving QO-100. The RSP1A sampling rate is set to 2000000 and the receiver is set to 768k. The radio samples are resampled to 768k before being processed by WDSP. The audio is OK. I do need to do some more work on this but it is looking promising.
|
|
Il 22/11/20 12:01, John Melton ha scritto:
I have made some progress with my RSP1A. The main problem is that WDSP
is designed to work with the HPSDR radios that have sample rates 48K,
96K,192K, 384K, 768K and 1536K, The RSP1A does not support these rates
so a sample rate conversion is required.
There is some vork done by Franco on SoapySDRPlay
(https://github.com/SDRplaySoapySDRPlay - extra_sample_rates branch) for
insert in SoapySDRPlay 96k,192k,384k and 768k sample rates with a
hardware sample rate fixed to 3072 and decimation factor of 32 16 8 and 4.
With this modifications linhpsdr seem able to receive correctly from
SDRPlay devices (my RSPP1 and Franco RSPduo)
Regards
Franco Spinelli
IW2DHW
|
|
Thanks, I have just downloaded and tested that branch and it works well. |
|
I have pushed the changes to allow sample rate selection in the radio dialog. |
|
Thanks for all your work, John! I just pulled your code, compiled, and ran it here with the RSP2, and I am now able to change sample rate from 768kHz to 384kHz without any problem. Next I am going to try with the RSPduo in dual tuner, and in master/slave mode to see what happens there. Franco |
|
The SDRplay RSPduo is a strange "animal" (see my description on how it works here: f4exb/sdrangel#586 (comment)). I ran it in single tuner mode without any problem. Then I ran it in master mode (without any slave client application, just to keep things as simple as possible); in this mode the RSPduo can only run with a very limited set of sample rates (62.5kHz, 125kHz, ..., all the way to 2MHz). What I noticed is that linhpsdr attempts to change the sample rate to say 192kHz, receives a warning that the sample rate is invalid, but it appears to ignore the warning, and displays (and possibly uses internally) the incorrect value of the sample rate (i.e. 192kHz, while the RSPduo in master mode is still sampling at 2MHz). To confirm this, I added another log message to the SoapySDRPlay driver, recompiled it, and this is part of the output when I try to change sample rate: Honestly I am not sure if there is a way to handle the sample rates for this case; they are all in a rational ratio of 125/96 of the values requested by linhpsdr, i.e. SR(linhpsdr) = 96/125 * SR(RSPduo). I am not familiar with rational resampling, so I can't really say much at this point (note that 96=2^5*3 and 125=5^3, not sure if that helps). On the other hand the different values for the sample rate displayed (and possibly used) by linhpsdr and the one actually used by the RSPduo has me a little concerned, because my linhpsdr (here on Linux Fedora 33) kept streaming for a few minutes, but I am not really sure if it was streaming correctly. Franco |
|
John, I did some quick troubleshooting about this problem, and it looks like at that point all the internal sample buffers in the SoapySDRPlay driver are full (not sure why), the drivers sends out the error code 'SOAPY_SDR_OVERFLOW' (which has a value of '-4'), linhpsdr sees a negative value being returned by Soapy_readStream(), and that causes the behavior described above. I am not sure why all the sample buffers fill up (if I remember correctly they can hold about 512k I/Q samples); in my case I was streaming with a sample rate of 384kHz, which is one of the values supported by linhpsdr and wdsp Franco |
|
I will take a look. I have been running my RSP1a at 768k all day and night
with no problems monitoring QO-100.
…-- John
On Wed, 25 Nov 2020, 13:51 Franco Venturi, ***@***.***> wrote:
John,
Franco ***@***.*** <https://github.com/frspin> ) and I also noticed that
after we leave linhpsdr running (and streaming) from our SDRplay RSPs for
some time (say half an hour, or one hour, or longer), "something" happens
where linhpsdr stops streaming and displays a warning about 'No data
available'.
I did some quick troubleshooting about this problem, and it looks like at
that point all the internal sample buffers in the SoapySDRPlay driver are
full (not sure why), the drivers sends out the error code
'SOAPY_SDR_OVERFLOW' (which has a value of '-4'), linhpsdr sees a negative
value being returned by Soapy_readStream(), and that causes the behavior
described above.
I am not sure why all the sample buffers fill up (if I remember correctly
they can hold about 512k I/Q samples); in my case I was streaming with a
sample rate of 384kHz, which is one of the values supported by linhpsdr and
wdsp
Franco
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#87 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJEH5O4DLYJUOSIXEHF2GTSRUDU3ANCNFSM4SVY7VVQ>
.
|
|
I was only able to get the -4 error when changing sample rates and have pushed a fix for that. I have also pushed a small fix for the GEN and WWV default band setting that were missing 2 fields each. |
|
Il 27/11/20 12:31, John Melton ha scritto:
I was only able to get the -4 error when changing sample rates and have
pushed a fix for that. I have also pushed a small fix for the GEN and
WWV default band setting that were missing 2 fields each.
Error -4 was obtained after 70' of run, starting another program, but
system monitor show a 20% of CPU load, no network traffic and no disk
I/O load. It seems a problem on internal buffers for linhpsdr and/or
wdsp but changing 2048 to 4096 in radio [1106] is useless
(radio.buffer_size from config file seem ignored).
I will update from GIT and retest it with latest changes
Regards
Franco Spinelli
IW2DHW
|
|
Il 27/11/20 12:31, John Melton ha scritto:
I was only able to get the -4 error when changing sample rates and have
pushed a fix for that. I have also pushed a small fix for the GEN and
WWV default band setting that were missing 2 fields each.
Downloaded latest changes and, after 85' of normal PC usage, I get usual
error:
Oreceive_thread: elements=-4 max_samples=4096
receive_thread: receive_thread: SoapySDRDevice_deactivateStream
Regards
Franco Spinelli
IW2DHW
|
|
I have been running for 180 minutes with no problems. I will leave it running all night and see if I can get it to happen. I am running an RSP1A on Ubuntu 20.10, AMD FX-6300 6 core processor at 3.8GHz with 16GB memory. The RSP1A is connected to a USB3 port. -- John |
|
Il 27/11/20 19:39, John Melton ha scritto:
I have been running for 180 minutes with no problems. I will leave it
running all night and see if I can get it to happen.
I have seen that there is necessity of other programs working. I have
done test with linhpsdr and fldigi decoding meteofax.
Can you give me some details of the system you are running? CPU, OS
version, USB connection (2 or 3), radio version.
My radio is a RSP1 but fventuri have same problem with a RSPDuo
My PC is an Intel I5-4440 at 3.1 GHz with 4 cores and 8 Gb of RAM
OS is Ubuntu 20.04 - 64 bit and RSP1 is connected to a USB2 port.
I also tested with CubicSDR, Gqrx, Quisk and Welle-io (for DAB) all
using RSP1 and SoapySDRPlay. In all test I don't have problems of "-4
code error". I can retry with this programs tomorrow for another test.
Regards
Franco Spinelli
IW2DHW
|
|
Quick correction: my tests where I was able to reproduce Franco's (@frspin) problem were with the SDRplay RSP2 (not the RSPduo); the reason I chose the RSP2 for these tests is because I thought it was the closest I had to Franco's RSP1 and John's RSP1A. I haven't run any tests with the new code today, but later in the day I hope I'll have some time to let it run for a while with the new code, and I'll let you know how it goes. Franco |
|
I added a couple of print statements with timestamps in the rx_callback() function in the driver source file 'Streaming.cpp', and ran a couple of tests with my RSP2 (my Linux distribution is Fedora 33). First test: Second test: It looks like number of full buffers (stream->count) stays at 0 the whole time, except when it suddenly jumps to the total number of buffers (8) for some reason, and then it's gave over. Franco |
|
I have been running for over 16 hours now with no problems. So I cannot reproduce the problem on my Ubuntu 20.10 system with the RSP1A. -- John |
|
Thanks John. Franco |
|
John,
without that line @frspin and I have the problem that, when try to change the sample rate while the RSP is streaming, linhpsdr receive the usual -4 error (SOAPY_SDR_OVERFLOW), and it stops working until we restart the application. A few minutes ago, I put back that line in 'radio.c', recompiled it, and now when I switch sample rate, I see the 'No data available' message for a split second, after that linhpsdr resumes streaming with the new sample rate, which seems to be better than the current behavior. One last note is about the RSPduo; since in dual-tuner mode it can behave as two (almost) independent receivers, I had that you could add another receiver in linhpsdr and tune/stream both receivers at the same time, if you wanted to; this might be an useful feature you may want to keep. Franco |
|
Quick update: I asked Franco (@frspin) to try those two changes on his installation of linhpsdr this morning, and he confirmed that they seem to solve the two problems he was having too . Franco |
|
Hello John, linhpsdr is also crashing for me with a segmentation fault, on pressing the "start receiver" button, using both LimeSDR-USB and RTL-SDR. I have tried it on my desktop (Kubuntu 20.04 LTS) and on my small laptop (Kubuntu 20.10). I built from source in both cases although the desktop has some things from the distribution and MyriadRF PPA. The laptop has soapy, limesuite and linhpsdr all built from source yesterday and in that order. I am a reasonably competent Linux user but by no means a command line expert. I haven't been able to discover where the 'core dump' file is but if you give me a clue I ought to be able to. Here is various info from 'Terminal' for both LimeSDR and RTL connected (not at the same time). ian@netbook:~$ linhpsdr [INFO] Reference clock 30.72 MHz starting LinHPSDR (Beta): lime Soapy 4 USB [INFO] Reference clock 30.72 MHz ian@netbook:~$ linhpsdr ian@netbook:~$ SoapySDRUtil --info Soapy SDR -- the SDR abstraction library###################################################### Lib Version: v0.8.0-g926c86d9
|
|
@g4ixt - the best way to troubleshoot segmentation fault errors is to make sure linhpsdr has been compiled in 'debug' mode (i.e. the After that it should generate a core dump file somewhere (it depends on the Linux distribution); that file can be examined with In some Linux distributions the command above can be different; for instance here on Fedora the command is Please post the output from the Franco |
|
I managed to generate a core dump file after changing some Apport settings but when I use gdb it says it doesn't recognise the format. The journald log says this: linhpsdr[1843]: segfault at 100000027 ip 00007f858e43c5d4 sp 00007ffe11156778 error 4 in libLMS7Support.so[7f858e42a000+16000] I can't see how to attach the crash file (_usr_local_bin_linhpsdr.1000.crash) here but I could put it in my google drive and link to it if it would be any use? Ian |
|
@g4ixt - a couple of things:
Franco |
|
Franco @fventuri, The core dump isn't a compressed file. The 'file' command says: "ASCII text, with very long lines". I had a look at the instructions for the gdb but I couldn't see anything relevant or figure out how to run linhpsdr directly with gdb, although I tried. Thank you for your advice so far. Other programmes work fine for me that use SoapyLMS7, such as Qspectrumanalyzer and SDRAngel. Top partProblemType: Crash Bottom partProcStatus: |
|
@g4ixt - the file you show does not look like a core dump to me (or at least a core dump like the ones I am used to see here on Fedora); for instance a (compressed) core dump from a crash in CubicSDR on my PC last night looks like this (mine are in the directory Franco |
Fresh wdsp and linhpsdr source from Github.
Required libraries all from repository of Ubuntu 20.04
Compile and link for wdsp library is correct
Compile of linhpsdr work without errors.
Running linhpsdr from same directory crash with:
Build: 2020-10-12 Beta GTK+ version 3.24.20 sysname: Linux nodename: franco release: 5.4.0-51-generic version: #56-Ubuntu SMP Mon Oct 5 14:28:49 UTC 2020 machine: x86_64 load_css opengl: 0 Warning: failed to set icon for main_window: /usr/share/linhpsdr/hpsdr.png Apertura del file «/usr/share/linhpsdr/hpsdr.png» non riuscita: File o directory non esistente Creating wisdom file: /home/spin/.local/share/linhpsdr/ discovery protocol1_discovery discover: looking for HPSDR devices on lo discover: bound to lo discover_receive_thread discovery: bytes read -1 discovery: recvfrom socket failed for discover_receive_thread: Risorsa temporaneamente non disponibile discovery: exiting discover_receive_thread discover: exiting discover for lo discover: looking for HPSDR devices on enp2s0 discover: bound to enp2s0 discover_receive_thread discovery: bytes read -1 discovery: recvfrom socket failed for discover_receive_thread: Risorsa temporaneamente non disponibile discovery: exiting discover_receive_thread discover: exiting discover for enp2s0 discovery found 0 devices protocol2_discover: looking for HPSDR devices on enp2s0 protocol2_discover: bound to enp2s0 192.168.1.4 255.255.255.0 protocol2_disovery: thread_id=0x55d734e9ca40 protocol2_discover: bytes read -1 protocol2_discover: recvfrom socket failed for discover_receive_thread: Risorsa temporaneamente non disponibile protocol2_discover: exiting protocol2_discover_receive_thread protocol2_discover: exiting discover for enp2s0 protocol2_discovery found 0 devices soapy_discovery [INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100; UHD_3.15.0.0-2build5 soapy_discovery: get_info: sdrplay [INFO] devIdx: 0 [INFO] hwVer: 1 DriverKey=SDRplay HardwareKey=B0003P0007 soapy_discovery: hardware info key=sdrplay_api_api_version val=3,070000 soapy_discovery: hardware info key=sdrplay_api_hw_version val=1 Rx channels: 1 Rx channel full duplex: channel=0 fullduplex=1 Tx channels: 0 Rx sample rates: 62500,000000 -> 62500,000000 (1,302083),125000,000000 -> 125000,000000 (2,604167),250000,000000 -> 250000,000000 (5,208333),500000,000000 -> 500000,000000 (10,416667),1000000,000000 -> 1000000,000000 (20,833333),2000000,000000 -> 2000000,000000 (41,666667),2048000,000000 -> 2048000,000000 (42,666667),3000000,000000 -> 3000000,000000 (62,500000),4000000,000000 -> 4000000,000000 (83,333333),5000000,000000 -> 5000000,000000 (104,166667),6000000,000000 -> 6000000,000000 (125,000000),7000000,000000 -> 7000000,000000 (145,833333),8000000,000000 -> 8000000,000000 (166,666667),9000000,000000 -> 9000000,000000 (187,500000),10000000,000000 -> 10000000,000000 (208,333333), sample_rate selected 6000000 Tx sample rates: 62500,000000 -> 62500,000000 (1,302083),125000,000000 -> 125000,000000 (2,604167),250000,000000 -> 250000,000000 (5,208333),500000,000000 -> 500000,000000 (10,416667),1000000,000000 -> 1000000,000000 (20,833333),2000000,000000 -> 2000000,000000 (41,666667),2048000,000000 -> 2048000,000000 (42,666667),3000000,000000 -> 3000000,000000 (62,500000),4000000,000000 -> 4000000,000000 (83,333333),5000000,000000 -> 5000000,000000 (104,166667),6000000,000000 -> 6000000,000000 (125,000000),7000000,000000 -> 7000000,000000 (145,833333),8000000,000000 -> 8000000,000000 (166,666667),9000000,000000 -> 9000000,000000 (187,500000),10000000,000000 -> 10000000,000000 (208,333333), Rx bandwidths: 200000,000000, 300000,000000, 600000,000000, 1536000,000000, 5000000,000000, 6000000,000000, 7000000,000000, 8000000,000000, Tx bandwidths: 200000,000000, 300000,000000, 600000,000000, 1536000,000000, 5000000,000000, 6000000,000000, 7000000,000000, 8000000,000000, RX0: bandwidth=200000,000000 TX0: bandwidth=0,000000 Rx freq ranges: [10000,000000 Hz -> 2000000000,000000 Hz step=0,000000], Rx antennas: RX, Tx antennas: has_automaic_gain=1 has_automaic_dc_offset_correction=1 Rx formats: CS16, CF32, float=4 double=8 Sensors: Rx gains: IFGR 20,000000 -> 59,000000 step=0,000000 IFGain 20,000000 -> 59,000000 step=0,000000 RFGR 0,000000 -> 3,000000 step=0,000000 RFGain 0,000000 -> 3,000000 step=0,000000 Tx gains: IFGR 20,000000 -> 59,000000 step=0,000000 IFGain 20,000000 -> 59,000000 step=0,000000 RFGR 0,000000 -> 3,000000 step=0,000000 RFGain 0,000000 -> 3,000000 step=0,000000 main: discovery found 1 devices discovered: 0 device=8 adding sdrplay tree_selection_changed_cb tree_selection_changed_cb: selected=sdrplay,SoapySDR,,USB, tree_selection_changed_cb: first=sdrplay,SoapySDR,,USB, found 0 starting LinHPSDR (Beta): sdrplay Soapy USB create_radio for sdrplay 8 loadProperties: /home/spin/.local/share/linhpsdr/sdrplay.props loadProperties: version=0,000000 expected version=2,000000 ignoring soapy_protocol_init soapy_protocol_init: SoapySDRDevice_make audio_get_backend_name: JACK audio: create_audio: USE_SOUNDIO: 1 JACK create_audio: soundio_connect_backend: unable to initialize audio backend create_receiver: channel=0 sample_rate=6000000 create_receiver: channel=0 frequency_min=10000 frequency_max=2000000000 create_receiver: buffer_size=1024 create_receiver: fft_size=2048 create_receiver: OpenChannel: channel=0 buffer_size=1024 sample_rate=6000000 fft_size=2048 output_samples=8 receiver_change_sample_rate: resample_step=1 Errore di segmentazione (core dump creato)Discovery is correct and segmentation error is on starting receiver
Any tip for debug the problem?
Regards
Franco Spinelli
IW2DHW
The text was updated successfully, but these errors were encountered: