[Tilecache] Tilecache 2.0.1 Segfault

[Steve Lime]

Hasn't been much of a help when the problem could be in code linked to python. I can't get any
output from just wrapping the call to tilecache_seed.py in valgrind. I'm probably using it wrong
though so will have to research more.

Steve

>>> On 3/19/2008 at 1:33 PM, in message <47E15C82.4020404 at saucontech.com>, Mark
Deneen <mdeneen+tiles at saucontech.com> wrote:
> I have not been following this thread very carefully, but valgrind 
> (www.valgrind.org) is a wonderful tool for finding leaks.  It may be a 
> bit more low-level than you want for this purpose...  but I would give 
> it a shot.
> 
> Mark
> 
> 
> Steve Lime wrote:
>> I just tried rebuilding the mapscript bindings with the latest version of 
> Swig and the more
>> advanced interface. No luck. 
>>
>> In my case the mapfile is made up of a bunch of includes so perhaps there is 
> a leak there. I'll
>> try expanding those and see what happens.
>>
>> Steve
>>
>>   
>>>>> On 3/19/2008 at 12:58 PM, in message <20080319175857.GA23409 at metacarta.com>,
>>>>>         
>> Christopher Schmidt <crschmidt at metacarta.com> wrote:
>>   
>>> On Wed, Mar 19, 2008 at 12:34:21PM -0500, Steve Lime wrote:
>>>     
>>>> The backtrace output is below. I don't think it tells me much. It's dying in 
> 
>>>>       
>>> MapServer but I think it's because
>>>     
>>>> there simply isn't any more memory to allocate so a small malloc fails 
>>>>       
>>> (there is no error check) and then the
>>>     
>>>> fread causes the segfault. The question is why there is no memory. When I 
>>>>       
>>> run the seeding the python
>>>     
>>>> process the python process memory usage swells to 1.4Gb. I've tried with and 
> 
>>>>       
>>> without metatiling, same
>>>     
>>>> result. There must be a leak someplace. Any idea how to debug?
>>>>       
>>> Yeah, clearly there's a memory leak: I don't hae any idea where it is
>>> though, nor do I have any suggestions on how to debug. Keeping the map
>>> object open might actually help in this case, because if there's a leak
>>> somewhere in the mapObj open (something not gtting freed), it would be
>>> less prominent if we weren't constantly recreating the mapObj, yeah? 
>>>
>>> Regards,
>>>     
>>
>> _______________________________________________
>> Tilecache mailing list
>> Tilecache at openlayers.org 
>> http://openlayers.org/mailman/listinfo/tilecache 
>>   
> 
> _______________________________________________
> Tilecache mailing list
> Tilecache at openlayers.org 
> http://openlayers.org/mailman/listinfo/tilecache