[Tile-serving] mod_tile causes segfault on debian 7.0
kakrueger at gmail.com
Wed May 22 17:20:30 UTC 2013
On 05/22/2013 11:04 AM, Tom Hughes wrote:
> On 22/05/13 17:47, Kai Krueger wrote:
>> So, unless you are using the memcached backend, this commit in theory
>> should be fine and I have done a bunch of load testing with ab to
>> confirm this. (Although limited ab testing can't properly simulate real
>> world load). I'll have another look through the file system backend, if
>> I can see anything that might be thread unsafe.
> I can...
> The call to get_storage_backend comes from the translate_name hook
> which I believe is called for each request.
Yes, that is correct.
> If the stores array does not exist yet then it will try to create it
> by allocating from a memory pool that is shared by all threads in that
> So if a new child is started, and multiple requests arrive more or
> less simultaneously to different threads in that process, then they
> will both try and allocate the stores array which means they will both
> be trying to manipulate the memory pool at the same time.
The apache routines to manipulate memory pools should be thread safe, so
that part should be fine.
It does look like it is possible that multiple processes can allocate a
new storage array simultaneously, but that should "only" lead to memory
leak, rather than crashes. In that race, simply one of the threads wins
and gets to set the stores array and the other allocated arrays go
unused. As all allocations are equivalent, it shouldn't matter which wins.
That race should be fixable, by simply adding an explicit lock after the
stores==null check. As this only happens at process / thread
initialisation and all operations are fast, the performance impact of
that should be negligible.
More information about the Tile-serving