20.04 Focal: uNav freezes with GPS enabled

[lduboeuf]

@kristatos said in 20.04 Focal: uNav freezes with GPS enabled:

@lduboeuf Yes, he said it's working for him under noble. But It think he's using a Fairphone 4 or 5.
I don't think it's a device issue because there are multiple affected devices and under these, there are Mediatek and Qualcomm chipsets.
But, like @haagch said, it would be nice to know, how to debug this issue to help get this annoying bug fixed.

Just tested on Noble, FP4 with Unav and i have the freeze issue.
@AppLee do you confirm it is working for you on FP5 ?

[AppLee]

Hi @lduboeuf

Not sure what the problem is, there might be several...
I noticed some freezes, but I can overcome them and I managed to have to location updated while walking.
When freeze occurs it's often after making a search or new navigation or this kind of operation.
Edit: to be thorough only uNav freezes.

I don't remember exactly but I think I make my search before asking to locate me.
Basically there is an order that work ; search the location, then start the navigation, then location activation.

I'm using a FP5 on Noble and Pure Maps doesn't work on Noble yet.

[kristatos]

@AppLee said in 20.04 Focal: uNav freezes with GPS enabled:

I don't remember exactly but I think I make my search before asking to locate me.
Basically there is an order that work ; search the location, then start the navigation, then location activation.

That was the way I thought it would work reliable, but also this order freezes sometimes.
When you first locate your position and then try to do something else (e.g. search a destination, calculate a route ...) the crash is save for about 99,9%.

Long story short, there's nobody who can say, that the navigation is working for him like expected and without issues. And for me, that was the case under Xenial. There have never been any freezes in conjunction with GPS. So, how can we figure out what causes this freezes?

[AppLee]

@kristatos said in 20.04 Focal: uNav freezes with GPS enabled:

And for me, that was the case under Xenial.

On Focal it navigation works fine with Pure Maps, I tested it earlier this year.
But since I'm testing Noble, I don't use Focal so much...

[CiberSheep]

As long as you don't cancel the navigation uNav will work (and it has been all this time).
If you cancel, then close and reopen uNav.

said in 20.04 Focal: uNav freezes with GPS enabled:

With gps, wifi, mobile network all on
Tap on the map
Start navigation

[haagch]

Getting just a bit more into UT, I guess I could get gdb on it, either by just finding a static gdb build and putting it in the user dir, or by making the system writable and installing it, and then attaching to the hanging process, but for the moment I'm just looking around.

uNav is really a QtWebEngineProcess and trivially freezing for me.

Pure Maps seems to be a native Qt application and it has been very rarely freezing (but it has happened) - on the other hand I'm not sure it ever actually stops locating with GPS while running, so it's hard to say if it suffers the same issue or not - What I'm wondering is if this is just a QtWebEngine issue or a general issue.

[Talkless]

Not sure if relevant, but I've reported some time ago tha PureMaps freezes for me unless I rebuild PureMaps without AppArmor confinement: https://github.com/rinigus/pure-maps/issues/619

I just use OSMand via Waydroyd. UBPorts is less and less usable for me.

[uxes]

@Talkless same here, when i need navigation, i use osmand+

unav and puremaps are not usable, issues with missing gps signal in app (but other apps in same time can show my location), crashing or freezing and after some application switching

[slowcyclist]

Just as @applee, I suspect that this thread possibly discusses several different bugs. Notably, I believe the problem described in reply #3, and maybe by @kristatos are the same as the one I described in this other topic. The issue in that other topic is related to how UBports interfaces with the android gps drivers and it affects all apps using gps on all ported android phones released since around 2020, but possibly with app-dependent symptoms : freezing, crashing, or just going on with a frozen location.

The good news is that the other topic's bug has a working fix which should hopefully land in an upcoming OTA.

[haagch]

Work wishes us to be familiar with the capabilities of AI, so I figured I'd let Opus 4.6 have a go at it.

It did fix the immediate issue and here is the result: https://haagch.frickel.club/files/ubtouch_gps_fix/

gps-fix.tar.xz contains a build of the fixed library for current 24.04.1-2 and the scripts to install it, and restore the original version. For installing this system wide fix the root partition needs to be made writeable, then the library replaced, then it can be made readonly again. This worked here, but will need to be applied after every OS update until it is fixed upstream.
Note that it's much better to reproduce a patched library yourself rather than installing a prebuilt one from a random stranger like me.

The patch fix-gps-singleton-instance.patch it came up with is this:

diff --git a/qt/position/core_geo_position_info_source.cpp b/qt/position/core_geo_position_info_source.cpp
index 62e5cfd..a4eeb53 100644
--- a/qt/position/core_geo_position_info_source.cpp
+++ b/qt/position/core_geo_position_info_source.cpp
@@ -389,7 +389,25 @@ void core::GeoPositionInfoSource::Private::handleVelocityUpdate(const cll::Updat
 
 void core::GeoPositionInfoSource::Private::createLocationServiceSession()
 {
-    instance = std::make_shared<Instance>();
+    // Keep the Instance alive as a process-wide singleton.  The dbus-cpp
+    // asio executor uses a global static boost::asio::io_context
+    // (see dbus-cpp executor.cpp make_executor()).  When an Instance is
+    // destroyed, its Executor::stop() calls io_context::stop() on that
+    // global object.  Because the io_context is shared, this permanently
+    // poisons it: any subsequent io_context::run() returns immediately,
+    // so a new Instance's worker thread exits at once and all blocking
+    // D-Bus calls (transact_method / invoke_method_synchronously) hang
+    // forever waiting for a reply that will never be dispatched.
+    //
+    // QtWebEngine's LocationProviderQt destroys and recreates its
+    // QGeoPositionInfoSource on every geolocation request cycle, which
+    // triggers Instance destruction → io_context::stop().  On the next
+    // cycle a new Instance is created but its worker is dead-on-arrival.
+    //
+    // Fix: use a persistent static shared_ptr so the Instance (and its
+    // worker thread / D-Bus connection) lives for the entire process.
+    static std::shared_ptr<Instance> s_instance = std::make_shared<Instance>();
+    instance = s_instance;
 
     try {
         session = instance->getService()->create_session_for_criteria(cll::Criteria{});

and the AGENTS.md and final_report.md files should contain enough info to reproduce this build via qemu and proot.

As usual with AI generated fixes, I don't claim that this is the correct way to fix this, nor that there are no issues with this like leaks. So don't go around and demand someone merge this immediately. I just figured I'd post this because it'll make my own smartphone slightly more useful for navigation right now.