#1571 closed defect (fixed)
OGR/Mapserver STYLEITEM "AUTO" broken in GDAL 1.4.1?
Reported by: | wollah | Owned by: | Daniel Morissette |
---|---|---|---|
Priority: | normal | Milestone: | 1.4.2 |
Component: | OGR_SF | Version: | 1.4.1 |
Severity: | normal | Keywords: | mitab style |
Cc: | Daniel Morissette, warmerdam |
Description
This pertains to GDAL 1.4.1/Mapserver 4.9. After upgrading from GDAL 1.3.2 to 1.4.1 STYLEITEM AUTO stopped working with most of the MapInfo TAB files in my project. With GDAL 1.3.2. the same mapfile worked fine. All ANNOTATION layers and some of the LINE layers don't display now ("premature end of script headers..."). All the files display fine in FME, QGIS, MapInfo, and they display with OGR when omitting STYLEITEM AUTO. I attach two non-working examples: DI_Ltg (LINE) and DI_Flurx (ANNOTATION).
Wollah
Attachments (4)
Change History (13)
by , 17 years ago
Attachment: | Kataster.zip added |
---|
comment:1 by , 17 years ago
Cc: | added |
---|---|
Component: | default → OGR_SF |
Keywords: | mitab style added |
Owner: | changed from | to
Version: | unspecified → 1.4.1 |
Mateusz,
Could you review differences in style strings returned for the above dataset, and document here? We will likely need to follow up with Daniel if there is a change that looks like it is broken. For now lets try to analyse this with ogrinfo rather than trying it with MapServer.
It is also desirable to compare 1.4.1 to 1.4.0 and trunk to see if any issue might already have been fixed in MITAB.
comment:2 by , 17 years ago
"premature end of script headers..." suggests that mapserver is crashing with GDAL 1.4.1 on those files. For this reason I suspect the issue is not related to the style strings but perhaps to some other changes in the MITAB lib. I'm leaving in a few minutes for the rest of the week so I can't test myself now, but I'd suggest that you start by a valgrind of ogrinfo on the files to see if that reports anything obvious.
comment:3 by , 17 years ago
I have been digging around a little and found the following:
this issue does not show up in my Windows builds (VC++7.0) of the same source trees (1.4.0/1.4.1/nightly snapshots). Thus, it is only occurring when built on my Linux Debian 3.1). The last working version is 1.3.2.0, released 2006/05/02. This looks quite strange to me.
comment:4 by , 17 years ago
I would agree with Daniel. Do a quick test of an "ogrinfo -al" report on the dataset with valgrind and if that is clean, close the problem as "works for me", and let Wollah follow up with MapServer and sufficient detail to reproduce the problem.
by , 17 years ago
Attachment: | valgrind-1.3.2_DI_Flurx.err added |
---|
by , 17 years ago
Attachment: | valgrind-1.4.1_DI_Flurx.err added |
---|
by , 17 years ago
Attachment: | valgrind-1.4.1_DI_Ltg.err added |
---|
comment:5 by , 17 years ago
I did some testing with gdal-1.3.2/1.4.1/valgrind and the mapserver tool 'shp2img' on two of the datasets in question. Attached is the output of valgrin ("valgrind --leak--check=yes"). HTH
comment:6 by , 17 years ago
Owner: | changed from | to
---|
Based on the Valgrind outputs I believe the issue is that OGRStyleTool::GetRGBFromString() receives a NULL pszColor and doesn't check that case. This would be related to the following MapServer bug: http://trac.osgeo.org/mapserver/ticket/1950
This bug is fixed in MapServer's SVN trunk and in the 4.10 branch (will be in 4.10.2), but I think we should still make GetRGBFromString() more robust by checking if the pszColor is NULL before calling sscanf. I'll make that change.
comment:7 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fixed in SVN trunk in r11398 (not backported to 1.4).
comment:9 by , 17 years ago
Milestone: | → 1.4.2 |
---|
Zipped MapInfó data