Return-Path: <tiff-bounces@lists.osgeo.org>
Delivered-To: even.rouault@spatialys.com
Received: from spool.mail.gandi.net (spool2.mail.gandi.net [217.70.178.211])
	by nmboxes134.sd4.0x35.net (Postfix) with ESMTP id F3EA361896
	for <even.rouault@spatialys.com>; Thu, 20 Jun 2019 15:31:59 +0000 (UTC)
Received: from lists.osgeo.org (osgeo6.osgeo.osuosl.org [140.211.15.3])
	by spool.mail.gandi.net (Postfix) with ESMTPS id 85FEE74008C
	for <even.rouault@spatialys.com>; Thu, 20 Jun 2019 15:31:57 +0000 (UTC)
Received: from osgeo6.osgeo.osuosl.org (localhost [127.0.0.1])
	by lists.osgeo.org (Postfix) with ESMTP id 79C6B6108851;
	Thu, 20 Jun 2019 08:31:54 -0700 (PDT)
Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com
 [209.85.221.66])
 by lists.osgeo.org (Postfix) with ESMTPS id 6CA836108848
 for <tiff@lists.osgeo.org>; Thu, 20 Jun 2019 08:31:52 -0700 (PDT)
Received: by mail-wr1-f66.google.com with SMTP id m3so3522304wrv.2
 for <tiff@lists.osgeo.org>; Thu, 20 Jun 2019 08:31:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=YajEbr4sfSONdzE3HZdTaTApidwUh9R+bpS28vhb70A=;
 b=DhVQT3A2zL+VTAaN74FtfXa8Tpr+41AK2odgrc+oaZpPTvMNspPGq7AepJTCROqigY
 KIE0P0vm+go5QIE6aRamjFi3nNfCIEM497TsQLMPul26TUR3VvMR77/+O7FmXgNEEzLO
 OdkKL1bJoYQ8I9JgveiZkbwV7EG7b1HqYtB8oOyuGxXeKdTm8BT2AReaCU9vOyaNGSf2
 c7G7NL9uDqQHEJJNW796Nv1GOODsjK6hZb2nA23v0Mu056wxL98wOmgXBSvhBcWI58VM
 MPWlAGjeuidn6nX0m72Y7RnhJ1LzN33MqavEroFb0At0zZ9Ht3qpa3FAgl1RRy88yBZx
 9x+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=YajEbr4sfSONdzE3HZdTaTApidwUh9R+bpS28vhb70A=;
 b=GcLlCH+ol7DyFsVpb4nrOHDdvsVBiwIobLOaD3ikAyTFM5VX9tFdgve4yJleM9rURG
 G1j08WxGl6n68SrZ9haN1KMfwcq/eGMhx4wpmY1zOeyX9stUXPUl+rmxmTV6uUyuH8PB
 fTHE2072tQLDgzCOf+CahUnkRXL5qmhBn0rPOyFp3sFMc/Y2ofr0Cao0ljis1w6C4Fyv
 JKM66q/z7FzHVnKZ1nUoooQFWs6oKdfK6rhBdXx57u3OmboZCE7FiRZYsMbu/raxAftk
 oYuPzfbsAQjfSTkJ93eTwuTLqVWpyrJFlL4X9t2sdm0+JYF+Hzdd2Xv5q/5VUoVeoCxQ
 do2w==
X-Gm-Message-State: APjAAAVEFu3FxxU6WRDVimPUIFnNjWorjVsMcvliPi36PYAm3ZdLwY+l
 OoPka4WJDwEj9KG2HjYv57LqSNWrieIthtwDGq6f5JLW
X-Google-Smtp-Source: APXvYqwMhHuFbnmtoNqWmWPprTFKWEwZBKSR+RYTMzTkCTJlzZAxrMJ+Li/WQxOymLKh2Dhu9LSd9+mCIbi1okbxtgY=
X-Received: by 2002:adf:de02:: with SMTP id b2mr15524376wrm.349.1561044711125; 
 Thu, 20 Jun 2019 08:31:51 -0700 (PDT)
MIME-Version: 1.0
References: <CAC=ZCwzS8buwTGZkhsJ0WGH=wkeWrssg9t-GOyMUrXRLnPcUVA@mail.gmail.com>
 <alpine.GSO.2.20.1906200734340.1813@freddy.simplesystems.org>
In-Reply-To: <alpine.GSO.2.20.1906200734340.1813@freddy.simplesystems.org>
From: ZdPo Ster <zdposter@gmail.com>
Date: Thu, 20 Jun 2019 17:31:39 +0200
Message-ID: <CAC=ZCwzVyVVo+cc2OV2sKb4dOqCUy=wSwrsKFvnUgz-MDdErjQ@mail.gmail.com>
To: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
Subject: Re: [Tiff] TIFFFdOpen crash on Windows 64bit
X-BeenThere: tiff@lists.osgeo.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.osgeo.org>
List-Unsubscribe: <https://lists.osgeo.org/mailman/options/tiff>,
 <mailto:tiff-request@lists.osgeo.org?subject=unsubscribe>
List-Post: <mailto:tiff@lists.osgeo.org>
List-Help: <mailto:tiff-request@lists.osgeo.org?subject=help>
List-Subscribe: <https://lists.osgeo.org/mailman/listinfo/tiff>,
 <mailto:tiff-request@lists.osgeo.org?subject=subscribe>
Cc: tiff@lists.osgeo.org
Content-Type: multipart/mixed; boundary="===============7539724185594420032=="
Errors-To: tiff-bounces@lists.osgeo.org
Sender: "Tiff" <tiff-bounces@lists.osgeo.org>
X-GND-Status: LEGIT

--===============7539724185594420032==
Content-Type: multipart/alternative; boundary="0000000000007c37f3058bc30b2d"

--0000000000007c37f3058bc30b2d
Content-Type: text/plain; charset="UTF-8"

Thanks for reply. Finally it seems I found solution ;-):
Problem is present in version 4.0.10[1], but it is fixed in current code -
I guess commit 59eb3517[2] fixed it. I was sure I was linking my test code
to gitlab version, but it turn out I was wrong.

Unfortunately also gitlab code (TIFFGetVersion()) returns "LIBTIFF, Version
4.0.10". Maybe LIBTIFF, Version 4.0.11dev or something like that (git
describe --abbrev=4) would help...

If I understand it correctly released 4.0.10 version used tif_unix.c in
windows cmake build => it does no work for me. Current code use tif_win32.c
and it works.

Best regards,


[1] https://download.osgeo.org/libtiff/tiff-4.0.10.zip
[2]
https://gitlab.com/libtiff/libtiff/commit/59eb35172f8dc9a46469ad0e4877f9c88ab796cd

On Thu, 20 Jun 2019 at 14:43, Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
wrote:

> On Thu, 20 Jun 2019, ZdPo Ster wrote:
>
> > Hello,
> >
> > When I try to use TIFFFdOpen on Windows 10 64bit - but it crash. In
> > attachment there is my testing code. I found this problem when I was
> > testing poppler[1] utility pdftoppm (to convert pdf to tif).
> >
> > IMO this is relevant to Bug 1941 - Win64 problem with tif_win32.c's
> > TIFFOpen() use of HANDLE (w/patch)[3],
>
> I should point out that it is possible to use tif_unix.c under Windows
> as well.  It appears that your code assumes use of tif_win32.c.  It
> may well be that tif_unix.c was used in the libtiff build.  I see that
> the Autoconf configure script offers the option --disable-win32-io to
> disable use of Windows I/O but it is possible that it might also be
> disabled by a test (e.g. if it thought that the host_os is Cygwin).
>
> Regardless, usually one should check for errors at each step, which
> your code does not do.
>
> It is safer to use TIFFClientOpen(), but then I/O wrapper functions
> need to be supplied, and this can take a few tries to implement
> perfectly.
>
> Bob
> --
> Bob Friesenhahn
> bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
> Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt
>

--0000000000007c37f3058bc30b2d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Thanks for reply. Finally it seems I found solution ;=
-):</div><div>Problem is present in version 4.0.10[1], but it is fixed in c=
urrent code - I guess commit
<span class=3D"gmail-commit-sha">59eb3517[2]

 fixed it. I was sure I was linking my test code to gitlab version, but it =
turn out I was wrong.</span></div><div><span class=3D"gmail-commit-sha"><br=
></span></div><div><span class=3D"gmail-commit-sha">Unfortunately also gitl=
ab code (TIFFGetVersion()) returns &quot;LIBTIFF, Version 4.0.10&quot;. May=
be LIBTIFF, Version 4.0.11dev or something like that (git describe --abbrev=
=3D4) would help...</span></div><div><span class=3D"gmail-commit-sha"></spa=
n></div><div><span class=3D"gmail-commit-sha"><br></span></div><div><span c=
lass=3D"gmail-commit-sha">If I understand it correctly released 4.0.10 vers=
ion used=20
tif_unix.c in windows cmake build =3D&gt; it does no work for me. Current c=
ode use=20
tif_win32.c and it works.</span></div><div><span class=3D"gmail-commit-sha"=
><br></span></div><div><span class=3D"gmail-commit-sha">Best regards,</span=
></div><div><span class=3D"gmail-commit-sha"><br></span></div><div><span cl=
ass=3D"gmail-commit-sha"></span> <br></div><div>
[1]=20

<a href=3D"https://download.osgeo.org/libtiff/tiff-4.0.10.zip">https://down=
load.osgeo.org/libtiff/tiff-4.0.10.zip</a></div><div>[2] <a href=3D"https:/=
/gitlab.com/libtiff/libtiff/commit/59eb35172f8dc9a46469ad0e4877f9c88ab796cd=
">https://gitlab.com/libtiff/libtiff/commit/59eb35172f8dc9a46469ad0e4877f9c=
88ab796cd</a></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cl=
ass=3D"gmail_attr">On Thu, 20 Jun 2019 at 14:43, Bob Friesenhahn &lt;<a hre=
f=3D"mailto:bfriesen@simple.dallas.tx.us">bfriesen@simple.dallas.tx.us</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Th=
u, 20 Jun 2019, ZdPo Ster wrote:<br>
<br>
&gt; Hello,<br>
&gt;<br>
&gt; When I try to use TIFFFdOpen on Windows 10 64bit - but it crash. In<br=
>
&gt; attachment there is my testing code. I found this problem when I was<b=
r>
&gt; testing poppler[1] utility pdftoppm (to convert pdf to tif).<br>
&gt;<br>
&gt; IMO this is relevant to Bug 1941 - Win64 problem with tif_win32.c&#39;=
s<br>
&gt; TIFFOpen() use of HANDLE (w/patch)[3],<br>
<br>
I should point out that it is possible to use tif_unix.c under Windows <br>
as well.=C2=A0 It appears that your code assumes use of tif_win32.c.=C2=A0 =
It <br>
may well be that tif_unix.c was used in the libtiff build.=C2=A0 I see that=
 <br>
the Autoconf configure script offers the option --disable-win32-io to <br>
disable use of Windows I/O but it is possible that it might also be <br>
disabled by a test (e.g. if it thought that the host_os is Cygwin).<br>
<br>
Regardless, usually one should check for errors at each step, which <br>
your code does not do.<br>
<br>
It is safer to use TIFFClientOpen(), but then I/O wrapper functions <br>
need to be supplied, and this can take a few tries to implement <br>
perfectly.<br>
<br>
Bob<br>
-- <br>
Bob Friesenhahn<br>
<a href=3D"mailto:bfriesen@simple.dallas.tx.us" target=3D"_blank">bfriesen@=
simple.dallas.tx.us</a>, <a href=3D"http://www.simplesystems.org/users/bfri=
esen/" rel=3D"noreferrer" target=3D"_blank">http://www.simplesystems.org/us=
ers/bfriesen/</a><br>
GraphicsMagick Maintainer,=C2=A0 =C2=A0 <a href=3D"http://www.GraphicsMagic=
k.org/" rel=3D"noreferrer" target=3D"_blank">http://www.GraphicsMagick.org/=
</a><br>
Public Key,=C2=A0 =C2=A0 =C2=A0<a href=3D"http://www.simplesystems.org/user=
s/bfriesen/public-key.txt" rel=3D"noreferrer" target=3D"_blank">http://www.=
simplesystems.org/users/bfriesen/public-key.txt</a><br>
</blockquote></div>

--0000000000007c37f3058bc30b2d--

--===============7539724185594420032==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVGlmZiBtYWls
aW5nIGxpc3QKVGlmZkBsaXN0cy5vc2dlby5vcmcKaHR0cHM6Ly9saXN0cy5vc2dlby5vcmcvbWFp
bG1hbi9saXN0aW5mby90aWZmCg==

--===============7539724185594420032==--

