LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
April 1998
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
1998.04.07 17:13 "Re: libtiff isn't closing all of the file handles on NT ?", by Gerben Vos
This may be fixed by defining __WIN32__ (Microsoft's compiler only defines WIN32), so the pv_map_handle member is added to the tiff directory structure. I don't remember anymore whether this was the fix to this problem or another, but you do need to define it. What i did, was to change the following in tiffcomp.h: 52a53,56 #if defined(__acorn) && defined(__riscos) #define __acornriscos #endif > > #ifdef WIN32 > #define __WIN32__ > #endif #if defined(__MWERKS__) || defined(THINK_C) #include <unix.h> Also, i changed this in tiffio.h: 74c74 typedef uint32 tstrip_t; /* strip number */ typedef uint32 ttile_t; /* tile number */ typedef int32 tsize_t; /* i/o size in bytes */ < #if defined(_WINDOWS) || defined(__WIN32__) || defined(_Windows) --- > #if defined(_WINDOWS) || defined(__WIN32__) || defined(WIN32) || defined(_Windows) #include <windows.h> 76c76 < #ifdef __WIN32__ --- > #if defined(__WIN32__) || defined(WIN32) DECLARE_HANDLE(thandle_t); /* Win32 file handle */ #else typedef HFILE thandle_t; /* client data handle */ (Note: the diff format may not be exactly the same as that of Unix diff -c) If this helps you people, maybe this could be added to the next version of libtiff, so people who blindly try to compile it with Microsoft's compiler get better results. Gerben. > -----Original Message----- > From: Rex_Jolliff@notes.ymp.gov [SMTP:Rex_Jolliff@notes.ymp.gov] > Sent: Tuesday, 07 April, 1998 17:41 > To: jmwhite@interserv.com > Cc: cgriffin@mathworks.com; tiff@sgi.com; jaxon@lizardtech.com; > vxf@lizardtech.com; grizz@lizardtech.com; bradley@lizardtech.com > Subject: Re: libtiff isn't closing all of the file handles on NT > ? > > > > > I saw this same behavior under VMS and traced it down to the file > mapping > code also. > I noticed that it was allocating a channel and then not mapping the > file > correctly, > so it gave up on the map, but it did not deallocate the channel after > the > mapping > error. Perhaps somthing similar is happening in the NT code? > > Rex. > > > >Chris, > > I have had this exact problem on NT. I have a program that needs > to > >open many TIFF files and eventually it hangs the system. I wrote a > >small test program that repeatedly opens and then closes the same > TIFF > >file. Foe each open/close it looks like there are 3-5 handles left > >around. I have looked into this a little bit and I've found nothing > >obvious. One possible place it in the routine _tiffMapProc where it > >calls MapViewOfFile but I'm not sure. I've found no good work around > >and I'd be interested in any information too. > > Jim White > >Chris Griffin wrote: > >> > >> Hi, > >> > >> I am using LIBTIFF from within a DLL to read and write TIFF images > on a > >> Windows NT machine. I am finding that after I read a file, I can > no > longer > >> write to that file, and I also cannot delete it at the OS level > until my > >> application > >> has exited. > >> > >> This leads me to beleive that TIFFClose is not properly closing the > file. > >> I rebuilt the library with debugging flags and ran the whole thing > in > >> a debugger, and the call to CloseHandle (in tif_win32) is returning > a 1, > >> which indicates that it succeeded. > >> > >> So now I'm completely stumped! Has anyone else seen this > >> problem? > >> > >> Thanks, > >> Chris > > >