GNOME Bugzilla – Bug 167973
missing ABI stability wrappers for gdk_pixbuf_save() and gdk_pixbuf_savev()
Last modified: 2005-06-18 17:53:00 UTC
Version details: gtk 2.6.2 Distribution/Version: XP service pack 2 Using GIMP 2.2.3 with GTK+ 2.6.2 an error dialog pops up every time GIMP is looking for a thumbnail in hte user directory. The user name is in hebrew and you get a ???? insted in hte path. See attached screen shot. ( simmilar problems to the hebrew directory names )
Created attachment 37713 [details] showing the dialog box pop up
Do you have the $HOME environment variable set? This looks like it's set in the wrong encoding.
I had a look at the glib code. The $HOME environment variable is actually checked for existance. So if it was set incorrectly, that test would most probably fail. It seems that either USERPROFILE is in the wrong encoding or any of the fallbacks in glib/gutils.c returns a wrong encoding. Please try to provide as much information about your system and your user environment as possible.
It appears that the Win32 specific implementation of g_get_home_dir() lacks some sanity checks and might return a directory in the wrong encoding. I also strongly dislike the fact that it is not guaranteed to return a non-NULL value. But I don't know enough about the Windows operating system to say for sure if my guesses are correct. I'd like to have Tor review this problem and will reassign it to glib for that reason.
I have committed a workaround to libgimpthumb; so this should be less of an issue for us now. The encoding issues of g_get_home_dir() should however still be reviewed.
Well, all the time GLib has been running on Windows it has been possible for g_get_home_dir() to return NULL. It's possible on Unix, too, if your NIS is temporarily screwed up or something like that. In GLib 2.6.*, all the file name related API uses UTF-8 on Windows. But for compatibility reasons, if the GLib- and GTK+-using application is built against GLib and GTK+ 2.4.*, it uses ABI compatibility versions of the API, that still returns and takes pathnames in the system codepage, even if GLib and GTK+ internally gets the home directory in Unicode (UTF-8). So, does the value of HOME, USERPROFILE, or your username contain characters that are not representable in the system codepage? Then you would see an end result like this. Is your Windows a Hebrew version?
So the problem ist that currently almost everyone uses Jernej's GIMP 2.2.3 which is built against 2.4.14. I didn't try this with my 2.6.2 based build yet, but it probably won't fail then? Regarding the NULL return value - this seems to hurt Win9x/Me users especially. Doing it like Emacs which uses C: when there is no chance to determine a home path - doesn't seem to be the worst idea. After all, there are multiple ways of changing it.
No, just recompiling GIMP 2.2.x (without any changes) against GTK+/GLib 2.6 is exactly what one should *not* do. Then no opening of files with non-ASCII names will work. Let's not draw any conclusions until we know what the exact situation with the original poster was.
I am running windows XP - which has hebrew built in - their is not specific hebrew version of windows XP - to any version you can add the support of the hebrew keyboard and charachter set. that is my version. My user name uses hebrew characters "עירא" this is written in hebrew but i have no clue how it will look after the HTML is posted. I didi not set any enviroment variables so \i do not know where the home directory is taken from. my enviroment is in hte attached file ... please note that in DOS the directory name appears strange, not the hebrew charachters, but it works... I am using this now against GTK+ 2.6.2 which i had a request from Sven to load. The problem did NOT occur when using GTK 2.4 ...
Created attachment 37750 [details] The enviroment as shown by hte CMD on windows Xp
Yes, it's always possible to add new keyboard layouts, and fonts, that's not the issue here. The issue is what system codepage does this machine use? If it is not 1255, Hebrew cannot be represented in normal, system codepage, "char" strings. What does GetACP() return on this machine? Please run the attached program in a Command Prompt window (result of compiling the below). #include <windows.h> #include <stdio.h> void main() { printf ("%d\n", GetACP ()); }
Created attachment 37757 [details] getacp.exe
Tor code page is 1255 this is the result of running the program D:\tmp\GIMP>getacp 1255 D:\tmp\GIMP>
Hmm, then I am at a loss. In theory, everything should work. Will have to stare more at the code...
Tor, shouldn't the Win32 implementation of g_get_home_dir() check the value of the USERPROFILE environment variable and the result of the other attempts at creating a return value? For the HOME environment variable the following check is performed: /* Only believe HOME if it is an absolute path and exists */ if (g_home_dir) { if (!(g_path_is_absolute (g_home_dir) && g_file_test (g_home_dir, G_FILE_TEST_IS_DIR))) { g_free (g_home_dir); g_home_dir = NULL; } } Similar checks should probably be done for any value before accepting it as a valid g_home_dir.
Well, there has been reports of HOME being used at some sites or by some software for something completely different than "home directory". As HOME is not set by Windows itself the logic behind using it in GLib is that "if it is set, the user (or sysadmin) has done it on purpose, and as HOME has a very clear traditional meaning, believe it, if it is an existing directory". But maybe using HOME should be dropped completely. It has been reported that the installer for other software ported from Unix (like Python, I think it was?) sets, or suggests setting, HOME to the installation directory of that software. The user, not knowing what HOME traditionally means, doesn't notice anything strange with this. Anyway, USERPROFILE is set by Windows itself in Windows 2000 and newer, so if it exists, I think one can be pretty certain that it points to an existing directory, so no need to check there. After all, nothing guarantees that the home directory from a Unix passwd database happens to exist or be accessible at some particular time, either, and we don't do any such check there? As for Ira's situation, I will write a more detailled test program and attach here later today, to find out more details.
Created attachment 37979 [details] Test program "home.c"
Created attachment 37980 [details] home.exe
Please run the attached "home.exe" program in a Command Prompt window. (*NOT* in a Cygwin or MSYS shell window, if you happen to be using those. At least Cygwin mishandles environment variables with non-ASCII chars in them for me.) The program uses GLib, so make sure it is in your PATH. Paste the output here. Thanks.
Created attachment 38021 [details] running home.exe on my computer result of running home.exe on my computer. it was run in hte standard CMD shell. Hope this helps...
Created attachment 38024 [details] home.exe, new version The results you attached indicate that everything should work OK from GLib's point of view. I still have no clue... Still, I forgot to try the conversion from UTF-8 back to system codepage in the test program, please run the new home.exe, too. I also check what g_get_home_dir() returns now. I doubt it will give any more help, but still.
Created attachment 38025 [details] Updated home.c
the results from the new home.exe -- How do i find the version of Glib i am using... Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\עירא.BALCONY-B>d:\tmp 'd:\tmp' is not recognized as an internal or external command, operable program or batch file. C:\Documents and Settings\עירא.BALCONY-B>d: D:\>cd tmp D:\tmp>cd gimp D:\tmp\GIMP> D:\tmp\GIMP> D:\tmp\GIMP> D:\tmp\GIMP> D:\tmp\GIMP>newhome SHGetPathFromIDListW (CSIDL_PROFILE): L"C:\\Documents and Settings\\\u05e2 \u05d9 \u05e8\u05d0.BALCONY-B" UTF-8: "C:\\Documents and Settings\\\327\242\327\231\327\250\327\220.BALCONY- B" in system codepage: "C:\\Documents and Settings\\\362\351\370\340.BALCONY-B" SHGetPathFromIDListW (CSIDL_PERSONAL): L"D:\\Users\\\u05e2\u05d9\u05e8\u05d0" UTF-8: "D:\\Users\\\327\242\327\231\327\250\327\220" in system codepage: "D:\\Users\\\362\351\370\340" SHGetPathFromIDListW (CSIDL_APPDATA): L"C:\\Documents and Settings\\\u05e2 \u05d9 \u05e8\u05d0.BALCONY-B\\Application Data" UTF-8: "C:\\Documents and Settings\\\327\242\327\231\327\250\327\220.BALCONY- B\ \Application Data" in system codepage: "C:\\Documents and Settings\\\362\351\370\340.BALCONY- B\\App lication Data" SHGetPathFromIDListW (CSIDL_INTERNET_CACHE): L"D:\\tmp\\Temporary Internet Files " UTF-8: "D:\\tmp\\Temporary Internet Files" in system codepage: "D:\\tmp\\Temporary Internet Files" SHGetPathFromIDListW (CSIDL_COMMON_APPDATA): L"C:\\Documents and Settings\\All U sers.WINDOWS\\Application Data" UTF-8: "C:\\Documents and Settings\\All Users.WINDOWS\\Application Data" in system codepage: "C:\\Documents and Settings\\All Users.WINDOWS\\Application Data" SHGetPathFromIDListW (CSIDL_COMMON_DOCUMENTS): L"C:\\Documents and Settings\\All Users.WINDOWS\\Documents" UTF-8: "C:\\Documents and Settings\\All Users.WINDOWS\\Documents" in system codepage: "C:\\Documents and Settings\\All Users.WINDOWS\\Documents" HOME: not found USERPROFILE: len: 41 chars value: L"C:\\Documents and Settings\\\u05e2\u05d9\u05e8 \u05d0.BAL CONY-B" UTF-8: "C:\\Documents and Settings\\\327\242\327\231\327\250\327\220.BALCONY- B" in system codepage: "C:\\Documents and Settings\\\362\351\370\340.BALCONY-B" HOMEDRIVE: len: 3 chars value: L"C:" UTF-8: "C:" in system codepage: "C:" HOMEPATH: len: 39 chars value: L"\\Documents and Settings\\\u05e2\u05d9\u05e8 \u05d0.BALCO NY-B" UTF-8: "\\Documents and Settings\\\327\242\327\231\327\250\327\220.BALCONY-B" in system codepage: "\\Documents and Settings\\\362\351\370\340.BALCONY-B" TMPDIR: not found TMP: len: 37 chars value: L"C:\\DOCUME~1\\D57B~1.BAL\\LOCALS~1\\Temp" UTF-8: "C:\\DOCUME~1\\D57B~1.BAL\\LOCALS~1\\Temp" in system codepage: "C:\\DOCUME~1\\D57B~1.BAL\\LOCALS~1\\Temp" TEMP: len: 37 chars value: L"C:\\DOCUME~1\\D57B~1.BAL\\LOCALS~1\\Temp" UTF-8: "C:\\DOCUME~1\\D57B~1.BAL\\LOCALS~1\\Temp" in system codepage: "C:\\DOCUME~1\\D57B~1.BAL\\LOCALS~1\\Temp" PATH: len: 98 chars value: L"C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32 \ \Wbem;D:\\Program Files\\Common Files\\GTK\\2.0\\bin" UTF-8: "C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32 \\Wbem;D:\\Progr am Files\\Common Files\\GTK\\2.0\\bin" in system codepage: "C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32 \\Wb em;D:\\Program Files\\Common Files\\GTK\\2.0\\bin" FOO: not found g_get_home_dir(): "C:\\Documents and Settings\\\362\351\370\340.BALCONY-B" D:\tmp\GIMP>
the file i am using is in libglib-2.0-0.dll version 2.6.2 which is in common files\GTK\2.0\bin and is the only file with this name on the computer. Ira
Well, to me it seems clear from the above that the problem is not in GLib... the test program was built against GLib-2.4 (like GIMP 2.2 is), and when it calls g_get_home_dir() it gets the correct string, in the system codepage.
I can however not find anything wrong in libgimpthumb. The code to construct the thumbnail location is rather simple and the only possible non-ASCII string involved is the result of g_get_home_dir(). Is it certain that the user's GIMP 2.2 was built against GLib 2.4? Tor, I may just have missed it, but to my knowledge you never made it clear on any of the mailing-lists that I follow that building an application against GLib 2.6 w/o porting it to gstdio is not a good idea.
Hello, I encountered probably the same problem with german umlauts in my % USERPROFILE%. See bug report #165002 comments 8f. http://bugzilla.gnome.org/show_bug.cgi?id=165002#c8 Just let me know if you need any further information. Guenther
What's confusing me a little is that the error message says "Invalid argument". This error message comes from gdk_pixbuf_savev(), so this is the result of calling fopen (filename, "wb"). How can that cause EINVAL? According to the fopen manpage, that would be the case if an invalid mode is being passed to fopen(), but "wb" looks like a correct mode to me and it seems to work for a lot of people, even on Win32.
*** Bug 169412 has been marked as a duplicate of this bug. ***
*** Bug 169738 has been marked as a duplicate of this bug. ***
After all those test, it appears that my analysis has been wrong and the problem is not g_get_home_dir(). Something seems to be wrong with gdk_pixbuf_savev() in GTK+-2.6 when being called from GIMP 2.2.
See also bug #169750 which seems to be a similar problem, caused by incompatibilities with GLib/GTK+ 2.6.
The ABI stability wrappers seems to be missing for gdk_pixbuf_save and gdk_pixbuf_savev.
Again, Robert hits the nail on the head! That probably is it. No idea why I left them out, but did make ABI stability wrappers for the .*_new_from_file_* functions. Will add.
ABI stability added in gtk-2-6 and HEAD: 2005-03-10 Tor Lillqvist <tml@novell.com> * gdk-pixbuf-core.h * gdk-pixbuf-io.c * gdk-pixbuf.symbols: Implement DLL ABI stablility for gdk_pixbuf_save() and gdk_pixbuf_savev(). (#167973)
Closing this report as FIXED then. If we should still get reports about this problem from people using gtk+ with this change, then we will reopen it.
Hmm, would probably make sense to have the report with the proper product and a proper summary. Changing that ...
where can I down load a fixed version, so i can test an reverify? Ira
Thanks!
The fix is in the source code repository (CVS). It will thus be in the next source code release (2.6.5). When that will be I have no idea. And then it will take some time before a Win32 distribution is made of it.
*** Bug 170555 has been marked as a duplicate of this bug. ***
*** Bug 170640 has been marked as a duplicate of this bug. ***
*** Bug 172274 has been marked as a duplicate of this bug. ***
Just for information. Tested today the new version of GIMP distribution, 2.2.4 with GTK+ 2.6.4 and problem still exists as expected. Will repost when GTK+ 2.6.5 is available... Ira
*** Bug 172716 has been marked as a duplicate of this bug. ***
*** Bug 304420 has been marked as a duplicate of this bug. ***
*** Bug 304111 has been marked as a duplicate of this bug. ***
*** Bug 305523 has been marked as a duplicate of this bug. ***
*** Bug 305626 has been marked as a duplicate of this bug. ***
*** Bug 308202 has been marked as a duplicate of this bug. ***