That's really weird. Maybe the user could expand the DEBUG output that prints
the -1 return from write() to also print the strerror (saved_errno) to see what
the failure is (this should really be in there, but I didn't yet get to clean up
the debug output to be more informative).

I suspect it is probably a closed pipe, which would indicate that gpg closes its
end of the pipe before we sent the whole file. However, it could also be
something else. Really difficult to tell. If it is gpg, then one could start
to debug gpg (see its documentation). If it is not, then one could debug
sylpheed-claws to see if another thread (are there other threads?) closes the
local end of the fd accidentially.

It would also be interesting to learn if this can be reproduced
deterministically, or if it is random. Either answer would only give hints, and
no conclusive determination, but randomness would indicate timing issues.

I am sorry that I can't be of more help here. This type of bugs requires
delicate debugging. But when we know why the write fails, we may be able to
track down where and why the file descriptor is closed...

The reporter of the problem in S-Claws bugtracker, Michael Hughes, registered
here (mdh) but he says he can't comment on this issue. Anything he could do?

That is because as a Provisional User (which is the default) he can only comment
on his own bugs. Michael: I have set you to regular user, so you should now be
able to comment.

What level of GPGME_DEBUG do I need to use to get the output you are looking for?

D29: 90_gpgme_log_errno.patch

Hi Michael,

I think what you'll need is to apply a patch such as the attached one, and run
with GPGPME_DEBUG=5. The patch adds the printing of errno to the debug.

I have uploaded to files. 139_bad and 139_good. 139_bad is a log when BADSIG
is returned and 139_good is a log of the same message that return a good signature.

Thanks for the logs. Unfortunately, they don't reveal any secrets. The errno
35 is bogus, because the write() succeeded, so errno is not valid.

Apart from that, the only difference is that in the bad case, gnupg never seems
to read the plain text. It's clearly visible in the progress filter output.
This is also consistent with the previous debug log where write returns -1. If
gpg just exits before reading the plain text, this would have the same effect.

I am at a loss however to why it would do that. I read in the original report
that this is on FreeBSD, which makes it difficult for me to reproduce.

Michael, can you give us some more details on your platform? Is it Free BSD?
Which version? And which version of GnuPG are you using?

I am running FreeBSD 4.8-RELEASE. It is running on a Intel Celeron 900MHz
Gateway computer. I have gnupg-1.4.5 and gpgme-1.1.2 installed from source.

Let me know if there is anything else I can do to help track this down.

I have upgraded to GnuPG 1.4.7 and pgpme 1.1.4. I am still having the same
problem. I would really like to find a fix for this. I am willing to do
anything to help track this problem down. Any help at all on this?

You could try to debug GNUPG ((set debug-file and debug-level=guru option).
Maybe that reveals something.

I have looked and I can't find how to do this thru environment variables, is
there a way to do this?

I did run Claws Mail after setting GPGME_DEBUG=9:/tmp/mygpgme.log. Will the
output from that help any? I have uploaded two files, one is for a good and one
from a bad result.

Is there any way we can make process on this one? Is it still an issue?