After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 794949 - Opening png, jpeg or tiff with non-latin unicode path fails to load metadata
Opening png, jpeg or tiff with non-latin unicode path fails to load metadata
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: Plugins
2.10.0-RC1
Other Windows
: Normal normal
: 2.10
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2018-04-03 18:53 UTC by Jicksaw
Modified: 2018-05-24 19:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
errors (48.92 KB, image/jpeg)
2018-04-04 08:24 UTC, sylvie.alexandre
Details
Errors AppData Local (288.02 KB, application/octet-stream)
2018-04-04 20:37 UTC, sylvie.alexandre
Details

Description Jicksaw 2018-04-03 18:53:07 UTC
When I try to open a png, jpeg or tiff file that has a character higher than U+00FF in its path the file specific plugin crashes (i.e file-png.exe). It only happens when the file is on a drive other than C:\ nor on a USB drive. BMP and GIF files do not crash.

Error messages:
----
Microsoft Visual C++ Runtime Library
Runtime Error!
Program C:\Ohjelmat\GIMP 2.10\lib\gimp\2.0\plug-ins\file-png.exe
----
APPCRASH
file-png.exe
2.9.8.0
5aba5815
libstdc++-6.dll
----
Plug-in crashed: "file-png.exe"
(C:\Ohjelmat\GIMP 2.10\lib\gimp\2.0\plug-ins\file-png.exe

Opening 'J:\都.png' failed:
Procedure 'file-png-load' returned no return values
Comment 1 Jehan 2018-04-03 19:00:40 UTC
For the record, I can't reproduce a crash on Linux using the same file name. There must be something specific on Windows.
The fact it also depends on the partition you load from is weird as well.

Can anyone reproduce?
Comment 2 sylvie.alexandre 2018-04-03 19:38:17 UTC
Bonjour,

> Can anyone reproduce?

No, I open without any problem the file named 都.png with Gimp 2.10.RC :
Partha 64-bit Win
GimpEval Win 32 & 64 bit

:o)
Comment 3 sylvie.alexandre 2018-04-03 19:49:42 UTC
ERROR

The Problem exist for 
  F:\都.png  (SSD NTFS) 
but not with 
  E:\都.png  (HDD NTFS)

:o)
Comment 4 sylvie.alexandre 2018-04-03 19:53:19 UTC
The problem disappears if we change the first letter, for example :
F:\a都.png  (SSD NTFS)
Comment 5 sylvie.alexandre 2018-04-03 20:05:06 UTC
I'm tired tonight, the file F:\a都.png  (SSD NTFS) does not open in Gimp 2.10.RC ... :o(

These 2 files open well in Paint ( F:\a都.png  & F:\都.png )
Comment 6 Jehan 2018-04-03 20:17:49 UTC
Thanks for the test Sylvie! What a weird bug.

We do agree that this is any random PNG. Only the name and the letter used for the disk seems to change anything, right?
Comment 7 sylvie.alexandre 2018-04-03 22:19:31 UTC
@Jehan

I compiled the 'file-png.c' file of Gimp 2.9.2 and Gimp 2.8.22 versions into my MSYS2 64-bit Win environment.

The GIMP 2.9.2 PNG plug-in gives the error at opening.

The PNG plug-in of Gimp 2.8.22 works correctly and allows to open this filename.

:o)
Comment 8 Jehan 2018-04-03 22:26:01 UTC
Well a lot of things change in the way we open files since then. In particular we now use GIO. But as it is said that it works well with other formats, there is probably something wrong in the file-png plug-in, not in GIO.
Comment 9 sylvie.alexandre 2018-04-03 22:49:32 UTC
@Jehan

Sorry, I will write in French.

Comme mon premier essai avec Gimp 2.9.2 ne fonctionnait pas, j'ai téléchargé les sources de Gimp 2.8.22.

J'ai décompressé les sources de Gimp 2.9.2 et dans ces sources j'ai remplacé 'file-png.c' par 'file-png.c' de la version Gimp 2.8.22

J'ai compilé Gimp 2.9.2 avec 'file-png.c' de Gimp 2.8.22

Je crois que le problème est lié à file-png.c

:o)
Comment 10 sylvie.alexandre 2018-04-04 08:24:07 UTC
Created attachment 370518 [details]
errors

Bonjour,

Here are the results of some opening tests with different image formats (erreur_ouverture_fichiers.jpg).

:o)
Comment 11 sylvie.alexandre 2018-04-04 12:25:03 UTC
I do not know if this can help but I compared the libraries called by the executable files :

PNG (version Gimp 2.8.22) without error when opening the image & compiled with Gimp 2.9.2
libgimpui-2.0-0.dll
libgimp-2.0-0.dll
libgimpbase-2.0-0.dll
libgimpcolor-2.0-0.dll
libgimpwidgets-2.0-0.dll
libglib-2.0-0.dll
libgobject-2.0-0.dll
libgtk-win32-2.0-0.dll
libintl-8.dll
libpng16-16.dll
KERNEL32.dll
msvcrt.dll


PNG ERROR (version Gimp 2.10.0.RC1)
libgimpui-2.0-0.dll
libgimp-2.0-0.dll
libgimpbase-2.0-0.dll
libgimpcolor-2.0-0.dll
libgimpwidgets-2.0-0.dll
libbabl-0.1-0.dll
libgegl-0.3-0.dll
libgio-2.0-0.dll
libglib-2.0-0.dll
libgobject-2.0-0.dll
libgtk-win32-2.0-0.dll
libintl-8.dll
libpng16-16.dll
KERNEL32.dll
msvcrt.dll



SVG without error when opening the image (version Gimp 2.10.0.RC1)
libgimpui-2.0-0.dll
libgimp-2.0-0.dll
libgimpbase-2.0-0.dll
libgimpwidgets-2.0-0.dll
libgdk_pixbuf-2.0-0.dll
libglib-2.0-0.dll
libgobject-2.0-0.dll
libgtk-win32-2.0-0.dll
libintl-8.dll
librsvg-2-2.dll
KERNEL32.dll
msvcrt.dll


*****

These 3 libraries seem to correlate with the error (this is an assumption) :
libbabl-0.1-0.dll
libgegl-0.3-0.dll
libgio-2.0-0.dll
Comment 12 Jehan 2018-04-04 18:38:41 UTC
Hi Sylvie!

Do you build with Drmingw?

If so, could you check the directory C:\Users\<your-user-name>\AppData\Local\GIMP\2.10\CrashLog\ (or another directory which is meant to be under the *non-roaming* data directory of Windows). With some luck, you will find a recent crash file named `file-png.exe-crash-<some-numbers>.txt`. Well even several such files (one per test you did which resulted in a crash).

DrMingw does not seem to always catch all types of errors, so I am not 100% positive you'll find these files, but hopefully you will. If you do, could you upload one of these here please?
Comment 13 sylvie.alexandre 2018-04-04 20:37:48 UTC
Created attachment 370532 [details]
Errors AppData Local

Bonjour,

Here are 2 error files that I just created.

:o)
Comment 14 Jehan 2018-04-04 22:38:58 UTC
Thanks Sylvie!

In the end, I could reproduce in a VM and found the issue. I took quite some time, but I can only get a workaround right now. Basically the issue is that g_win32_locale_filename_from_utf8() was returning NULL for this specific filename, and that was crashing gexiv2_metadata_open_path() which needs a path in the local encoding.
Also just passing the UTF-8 filename does not work anyway (I tried, just in case). As Mitch notes on IRC, the real solution we need here is for GExiv2 to support GIO so that we can pass it a GFile, because GIO does everything the right way for each platform.
I opened bug 794992 for this.

commit ba06a0fe86088b37cef3eeb3db1ce5bb39f2257c (HEAD -> master, origin/master, origin/HEAD)
Author: Jehan <jehan@girinstud.io>
Date:   Thu Apr 5 00:12:00 2018 +0200

    Bug 794949 - Plugin crash when opening png, jpeg or tiff with...
    
    ... non-latin unicode path.
    g_win32_locale_filename_from_utf8() was sometimes returning NULL for
    some paths on Windows. Then the call to gexiv2_metadata_open_path() with
    a NULL value was crashing plug-ins.
    This commit only prevents from crashing by simply failing to load
    metadata when this occurs, which means losing metadata support on
    Windows depending on filenames. A proper solution will have to be
    implemented.

 libgimpbase/gimpmetadata.c | 11 +++++++++++
 1 file changed, 11 insertions(+)
Comment 15 Jehan 2018-04-04 22:41:03 UTC
Title updated. Now at least it doesn't crash. But we now lose metadata support for some files, so let's leave this report opened until we fix this.
Comment 16 sylvie.alexandre 2018-04-04 23:22:30 UTC
@Jehan

Bonjour,

Congratulations and thank you for finding a solution (peut-être temporaire) for this bug.
I will make a compilation tomorrow of GimpEval.

:o)
Comment 17 GNOME Infrastructure Team 2018-05-24 19:25:39 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/1350.