[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