I installed GPG4Win 2.2.0-beta on Windows 7 - 64 bit.
gpgex shows up in the shell, but right clicking on a file and selecting any
gpgex function causes Windows Explorer to crash and reload. This occurs 100% of
the time.
All other key management, encryption, signing, and decryption functions appear
to be working normally using Kleopatra.
Thanks,
Here is some additional information which may be helpful:
(1) Output of Events Viewer
Faulting application name: Explorer.EXE, version: 6.1.7601.17567, time stamp:
0x4d672ee4
Faulting module name: ntdll.dll, version: 6.1.7601.17725, time stamp: 0x4ec4aa8e
Exception code: 0xc0000374
Fault offset: 0x00000000000c40f2
Faulting process id: 0x1934
Faulting application start time: 0x01ce82dff437854c
Faulting application path: C:\Windows\Explorer.EXE
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 9f753f17-eee3-11e2-9f80-0016d33c76d0
I hope this is helpful. Thank you.
1 month, and not even a single comment. Am I the ONLY person on earth with this
problem, or the ONLY 1 who cares?
Issue 1530 notes that gpgex crashed Explorer (Win7-64bit) when the Environment
Variable for GNUPGHOME is not at the default setting.
I can confirm this! My configuration is customized, and I am not using the
default path.
I notice that there are other users with the crash problem who are using a non-
standard location for the home directory, and using GNUPGHOME in the Environment
Variables to point to the homedir.
As an experiment, I tested moving the GNUPGHOME pointer from the "User
variables" to the "System Variables" section of the configuration screen. It
makes NO difference - gpgex crashes Windows 7 Explorer in both scenarios,
although Kleopatra functions as expected in both scenarios.
Hi Werner,
I've reproduced this crash. Last trace before the crash is uiserver_connect.
I believe the crash (without having a backtrace) to be caused by the free in
default_socket_name or by that weird cast.
dir = default_homedir (); if (dir)
{
try { name = ((string) dir) + "\\S.uiserver"; } catch (...) {}
free ((void *) dir);}
}
default_homedir can return a pointer to an environment variable or a static
string! So just calling free there is definitely a very bad idea.
standard_homedir (which might also be called from default_homedir) also returns
eiher a Heap allocated value or a static string.
I think we should ensure that default_homedir and standard_homedir always return
allocated memory so that it can be safely freed.
issue1530 and T1536 also describe this bug.
I've closed the other two as duplicates as this one was the first.
Thanks for looking at this. If you like I could test your fixes. I currently
have a build setup and a test setup where I can reproduce the crash.
Btw. Maybe I don't understand c++ enough but afaik this just makes no sense and
is broken:
try { name = ((string) dir) + "\\S.uiserver"; } catch (...) {}should be rather something like:
if (dir)
name = string(dir) + "\\S.uiserver";
The bug is pretty obvious. I consider to rewrite it by calling gpgconf
--list-dirs to get the home directory. This would be simliar to what we do in
gpgme. Or well, we could link to to gpgme to and make use of its higher level
interface.
Using gpgme would be nice of course to avoid duplicated functionality (this same
stuff is also implemented in gpgol although without the bug) but remember that
we would then also need a x64 version of gpgme.
I just pushed a fix.
The problem with gpgme is that we need to stop the Explorer if we want to update
or uninstall gpgme. Given tha we can't use gpgex with the portable version
anyway, I think it is better to keep the existing code and don't switch to gpgme.
With your fix it no longer crashes. But you are leaking memory in case
default_homedir returns allocated memory from read_w32_registry_string or
standard_homedir with a successful call to w32_shgetfolderpath.
As the result should be cached in the static variable this is probably not an
issue..