OGR/Mapserver STYLEITEM "AUTO" broken in GDAL 1.4.1?

[wollah]

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

[wollah]

Zipped MapInfó? data

[warmerdam]

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.

[dmorissette]

"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.

[wollah]

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.

[warmerdam]

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.

[wollah]

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

[dmorissette]

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.

[dmorissette]

Fixed in SVN trunk in r11398 (not backported to 1.4).

[warmerdam]

Backported to 1.4 (r11399)