LibTiff Mailing List

Sean wrote:
> Since I am using VC6 and not 7, I assume that the "Enable Just-in-time 
> debugging" is analogous to "When the exception is thrown: Break into the 
> debugger" in VC7. 

The JIT stuff is a little different; VS6 does have an exception options
dialog as well, AFAIK under the 'debug' menu.

If you have a library or book budget at your disposal, I suggest finding
"Debugging Applications for Microsoft .NET and Microsoft Windows" by John
Robbins.  It seems like an excellent resource.

>     I recompiled the code with gcc/cygwin.  When executed it 
> throws an exception, but this one is a little more detailed:
> 
> Exception: STATUS_ACCESS_VIOLATION at eip=6FD8CF73
> eax=00000000 ebx=00000004 ecx=009A1FA0 edx=009A1FA0 esi=00000090 
> edi=00000000
> ebp=00000100 esp=0022ECD8 program=c:\Program Files\Microsoft Visual 
> Studio\MyProjects\write2DTIFF\Debug\write2DTIFF.exe, pid 
> 5252, thread main
> cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
> Stack trace:
> Frame     Function  Args
>       6 [main] write2DTIFF 5252 _cygtls::handle_exceptions: 
> Error while 
> dumping state (probably corrupted stack)
> 
>     In both cases, my dll is linked to libtiff.lib - presumably the 
> static library.

Ah, I think I misunderstood your setup -- do you mean that you're linking a
static build of libtiff to your own (home-brewed) DLL, which you then link
dynamically from another app?

I'm starting to suspect a mismatch between call models or perhaps something
else that's more "linking"-related.  Stack-based problems are often the
result of parameter size or order changes between caller and callee (it's
usually difficult to fool the compiler/linker, but sometimes you can slip
stuff past 'em).  Can you describe the framework of your application?  (e.g.
app links dynamically to mylib.dll; mylib.dll links statically to
libtiff.lib; etc).

Until now, I've been under the impression that you have an app that links
statically to libtiff.lib, resulting in a single-file application (just the
final .exe), but now I'm not sure...

>     On the subject of TIFFOpen, it does appear that some 
> default values are written if the program terminates before any 
> other commands are called.

Yep, I gather you're referring to TIFFDefaultDirectory().  So that reduces
the odds that the problem is within libtiff itself.

BTW, if anyone feels this is not relevant enough to the list, please email
me and say so, and I will be happy to take up the matter via email -- I just
figured others in future might run into similar problems and get some
benefit from this thread.


AWARE [SYSTEMS]		Imaging expertise for the Delphi developer
		TIFF and LibTiff Mailing List Archive
	LibTiff Mailing List TIFF and LibTiff Mailing List Archive August 2006 Previous Thread Next Thread Previous by Thread Next by Thread Previous by Date Next by Date Contact The TIFF Mailing List Homepage This list is run by Frank Warmerdam Archive maintained by AWare Systems	Thread 2006.08.04 15:56 "libtiff and MSVC 6 Update", by Sean Burke 2006.08.04 18:13 "Re: libtiff and MSVC 6 Update", by Bernie Pallek 2006.08.04 18:13 "Re: libtiff and MSVC 6 Update", by Bernie Pallek Sean wrote: > Since I am using VC6 and not 7, I assume that the "Enable Just-in-time > debugging" is analogous to "When the exception is thrown: Break into the > debugger" in VC7. The JIT stuff is a little different; VS6 does have an exception options dialog as well, AFAIK under the 'debug' menu. If you have a library or book budget at your disposal, I suggest finding "Debugging Applications for Microsoft .NET and Microsoft Windows" by John Robbins. It seems like an excellent resource. > I recompiled the code with gcc/cygwin. When executed it > throws an exception, but this one is a little more detailed: > > Exception: STATUS_ACCESS_VIOLATION at eip=6FD8CF73 > eax=00000000 ebx=00000004 ecx=009A1FA0 edx=009A1FA0 esi=00000090 > edi=00000000 > ebp=00000100 esp=0022ECD8 program=c:\Program Files\Microsoft Visual > Studio\MyProjects\write2DTIFF\Debug\write2DTIFF.exe, pid > 5252, thread main > cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023 > Stack trace: > Frame Function Args > 6 [main] write2DTIFF 5252 _cygtls::handle_exceptions: > Error while > dumping state (probably corrupted stack) > > In both cases, my dll is linked to libtiff.lib - presumably the > static library. Ah, I think I misunderstood your setup -- do you mean that you're linking a static build of libtiff to your own (home-brewed) DLL, which you then link dynamically from another app? I'm starting to suspect a mismatch between call models or perhaps something else that's more "linking"-related. Stack-based problems are often the result of parameter size or order changes between caller and callee (it's usually difficult to fool the compiler/linker, but sometimes you can slip stuff past 'em). Can you describe the framework of your application? (e.g. app links dynamically to mylib.dll; mylib.dll links statically to libtiff.lib; etc). Until now, I've been under the impression that you have an app that links statically to libtiff.lib, resulting in a single-file application (just the final .exe), but now I'm not sure... > On the subject of TIFFOpen, it does appear that some > default values are written if the program terminates before any > other commands are called. Yep, I gather you're referring to TIFFDefaultDirectory(). So that reduces the odds that the problem is within libtiff itself. BTW, if anyone feels this is not relevant enough to the list, please email me and say so, and I will be happy to take up the matter via email -- I just figured others in future might run into similar problems and get some benefit from this thread.

LibTiff Mailing List

Thread

2006.08.04 18:13 "Re: libtiff and MSVC 6 Update", by Bernie Pallek