[OSM-dev] [Tile-serving] mod_tile causes segfault on debian 7.0

Tom Hughes tom at compton.nu
Wed May 22 17:27:28 UTC 2013


On 22/05/13 18:20, Kai Krueger wrote:

> On 05/22/2013 11:04 AM, Tom Hughes wrote:
>
>> 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.

That's not what the interwebs are telling me - do you have some 
documentation for that claim? Only I'm finding quotes like "Pools are 
explicitly thread unsafe".

That's why you have things like per-request pools - so that you can do 
allocations in request context without locking overheads as well as so 
you can clean up easily.

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

Can the stores array not just be allocated in the child_init hook?

That way it is only the apr_pool_userdata_get call that you are relying 
on to be thread safe - no idea if it is, but at it is reading things it 
is more likely to be.

Tom

-- 
Tom Hughes (tom at compton.nu)
http://compton.nu/



More information about the dev mailing list