file-tiff-load crashes if I try to open a BigTIFF file

tobias said:

And this is the error message in the command line:

$ ./dev/bin/bin/gimp-2.9 ./Downloads/Rome_Sample/176__MRC-00003618__SEG-001__20140703_143825Z_ORT_16_06780703.TIF This is a development version of GIMP. Debug messages may appear here.

bps: 16 babl-model.c:350 babl_model() babl_model("A"): not found Could not attach to process. If your uid matches the uid of the target process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf ptrace: Die Operation ist nicht erlaubt. /tmp/babl.gdb:1: Error in sourced command file: No stack. plug-in 'file-tiff-load' aborted before sending its procedure return values EEEEeEeek! 3 GeglBuffers leaked

tobias said:

And if I run it as root I get this:

~$ sudo ./dev/bin/bin/gimp-2.9 ./Downloads/Rome_Sample/176__MRC-00003618__SEG-001__20140703_143825Z_ORT_16_06780703.TIF This is a development version of GIMP. Debug messages may appear here.

(gimp-2.9:3955): IBUS-WARNING **: The owner of /home/tobias/.config/ibus/bus is not root! bps: 16 babl-model.c:350 babl_model() babl_model("A"): not found 31 ../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.

#5  0x00007ffd5ae74ec9 in babl_die () at babl-internal.c:74
#6  0x00007ffd5ae768fc in babl_model (name=name@entry=0x4060a9 "A") at babl-model.c:350
#7  0x000000000040404e in load_image (error=0x7fff8ee36ad8, resolution_loaded=<synthetic pointer>, pages=0x7fff8ee36b10, tif=0x19a63e0, filename=0x19586c0 "/home/tobias/Downloads/Rome_Sample/176__MRC-00003618__SEG-001__20140703_143825Z_ORT_16_06780703.TIF") at file-tiff-load.c:1131
#8  run (name=<optimized out>, nparams=<optimized out>, param=0x1958640, nreturn_vals=0x7fff8ee36bf4, return_vals=<optimized out>) at file-tiff-load.c:269
#9  0x00007ffd5c14f88d in gimp_proc_run (proc_run=0x194cb20) at gimp.c:2068
#10 gimp_loop () at gimp.c:1897
#11 gimp_main (info=<optimized out>, argc=<optimized out>, argv=<optimized out>) at gimp.c:520
#12 0x00007ffd5a0daec5 in __libc_start_main (main=0x403020 <main>, argc=6, argv=0x7fff8ee36d98, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff8ee36d88) at libc-start.c:287
#13 0x0000000000403058 in _start ()
plug-in 'file-tiff-load' aborted before sending its procedure return values
EEEEeEeek! 3 GeglBuffers leaked

tobias said:

I was looking for easier assessable example images and found this collection form graphicsmagick: ftp://ftp.graphicsmagick.org/pub/tiff-samples/

The images tiger-75-gray-jpg.tiff and tiger-75-rgb-jpg.tiff don't load correctly in the latest git version compared to 2.8 or eog.

And the 64K-colormap.tiff crashes the tiff plugin, if I run it ass root, but not if I run it as normal user. This is the stacktrace:

~$ sudo ./dev/bin/bin/gimp-2.9 ./Downloads/BigTIFF/64K-colormap.tiff [sudo] password for tobias: This is a development version of GIMP. Debug messages may appear here.

(gimp-2.9:17193): IBUS-WARNING **: The owner of /home/tobias/.config/ibus/bus is not root! bps: 16 photomet: 3 (3) load_rgba /home/tobias/dev/bin/lib/gimp/2.0/plug-ins/file-tiff-load: fatal error: Speicherzugriffsfehler /home/tobias/dev/bin/lib/gimp/2.0/plug-ins/file-tiff-load (pid:17202): [E]xit, [H]alt, show [S]tack trace or [P]roceed: S

#0  0x00007fe65813fe9c in __libc_waitpid (pid=17207, stat_loc=0x7fff2a3536fc, 
#1  0x00007fe6585dfc93 in g_on_error_stack_trace ()
#2  0x00007fe6585dfdea in g_on_error_query ()
#3  0x00007fe659e00034 in gimp_plugin_sigfatal_handler (
#4  <signal handler called>
#5  conv_16_F (src=0x7fe649cd5000 "\b\036 ", dst=0x7fff2a3576a0 "", 
#6  0x00007fe64e2cd631 in conv_rgba16_rgbaF (src=<optimised out>, 
#7  0x00007fe658b1f110 in babl_conversion_linear_process (
#8  babl_conversion_process (babl=0x1a48e00, 
#9  0x00007fe658b20680 in process_conversion_path (path=0x1a8e2e0, 
#10 0x00007fe658b20c97 in babl_fish_path_process (n=256, 
#11 babl_fish_process (n=256, destination=0x62aef10, source=0x7fe649cd4810, 
#12 babl_process (cbabl=cbabl@entry=0x1a8e230, 
#13 0x00007fe659103cfd in gegl_buffer_iterate_write (level=0, 
#14 gegl_buffer_set_internal (rowstride=<optimised out>, src=0x7fe649cce010, 
#15 _gegl_buffer_set_with_flags (flags=GEGL_BUFFER_SET_FLAG_FULL, 
#16 gegl_buffer_set (buffer=0x1b32840, rect=rect@entry=0x7fff2a359280, 
#17 0x0000000000404805 in load_rgba (channel=0x1b2cd50, channel=0x1b2cd50, 
#18 load_image (error=0x7fff2a359238, 
#19 run (name=<optimised out>, nparams=<optimised out>, param=0x1a025d0, 
#20 0x00007fe659e0088d in gimp_proc_run (proc_run=0x19f6b20) at gimp.c:2068
#21 gimp_loop () at gimp.c:1897
#22 gimp_main (info=<optimised out>, argc=<optimised out>, 
#23 0x00007fe657d8bec5 in __libc_start_main (main=0x403020 <main>, argc=6, 
#24 0x0000000000403058 in _start ()

Mukund Sivaraman said:

(In reply to comment 3)

I was looking for easier assessable example images and found this collection form graphicsmagick: ftp://ftp.graphicsmagick.org/pub/tiff-samples/

The images tiger-75-gray-jpg.tiff and tiger-75-rgb-jpg.tiff don't load correctly in the latest git version compared to 2.8 or eog.

This is fixed in master in:

2b415203 file-tiff-load: Fix rowstride for edge tiles (#743034 comment 3)

And the 64K-colormap.tiff crashes the tiff plugin, if I run it ass root, but not if I run it as normal user. This is the stacktrace:

Colormap images are no longer processed. We should outright reject these or support them, not do something half-baked. I'll commit a patch towards it.

Mukund Sivaraman said:

(In reply to comment 0)

What I've done:

downloaded the Rome example from: http://lp.urthecast.com/theia-sample- product/

Unziped it.

Tried to open the BigTIFF file (5,3 GB) with Gimp (git master and 2.8.14 (64Bit version))

Selected all pages in the dialog and clicked OK. -> crash

This is way too large for me to download. Also this seems to be a non-free image. Can you find a smaller file-sized image that demonstrates the problem?

I have tried the big tiff images from the GraphicsMagick collection and they seem to load properly.

tobias said:

(In reply to comment 5)

(In reply to comment 0)

downloaded the Rome example from: http://lp.urthecast.com/theia-sample- product/ This is way too large for me to download. Also this seems to be a non-free image.

I don't have the image here on the machine I'm at the moment, but afaik the the license of the image was OK. I'll can post it here later.

Can you find a smaller file-sized image that demonstrates the problem?

No. I already searched for other images. That's why I found the GraphicsMagick collection. I have a sneaky feeling that the size of the image is part of the problem.

I have tried the big tiff images from the GraphicsMagick collection and they seem to load properly.

Yes, I know. I tested them, too.

Can I somehow give you more information about the crash? Special gdb parameters or something like that?

Michael Natterer @mitch said:

All the stuff pasted above sounds as if only the plug-in crashed.

What does crash, file-tiff or gimp or both?

tobias said:

I've just tested it with the last version from git and it is "just" the plug-in 'file-tiff-load'.

On IRC Mukund Sivaraman told me, that he already has the image and confirmed the problem. If I remember it right, he planned to work on a fix.

Michael Natterer @mitch said:

Thanks.

Michael Natterer @mitch said:

This fixes the crash, but the "Rome" example loads as black pages only...

commit 1243e1f9 Author: Michael Natterer mitch@gimp.org Date: Sun Sep 13 16:21:35 2015 +0200

[Bug 743034](https://bugzilla.gnome.org/show_bug.cgi?id=743034) - file-tiff-load crashes if I try to open a BigTIFF file

Use a Babl format that actually exists for extra channels. Makes the
plug-in load black pages from the mentioned "Rome" BigTIFF, so this
only fixes the plug-in crash but doesn't fix loading of BigTIFF
images, whatever they are...

plug-ins/common/file-tiff-load.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)

tobias said:

Mitch, the corners of the "Rome" BigTIFF are black you can see that in the jpeg image thats in the ZIP file too. I was not able to test your fix. My Computer was not responsible for hours after trying to open the image and then I rebooted because I had other stuff to do. :(

tobias uploaded an attachment:

I've scaled the Rome image down an converted it to 8 bit. Then I saved it as XCF. The problem of the image is still there. It is black, even if you hide all layers or add a white layer at top of the image. If you copy the background layer an insert it as a new image you get an image, that looks closer to the expected result. I hape its easier and faster to test with this image.

Attachment 311506, "Rome image scaled down and saved as xcf":
export_test_all_layers_small.xcf

Jonathan Tait said:

(In reply to tobias from comment 12)

Created attachment 311506 [details] Rome image scaled down and saved as xcf

I've scaled the Rome image down an converted it to 8 bit. Then I saved it as XCF. The problem of the image is still there. It is black, even if you hide all layers or add a white layer at top of the image. If you copy the background layer an insert it as a new image you get an image, that looks closer to the expected result. I hape its easier and faster to test with this image.

Look in the Channels dialog - that image has got 12 extra channels, all absolute black! If you turn-off the visibility of those channels, there is something in the Layers which does resemble a scaled map, but with strangely low opacity.

added 1. Bug label

added 2.10.8 label

I think this issue can be closed, because:

The download for example file no longer exists.
The crash is fixed.

Alternatively it could be renamed to: "Improve BigTiff support" Here are more information about BigTiff and example images: https://www.awaresystems.be/imaging/tiff/bigtiff.html http://fileformats.archiveteam.org/wiki/BigTIFF

Thanks @Tobias, closing.

closed

mentioned in issue #7956 (closed)

file-tiff-load crashes if I try to open a BigTIFF file

Submitted by tobias

Description

See also

Designs

Child items ...

Activity