How to ensure all library changes are flushed to database

Hi Andrew,

I'm afraid it's not possible to say straight away if all mods were safely written. We would need to know the cause of the app crash, all events preceding (or leading to) the crash and so on. So please when someting like that occurs, report it immediately according to the instructions in https://docs.locusmap.app/doku.php?id=manual:faq:issue_reporting. Thanks a lot!

Thanks Michal, but maybe you misunderstood the question - I can guarantee the database is up-to-date by exiting Locus. But is there a faster method?

.

Doing a crash report is often not convenient, certainly when outside navigating, and to be useful to you, takes an amount of time to write (I've done plenty before).

Do you mean some "reload" or "refresh" button in the library? I'm afraid I don't know about any... all changes should be written in the library immediately after executing the change. Unless the process is disrupted by something else, like a crash.

"all changes written immediately" - that's my point - assuming sqlite database, inserts or updates are generally never written immediately unless a transaction; any crash & the last few need to be done again

I've verified this with @Menion : all changes to tracks, routes and points are immediately written into the database. Unless the process is interrupted by a crash. That's why we need as much as possible info about the actions leading to the crash. If possible, including your user ID or bugreport.

Hmm. Interesting. The last time I had made 3 or 4 changes in the library, moved between folders etc. but later (not immediately) while dragging around the map, there was a crash, then on restart the changes were lost. Not the 1st time. Not often. But I know it happens. Often it's simply not convenient to do a bug report sorry.

I understand, I ride a bike too and when there is a problem with Locus there's no time to deal with it. But when something happens when fiddling with the library on your sofa... it's another story. Anyway, thanks a lot for your cooperation.

Hello Andrew,

may you write me here a "user ID" from the app (about app > user ID)? Crashes should be (not always as Firebase service we use seems not to be 100% reliable) send to our server, so if you write me your ID and the day it happen, I may try to find the reason of the crash. Thanks.

Not online Firebase service, I think local sqlite database? I think all databases cache/ batch updates to backend? I was not using cloudsync. But if useful 046392f35. Maybe in the app make this ID copyable with long tap.

/Android/media/menion.../data/database/*.db-journal or db-wal

regards Andrew (in bus shelter on side of quiet French road)

Hello Andrew,

what happens to you (crash) is a different problem we are still trying to solve. Next (Beta) version will have a minor changes that should help here.

Enjoy the trip!

Quite interesting Menion. How do you know (crash) what happened without a crash report from me? Alsace/ Thann tomorrow. Cheers Andrew

I'm able to get to this ... anonymous crash report thanks to "Firebase Crashlytics" system we use. Not all crashes are there (not sure why not), but many yes ...

A very useful library. So offline/ local database is Firebase not sqlite. My mistake.

ok, another crash. now 4.30. i have 5 POI. I set visibility to none. All good. I started new testing of online search, unrelated to POI. 1st time: 4 results but tap of any result is ignored. i closed the bottom panel. Did same search. LM crashed. when I restarted, the 5 POI were visible again. so my interpretation is the library changes hadn't been flushed to file?

Hello Andrew, another crash and this time, I see nothing in the "Crashlytics" 😥. I can't say it is identical problem as before (I hoped it will be fixed in 4.30+ version).

Since some months, Locus Map should write these crashes also into Locus/logs directory, so sharing log from correct day may help (if you are able to get to this directory > hmm, I should finally do some tool that will help with it)

Visibility of points/tracks is not saved in the database, but in a separate files next to database files. And this file is wrote in the moment, the app is minimized if I remember correctly. So crash, don't cause a save.

Ok. I've attached log for 19-06-2025. 296 files there, ha ha. In a way, your last reply answers my question - do a app swap or minimise app, to increase chance of all info is flushed to file, right?

Those files are relatively small but could be purged after a certain time span, maybe a few months?

Hello Andrew,

thanks for the log. I also do not see anything useful in it. Have you tried that latest 4.30.1 version?

Btw. purging of logs > good idea, implemented.

thanks for checking

yes, am using 4.30.1

I sent another Android crash report yesterday too

Thanks Andrew,

I see in your bug report native crash. Based on the AI, it is

This is a native crash, specifically a SIGSEGV (Segmentation Fault) with code SEGV_MAPERR, indicating a null pointer dereference. The crash occurs in libhwui.so, which is Android's hardware-accelerated UI rendering library.

Give a try next Beta version (end of this week). Does it happen often on this device? It may rarely happen in unknown cases, but definitelly not on regular basis.

based on AI - LOL - maybe the whole reply is written by AI instead of my virtual friend Menion ;-) how to tell?

the report seems consistent, yes, thanks

I think the crash happens more with older hardware

I don't think it's ever happened on the new-ish phone, generally the older tablet, & it doesn't happen often, and may even be less than older LM versions

null pointer - should be using c# instead of c or c++, just joking