GNOME Bugzilla – Bug 794949
Opening png, jpeg or tiff with non-latin unicode path fails to load metadata
Last modified: 2018-05-24 19:25:39 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
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?
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)
ERROR The Problem exist for F:\都.png (SSD NTFS) but not with E:\都.png (HDD NTFS) :o)
The problem disappears if we change the first letter, for example : F:\a都.png (SSD NTFS)
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 )
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?
@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)
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.
@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)
Created attachment 370518 [details] errors Bonjour, Here are the results of some opening tests with different image formats (erreur_ouverture_fichiers.jpg). :o)
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
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?
Created attachment 370532 [details] Errors AppData Local Bonjour, Here are 2 error files that I just created. :o)
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(+)
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.
@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)
-- 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.