search

jankae / LibreVNA

100kHz to 6GHz 2 port USB based VNA
GNU General Public License v3.0
1.08k stars 204 forks source link

LibreVNA-GUI v1.2.1 interface crashes #92

Closed spannohouse closed 1 year ago

spannohouse commented 2 years ago

I use libreVNA as a measuring device that takes measurements every hour for a total duration of about 12 hours.

I read the libreVNA data from MATLAB via SCPI commands.

I've noticed that after a while the windows gui (running as a server) crashes. Basically the measurement data is not updated anymore. Matlab still reads the data but they are old data. If I close the gui and restart it, everything works correctly.

jankae commented 2 years ago

This sounds like the same issue as mentioned here: https://groups.io/g/LibreVNA-support/topic/87874876#479

The problem is that I have never personally observed it, so I don't know where to start looking. If you can figure out a way to trigger it reliably, I'd be happy to fix it.

spannohouse commented 2 years ago

Yes it is the same problem. I have updated the gui and firmware as indicated in the forum (The updated version is available here: https://github.com/jankae/LibreVNA/actions/runs/1637768476)

Today I leave it on and tomorrow I will see if it works

spannohouse commented 2 years ago

It doesn't work, after not even 10 minutes the gui has already freezed. (when I unplug the cable, the displayed track remains the same) I didn't put any special settings: 1GHz - 6GHz, 1024 points, -5 dBm, IF BW 10.0 kHz (LibreVNA-GUI v1.2.1)

jankae commented 2 years ago

With the same settings it is has been running here for about an hour without any problems so far. Can you share a few more details please?

spannohouse commented 2 years ago

OS: Windows 10 Enterprise, version 21H2 LibreVBA-GUI: 1.2.1-8e47d1419 (installed from: GUI_Windows-v1.2.1-2021-12-30-14-25-57.zip) firmware: installed from: EmbeddedFirmware-hw-rev-B-v1.2.1-2021-12-30-14-24-00.zip

attached you can find the preferences: Immagine

melikhaneren commented 2 years ago

Hello everyone, I also faced the same issue @spannohouse mentioned. I'm trying to get measurement results using SCPI with LibreVNA for a raster-scan that will take about 7 hours. However, after running for about 1 hour, LibreVNA GUI shut itself down because it could not receive data and my measurement failed. Due to the urgency of taking my measurements, I need to resolve this issue. What can I do for it? Have you found any solution? @jankae OS: Windows 10 LibreVNA GUI: 1.2.1 1GHz - 6GHz, 501 points, -10 dBm, IF BW 100 Hz

jankae commented 2 years ago

Sorry everyone - I get that this is an annoying issue and would really like to solve it but I don't know where to start. No crashes or freezes on my side so far. Please try the latest development version as well (https://github.com/jankae/LibreVNA/actions/runs/1952430415). I don't really think that this improves things (have not fixed anything that could crash the GUI lately) but it could be worth a try.

LibreVNA GUI shut itself down because it could not receive data

Why do you think this is the reason for the shutdown? Is there an error message indicating a problem about receiving data?

What can I do for it?

Get me as much information about the crash as possible - you already mentioned your sweep settings and version number, this is a good start. If you are able/allowed, you can also send me your measurement script which issues the SCPI commands. I'd like to replicate your scenario as much as possible.

One more thing that could really help (if you or someone else with the problem is comfortable around code): Compile the GUI from code (using QtCreator) and then let it run in debug mode. Once it crashes, send me the stack trace.

spannohouse commented 2 years ago

I updated the gui and firmware as directed: https://github.com/jankae/LibreVNA/actions/runs/1952430415

I will test the system now and let you know tomorrow.

spannohouse commented 2 years ago

nothing to do ... even with this firmware the system after a while 'freezes

sp9bsl commented 2 years ago

Hi all, I have the same issue with firmware/software v1.3.0. Everything freezes sometimes after few minutes and sometimes after an hour. Sometimes entering new value for freq span or center helps. AMD FX6300 Win 10 21H2. Center 3.2GHz, span 100MHz, 501 points, -5dBm, BW 1k. ADC not overdriven.

Slawek

TopQuark12 commented 2 years ago

@jankae Here you go, compiled from source and ran in debug mode, waited a few hours until it crashed. I exported the full back trace, not sure this is the "stack trace" you are referring to.

Hope it helps.

backtrace crash.txt

jankae commented 2 years ago

Hi TopQuark, many thanks for that, definitely interesting. I do not have a lot of experience analyzing these logs, but my first guess is a buffer overflow (due to all the 'corrupt stack' messages). Did your debugger stop at a specific line when the crash occured? Also some questions to that I can replicate your setup:

TopQuark12 commented 2 years ago

I have experienced crashes without TDR, I just happened to have it setup for this crash.

The debugger did not stop at any line, but the application output terminal stopped updating after crashing.

I am on commit adc873e776db929895f98f4972b68439733dd1c4

I've attached my setup file as requested. Funny enough, saving the setup file caused the program to crash.

crash setup.setup.txt

jankae commented 1 year ago

I'll close this one as 1.2.1 is not up to date anymore. But I will be happy (well, not really) to receive a new issue if the newer GUI versions still crash

spannohouse commented 1 year ago

I also tried with the latest version of Firmware v1.4.0 but with the same result. After a while the system freezes