[Tilecache] Tilecache 2.0.1 Segfault

Wed Mar 19 13:34:21 EDT 2008

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?

Steve

#0  0x400d8f4c in mempcpy () from /lib/tls/libc.so.6
#1  0x400cd1a4 in _IO_file_xsgetn_internal () from /lib/tls/libc.so.6
#2  0x400cf028 in _IO_sgetn_internal () from /lib/tls/libc.so.6
#3  0x400c3ba9 in fread () from /lib/tls/libc.so.6
#4  0x4065ebe5 in msSHPOpen () from /usr/local/lib/python2.5/site-packages/_mapscript.so
#5  0x4065eda8 in msShapefileOpen () from /usr/local/lib/python2.5/site-packages/_mapscript.so
#6  0x4065efcb in msShapeFileLayerOpen () from /usr/local/lib/python2.5/site-packages/_mapscript.so
#7  0x4068ba71 in msLayerOpen () from /usr/local/lib/python2.5/site-packages/_mapscript.so
#8  0x406a17f6 in msDrawVectorLayer () from /usr/local/lib/python2.5/site-packages/_mapscript.so
#9  0x406a1da1 in msDrawLayer () from /usr/local/lib/python2.5/site-packages/_mapscript.so
#10 0x406a34d4 in msDrawMap () from /usr/local/lib/python2.5/site-packages/_mapscript.so
#11 0x4063a2b1 in _wrap_mapObj_draw (self=0x0, args=0x42a2968c) at mapscript_wrap.c:3858
#12 0x08127536 in PyCFunction_Call (func=0x40541dac, arg=0x42a2968c, kw=0x0) at methodobject.c:93
#13 0x0805ab7e in PyObject_Call (func=0x40541dac, arg=0x42a2968c, kw=0x0) at abstract.c:1860
#14 0x080d6380 in PyEval_EvalFrameEx (f=0x829dcb4, throwflag=0) at ceval.c:3844
#15 0x080da3f7 in PyEval_EvalCodeEx (co=0x40522218, globals=0x40424dfc, locals=0x0, args=0x824b018, argcount=1, kws=0x824b01c, kwcount=0,
    defs=0x0, defcount=0, closure=0x0) at ceval.c:2831
#16 0x080d7b03 in PyEval_EvalFrameEx (f=0x824aecc, throwflag=0) at ceval.c:3659
#17 0x080d946f in PyEval_EvalFrameEx (f=0x824737c, throwflag=0) at ceval.c:3650
#18 0x080d946f in PyEval_EvalFrameEx (f=0x8246964, throwflag=0) at ceval.c:3650
#19 0x080d946f in PyEval_EvalFrameEx (f=0x824637c, throwflag=0) at ceval.c:3650
#20 0x080da3f7 in PyEval_EvalCodeEx (co=0x40264338, globals=0x40408bdc, locals=0x0, args=0x82448c0, argcount=2, kws=0x82448c8, kwcount=0,
    defs=0x40418778, defcount=1, closure=0x0) at ceval.c:2831
#21 0x080d7b03 in PyEval_EvalFrameEx (f=0x824472c, throwflag=0) at ceval.c:3659
#22 0x080da3f7 in PyEval_EvalCodeEx (co=0x401e9c38, globals=0x401e1f0c, locals=0x0, args=0x8241174, argcount=5, kws=0x8241188, kwcount=0,
    defs=0x401f7cd8, defcount=2, closure=0x0) at ceval.c:2831
#23 0x080d7b03 in PyEval_EvalFrameEx (f=0x824100c, throwflag=0) at ceval.c:3659
#24 0x080d946f in PyEval_EvalFrameEx (f=0x818c314, throwflag=0) at ceval.c:3650
#25 0x080da3f7 in PyEval_EvalCodeEx (co=0x401d8578, globals=0x401a5acc, locals=0x401a5acc, args=0x0, argcount=0, kws=0x0, kwcount=0,
    defs=0x0, defcount=0, closure=0x0) at ceval.c:2831
#26 0x080da5e5 in PyEval_EvalCode (co=0x401d8578, globals=0x401a5acc, locals=0x401a5acc) at ceval.c:494
#27 0x080f90eb in PyRun_FileExFlags (fp=0x817e008, filename=0xbffff1cf "./tilecache_seed.py", start=257, globals=0x401a5acc,
    locals=0x401a5acc, closeit=1, flags=0xbfffee7c) at pythonrun.c:1271
#28 0x080fab6d in PyRun_SimpleFileExFlags (fp=0x817e008, filename=0xbffff1cf "./tilecache_seed.py", closeit=1, flags=0xbfffee7c)
    at pythonrun.c:877
#29 0x08056e28 in Py_Main (argc=6, argv=0xbfffefb4) at main.c:523
#30 0x080563c8 in main (argc=7, argv=0xbfffefb4) at python.c:23

>>> On 3/18/2008 at 2:24 PM, in message <20080318192428.GA16166 at metacarta.com>,
Christopher Schmidt <crschmidt at metacarta.com> wrote:
> On Mon, Mar 17, 2008 at 03:58:44PM -0500, Steve Lime wrote:
>> Hi all: I'm using tilecache with a MapServer layer and running into problems 
> when seeding the cache. In this instance
>> all the layers in the mapfile are STATUS DEFAULT, on all the time. Running 
> the seeding program seems to work ok
>> with 2 exceptions:
>> 
>>   1) for every tile I get a WMS exception
>> 
>>   <CTYPE ServiceExceptionReport SYSTEM 
> "http://schemas.opengis.net/wms/1.1.1/exception_1_1_1.dtd">
>>     <ServiceExceptionReport version="1.1.1">
>>       <ServiceException code="LayerNotDefined">
>>         msWMSLoadGetMapParams(): WMS server error. Invalid layer(s) given in 
> the LAYERS parameter.
>>       </ServiceException>
>>   </ServiceExceptionReport>
>> 
>> This is expected I guess since there is no layer specified in the 
> tilcache.cfg file (since all are on by default). The
>> tiles ARE created despite the error message. Would be nice to suppress that 
> if it's benign.
> 
> Since TileCache uses the owsParams way of loading a mapobj, it has the
> same requirements that a WMS Request does, so this is 'automatic': I'm
> not sure how you're getting a WMS Exception but still getting tiles
> created? That definitely seems weird to me.
> 
>>   2) after every 500 to 1,000 tiles or I get a segmentation fault. No other 
> error information
>> 
>> If I re-run the seed command it picks up again from where it dies, although I 
> sometimes have to run it twice to clear
>> our any file locks. It'll run another 500 to 1,000 or so and it dies again.
>> 
>> Could be a MapServer issue or TileCache, not sure. The debugger gives me:
>> 
>>   Program received signal SIGSEGV, Segmentation fault.
>>   [Switching to Thread 1075357376 (LWP 31768)]
>>   0x400d8f4c in mempcpy () from /lib/tls/libc.so.6
>> 
>> Has anyone else into anything like this?
> 
> I've seen this on a SuSE box as well. (Specifically, 'hypersphere', a
> telasciecne/OSGeo machine.) As far as I know, this is a MapServer
> segfault of some kind: does a backtrace help you here? I've never had
> the desire to debug it, to be honest. I've never had it happen on
> Debian.  
> 
> Regards,