----------------------------------------
> From: rw_nor...@hotmail.com
> To: viking-devel@lists.sourceforge.net
> Date: Sun, 13 Jul 2014 12:16:51 +0100
> Subject: Re: [Viking-devel] Segmentation fault with git HEAD
>
>> 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.
I have committed a basic fix for this which checks tmp before trying to use it.
> 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.
>
After further thought, I now believe the second data structure has use of a
LIFO queue, so that when the maximum cache size is reached it removes the
oldest tiles (in terms of being added to the map cache).
For the complication of the code this LIFO method creates, one might instead
simply flush the entire memory cache and allow it to build up again. The user
is unlikely to notice any difference.
However since the map cache is 'working' well enough, I'm concentrating on
adding other features.
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Viking-devel mailing list
Viking-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viking-devel
Viking home page: http://viking.sf.net/
