Return-Path: <tiff-bounces@remotesensing.org>
Received: from inmx009.isp.belgacom.be (inmx009.isp.belgacom.be [195.238.3.146])
        by mailst035.isp.belgacom.be (8.12.11/8.12.11/Skynet-MAILSTORE-2.14) with ESMTP id iBRDYTEu015366
        for <joris.at.lebbeke@skynet.be>; Mon, 27 Dec 2004 14:34:29 +0100
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from xserve.flids.com (adsl-065-083-169-202.sip.mco.bellsouth.net [65.83.169.202])
        by inmx009.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id iBRDYGde018148
        for <joris.at.lebbeke@skynet.be>; Mon, 27 Dec 2004 14:34:18 +0100
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from adsl-065-083-169-202.sip.mco.bellsouth.net (localhost [127.0.0.1])
	by xserve.flids.com (Postfix) with ESMTP
	id E6A155600E7; Mon, 27 Dec 2004 08:33:57 -0500 (EST)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194])
	by xserve.flids.com (Postfix) with ESMTP id 7D58D5600CC
	for <tiff@remotesensing.org>; Mon, 27 Dec 2004 08:33:55 -0500 (EST)
Received: by wproxy.gmail.com with SMTP id 71so362604wra
	for <tiff@remotesensing.org>; Mon, 27 Dec 2004 05:33:54 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
	b=GqZ8vApmTcFcDvCemO+1ps+CJ/MBVPbdNFRe3GGUg36Io9rutTMiBtCcn6vjA6jPm2iLMXgFo+ujqzmAxnc+Jw01tBcAuimGjIXa2UpY8+0CIFtfEijYLNKiCRUNa98vsStmkCgHN5a1ObYa1/cddwvT8yOrJwfh4KI0ndOiNHg=
Received: by 10.54.26.3 with SMTP id 3mr29673wrz;
	Sun, 26 Dec 2004 07:47:13 -0800 (PST)
Received: by 10.54.13.2 with HTTP; Sun, 26 Dec 2004 07:47:13 -0800 (PST)
Message-ID: <931f8ea9041226074768b03c0f@mail.gmail.com>
Date: Sun, 26 Dec 2004 10:47:13 -0500
From: Frank Warmerdam <fwarmerdam@gmail.com>
To: Bill Bither <bill.bither@atalasoft.com>
Subject: Re: [Tiff] TIFF_BEENWRITING
In-Reply-To: <2A7F84B7BBB1CC4F88A9AD71142B91C8047087@ATALADC1.atalasoft.lcl>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <2A7F84B7BBB1CC4F88A9AD71142B91C8047087@ATALADC1.atalasoft.lcl>
Cc: tiff@remotesensing.org
X-BeenThere: tiff@remotesensing.org
X-Mailman-Version: 2.1.2
Precedence: list
Reply-To: warmerdam@pobox.com
List-Id: TIFF and libtiff discussion  <tiff.remotesensing.org>
List-Unsubscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=unsubscribe>
List-Archive: <http://xserve.flids.com/pipermail/tiff>
List-Post: <mailto:tiff@remotesensing.org>
List-Help: <mailto:tiff-request@remotesensing.org?subject=help>
List-Subscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=subscribe>
Sender: tiff-bounces@remotesensing.org
Errors-To: tiff-bounces@remotesensing.org
X-UIDL: 5f41684081c7b65eb920ccb72a8375a8

On Thu, 23 Dec 2004 11:34:17 -0500, Bill Bither
<bill.bither@atalasoft.com> wrote:
>  
>  
> 
> As of version 3.6.1, there has been a problem with the function
> TIFFWriteCheck in tiff_write.c.  The code 
> 
> Tif->tif_flags |= TIFF_BEENWRITING causes an overflow problem with GDI+ in
> .NET. When I comment it out, it appears to be fine.  Please see bug 719 for
> reference.  What does that flag do?  Any ideas on the real bug fix here? 

Bill, 

My understanding is that this flag is used to determine if any imagery
has been written yet.  When the first image data is written, this flag is
after various conditions are tested.  Thereafter various  image configuration
information (width, height, etc) becomes fixed.  This seem to be supported
by the comment in TIFFWriteCheck():

	/*
	 * On the first write verify all the required information
	 * has been setup and initialize any data structures that
	 * had to wait until directory information was set.
	 * Note that a lot of our work is assumed to remain valid
	 * because we disallow any of the important parameters
	 * from changing after we start writing (i.e. once
	 * TIFF_BEENWRITING is set, TIFFSetField will only allow
	 * the image's length to be changed).
	 */

I have skimmed 719 a couple times, but I am not terribly optimistic
it will be easy to isolate and correct the problem with the information
given.  I, for one, don't have particularly good memory corruptions
testing tools for win32, not any familiarity with the .net environment
so I am not sure it will be easy to reproduce the problem with the
given environment. If the problem could be reproduced with a C program
that we could also run on linux that would be helpful, as the valgrind
tool is very helpful for isolating heap corruption or other memory bugs. 

If anyone else on the list is feeling ambitious feel free to take a swing
at bug 719. 

  http://bugzilla.remotesensing.org/show_bug.cgi?id=719

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent
_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://xserve.flids.com/mailman/listinfo/tiff
