Bug#735847: freeimage: builds wrong tiff, broken 32 bit

2014-01-19 Thread Scott Howard
On Sun, Jan 19, 2014 at 8:18 PM, Julian Taylor
 wrote:
> I disagree, all three issues found do seem like independent issues with
> little relation (on amd64 at least).

Ok, so there are three bugs:

1)
> the exif tag truncation is very unlikely cause the complete data
> structure corruption.

Ah, Sources/LibTIFF4 instead of LibTIFF on the lines that updated the
sources. Thanks for finding that (gensrclist.sh, genfipsrclist.sh)

2) [patch is available]
> tag truncation

3)
> The wrong type sizes can not be related because I tested that and it
> only affects 32 bit (which I was not using for debugging).

On bug #3, it looks like Source/LibTIFF/ is configured at build time,
but Source/LibTIFF4/ has already been configured and shipped by
upstream.

This is extra confusing, because upstream's tiffconf.h in SVN doesn't
match what they are distributing in their source tarballs:
http://freeimage.cvs.sourceforge.net/viewvc/freeimage/FreeImage/Source/LibTIFF4/tiffconf.h?view=markup
At no point in the history did tiffconf.h match what they are distributing.

Also, this has been reported before:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601762

And fixed with these two patches
http://anonscm.debian.org/gitweb/?p=collab-maint/freeimage.git;a=commitdiff;h=5657e6b0bbc7def9e5598e6872a91a202b7b4113
http://anonscm.debian.org/gitweb/?p=collab-maint/freeimage.git;a=commitdiff;h=cddd3e04b65efb1291ed6b28ac8310f33eec4466

namely
+/* Signed 64-bit type formatter */
+#define TIFF_INT64_FORMAT "%" PRId64
+
+/* Signed 64-bit type */
+#if SIZEOF_LONG == 8
+#define TIFF_INT64_T signed long
+#else
+#define TIFF_INT64_T signed long long
+#endif
+
+/* Unsigned 64-bit type formatter */
+#define TIFF_UINT64_FORMAT "%" PRIu64
+
+/* Unsigned 64-bit type */
+#if SIZEOF_LONG == 8
+#define TIFF_UINT64_T unsigned long
+#else
+#define TIFF_UINT64_T unsigned long long
+#endif

I'll go ahead and ask upstream if they could reconsider allowing their
packages to build using system libraries, these are all things best
handled by (and probably already solved by) libtiff maintainers.

Thanks again,
Scott


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#735847: freeimage: builds wrong tiff, broken 32 bit

2014-01-19 Thread Julian Taylor
On 20.01.2014 01:46, Scott Howard wrote:
> 
> Before uploading that patch and closing this bug, I'd like to look at
> "long is 32 bit on 32 bit arches. it needs to be int64_t or long long.
> This occurs several times in the file." LibTIFF4/tiffconf.h is
> generated at build time, so it should be OK on all archs. In the
> source package, there is LibTIFF4/tiffconf.h.in which is the template
> for tiffconf.h after it is configured. Is this not the case? That
> would be a different bug if so.
> 

just checked it again, the file wrongly has long as 64 bit type *after*
the package has built. So it has not been reconfigured from the configure.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#735847: freeimage: builds wrong tiff, broken 32 bit

2014-01-19 Thread Julian Taylor
On 20.01.2014 01:46, Scott Howard wrote:
> 
> Checking over the package, I don't think it's a problem of not
> updating the patch. The previous version of the package and patches
> didn't touch anything related to TIFF and used freeimage's included
> libtiff. The current version also doesn't touches anything involving
> libtiff (or the internal libtiff) since freeimage requires private
> headers and interfaces. At this point, it looks like bug is the
> upstream bug you found. If their patch fixes this, it can be uploaded.

I disagree, all three issues found do seem like independent issues with
little relation (on amd64 at least).
the exif tag truncation is very unlikely cause the complete data
structure corruption.
While I think its unlikely it is possible the tag truncation patch fixes
it, I didn't test it (does it even apply to the old libtiff?)

The wrong type sizes can not be related because I tested that and it
only affects 32 bit (which I was not using for debugging).

I didn't look into much detail why the tiff plugin is so messed up, as
simply updating the debian patch solved all my problems and I could move
on to the next one (the tag truncation).
Whatever route you choose, please make sure the skimage test suite is
running afterwards.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#735847: freeimage: builds wrong tiff, broken 32 bit

2014-01-17 Thread Julian Taylor
Package: freeimage
Version: 3.15.4
Severity: serious

the recent update to .4 updates the internal tiff to libtiff4 but does
not update the debian patch
debian/patches/disable_embedded_libraries.patch appropriately.
This leads to some internals using the libtiff internals instead of the
libtiff4
This breaks e.g. the skimage tests with a expected segfault due to
complete data structure corruption.

Additionally LibTIFF4/tiffconf.h is configured for 32 bit and will most
likely break on 32 bit:

/* Signed 64-bit type */
#ifdef _MSC_VER
#define TIFF_INT64_T signed __int64
#else
#define TIFF_INT64_T signed long
#endif // _MSC_VER

...

long is 32 bit on 32 bit arches. it needs to be int64_t or long long.
This occurs several times in the file.


Fixing all this still lets the skimage tests fail:

FAIL: test_freeimage.test_metadata
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File "/usr/lib/python2.7/dist-packages/numpy/testing/decorators.py",
line 146, in skipper_func
return f(*args, **kwargs)
  File "/tmp/buildd/skimage-0.9.3/skimage/io/tests/test_freeimage.py",
line 104, in test_metadata
assert meta[1][('EXIF_MAIN', 'Software')].startswith('ImageMagick')
AssertionError:


it truncates the tag to just 'I'

I'm not sure if that what the reason for that could be.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org