[Tilecache] Tilecache 2.0.1 Segfault

[Beau Gunderson]

Some pointers for valgrind + python here:

http://svn.python.org/projects/python/trunk/Misc/README.valgrind
http://svn.python.org/projects/python/trunk/Misc/valgrind-python.supp


On Thu, Mar 20, 2008 at 7:36 AM, Steve Lime <Steve.Lime at dnr.state.mn.us>
wrote:

> 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
>
> _______________________________________________
> Tilecache mailing list
> Tilecache at openlayers.org
> http://openlayers.org/mailman/listinfo/tilecache
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/tilecache/attachments/20080320/6370e2b7/attachment.html