GNOME Bugzilla – Bug 670233
g_spawn_async_with_pipes fails if path contains invalid directory
Last modified: 2018-05-24 13:47:34 UTC
Created attachment 207792 [details] Small program to illustrate this bug. I have run into this with GnuCash on Windows XP, sp3 (see bug 657117). It seems that if the path has an invalid directory, g_spawn_async_with_pipes fails with an "Invalid Argument" error. An "invalid directory" in this case is for example: C:\Program Files\CyberLink\Power2GoC:\Program Files\PHP\ -> the ";" was forgotten to separate two directories. Non-existent directories are no problem, the call really failed on the missing ";". I suppose that a directory spec with two colons are considered an invalid on Windows. Clearly g_spawn_async_with_pipes was called with the G_SPAWN_SEARCH_PATH flag set. The position of the invalid directory in the path is important as well. Suppose we call g_spawn_async_with_pipes to run perl.exe, and this tool is located in c:\perl\bin With a path like PATH=c:\perl\bin;<invalid dir> the call will work fine, but with a path like PATH=<invalid dir>;c:\perl\bin the call will fail So if the application is found in the PATH before an invalid directory is encountered, all is ok, but if an invalid directory is encountered before the app is found, the call fails. Note that the Windows command prompt doesn't have issues with such an invalid directory. It will simply ignore it and find the app correctly. I confirmed this behaviour on behalf of a GnuCash user (see the above bugreport on how to reproduce). I also ran into a thread on the glib mailing list from a couple of years back [1] that I believe describes the same problem, but was never diagnosed as such. I have attached the simple source file from that thread to illustrate the problem. That is probably easier than compiling gnucash to try to reproduce. [1] http://mail.gnome.org/archives/gtk-app-devel-list/2008-September/msg00054.html
Took a quick peek at gspawn-win32.c and gspanw-win32-helper.c and it looks like we don't fiddle with the environment withing GLib (other than converting to wide chars in some cases) when spawning processes. We call _wspawnvpe() (with the wide char converted env) when the helper exe isn't used or _wspawnvp() when the helper exe is used. Looking at what happens with dependencywalker's profiler leads me to believe these internally call CreateProcess(). On what windows version did you test this? What's the exact version number of kernel32.dll (which provides CreateProcess)? Note this depends on what was executed where: - C:\Windows\system32\kernel32.dll when executing a 32-bit GLib on a 32-bit Windows; - C:\Windows\system32\kernel32.dll when executing a 64-bit GLib on a 64-bit Windows; - C:\Windows\SysWOW64\kernel32.dll when executing a 32-bit GLib on a 64-bit Windwos So, first impression is that this is going to be something out of our control. And this does raise questions as to how the command prompt spawns it's processes...
I'm using Window XP-SP3. The kernel32.dll version is 5.1.2600.5781. I unfortunately don't have the opportunity to test this with more recent Windows versions.
-- 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/glib/issues/516.