Opened 10 years ago

Last modified 4 years ago

#1067 new defect/bug

Handle low-memory situations more gracefully

Reported by: mvglasow (2) Owned by: KaZeR
Priority: major Milestone: version 0.6.0
Component: core Version: git master
Severity: complex Keywords: performance, crash


Some operations in Navit, e.g. search and routing, can exhaust all available memory. This is an issue especially on low-end devices with low memory.

Currently Navit does not handle such conditions very gracefully, in most cases it will just crash or exit with no clear indication of what happened.

I suggest improving handling of such conditions. Main goals are:

  • To keep Navit running even if memory is exhausted
  • Provide the user with feedback of what happened
  • Try to continue the operation that exhausted the memory with a tightened belt

First of all, we need to handle indications of low memory. Possible approaches are:

  • In the loop of potentially memory-hungry operations, query available memory on each run. If it falls below a threshold, tighten the belt.
  • On Android, process ComponentCallbacks?.onLowMemory() (see and tighten the belt.
  • As a last resort, afaik Unix-line environments send a signal to processes when the system runs out of memory, and kills processes unless they process the signal. Although this is probably available on all platforms on which Navit currently runs, we will get this signal when there is already no more memory available. A workaround would be to assign an "iron reserve" of memory (size equal to the threshold mentioned in the first point) and free it in the signal handler, then set a flag that will cause all operations to tighten their belt.

User feedback: Currently Navit doesn't have a real interface for reporting status messages to the user. Approaches are:

  • Android has a nice "toast alert", which briefly displays a message in the bottom portion of the screen - such as the success/failure of an operation or other operations that the user should be aware of but which do not require user interaction to proceed. Something similar could be implemented in Navit.
  • Introduce a new OSD element which stays hidden until there is a message to display. It may remain visible as long as a given state persists (e.g. route calculation consumed all memory stays visible until routing is canceled or a new route is calculated) or for a fixed period of time (e.g. 5 seconds). We'd still need something for the internal GUI in this case.

Tightening the belt: We need to prevent the current operation from consuming more memory and still return a useful result.

  • For search: If the number of matches is too big to fit in memory, an option for free-text searches is to return only exact matches. Then fill up with partial matches as long as memory is still available and truncate results when memory is low. The user can then enter additional characters to get more suggestions. Feedback is important ("Too many results, try typing in more characters"). For other searches, reduce the search radius until results fit in memory and notify the user about it ("Too many results, the search radius has been reduced").
  • For routing: This is a tricky part, see also #456 and #1066. The last resort is to abort routing and return a status. I would suggest a separate "out of memory" status - because for debugging purposes it is important to tell that from "no route found". Another option is to set route_depth to something less memory-consuming and set a flag to retry route calculation as we approach the destination.

Change History (5)

comment:1 Changed 9 years ago by usul

  • Keywords performance crash added
  • Milestone set to version 0.5.1

Sounds reasonable to me, but might result in a lot of work.

comment:2 Changed 9 years ago by mvglasow (2)

I think this can be done in steps, and the most urgent issue is to prevent crashes. A first step could be to detect when memory is exhausted and react to that - stop navigation or truncate search results, and log an error (important for debugging). The other things - user feedback and graceful recovery - are less urgent.

comment:3 Changed 9 years ago by usul

  • Severity set to complex

comment:4 Changed 5 years ago by

  • Milestone changed from version 0.5.1 to version 0.5.2

This ticket was pushed back in order to bring 0.5.1 out soon.

comment:5 Changed 4 years ago by

  • Milestone changed from version 0.5.2 to version 0.6.0

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.