GPS positioning stops working after a random duration

[Keneda]

@slowcyclist
I moved thread so it gets more views, because it may not be device specific.

[gpatel-fr]

@slowcyclist

I don't see anything of the sort in my logs of the preceding month, however I am not really using the feature, I have posted that the behaviour was too unreliable (hit and miss, sometimes it works very well, sometimes not at all.

I tested it a bit at some time to see if AGPS could be made to work, without success so far, however in the process I had found this command:

sudo lomiri-location-serviced-cli --bus system --test

that allows to follow the activity of the satellite detection in the Halium container; IIRC this command was terminating regularly if left to run continuously, maybe this is related ? it could be linked to a restart of the container or something.

Looking at the service (systemctl cat lomiri-location-service), I see that no automatic restart has been configured like there is for services such as ofono, for example.
Maybe you could add an overlay to the service to see if it brings some more reliability ? Beware that an overlay already exists, you would have to take care of that somehow by naming the overlay file such as it comes after the existing one.

[slowcyclist]

@gpatel-fr Except for the bug I report here, I find that GPS on the FP5 works reliably outdoors, although it may take up to a few minutes to get the first fix ( hence maybe the hit-or-miss impression if one is not patient enough). The problem I report here is that, once you get a fix, you can't use the GPS for an arbitrarily long period: at some point (it can be after 5 minutes, 20 minutes or 2 hours) you'll hit this bug and you'll need to reboot to recover usage of the gps (the phone still works well besides that).

I've also been monitoring what goes on on the android side when the bug occurs:
LocSvc_GnssAPIClient tries to deliver an NMEA sentence via gnssNmeaCb callback to the UBports hybris layer
The binder call fails with DEAD_OBJECT because the ubuntu_application_gps_hidl_for_hybris process on the UBports side has died
LocSvc_GnssInterface detects serviceDied and calls cleanup
It sends QMI_LOC_STOP_REQ_V02 to the modem — actively stopping GPS at the hardware level
Then QMI_LOC_SET_ENGINE_LOCK_REQ_V02 — locking the engine
From this point isGpsEnabled:0 — the session is permanently dead until reboot

It seems rather clear that the root cause is the UBports process ubuntu_application_gps_hidl_for_hybris that bridges the Android GNSS HAL to the Linux side dying, at which point the Android HAL correctly detects the dead binder and shuts everything down. The GPS hardware itself is fine — it's the UBports bridge process that's crashing due to the segfault.

If the termination of the lomiri-location-serviced-cli that you observed was due to the same issue, then GPS would seem disabled afterwards, until reboot. And AFAIU having the service auto-restarting would not resucitate the GPS, but I'll give it a try.

[gpatel-fr]

@slowcyclist

I never used GPS a lot , but now that you are speaking of it, I'm beginning to vaguely remember that there could be one or 2 times when GPS stopped mysteriously indeed.

I'd say that with a process calling back into another, the first process locking everything just because one time it did not get a reply from the client layer would be a fragile design, maybe Google has done this but this does not look like something people designing a system for billions of users would do.
If there is some retry mechanism, restarting the UT service could be of help.

[slowcyclist]

@gpatel-fr Hey, you were right! By merely restarting the service, positioning becomes available again (no need to reboot!), and adding Restart=on-failure in the service file does the job automatically.
Alas, it's not really a fix for the problem : all the applications that were using the gps at the time of the service failure/restart quit as soon as you try to get back to them. Restarting PureMaps is much faster than rebooting, but you still need to acquire a new gps fix...

I've seen other errors than segfaults in the same piece of code :

Mar 03 15:01:50 ubuntu-phablet lomiri-location-serviced-wrapper[6592]: malloc(): unaligned fastbin chunk detected
Mar 03 15:01:50 ubuntu-phablet systemd[1]: lomiri-location-service.service: Main process exited, code=killed, status=6/ABRT
Mar 03 15:01:50 ubuntu-phablet systemd[1]: lomiri-location-service.service: Failed with result 'signal'.

Mar 03 15:08:19 ubuntu-phablet lomiri-location-serviced-wrapper[7546]: malloc_consolidate(): unaligned fastbin chunk detected
Mar 03 15:08:19 ubuntu-phablet systemd[1]: lomiri-location-service.service: Main process exited, code=killed, status=6/ABRT
Mar 03 15:08:19 ubuntu-phablet systemd[1]: lomiri-location-service.service: Failed with result 'signal'.

It seems this daemon's code did not evolve much lately. It was working well on my Xperia X which was armhf while now I have random alignment errors or segfaults on the FP5 which is arm64. But if the architecture is the reason, it should likely affect all arm64 phones running UBports, unless compilations options/checks are set differently on the FP5...

I guess I'll try to rebuild this piece of code with debug symbols, but then guidance for running it with gdb would be welcome.

[gpatel-fr]

@slowcyclist

I don't recall ever having things like that in my logs. I am not running the same version as you, I stick to stable. Not sure if it could make a difference since AFAIK your daily version was the same as the 24.04-1.2 stable 12 days ago, I take it that the problem is older than that for you ? I never tried the daily, do you really upgrade your phone every day ?

[WillemHexspoor]

@slowcyclist You're not the only one... I'm having the exact same issue, also on FP5. I'm running 24.04-1.2 stable

[gpatel-fr]

@WillemHexspoor said:

I'm having the exact same issue, also on FP5. I'm running 24.04-1.2 stable

hum, do you have only the same symptoms, or do you also have segfaults and unaligned errors in your logs ?

I have the same phone with the exact same version, I may have had the same symptoms (not sure), but definitely not the unaligned errors, at least for the 5 weeks worth of journal data that I have on my phone. @slowcyclist don't use the same version of UT I think, it's daily instead of stable.

[WillemHexspoor]

@gpatel-fr

My apologies, I replied to the initial post of @slowcyclist, and while re-reading my own post it is indeed not very clear.
I'm having the both mallooc and segfaults. Especially the segfaults result into freezing navigation apps.

Mar 07 09:42:25 ubuntu-phablet lomiri-location-serviced-wrapper[1708]: malloc(): unaligned fastbin chunk detected
Mar 07 09:42:25 ubuntu-phablet systemd[1]: lomiri-location-service.service: Main process exited, code=killed, status=6/ABRT
Mar 07 09:42:25 ubuntu-phablet systemd[1]: lomiri-location-service.service: Failed with result 'signal'.
Mar 07 09:42:25 ubuntu-phablet systemd[1]: lomiri-location-service.service: Consumed 6.437s CPU time.

Mar 08 20:48:56 ubuntu-phablet systemd[1]: lomiri-location-service.service: Main process exited, code=killed, status=11/SEGV
Mar 08 20:48:56 ubuntu-phablet systemd[1]: lomiri-location-service.service: Failed with result 'signal'.
Mar 08 20:48:56 ubuntu-phablet systemd[1]: lomiri-location-service.service: Consumed 3.987s CPU time.

[gpatel-fr]

@WillemHexspoor

thanks for the precisions, now my guess is that I have yet not seen this problem because I have not used GPS a lot in the recent past.