> 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/
