Map freezing everything after first fix

[avalori1]

I managed to have the tool working, but only if the map tab is deactivated.
Here below some observations:

• If I start gnss-sdr while the map tab in gnss-sdr-monitor is ACTIVE, the gnss-sdr-monitor stays responsive UNTIL THE FIRST FIX IS AVAILEABLE, after the first position is determined, gnss-sdr-monitor stops responding and the Force Quit or Wait window shows up.
• If I start gnss-sdr while the map is INACTIVE, I can toggle the map until the first position is NOT computed. If I activate the map after the first position is computed, I get back to the unresponsive situation.

Clearly the issue is a combination of the map tab ON and the position determined.

[TheJForge]

I can confirm the same behavior on Ubuntu 22.10 ,Xorg, and Gnome-shell.

If I open gnss-sdr-monitor before gnss-sdr is running, disable the map, and run gnss-sdr, all goes well until the run is over.

If I open gnss-sdr-monitor before gnss-sdr is running, enable the map, and run gnss-sdr, gnss-sdr-monitor works as expected until a position fix is achieved, then the entire application freezes, "Force Quit or Wait" pops up, and I have to force quit it.

It also appears that one CPU core gets pegged at 100% utilization at the same time.

[acebrianjuan]

Thank you @avalori1 and @TheJForge for reporting the issue.
I am going to look into it.

[alphafox02]

I’m seeing this now on 22.04 using Gnss-SDR from source and latest Gnss-SDR monitor. I’ll have to double check the map trick, but essentially the monitor just becomes unresponsive - although maybe somewhat unrelated I also see Gnss-SDR itself peg one core to max and I start seeing 0000 in terminal. This occurs after adding the necessary monitor config options to the .conf for the SDR.

[gabegarz]

I have experienced the same issue running a 22.04 VM where the program runs as long as map is disabled. It seems the map is not loading and gets stuck.