Opened 5 years ago

Last modified 4 years ago

#1362 new defect/bug

Valgrind memcheck finds multiple issues

Reported by: mvglasow (2) Owned by: KaZeR
Priority: minor Milestone: version 0.6.0
Component: core Version: git master
Severity: normal Keywords:


TL;DR: Navit has a few issues with out-of-bound reads or memory which is not properly initialized or freed after use. We need a few people who have some standard test cases, as this will need to be tested with as many different usage scenarios as possible. If you've never used Valgrind before, this would be a good opportunity to start.

When examining Navit with valgrind, multiple issues are found, such as:

  • invalid reads (beyond allocated memory or from memory that has been deallocated): this may become an issue as behavior is unpredictable—this kind of thing leads to spurious and seemingly inexplicable errors
  • jumps depending on uninitialized memory (a variable which has never been initialized is used as a condition in a loop or if statement): essentially the same consequences as above
  • lost memory blocks (memory which is allocated but never free'd): this may cause memory usage to increase if the program runs for a longer time, and may lead to the system running out of memory

To reproduce, I recommend using Eclipse (see instructions on the Wiki), installing Valgrind and getting the Valgrind plugin for Eclipse. (If you are not using the latest versions of Eclipse and Valgrind, note dependencies of the plugin on certain versions of the two—get the latest version of the plugin which supports your setup, but no later than that.)

A limitation with Valgrind is that it will find such conditions only if the code in question actually runs. At present, just starting Navit and exiting again will generate a bunch of issues; however, you won't find issues in the routing code unless you actually calculate a route. Therefore, once Navit starts without any complaint from Valgrind, I recommend running some real-world test cases (such as calculating a few routes) and then examining the Valgrind report.

I encourage everyone who has not yet used Valgrind to give it a try—it's a useful skill to acquire, and in the few weeks since I started using Valgrind, I have found it a very useful tool which has helped me identify the sources of many otherwise inexplicable errors.

Change History (3)

comment:1 Changed 5 years ago by

I think 1 of the 1st step before that would be the move to g_* functions for memory allocation (there are still a few occurences out there that don't use tehm, I'm working on cleaning that up lately). I'd be interested to help on that along with the unit tests (

comment:2 Changed 5 years ago by

Added this one to the code cleanup and sanity project:

comment:3 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.