Opened 16 years ago
Closed 13 years ago
#2016 closed defect (wontfix)
VSI_TIFFOpen calls VSIFCloseL sometimes with fatal consequencies
Reported by: | Ari Jolma | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | GDAL_Raster | Version: | unspecified |
Severity: | normal | Keywords: | gtiff libtiff |
Cc: |
Description
Creating a dataset with GTiff driver leads to core dump in some cases if the dataset already exists.
The reason is that VSI_TIFFOpen calls VSIFCloseL after failed XTIFFClientOpen, which has already closed the FILE. This happens at least in my environment which uses libtiff from GTK+.
The code is
use Geo::GDAL; Geo::GDAL::GetDriver('GTiff')->CreateDataset('test.tif', 100, 100);
and test.tif is a bogus file. In fact the program dumps the core *only* if test.tif is *not* a valid tiff.
Ari
Attachments (1)
Change History (6)
comment:1 by , 16 years ago
by , 16 years ago
Attachment: | gdal_svn_trunk_gtiff_hack_for_2016.patch added |
---|
follow-up: 3 comment:2 by , 16 years ago
Component: | default → GDAL_Raster |
---|---|
Keywords: | gtiff libtiff added |
I have reviewed libtiff 4alpha and libtiff 3.9alpha and in both cases I don't see how closeproc() would get called by TIFFClientOpen(). If TIFFClientOpen() fails it will call TIFFCleanup() but this does not call tif->tif_closeproc().
Perhaps an older libtiff does call tif_closeproc in TIFFCleanup()?
Ari, what version of libtiff are you using?
comment:3 by , 16 years ago
Ari, what version of libtiff are you using?
I've put the libtiff and test.tif to http://map.hut.fi/files/misc/
It is quite old (10.2.2004) and I don't know where did it come from. I'm trying to check.
comment:4 by , 16 years ago
Well, it is from the latest Galde/GTK for Windows build at http://gladewin32.sourceforge.net/
Ari
comment:5 by , 13 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Assuming this works with current libtiff versions. Closing
I didn't manage to reproduce your crash on a bogus tiff with internal libtiff (maybe you could provide your particular test.tif). However by reading tifvsi.cpp, I share your analysis that if _tiffCloseProc is called and XTIFFClientOpen returns NULL, a crash will probably occur.
Is it a bogus behaviour of your particular version libtiff ? I don't know.
Maybe you can try the attached patch. I'm not particularly proud of it, but it should solve your issue. Basically, it prevents XTIFFClientOpen from closing the file. It defers the closing afterwards.