2006.08.04 18:13 "RE: [Tiff] libtiff and MSVC 6 Update", by

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.