<sigh> I'm an idiot. Total size is much smaller. 72K agg_wms_segfault.tar.gz
Paul, you'll appreciate this. The file is much smaller when you do this: $ ogr2ogr parcel_clip.shp PG:"host=localhost dbname=foo" \ -sql "SELECT parcel_id, import_exp, external_i, ST_Intersection('SRID=4326;POLYGON((-122.339256836 47.6576914062, -122.331763672 47.6576914062, -122.331763672 47.6651845703, -122.339256836 47.6651845703, -122.339256836 47.6576914062))', the_geom) FROM parcel WHERE 'SRID=4326;POLYGON((-122.339256836 47.6576914062, -122.331763672 47.6576914062, -122.331763672 47.6651845703, -122.339256836 47.6651845703, -122.339256836 47.6576914062))' && the_geom" \ -nlt POLYGON instead of just: $ ogr2ogr parcel_clip.shp PG:"host=localhost dbname=foo" \ -sql "SELECT parcel_id, import_exp, external_i, ST_Intersection('SRID=4326;POLYGON((-122.339256836 47.6576914062, -122.331763672 47.6576914062, -122.331763672 47.6651845703, -122.339256836 47.6651845703, -122.339256836 47.6576914062))', the_geom) FROM parcel" -nlt POLYGON I'll file the bug now. Roger -- On Fri, Jan 29, 2010 at 4:42 PM, Paul Ramsey <pram...@opengeo.org> wrote: > File bug in trac > > http://trac.osgeo.org/mapserver > > With a 5mb attachement, you might need to separately upload it somewhere > and post a URL, not sure what the attachment max size is for osgeo trac. > > P > > On 2010-01-29, at 4:40 PM, Roger André wrote: > > Alright, I've clipped the data sets down to areas just slightly larger than > the WMS bbox, cleaned up the map file, and replicated the WMS to make sure > that it still breaks. The tgz file that contains the mapfile and 2 > shapefiles is just under 5 MB. Where should I file the bug, and can I > attach the data to the bug? > > Thanks, > > Roger > -- > > > > On Fri, Jan 29, 2010 at 2:57 PM, Roger André <ran...@gmail.com> wrote: > >> Hi Paul, >> >> Ok. I'll see if I can replicate the problem with a single data layer, and >> will then package everything together so another developer can run it. >> >> Thanks, >> >> Roger >> -- >> >> >> On Fri, Jan 29, 2010 at 2:16 PM, Paul Ramsey <pram...@opengeo.org> wrote: >> >>> Lovely, Another AGG bug. Well the next thing is to package up your >>> environment so a developer can duplicate the problem on their rig. Figure >>> out which layer it is, so you only have to pack that data up. Since the >>> issue is arising in AGG, flag the ticket to the AGG module. When you pack up >>> your map file, remember to also pack up or strip out things like templates, >>> font libraries, symbol libraries, etc. Ideally, copy the whole mess to a new >>> path on your system ensure it does in fact run independently of the rest of >>> your installation. >>> >>> Best, >>> >>> Paul >>> >>> On 2010-01-29, at 2:11 PM, Roger André wrote: >>> >>> Hi Paul, >>> >>> Thanks for the advice. (Chris Schmidt suggested I do the same thing in >>> IRC yesterday, and I forgot to try it.) >>> >>> Below are the results of gdb. It's fun to run, but uhm... not something >>> I'm readily able to decipher (yet). >>> >>> $ gdb /usr/lib/cgi-bin/mapserv >>> GNU gdb (GDB) 7.0-ubuntu >>> Copyright (C) 2009 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later < >>> http://gnu.org/licenses/gpl.html> >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show >>> copying" >>> and "show warranty" for details. >>> This GDB was configured as "i486-linux-gnu". >>> For bug reporting instructions, please see: >>> <http://www.gnu.org/software/gdb/bugs/>... >>> Reading symbols from /usr/lib/cgi-bin/mapserv...done. >>> (gdb) run >>> "QUERY_STRING=map=/var/www/mapfiles/seattle.map&layers=roads&styles=&service=WMS&width=256&format=image/png&request=GetMap&height=256&srs=EPSG:4326&version=1.1.1&bbox=-122.338256836,47.6586914062,-122.332763672,47.6641845703" >>> Starting program: /usr/lib/cgi-bin/mapserv >>> "QUERY_STRING=map=/var/www/mapfiles/seattle.map&layers=roads&styles=&service=WMS&width=256&format=image/png&request=GetMap&height=256&srs=EPSG:4326&version=1.1.1&bbox=-122.338256836,47.6586914062,-122.332763672,47.6641845703" >>> [Thread debugging using libthread_db enabled] >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> 0x0740bbf2 in ?? () from /lib/tls/i686/cmov/libc.so.6 >>> (gdb) bt >>> #0 0x0740bbf2 in ?? () from /lib/tls/i686/cmov/libc.so.6 >>> #1 0x0740d868 in malloc () from /lib/tls/i686/cmov/libc.so.6 >>> #2 0x006abbb7 in operator new(unsigned int) () from >>> /usr/lib/libstdc++.so.6 >>> #3 0x006abced in operator new[](unsigned int) () from >>> /usr/lib/libstdc++.so.6 >>> #4 0x080dbdd5 in void >>> mapserver::render_scanlines<mapserver::rasterizer_scanline_aa<mapserver::rasterizer_sl_clip<mapserver::ras_conv_int> >>> >, mapserver::scanline_u8, >>> mapserver::renderer_scanline_aa_solid<mapserver::renderer_base<mapserver::pixfmt_alpha_blend_rgba<mapserver::blender_rgba_pre<mapserver::rgba8, >>> mapserver::order_bgra>, mapserv_row_ptr_cache<int>, int> > > >>> >(mapserver::rasterizer_scanline_aa<mapserver::rasterizer_sl_clip<mapserver::ras_conv_int> >>> >&, mapserver::scanline_u8&, >>> mapserver::renderer_scanline_aa_solid<mapserver::renderer_base<mapserver::pixfmt_alpha_blend_rgba<mapserver::blender_rgba_pre<mapserver::rgba8, >>> mapserver::order_bgra>, mapserv_row_ptr_cache<int>, int> > >&) () >>> #5 0x080ba7ac in T.1744 () >>> #6 0x080bdbda in msDrawShadeSymbolAGG () >>> #7 0x0813b3d2 in msDrawShadeSymbol () >>> #8 0x0809ff17 in msDrawShape () >>> #9 0x080a2cfe in msDrawVectorLayer () >>> #10 0x080a343d in msDrawLayer () >>> #11 0x080a4fd7 in msDrawMap () >>> #12 0x08157d82 in msWMSGetMap () >>> #13 0x0815cf36 in msWMSDispatch () >>> #14 0x080e9924 in msOWSDispatch () >>> #15 0x08056583 in main () >>> (gdb) >>> >>> Roger >>> -- >>> >>> On Fri, Jan 29, 2010 at 1:38 PM, Paul Ramsey <pram...@opengeo.org>wrote: >>> >>>> Roger, >>>> >>>> It looks like you're on Linux, so pull a stacktrace, it's fun! >>>> >>>> gdb /path/to/mapserv >>>> >>>> ... lots of info ... >>>> >>>> (gdb) run >>>> "QUERY_STRING=map=/var/www/mapfiles/seattle.map&layers=roads&styles=&service=WMS&width=256&format=image/png&request=GetMap&height=256&srs=EPSG:4326&version=1.1.1&bbox=-122.338256836,47.6586914062,-122.332763672,47.6641845703" >>>> >>>> then when you hit to segfault, do >>>> >>>> (gdb) bt >>>> >>>> bt stands for backtrace >>>> >>>> now you'll have a lot more useful information about what went wrong, >>>> >>>> Yours, >>>> >>>> Paul >>>> >>>> On Fri, Jan 29, 2010 at 1:27 PM, Roger André <ran...@gmail.com> wrote: >>>> > Hi All, >>>> > >>>> > I'm experiencing some strange behavior that I would appreciate some >>>> help >>>> > testing. My MapServer 5.6 instance is segfaulting in response to >>>> certain >>>> > WMS requests it is receiving from TileCache. Below is one of the >>>> specific >>>> > requests: >>>> > >>>> > >>>> http://localhost/cgi-bin/mapserv?map=/var/www/mapfiles/seattle.map&layers=roads&styles=&service=WMS&width=256&format=image/png&request=GetMap&height=256&srs=EPSG:4326&version=1.1.1&bbox=-122.338256836,47.6586914062,-122.332763672,47.6641845703 >>>> > >>>> > I'd appreciate it if someone who has a layer that covers Seattle would >>>> try >>>> > the bbox extents listed above and report back if it causes an error >>>> for >>>> > them. >>>> > >>>> > FYI - When I set this bbox as the EXTENTS in my MAP, and the SIZE to >>>> 256 >>>> > 256, Mapserver delivers the image without any problem. >>>> > >>>> > Thanks, >>>> > >>>> > Roger >>>> > >>>> > _______________________________________________ >>>> > mapserver-users mailing list >>>> > mapserver-users@lists.osgeo.org >>>> > http://lists.osgeo.org/mailman/listinfo/mapserver-users >>>> > >>>> > >>>> >>> >>> >>> -- >>> Paul Ramsey >>> OpenGeo - http://opengeo.org >>> Breath in. Breath out. Ahhh. PostGIS. >>> >>> >>> >>> >> > > -- > Paul Ramsey > OpenGeo - http://opengeo.org > PostGIS topical ointment. Cures slow maps. > > > >
_______________________________________________ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users