Access violation in TiffOpen Function in "write" mode

[acanicio]

Hello everybody,

I use LibTiffDelphi version 3.7.0.0 with LibTiff version 3.7.0.0

I have an issue using the TiffOpen Function. Whenever I try to open a Tiff file in "w" (write) mode, I get an access violation.

I have traced the error through the following stack of calls :

1 - In my program :
OpenTiff is a pointer.
Filename is a string containing the value 'c:\dev\testtiff\test.tif';
Of course, the file does NOT exist. The directory does.
<<
OpenTiff :=TTiffOpen(PAnsichar(Filename),'w');
>>

2 - In LibTiffDelphi.pas line 1652 function TTiffOpen :
<<
Result:=TIFFClientOpen(PChar(Name),PChar(Mode),fd,@TIFFFileReadProc,@TIFFFileWriteProc,@TIFFFileSeekProc,@TIFFFileCloseProc,@TIFFFileSizeProc,@TIFFNoMapProc,@TIFFNoUnmapProc);
>>

3 - In tif_open.c line 333, function TIFFClientOpen :
<<
if (!TIFFDefaultDirectory(tif))
goto bad;
>>

4 - In tif_dir.c , line 1198, function TIFFDefaultDirectory:
<<
(void) TIFFSetField(tif,TIFFTAG_COMPRESSION,COMPRESSION_NONE);
>>
5 - In tif_dir.c , line 708, function TIFFSetField :
<<
status = TIFFVSetFIeld(tif,tag,ap);
>>

6 - In tif_dir.c,line 177, function TIFFVSetFIeld:
<<
if(status = TIFSetCompressionScheme(tif,v) !=0)
>>

7 - In tif_compress.c function TIFSetCompressionScheme:

<<
int
TIFFSetCompressionScheme(TIFF* tif, int scheme)
{
const TIFFCodec *c = TIFFFindCODEC((uint16) scheme);
_TIFFSetDefaultCompressionState(tif);
/*
* Don't treat an unknown compression scheme as an error.
* This permits applications to open files with data that
* the library does not have builtin support for, but which
* may still be meaningful.
*/
return (c ? (*c->init)(tif, scheme) : 1);
}
>>
It crashes at the "return" clause, with the following error :
"Access violation at address B0B8005C . Read of address B0B8005C."
I don't have a C compiler so I cannot make changes to it or even test...
Thank you for any help.
Best regards
Axel

[acanicio]

Hello,

I just found out that I have the same problem with some other programs (not mine), and also in "read" mode...

So I just spent the last 6 hours trying to figure out the problem...

And something incredible happened.

It works !!.   Without having changed a single line of code !!.

I just set the "record field alignment" in the delphi compiler options to "4" instead of "2".

Geee... Can anybody explain to me why a value of "2" or "1" this ends up crashing when using libtiff ?

Best regards
Axel

[Toby Thain-2]

On 4-Jul-09, at 12:56 PM, acanicio wrote:

>
> Hello,
>
> I just found out that I have the same problem with some other  
> programs (not
> mine), and also in "read" mode...
>
> So I just spent the last 6 hours trying to figure out the problem...
>
> And something incredible happened.
>
> It works !!.  :jumping: Without having changed a single line of  
> code !!.
>
> I just set the "record field alignment" in the delphi compiler  
> options to
> "4" instead of "2".
>
> Geee... Can anybody explain to me why a value of "2" or "1" this  
> ends up
> crashing when using libtiff ? :confused:

Presumably your setting was different from that used by the ABI  
assumed by the libraries. This could cause various kinds of  
unexpected behaviour. The manual may have more to say about it.

--Toby

>
> Best regards
> Axel
>
>
>
>
>
>
> --
> View this message in context: http://www.nabble.com/Access- 
> violation-in-TiffOpen-Function-in-%22write%22-mode-
> tp24311610p24336211.html
> Sent from the Tiff / LibTiff mailing list archive at Nabble.com.
>
> _______________________________________________
> Tiff mailing list: Tiff@...
> http://lists.maptools.org/mailman/listinfo/tiff
> http://www.remotesensing.org/libtiff/

_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

[Bob Friesenhahn]

On Sat, 4 Jul 2009, acanicio wrote:

>
> I just found out that I have the same problem with another program, and also
> in "r" mode...
> I just spent the last 6 hours trying to figure out the problem...
>
> And something incredible happened.
>
> Now it works.  :jumping: Without having changed a single line of code !!.
>
> I just set the "record field alignment" in the delphi compiler options to
> "4" instead of "2".
>
> Geee... Can anybody explain to me why a value of "2" or "1" this ends up
> crashing when using libtiff ? :confused:

On some CPU types (probably not yours though) unaligned word access
will cause a segmentation violation.  In some cases this is a compiler
option since the application could arrange use less efficient
byte-level access to access the data word, or the OS could trap to a
function which does so.

It is likely that the old libtiff you are using has bugs in that it is
making assumptions about alignment, endian order, or word size.
Oodles of such bugs have been fixed over time.  During my short time
of helping out with libtiff, I have observed more bugs in the
directory tag code than any other part of libtiff.

Regardless, you are likely to see better application performance when
you compiler uses a default alignment of 4 rather than something less.

Defaulting to a word alignment of 2 and use of tiny data types for
enumerations are Borland oddities which don't match up with MSVC does.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/