Hello,
we are experiencing higher memory usage after version 3.54.3 . The memory usage is expanding over the time from 500Mb till all the free memory is used and the complete system crashes (after +-4 hrs off driving). We are experiencing this in the all latest versions; our system is android 11 and has 4GB off ram. the issue was also there with android 10.
As side info: we use Lomaps (offline maps) in combination with a lot off tracks
I have the same experience with LM4 while geocaching
https://forum.locusmap.eu/index.php?msg=66982
where do you see the memory usage ?
Android settings/Apps/Locus memory?
@balloni55 depending on device:
Developer settings, running services;
you can try to install an older version and see if you experience the same as us. I think vs 4.3 is somthing like our working version
We don't use geocaching
I am also not sure if the problem started with 3.43, i only know that the newer versions give problems to us (3.6X defenitly)
Hi guys, this sounds like a serious problem. Balloni has this problem with geocaching and without the navigation & jordyke during navigation. So common here is the work with map > zooming & panning right?
I've noted a TODO task and will test it next weeks a little.
Hello,
is there more info about this?
We tested
-using on-and offline maps (no difference),
-no wps (no difference)
-no active kml (no difference)
-only points and tracks (no difference)
-all settings default (except screen allways on!)
rollback to 3.54.3 seems to solve the 'crash' problem (bus still a pretty high memory usage).
Hi guys,
yesterday was published a new app version. I rewrote one part of the background map system that may have influenced this. Based on my measurement, it helped a little. So give the new version a try please and let me know. Thanks.
What is the best/ preferred way of measuring for/ reporting of memory leaks?
@ menion
today on a winter cache biketour (-5°C) i could not notice any improvement, sorry
no improvement.jpg
Hmm thanks
@balloni55 , 1.1GB, it is still too much. Oki, I'll keep searching next few days/weeks, damn...
@Andrew Heard you may see on ballonis screenshot, simply every app/system setting that display current app consumption.
@menion - no memory leak here, but my situation was quite simplistic - track recording - after startup 154MB, after track record 220MB, a few hours later with no further use 191MB, next day with no further use 175MB .
Thanks Andrew, appreciate your tests. I'm unable to find the difference because of your/mine usage and how
@balloni55 or
@jordyke use the app. There has to be some issue, but it is quite hard to find ...
It sounds like the leak is only with geocaching. I was only using track recording, not geocaching. As a retired programmer I don't miss tracking down memory leaks ;-)
Quote from: Andrew Heard on December 16, 2022, 22:32:35It sounds like the leak is only with geocaching.
Hello Andrew
no,
memory leak occurs when:
- map is visible
- map is centered
- map is moving (new tiles are loaded)
- map rotate ?
Wolfgang
ok, in my testing you'd think then that I had all those factors? Or what different should I try to reproduce the leak?
what map and theme do you use?
i use OAM V5 with TOTM mapsforge
OAM V5 mostly with Karl Chick's Ordnance Survey (OS) map theme.
I was testing it a lot over the weekend and there seems to be a problem with map tile images (so directly bitmap images) remaining in the native memory.
The most simple test is to have a NMEA file for simulation, zoom in a lot, so the map move also. Navigation and also track recording seems to be without a problem. Now I have to find out why this happens ...
Hallo menion,
long time nothing heard from you on this problem
it seems to me that since the V4map change, the problem has worsened.
Today after about 2.5 hours 1.7GB were used by Locus
Ah, thanks balloni for the reminder ... visible truth is that I've forgot about it. I remember I tested it and noticed a very similar (not so critical) problem, but even after some testing, I wasn't able to find out why this happens.
Hmm ... complicated problem.
I may only add it higher in the never-ending list of priority tasks.
Quotevisible truth is that I've forgot about it.
sorry, i can't forget it....
after ~ 2.5 hours locus first becomes very slow and then it grinds
Hi balloni,
I've finally yesterday and today made some tests and found only a single problem that was caused by using the auto-zoom feature. Are you using it?
Quotethat was caused by using the auto-zoom feature. Are you using it?
no, never sorry. Only manual zoom in/out
the problem results exclusively from loading new map tiles
Sadly, this behaviour continues in 2024. I mentioned it last year here (https://forum.locusmap.eu/index.php?topic=8532.msg72561#msg72561). Did my first longer motorcycle day trip for this year and what happened: Locus crashes. Worse! App freeze after 2.5 hours, then it close itself.
I have gold abo, newest LoMaps, Sunny 1" SRTM with shading activated, Autozoom enabled and was navigation a route planned with Locus Routeplanner about 250 km.
Please fix this issue. I use Locus Maps since 2018 for motorcyling with thousands of kilometers and never had this issue since last year.
I have the same impression, although from another scenario. Locus running in the background as a service basically 7 x 24 (even when not out of the house), over time it will eat up memory. This makes some popup menus pure white. Most of the cases it recovers some time later, but sometimes I need to restart Locus to get it back "on track".
As memory leaks are one of the hardest things to catch in development, I recommend to switch off shading while traveling. For planning I understand shading is very helpful. While "executing" it's not, for sure not when you go 100 mph + :-)))
Anyway, just my 2c, trying to "buy time" until resolution, which might take quite some time.
Cheers
Michael
PS: I am not claiming that shading IS the culprit, but for sure it is a load for battery and memory alike, hence low hanging fruit - without guarantees, though ...
My configuration (except better Hardware) has not changed. So it's a Locus failure.
I did not dispute that - I thought and wrote about a practical chance to ease pain a bit for the time being.
Analysis and fix has to be on Locus side for sure.
Quote from: michaelbechtold on April 07, 2024, 13:26:24Analysis and fix has to be on Locus side for sure.
One year passed - result?
Confirmed today during a ride to work ... 45 minutes till the system killed stucked Locus. I have to look at it more carefully soon.
That's a brutal one ...
I very rarely had a crash related to memory in more than 10 years, but blank popup menues and screens and alike have been a regular issue.
Hence I suspect there might be more than one leak OR one root cause leak that develops towards different, more or less serious consequences, based on still unknown conditions.
Good luck!!
Cheers
Michael
45 minutes? Than I am lucky with 2,5 h 8) Thanks for looking at this, Menion.
No obvious memory leak in 4.23.0 here.
- Initial memory 153 MB
- 15m later 154 MB
- 7h later 211 MB (after tracking recording)
@Andrew Heard
what map and theme do you use?
which zoom range?
with map rotation?
- map shading?
- dynamic elevation?
Track recording causes no problems. My test setup used an active navigation with many recalculations (maybe 30+ during a 45 min ride). So I believe it will be connected. Anyway, I promise I'll look at it during the next weeks ...
Quote from: balloni55 on April 10, 2024, 08:04:46@Andrew Heard
what map and theme do you use?
which zoom range?
with map rotation?
Quote from: michaelbechtold on April 10, 2024, 21:51:33- map shading?
- dynamic elevation?
- 2021-11-28 OpenAndroMaps Australia-Tasmania
- 200m (on ruler) (whatever ZL that is I don't generally view)
- map rotation:on
- track recording:on
- navigation:off
- map shading:off
- dynamic elevation:off
- display is normally off (99.99% of recording time)
Wrong topic I know, sorry, but charts below (time vs. battery current milliamps each 2 minutes) comparing Locus with just track recording vs. Locus with navigation and track recording. Just thought it was interesting & confirms for battery misers when riding all day why avoiding navigation mode could wring out the life of the battery before it goes flat. Ignore the -250mA spike on the 1st chart - was when camera used, not just Locus running. I have found/ discovered recently that measuring/ logging current with Tasker rather than %level is a better indication of energy usage. At 10:45 in 2nd chart, navigation stopped and was then just track recording.
@menion- I note in v4.23.1 release notes "reduced app refresh in the background when not active" - charts below are for 4.23.0 so would be interesting now to see whether this affects the battery current. Did you make this change to save battery energy?