frspin commented 3 years ago

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

g0orx commented 3 years ago

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

frspin commented 3 years ago

I have done all mods suggested by fventuri in pull request #84 and now segmentation error on startup is gone. Now there is a strange GUI, as in image attached, without a "close" button. Audio is chopped and, after few errors:

full_rx_buffer: channel=0 fexchange0: error=-2

a segmentation fault.

Now output on console window is:

adding sdrplay tree_selection_changed_cb tree_selection_changed_cb: selected=sdrplay,SoapySDR,3,07,fU, tree_selection_changed_cb: first=sdrplay,SoapySDR,3,07,fU, found 0 starting LinHPSDR (Beta): sdrplay Soapy 3,07 fU
create_radio for sdrplay 8 loadProperties: /home/spin/.local/share/linhpsdr/sdrplay.props soapy_protocol_init soapy_protocol_init: SoapySDRDevice_make [INFO] devIdx: 0 [INFO] hwVer: 1 output_device: plughw:0,3 HDA Intel HDMI output_device: plughw:0,7 HDA Intel HDMI output_device: plughw:0,8 HDA Intel HDMI output_device: plughw:0,9 HDA Intel HDMI output_device: plughw:0,10 HDA Intel HDMI input_device: plughw:1,0 HDA Intel PCH output_device: plughw:1,0 HDA Intel PCH input_device: plughw:1,2 HDA Intel PCH input_device: plughw:2,0 USB Device 0x41e:0x30d3 output_device: plughw:2,0 USB Device 0x41e:0x30d3 output_device: name=dmix:CARD=HDMI,DEV=3 descr=HDA Intel HDMI, HDMI 0 Direct sample mixing device output_device: output_device: name=dmix:CARD=HDMI,DEV=7 descr=HDA Intel HDMI, HDMI 1 Direct sample mixing device output_device: output_device: name=dmix:CARD=HDMI,DEV=8 descr=HDA Intel HDMI, HDMI 2 Direct sample mixing device output_device: output_device: name=dmix:CARD=HDMI,DEV=9 descr=HDA Intel HDMI, HDMI 3 Direct sample mixing device output_device: output_device: name=dmix:CARD=HDMI,DEV=10 descr=HDA Intel HDMI, HDMI 4 Direct sample mixing device output_device: output_device: name=dmix:CARD=PCH,DEV=0 descr=HDA Intel PCH, ALC887-VD Analog Direct sample mixing device output_device: output_device: name=dmix:CARD=PCH,DEV=2 descr=HDA Intel PCH, ALC887-VD Alt Analog Direct sample mixing device output_device: output_device: name=dmix:CARD=U0x41e0x30d3,DEV=0 descr=USB Device 0x41e:0x30d3, USB Audio Direct sample mixing device output_device: n_input_devices=3 create_receiver: channel=0 sample_rate=2048000 create_receiver: channel=0 frequency_min=10000 frequency_max=2000000000 create_receiver: buffer_size=2048 create_receiver: fft_size=1024 create_receiver: OpenChannel: channel=0 buffer_size=2048 sample_rate=2048000 fft_size=1024 output_samples=48 receiver_change_sample_rate: resample_step=1 receiver_update_title: LinHPSDR: sdrplay Rx-0 ADC-0 2048000 create_vfo: rx=0 audio_open_output: ALSA: pulse audio_open_output: hw=pulse audio_open_output: handle=0x55662e37bf00 audio_open_output: trying format FLOAT_LE (Float 32 bit Little Endian) audio_open_output: using format FLOAT_LE (Float 32 bit Little Endian) audio_open_output: local_audio_buffer: size=4096 sample=4 audio_open_output: rx=0 handle=0x55662e37bf00 buffer=0x55662e37cfd0 size=4096 soapy_protocol_create_receiver: setting bandwidth=1000000,000000 soapy_protocol_create_receiver: setting samplerate=2048000,000000 soapy_protocol_create_receiver: SoapySDRDevice_setupStream: channel=0 [INFO] Using format CF32. soapy_protocol_set_rx_antenna: set_rx_antenna: RX soapy_protocol_start_receiver: activate_stream soapy_protocol_start_receiver: create receive_thread soapy_protocol_start_receiver: receive_thread: id=0x55662bdf7120 receive_thread: receive_thread x=35 y=35 moving main_window to x=35 y=35 rx_panadapter: resize_timeout radio_start

Please show me how can I obtain a back trace of core dump. I don't have a "core" file.

Regards Franco Spinelli IW2DHW Schermata del 2020-11-04 13-57-28

g0orx commented 3 years ago

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

frspin commented 3 years ago

Ulimit -c give me 0 as response. I will study how to obtain a core dump and process with gdb.

In the meantime how can I close program without a in console window where was started?

Regards

Franco Spinelli IW2DHW

frspin commented 3 years ago

After some work with fventuri now some problems are gone. There is one big problem with RTL-SDR device and with SDRPlay device

Any change from USB to any other mode crash program with segmentation violation.

gdb command "where" on core show:

(gdb) where

0 mode_cb (menu_item=0x563c692c89e0, data=0x563c692cbfc0) at vfo.c:445

1 0x00007f6ad7489802 in g_closure_invoke ()

at /lib/x86_64-linux-gnu/libgobject-2.0.so.0

2 0x00007f6ad749d814 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0

3 0x00007f6ad74a8b9e in g_signal_emit_valist ()

at /lib/x86_64-linux-gnu/libgobject-2.0.so.0

4 0x00007f6ad74a90d3 in g_signal_emit ()

at /lib/x86_64-linux-gnu/libgobject-2.0.so.0

5 0x00007f6ad7c9cab2 in gtk_widget_activate ()

at /lib/x86_64-linux-gnu/libgtk-3.so.0

6 0x00007f6ad7b6aa36 in gtk_menu_shell_activate_item ()

at /lib/x86_64-linux-gnu/libgtk-3.so.0

7 0x00007f6ad7b6acc3 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0

8 0x00007f6ad7cef5ef in () at /lib/x86_64-linux-gnu/libgtk-3.so.0

9 0x00007f6ad7489a56 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0

10 0x00007f6ad74a7dd1 in g_signal_emit_valist ()

at /lib/x86_64-linux-gnu/libgobject-2.0.so.0

11 0x00007f6ad74a90d3 in g_signal_emit ()

at /lib/x86_64-linux-gnu/libgobject-2.0.so.0

12 0x00007f6ad7c99c23 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0

13 0x00007f6ad7b55128 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0

14 0x00007f6ad7b573db in gtk_main_do_event ()

at /lib/x86_64-linux-gnu/libgtk-3.so.0

--Type for more, q to quit, c to continue without paging--

15 0x00007f6ad783ff79 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0

16 0x00007f6ad7873106 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0

17 0x00007f6ad739dfbd in g_main_context_dispatch ()

at /lib/x86_64-linux-gnu/libglib-2.0.so.0

18 0x00007f6ad739e240 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0

19 0x00007f6ad739e2e3 in g_main_context_iteration ()

at /lib/x86_64-linux-gnu/libglib-2.0.so.0

20 0x00007f6ad75b7fd5 in g_application_run ()

at /lib/x86_64-linux-gnu/libgio-2.0.so.0

21 0x0000563c647bc714 in main (argc=1, argv=0x7fffc6580058) at main.c:568

Regards Franco Spinelli IW2DHW

g0orx commented 3 years ago

Just received an RSP1A so I shall start looking at better support for it.

-- John g0orx/n6lyt

g0orx commented 3 years ago

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.

rsp1a-qo100

frspin commented 3 years ago

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

g0orx commented 3 years ago

Thanks, I have just downloaded and tested that branch and it works well. -- John

g0orx commented 3 years ago

I have pushed the changes to allow sample rate selection in the radio dialog. -- John

fventuri commented 3 years ago

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. Unfortunately due to the way those SDRplay RSPs do sampling and decimation, I am afraid there is no way to achieve a sample rate of 48kHz from the hardware alone, since as far as I know 62.5kHz is the lowest value (=2MHz/32).

Next I am going to try with the RSPduo in dual tuner, and in master/slave mode to see what happens there.

Franco

fventuri commented 3 years ago

The SDRplay RSPduo is a strange "animal" (see my description on how it works here: https://github.com/f4exb/sdrangel/issues/586#issuecomment-731608262).

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:

receiver_change_sample_rate: from 96000 to 192000 radio=192000
receiver_change_sample_rate: channel=0 rate=192000 buffer_size=1024 output_samples=256
soapy_protocol_change_sample_rate: setting samplerate=192000.000000
[WARNING] invalid sample rate. Sample rate unchanged.
[WARNING] ****** Request for sample rate 192000.000000 failed. Current sample rate: 2000000.000000 ***************

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^53 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

fventuri commented 3 years ago

John, Franco (@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

g0orx commented 3 years ago

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, notifications@github.com wrote:

John, Franco (@frspin 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 https://github.com/g0orx/linhpsdr/issues/87#issuecomment-733718246, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJEH5O4DLYJUOSIXEHF2GTSRUDU3ANCNFSM4SVY7VVQ .

g0orx commented 3 years ago

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.

frspin commented 3 years ago

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

frspin commented 3 years ago

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

g0orx commented 3 years ago

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. Can you give me some details of the system you are running? CPU, OS version, USB connection (2 or 3), radio version.

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

frspin commented 3 years ago

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

fventuri commented 3 years ago

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

fventuri commented 3 years ago

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:

radio_start
>>> 2020-11-27 16:44:20 - stream->count=0
full_rx_buffer: channel=0 fexchange0: error=-2
full_rx_buffer: channel=0 fexchange0: error=-2
full_rx_buffer: channel=0 fexchange0: error=-2
>>> 2020-11-27 16:44:50 - stream->count=0
full_rx_buffer: channel=0 fexchange0: error=-2
full_rx_buffer: channel=0 fexchange0: error=-2
full_rx_buffer: channel=0 fexchange0: error=-2
>>> 2020-11-27 16:45:20 - stream->count=0
>>> 2020-11-27 16:45:50 - stream->count=0
full_rx_buffer: channel=0 fexchange0: error=-2
>>> 2020-11-27 16:46:20 - stream->count=0
>>> 2020-11-27 16:46:50 - stream->count=0
>>> 2020-11-27 16:47:20 - stream->count=0
>>> 2020-11-27 16:47:50 - stream->count=0
>>> 2020-11-27 16:48:20 - stream->count=0
>>> 2020-11-27 16:48:50 - stream->count=0
>>> 2020-11-27 16:49:20 - stream->count=0
>>> 2020-11-27 16:49:50 - stream->count=0
>>> 2020-11-27 16:50:21 - stream->count=0
>>> 2020-11-27 16:50:51 - stream->count=0
>>> 2020-11-27 16:51:21 - stream->count=0
>>> 2020-11-27 16:51:51 - stream->count=0
>>> 2020-11-27 16:52:21 - stream->count=0
>>> 2020-11-27 16:52:51 - stream->count=0
>>> 2020-11-27 16:53:21 - stream->count=0
>>> 2020-11-27 16:53:51 - stream->count=0
>>> 2020-11-27 16:54:21 - stream->count=0
>>> 2020-11-27 16:54:33 - rx_callback() overflow @1 - stream->count=8

Second test:

radio_start
>>> 2020-11-27 17:07:02 - stream->count=0
full_rx_buffer: channel=0 fexchange0: error=-2
full_rx_buffer: channel=0 fexchange0: error=-2
full_rx_buffer: channel=0 fexchange0: error=-2
full_rx_buffer: channel=0 fexchange0: error=-2
full_rx_buffer: channel=0 fexchange0: error=-2
full_rx_buffer: channel=0 fexchange0: error=-2
full_rx_buffer: channel=0 fexchange0: error=-2
>>> 2020-11-27 17:07:32 - stream->count=0
>>> 2020-11-27 17:08:02 - stream->count=0
>>> 2020-11-27 17:08:32 - stream->count=0
>>> 2020-11-27 17:09:02 - stream->count=0
>>> 2020-11-27 17:09:32 - stream->count=0
>>> 2020-11-27 17:10:02 - stream->count=0
>>> 2020-11-27 17:10:32 - stream->count=0
>>> 2020-11-27 17:11:02 - stream->count=0
>>> 2020-11-27 17:11:32 - stream->count=0
>>> 2020-11-27 17:12:02 - stream->count=0
>>> 2020-11-27 17:12:32 - stream->count=0
>>> 2020-11-27 17:13:02 - stream->count=0
>>> 2020-11-27 17:13:32 - stream->count=0
>>> 2020-11-27 17:14:02 - stream->count=0
>>> 2020-11-27 17:14:32 - stream->count=0
>>> 2020-11-27 17:15:02 - stream->count=0
>>> 2020-11-27 17:15:32 - stream->count=0
>>> 2020-11-27 17:16:02 - stream->count=0
>>> 2020-11-27 17:16:32 - stream->count=0
>>> 2020-11-27 17:17:02 - stream->count=0
>>> 2020-11-27 17:17:32 - stream->count=0
>>> 2020-11-27 17:18:02 - stream->count=0
>>> 2020-11-27 17:18:32 - stream->count=0
>>> 2020-11-27 17:19:02 - stream->count=0
>>> 2020-11-27 17:19:32 - stream->count=0
>>> 2020-11-27 17:20:02 - stream->count=0
>>> 2020-11-27 17:20:32 - stream->count=0
>>> 2020-11-27 17:21:02 - stream->count=0
>>> 2020-11-27 17:21:32 - stream->count=0
>>> 2020-11-27 17:22:02 - stream->count=0
>>> 2020-11-27 17:22:32 - stream->count=0
>>> 2020-11-27 17:23:02 - stream->count=0
>>> 2020-11-27 17:23:32 - stream->count=0
>>> 2020-11-27 17:24:02 - stream->count=0
>>> 2020-11-27 17:24:32 - stream->count=0
>>> 2020-11-27 17:25:02 - stream->count=0
>>> 2020-11-27 17:25:33 - stream->count=0
>>> 2020-11-27 17:26:03 - stream->count=0
>>> 2020-11-27 17:26:33 - stream->count=0
>>> 2020-11-27 17:27:03 - stream->count=0
>>> 2020-11-27 17:27:33 - stream->count=0
>>> 2020-11-27 17:28:03 - stream->count=0
>>> 2020-11-27 17:28:33 - stream->count=0
>>> 2020-11-27 17:29:03 - stream->count=0
>>> 2020-11-27 17:29:33 - stream->count=0
>>> 2020-11-27 17:30:03 - stream->count=0
>>> 2020-11-27 17:30:33 - stream->count=0
>>> 2020-11-27 17:31:03 - stream->count=0
>>> 2020-11-27 17:31:33 - stream->count=0
>>> 2020-11-27 17:32:03 - stream->count=0
>>> 2020-11-27 17:32:13 - rx_callback() overflow @1 - stream->count=8

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

g0orx commented 3 years ago

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

fventuri commented 3 years ago

Thanks John. It must be something here; I'll run another few tests with a sample rate of 96kHz (the lowest I can select) to see how it goes.

Franco

fventuri commented 3 years ago

John, a couple of things @frspin and I noticed:

the labels for the selection of the sample rates in the configuration menu for the SoapySDR radios were off by one; I just sent you a PR (https://github.com/g0orx/linhpsdr/pull/90) for that fix
I noticed that in this commit (https://github.com/g0orx/linhpsdr/commit/3636ca032ebf08b62ce4413c81d14306905013df), you removed line 87 from radio.c:
```
soapy_protocol_start_receiver(r->receiver[0]);
```

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. Perhaps it is just our install that has this problem; it might behave correctly on your computer.

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

fventuri commented 3 years ago

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 . Unfortunately the problem with linhpsdr reporting 'No data available' after some time, one hour or two, (regardless if we are even running other programs at that time) is still there.

Franco

g4ixt commented 3 years ago

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 Build: 2020-12-14 Beta GTK+ version 3.24.23 sysname: Linux nodename: netbook release: 5.8.0-33-generic version: #36-Ubuntu SMP Wed Dec 9 09:14:40 UTC 2020 machine: x86_64 load_css opengl: 0 Creating wisdom file: /home/ian/.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: Resource temporarily unavailable discovery: exiting discover_receive_thread discover: exiting discover for lo discover: looking for HPSDR devices on wlp3s0 discover: bound to wlp3s0 discover_receive_thread discovery: bytes read -1 discovery: recvfrom socket failed for discover_receive_thread: Resource temporarily unavailable discovery: exiting discover_receive_thread discover: exiting discover for wlp3s0 discovery found 0 devices protocol2_discover: looking for HPSDR devices on wlp3s0 protocol2_discover: bound to wlp3s0 192.168.1.70 255.255.255.0 protocol2_disovery: thread_id=0x55eaa23315e0 protocol2_discover: bytes read -1 protocol2_discover: recvfrom socket failed for discover_receive_thread: Resource temporarily unavailable protocol2_discover: exiting protocol2_discover_receive_thread protocol2_discover: exiting discover for wlp3s0 protocol2_discovery found 0 devices soapy_discovery [INFO] [UHD] linux; GNU C++ version 10.2.0; Boost_107100; UHD_3.15.0.0-3build2 soapy_discovery: get_info: lime [INFO] Make connection: 'LimeSDR-USB [USB 2.0] 9081C05C41930' [WARNING] Gateware version mismatch! Expected gateware version 2, revision 22 But found version 2, revision 23 Follow the FW and FPGA upgrade instructions: http://wiki.myriadrf.org/Lime_Suite#Flashing_images Or run update on the command line: LimeUtil --update

[INFO] Reference clock 30.72 MHz [INFO] Device name: LimeSDR-USB [INFO] Reference: 30.72 MHz [INFO] LMS7002M register cache: Disabled DriverKey=FX3 HardwareKey=LimeSDR-USB soapy_discovery: hardware info key=boardSerialNumber val=0x9081c05c41930 soapy_discovery: hardware info key=firmwareVersion val=4 soapy_discovery: hardware info key=gatewareVersion val=2.23 soapy_discovery: hardware info key=hardwareVersion val=4 soapy_discovery: hardware info key=protocolVersion val=1 Rx channels: 2 Rx channel full duplex: channel=0 fullduplex=1 Rx channel full duplex: channel=1 fullduplex=1 Tx channels: 2 Tx channel full duplex: channel=0 fullduplex=1 Tx channel full duplex: channel=1 fullduplex=1 Rx sample rates: 100000.000000 -> 65000000.000000 (0.130208), sample_rate selected 768000 Tx sample rates: 100000.000000 -> 65000000.000000 (2.083333), Rx bandwidths: Tx bandwidths: RX0: bandwidth=-1.000000 TX0: bandwidth=-1.000000 Rx freq ranges: [0.000000 Hz -> 3800000000.000000 Hz step=0.000000], Rx antennas: NONE, LNAH, LNAL, LNAW, LB1, LB2, Tx antennas: NONE, BAND1, BAND2, has_automaic_gain=0 has_automaic_dc_offset_correction=1 Rx formats: CF32, CS12, CS16, float=4 double=8 Sensors: clock_locked=true lms7_temp=27.476196 Rx gains: TIA 0.000000 -> 12.000000 step=0.000000 LNA 0.000000 -> 30.000000 step=0.000000 PGA -12.000000 -> 19.000000 step=0.000000 Tx gains: PAD 0.000000 -> 52.000000 step=0.000000 IAMP -12.000000 -> 12.000000 step=0.000000 main: discovery found 1 devices discovered: 0 device=8 adding lime tree_selection_changed_cb tree_selection_changed_cb: selected=lime,SoapySDR,4,USB, tree_selection_changed_cb: first=lime,SoapySDR,4,USB, found 0

starting LinHPSDR (Beta): lime Soapy 4 USB
create_radio for lime 8 loadProperties: /home/ian/.local/share/linhpsdr/lime.props loadProperties: version=0.000000 expected version=2.000000 ignoring soapy_protocol_init soapy_protocol_init: SoapySDRDevice_make [INFO] Make connection: 'LimeSDR-USB [USB 2.0] 9081C05C41930' [WARNING] Gateware version mismatch! Expected gateware version 2, revision 22 But found version 2, revision 23 Follow the FW and FPGA upgrade instructions: http://wiki.myriadrf.org/Lime_Suite#Flashing_images Or run update on the command line: LimeUtil --update

[INFO] Reference clock 30.72 MHz [INFO] Device name: LimeSDR-USB [INFO] Reference: 30.72 MHz [INFO] LMS7002M register cache: Disabled 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=768000 create_receiver: channel=0 frequency_min=0 frequency_max=3800000000 create_receiver: buffer_size=1024 create_receiver: fft_size=2048 create_receiver: OpenChannel: channel=0 buffer_size=1024 sample_rate=768000 fft_size=2048 output_samples=64 receiver_change_sample_rate: resample_step=1 receiver_update_title: LinHPSDR: lime Rx-0 ADC-0 768000 create_vfo: rx=0 soapy_protocol_create_receiver: setting bandwidth=2000000.000000 [INFO] RX LPF configured soapy_protocol_create_receiver: setting samplerate=768000.000000 soapy_protocol_create_receiver: SoapySDRDevice_setupStream: channel=0 Segmentation fault (core dumped) ian@netbook:~$ ulimit -c 0 ian@netbook:~$

ian@netbook:~$ linhpsdr Build: 2020-12-14 Beta GTK+ version 3.24.23 sysname: Linux nodename: netbook release: 5.8.0-33-generic version: #36-Ubuntu SMP Wed Dec 9 09:14:40 UTC 2020 machine: x86_64 load_css opengl: 0 Creating wisdom file: /home/ian/.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: Resource temporarily unavailable discovery: exiting discover_receive_thread discover: exiting discover for lo discover: looking for HPSDR devices on wlp3s0 discover: bound to wlp3s0 discover_receive_thread discovery: bytes read -1 discovery: recvfrom socket failed for discover_receive_thread: Resource temporarily unavailable discovery: exiting discover_receive_thread discover: exiting discover for wlp3s0 discovery found 0 devices protocol2_discover: looking for HPSDR devices on wlp3s0 protocol2_discover: bound to wlp3s0 192.168.1.70 255.255.255.0 protocol2_disovery: thread_id=0x55acbab3f0c0 protocol2_discover: bytes read -1 protocol2_discover: recvfrom socket failed for discover_receive_thread: Resource temporarily unavailable protocol2_discover: exiting protocol2_discover_receive_thread protocol2_discover: exiting discover for wlp3s0 protocol2_discovery found 0 devices soapy_discovery [INFO] [UHD] linux; GNU C++ version 10.2.0; Boost_107100; UHD_3.15.0.0-3build2 Found Rafael Micro R820T tuner soapy_discovery: get_info: rtlsdr Found Rafael Micro R820T tuner DriverKey=RTLSDR HardwareKey=R820T soapy_discovery: hardware info key=origin val=https://github.com/pothosware/SoapyRTLSDR soapy_discovery: hardware info key=rtl val=0 Rx channels: 1 Rx channel full duplex: channel=0 fullduplex=1 Tx channels: 0 Rx sample rates: 250000.000000 -> 250000.000000 (0.325521),1024000.000000 -> 1024000.000000 (1.333333),1536000.000000 -> 1536000.000000 (2.000000),1792000.000000 -> 1792000.000000 (2.333333),1920000.000000 -> 1920000.000000 (2.500000),2048000.000000 -> 2048000.000000 (2.666667),2160000.000000 -> 2160000.000000 (2.812500),2560000.000000 -> 2560000.000000 (3.333333),2880000.000000 -> 2880000.000000 (3.750000),3200000.000000 -> 3200000.000000 (4.166667), sample_rate selected 1536000 Tx sample rates: 250000.000000 -> 250000.000000 (5.208333),1024000.000000 -> 1024000.000000 (21.333333),1536000.000000 -> 1536000.000000 (32.000000),1792000.000000 -> 1792000.000000 (37.333333),1920000.000000 -> 1920000.000000 (40.000000),2048000.000000 -> 2048000.000000 (42.666667),2160000.000000 -> 2160000.000000 (45.000000),2560000.000000 -> 2560000.000000 (53.333333),2880000.000000 -> 2880000.000000 (60.000000),3200000.000000 -> 3200000.000000 (66.666667), Rx bandwidths: Tx bandwidths: RX0: bandwidth=0.000000 TX0: bandwidth=0.000000 Rx freq ranges: [23999000.000000 Hz -> 1764001000.000000 Hz step=0.000000], Rx antennas: RX, Tx antennas: RX, has_automaic_gain=1 has_automaic_dc_offset_correction=0 Rx formats: CS8, CS16, CF32, float=4 double=8 Sensors: Rx gains: TUNER 0.000000 -> 49.600000 step=0.000000 Tx gains: TUNER 0.000000 -> 49.600000 step=0.000000 main: discovery found 1 devices discovered: 0 device=8 adding rtlsdr tree_selection_changed_cb tree_selection_changed_cb: selected=rtlsdr,SoapySDR,,USB,0 tree_selection_changed_cb: first=rtlsdr,SoapySDR,,USB,0 found 0 starting LinHPSDR (Beta): rtlsdr Soapy USB 0 create_radio for rtlsdr 8 loadProperties: /home/ian/.local/share/linhpsdr/rtlsdr.props loadProperties: version=0.000000 expected version=2.000000 ignoring soapy_protocol_init soapy_protocol_init: SoapySDRDevice_make Found Rafael Micro R820T tuner 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=768000 create_receiver: channel=0 frequency_min=23999000 frequency_max=1764001000 create_receiver: buffer_size=1024 create_receiver: fft_size=2048 create_receiver: OpenChannel: channel=0 buffer_size=1024 sample_rate=768000 fft_size=2048 output_samples=64 receiver_change_sample_rate: resample_step=1 receiver_update_title: LinHPSDR: rtlsdr Rx-0 ADC-0 768000 create_vfo: rx=0 soapy_protocol_create_receiver: setting bandwidth=2000000.000000 soapy_protocol_create_receiver: setting samplerate=768000.000000 Invalid sample rate: 768000 Hz soapy_protocol_create_receiver: SoapySDRDevice_setupStream: channel=0 soapy_protocol_set_rx_antenna: set_rx_antenna: RX soapy_protocol_start_receiver: activate_stream soapy_protocol_start_receiver: create receive_thread soapy_protocol_start_receiver: receive_thread: id=0x55acb9ba69e0 Allocating 15 zero-copy buffers x=-1 y=-1 receive_thread: receive_thread Segmentation fault (core dumped)

ian@netbook:~$ SoapySDRUtil --info ######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Lib Version: v0.8.0-g926c86d9 API Version: v0.8.0 ABI Version: v0.8 Install root: /usr/local Search path: /usr/local/lib/SoapySDR/modules0.8 Module found: /usr/local/lib/SoapySDR/modules0.8/libLMS7Support.so (20.10.0-1480bfea) Available factories... lime Available converters...

CF32 -> [CF32, CS16, CS8, CU16, CU8]
CS16 -> [CF32, CS16, CS8, CU16, CU8]
CS32 -> [CS32]
CS8 -> [CF32, CS16, CS8, CU16, CU8]
CU16 -> [CF32, CS16, CS8]
CU8 -> [CF32, CS16, CS8]
F32 -> [F32, S16, S8, U16, U8]
S16 -> [F32, S16, S8, U16, U8]
S32 -> [S32]
S8 -> [F32, S16, S8, U16, U8]
U16 -> [F32, S16, S8]
U8 -> [F32, S16, S8] ian@netbook:~$

fventuri commented 3 years ago

@g4ixt - the best way to troubleshoot segmentation fault errors is to make sure linhpsdr has been compiled in 'debug' mode (i.e. the CFLAGS line in the Makefile should have the -g option and also possibly it should not have the -O3 option), rebuild it if you had to change the CFLAGS entry, rerun it and have it crash it again.

After that it should generate a core dump file somewhere (it depends on the Linux distribution); that file can be examined with gdb with something like this:

gdb linhpsdr <core file>

In some Linux distributions the command above can be different; for instance here on Fedora the command is coredumpctl debug. Once you get to the gdb> prompt, please enter the command where which should give you the complete list of function calls that caused the crash.

Please post the output from the where gdb command above; that will make it easier to troubleshoot your problem and come up with a fix.

Franco

g4ixt commented 3 years ago

@fventuri

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

fventuri commented 3 years ago

@g4ixt - a couple of things:

what was the name of the core dump file like? If it ended in '.gz' it was compressed, and you need to uncompress it first. Please run the command file on it and send the output, i.e.:
```
file <core dump file>
```
since that message you show (error 4 in libLMS7Support.so) seems to indicate a problem with the the LimeSuite SoapySDR driver, perhaps the problem is not in linhpsdr, but in SoapyLMS7, and you may want to create a new issue here: https://github.com/myriadrf/LimeSuite/issues

Franco

g4ixt commented 3 years ago

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. Here are the top and bottom "information" parts from the core dump file:

Top part

ProblemType: Crash Architecture: amd64 CurrentDesktop: KDE Date: Fri Jan 1 17:42:50 2021 DistroRelease: Ubuntu 20.10 ExecutablePath: /usr/local/bin/linhpsdr ExecutableTimestamp: 1609516311 ProcCmdline: linhpsdr ProcCwd: /home/ian ProcEnviron: SHELL=/bin/bash LANGUAGE=en_GB LANG=en_GB.UTF-8 TERM=xterm-256color XDG_RUNTIME_DIR= PATH=(custom, no user) ProcMaps: 55639c45f000-55639c46d000 r--p 00000000 08:01 2098880 /usr/local/bin/linhpsdr 55639c46d000-55639c4b9000 r-xp 0000e000 08:01 2098880 /usr/local/bin/linhpsdr 55639c4b9000-55639c4cc000 r--p 0005a000 08:01 2098880 /usr/local/bin/linhpsdr 55639c4cd000-55639c4cf000 r--p 0006d000 08:01 2098880 /usr/local/bin/linhpsdr 55639c4cf000-55639c4d5000 rw-p 0006f000 08:01 2098880 /usr/local/bin/linhpsdr 55639c4d5000-55639c4ed000 rw-p 00000000 00:00 0 55639d2b4000-5563a22d6000 rw-p 00000000 00:00 0 [heap]

Bottom part

ProcStatus: Name: linhpsdr Umask: 0002 State: S (sleeping) Tgid: 1819 Ngid: 0 Pid: 1819 PPid: 1811 TracerPid: 0 Uid: 1000 1000 1000 1000 Gid: 1000 1000 1000 1000 FDSize: 64 Groups: 4 5 20 24 27 30 46 118 128 1000 NStgid: 1819 NSpid: 1819 NSpgid: 1819 NSsid: 1811 VmPeak: 1400936 kB VmSize: 1305548 kB VmLck: 0 kB VmPin: 0 kB VmHWM: 96444 kB VmRSS: 96444 kB RssAnon: 49828 kB RssFile: 46528 kB RssShmem: 88 kB VmData: 204756 kB VmStk: 132 kB VmExe: 304 kB VmLib: 39116 kB VmPTE: 524 kB VmSwap: 0 kB HugetlbPages: 0 kB CoreDumping: 1 THP_enabled: 1 Threads: 11 SigQ: 0/7002 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000001000 SigIgn: 0000000000001000 SigCgt: 0000000180000000 CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: 000000ffffffffff CapAmb: 0000000000000000 NoNewPrivs: 0 Seccomp: 0 Speculation_Store_Bypass: not vulnerable Cpus_allowed: f Cpus_allowed_list: 0-3 Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001 Mems_allowed_list: 0 voluntary_ctxt_switches: 13366 nonvoluntary_ctxt_switches: 1187 Signal: 11 Uname: Linux 5.8.0-33-generic x86_64 UserGroups: adm cdrom dialout dip lpadmin plugdev sambashare sudo tty CoreDump: base64

fventuri commented 3 years ago

@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 /var/lib/systemd/coredump):

$ ls -l core.CubicSDR.1000.5752669e401b4326a16394b8034bc223.4106.1609902752000000.zst
-rw-r-----+ 1 root root 5383922 Jan  5 22:12 core.CubicSDR.1000.5752669e401b4326a16394b8034bc223.4106.1609902752000000.zst

$ zstd -dc core.CubicSDR.1000.5752669e401b4326a16394b8034bc223.4106.1609902752000000.zst | file -
/dev/stdin: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from './CubicSDR', real uid: 1000, effective uid: 1000, real gid: 1000, effective gid: 1000, execfn: './CubicSDR', platform: 'x86_64'

Franco

g0orx / linhpsdr

Segmentation error on Ubuntu wirh Soapy device #87

0 mode_cb (menu_item=0x563c692c89e0, data=0x563c692cbfc0) at vfo.c:445

1 0x00007f6ad7489802 in g_closure_invoke ()

2 0x00007f6ad749d814 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0

3 0x00007f6ad74a8b9e in g_signal_emit_valist ()

4 0x00007f6ad74a90d3 in g_signal_emit ()

5 0x00007f6ad7c9cab2 in gtk_widget_activate ()

6 0x00007f6ad7b6aa36 in gtk_menu_shell_activate_item ()

7 0x00007f6ad7b6acc3 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0

8 0x00007f6ad7cef5ef in () at /lib/x86_64-linux-gnu/libgtk-3.so.0

9 0x00007f6ad7489a56 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0

10 0x00007f6ad74a7dd1 in g_signal_emit_valist ()

11 0x00007f6ad74a90d3 in g_signal_emit ()

12 0x00007f6ad7c99c23 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0

13 0x00007f6ad7b55128 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0

14 0x00007f6ad7b573db in gtk_main_do_event ()

15 0x00007f6ad783ff79 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0

16 0x00007f6ad7873106 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0

17 0x00007f6ad739dfbd in g_main_context_dispatch ()

18 0x00007f6ad739e240 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0

19 0x00007f6ad739e2e3 in g_main_context_iteration ()

20 0x00007f6ad75b7fd5 in g_application_run ()

21 0x0000563c647bc714 in main (argc=1, argv=0x7fffc6580058) at main.c:568

Soapy SDR -- the SDR abstraction library

Top part

Bottom part