error (and memory leak?)
5468696A6D656E
thijmen at xs4all.nl
Sat Jan 31 15:38:36 CET 2004
On Fri, Jan 30, 2004 at 03:52:30PM +0100, 5468696A6D656E wrote:
>
> On this command:
> "C:\Program Files\gpg\gpg.exe" --no-default-keyring --ignore-time-conflict
> --yes --always-trust --no-options --homedir "C:/WINDOWS/Application Data/GnuPG" --sign-key -u 87654321
> 12345678
>
> I always get this error (from util/ttyio.c, line 138)
> gpg: fatal: open(CONOUT$) failed: rc=120secmem usage: 1408/1408 bytes in 2/2 blocks of pool 1408/32768
>
> I found this old mail which seems to have the same error:
> http://lists.gnupg.org/pipermail/gnupg-users/2001-August/009592.html
> Anyone seen this first hand?
>
> Allthough gpg has in the above command pipes around it, this isn't a problem
> for gpg usually. Host Os doesn't seem to matter, other command
> used in the same way (but with --batch in the
> arguments) work nicely and predictable with pipes around gpg.
>
> Experimenting with --no-tty gives:
> gpg: Sorry, no terminal at all requested - can't get input
>
> Additionally, when i use --command-fd 28 --status-fd 40 (those
> are the actual file descripters of my pipes) i get the same error.
Looking closer to the routine init_ttyfp, shouldn't it use
command_fd in some way (if it's not -1) ? And to make the WIN32
code more similar to the unix code, why not also use fopen() there?
Doesn't the preferred compiler of gpg for win32 support fopen()?
Other parts of the code seem to use fopen() without any special
#ifdef's for WIN32.
As for the actual error i got i found this at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/createfile.asp
Windows Me/98/95: The file system restricts CreateFile to creating or opening files;
you cannot create or open the other objects mentioned above. See the topics referenced in See Also at the end of this reference page
for more information on which of these facilities are available on these systems, and how to access them
So it looks like it's a bug to use CreateFile to open a screen buffer.
(since it's not supported on all platforms) And not using command_fd
may also be a bug for all platforms. (maybe someone with a better understanding of the
code than me can take a look at that)
Th.
--
__Thijmen Klok________
There are no bugs in NAH6 products. You are simply ironing out
any possible remaining cosmetic imperfections, that's all.
Zenon Panoussis, 2003-12-11
More information about the Gnupg-users
mailing list