[mapserver-dev] msautotest hanging on Windows due to arecent change

Steve Lime Steve.Lime at dnr.state.mn.us
Mon Jul 13 10:28:51 EDT 2009


Took me a few minutes to remember what iteminfo was in the first place. Simple is good so this
was another good find I guess. 

Steve

>>> On 7/12/2009 at 6:04 PM, in message
<f3b73b7d0907121604u412d986dh605ddc8e0bbc0ced at mail.gmail.com>, Tamas Szekeres
<szekerest at gmail.com> wrote:
> Steve,
> 
> Thank you for fixing this, that wasn't be so trivial for me to find out the
> problem easily ;-)
> I've checked this out, and the issue appears to be solved in the recent
> version.
> 
> Best regards,
> 
> Tamas
> 
> 
> 
> 
> 2009/7/12 Steve Lime <Steve.Lime at dnr.state.mn.us>
> 
>> I believe I've fixed this. Graticule layers had screwy functions to manage
>> iteminfo. For
>> some reason they were mucking with the items/numitems layer attributes and
>> the new
>> which items code exposed this problem. I imagine this stems from the
>> initial implementation
>> when, perhaps, there was thought to storing a graticule line's label in a
>> an attribute. Instead
>> shape->text holds that information. I don't believe graticules need *any*
>> attributes and a
>> bit of code could be removed from mapgraticule.c. Will create a ticket to
>> track that removal.
>>
>> Steve
>>
>> >>> "Steve Lime" <Steve.Lime at dnr.state.mn.us> 07/11/09 8:32 AM >>>
>> I'll check... Steve
>>
>> >>> Tamas Szekeres <szekerest at gmail.com> 07/10/09 6:09 PM >>>
>> Hi All,
>>
>> I've found an annoying effect of one of the recent changes in trunk causing
>> msautotest (buildbot) to hang in the following command (in
>> msautotest/misc):
>>
>> shp2img -m grid.map -o result/grid.png
>>
>> The process is running in an infinite loop with a significant cpu
>> utilization.
>>
>> By breaking the execution in a debugger the call stack looks something
>> like:
>>
>>     libmap.dll!_gdCacheGet()  + 0x20 bytes    C
>>     libmap.dll!_gdImageArc()  + 0x751 bytes    C
>>     libmap.dll!_gdImageStringFTEx()  + 0x843 bytes    C
>>     libmap.dll!_gdImageStringFT()  + 0x3c bytes    C
>> >    libmap.dll!msDrawTextGD(gdImageStruct * img=0x028e6cc0, pointObj
>> labelPnt={...}, char * string=0x02a3a678, labelObj * label=0x02ac17d8,
>> fontSetObj * fontset=0x00f0b3e8, double scalefactor=1.0000000000000000)
>> Line 2988 + 0x58 bytes    C
>>     libmap.dll!msDrawText(imageObj * image=0x028e6c80, pointObj
>> labelPnt={...}, char * string=0x02a3a678, labelObj * label=0x02ac17d8,
>> fontSetObj * fontset=0x00f0b3e8, double scalefactor=1.0000000000000000)
>> Line 822 + 0x31 bytes    C
>>     libmap.dll!msDrawLabelCache(imageObj * image=0x028e6c80, map_obj *
>> map=0x00f0b3a0)  Line 2424 + 0x4b bytes    C
>>     libmap.dll!msDrawMap(map_obj * map=0x00f0b3a0, int querymap=0)  Line
>> 507 + 0xd bytes    C
>>     shp2img.exe!00401ae7()
>>     [Frames below may be incorrect and/or missing, no symbols loaded for
>> shp2img.exe]
>>     shp2img.exe!00401dba()
>>     kernel32.dll!7d4e7d42()
>>
>>
>> I'd wonder if someone who have better knowledge about the recent changes
>> could find out the reason.
>> I could see a couple of changes related to msLayerWhichItems which caused
>> issues, but I don't see one by one correspondence between those changes and
>> this problem.
>>
>> Best regards,
>>
>> Tamas
>>
>> _______________________________________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org 
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev 
>>
>>



More information about the mapserver-dev mailing list