> Date: Sun, 22 Jun 2014 13:35:49 +0200 > From: em...@gmx.net > To: viking-devel@lists.sourceforge.net > Subject: [Viking-devel] Segmentation fault with git HEAD > > Not sure if the intention is that the Viking git master branch is > always clean but I did try it anyhow. > > I compiled the code based on git index 4200b261[*] and see that I can > easily trigger a Segmentation fault: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x9f851b40 (LWP 6998)] > 0x080b41b6 in a_mapcache_remove_all_shrinkfactors (x=x@entry=1051, > y=y@entry=675, z=0, type=13, zoom=zoom@entry=6) at mapcache.c:187 > 187 if ( strncmp(tmp->key, key, len) == 0 ) >
We've traced this due to the variable tmp being NULL, thus trying to perform tmp->key results in the crash. Further I don't understand the circumstances that leads to this condition, however it has caused me to look at the code in mapcache in general. There are two data structures in the mapcache: 1. An actual hash containing keys against map tiles - this makes sense. 2. A circular linked list queue (using own implementation - I don't think there is a glib support for ringbuffers) I don't understand the point of the second one. The queue seems to be equivalent of the hash cache and used just to compare the keys stored in deciding which ones can be removed. As far as I can tell the keys in the queue are not ordered in any way, so there is *no* efficiency gain compared to just comparing every entry in the hash cache directly. >From the naming of variables - it appears the mapcache was written first as a >list queue but then changed into the hash but somehow ending up as a mis-mash >between the two. (This is speculation as this is before the public source code >history starts). Given the list deals directly with pointers we have several sections that can easily have fatal errors, as seen with this error (and another one I came across). The mapcache is complicated by storing resized tiles (i.e. ones with shrinkfactors other than 1.0) that only exist in memory and need to be removed/recreated when the tile for that zoom level is downloaded. One alternative is to remove the shrinkfactors from the mapcache as this make the key store / removal very straight forward. Then the resized tiles would need to be recalculated every redraw. This would probably turn out to be too slow. If one tries to order the queue/list so the removal lookups are fast - then that imposes the insertions are ordered - so then the more common operation of insertion is slowed - so I don't think this best answer. So ATM my preferred thinking is to simply completely remove the queue from the code and simply when shrinkfactors are to be removed - just iterate through the entire hash cache to find and remove them. Any thoughts? ------------------------------------------------------------------------------ _______________________________________________ Viking-devel mailing list Viking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viking-devel Viking home page: http://viking.sf.net/