Copying a section from a png exported from a 16-bit image crashes gimp
GIMP version: 2.10.4
Operating System: Slackware64 current (as of 28 July 2018); libpng-1.6.34-x86_64-2
Package: Slackware64-current/xap/gimp-2.10.4-x86_64-1.txz
Description of the bug
Also see thread on LQ: https://www.linuxquestions.org/questions/slackware-14/gimp-bug-or-what-4175635145/
The Gimp crashes after trying to copy a selected section of a png derived from a 16-bit image which was processed on xnviewMP. With a jpg no such thing (image files are attached). I tried the same with a png coming from the same 16-bit image but then processed in FIJI, and again the Gimp crashed, so it does not seem to be linked to the program producing the png or the source of the image (also video-stills cause this; see thread on LQ). Copying from a 'simple' png (from a desktop-screen shot) did not cause a crash.
As the jpg works, could it be that libpng is the culprit, or the gimp not calling it correctly?
EDIT: When reducing the resolution of the offending png from 500 dpi to 200 dpi and the file-dimensions by 50% the crash does not happen. So possibly, the file-size is the bottleneck. (The jpg was much smaller than the png)
EDIT2:
The crash Closing the Gimp results in a warning of a GeglBuffer leak (see below)
EDIT3: The Crash is ONLY reproducible when an image file is OPEN in XnView (see below) Copying sections from a large tif, jpg or png then result in a crash
Reproduction
Is the bug reproducible? [Always ]
Reproduction steps:
1.Export a section of a large 16-bit image to png (attached) 2.Open an image file (72.kb lpg is enough) in XnView 3.Load png in The Gimp and select a section 4.Copy that selection and the Gimp crashes
…
Expected result:no crash
Actual result:crash
Additional information
Start The Gimp in one terminal, and find its pid in another:
16003 pts/14 Ss 0:00 bash
16016 pts/13 Sl+ 0:03 gimp --sync
16037 pts/13 Sl+ 0:00 /usr/lib64/gimp/2.0/plug-ins/script-fu -gimp 10 9 -ru
and start strace and then continue with the actions in gimp. This pops up in the strace-terminal:
bash-4.4$ strace -p 16037
strace: Process 16037 attached
select(1024, [10], NULL, NULL, NULL) = 1 (in [10])
read(10, "", 4) = 0
getpeername(2, 0x7ffc5f6a02d0, [128]) = -1 ENOTSOCK (Socket operation on non-socket)
futex(0x7f5d3e7e9598, FUTEX_WAKE_PRIVATE, 2147483647) = 0
ioctl(2, TCGETS, {B38400 opost isig -icanon -echo ...}) = 0
getpid() = 16037
openat(AT_FDCWD, "/etc/localtime", O_RDONLY|O_CLOEXEC) = 7
fstat(7, {st_mode=S_IFREG|0644, st_size=3687, ...}) = 0
fstat(7, {st_mode=S_IFREG|0644, st_size=3687, ...}) = 0
read(7, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\10\0\0\0\0"..., 4096) = 3687
lseek(7, -2347, SEEK_CUR) = 1340
read(7, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\10\0\0\0\0"..., 4096) = 2347
close(7) = 0
write(2, "\n(script-fu:16037): LibGimpBase-"..., 113) = 113
shmdt(0x7f5d34b10000) = 0
exit_group(0) = ?
+++ exited with 0 +++
Output in terminal from which gimp was run:
The program 'gimp' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
(Details: serial 117284 error_code 3 request_code 18 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
bash-4.4$
(script-fu:16037): LibGimpBase-WARNING **: 16:35:03.751: script-fu: gimp_wire_read(): error