gpgme test fail (more info)

[Marcus Brinkmann]

Hi,

sorry for the late reply.

At Tue, 11 Jan 2005 21:21:45 -0500,
ryan p bobko <ryan at ostrich-emulators.com> wrote:
> I previously posted about some trouble I'm having running the tests from the 
> gpgme /tests/gpg directory. I've now confirmed this problem on another 
> system, so I thought I'd post more details. Basically, all of the tests 
> appear to fail even though the compilation and linking and whatnot seem to 
> succeed flawlessly.

When reporting specific problems, please always include a log.  If you
can still reproduce this with the latest CVS versions, please give us
the output of the failing tests (and for a single test, it is useful to see

srcdir=. GNUPGHOME=. GPGME_DEBUG=3 ./t-decrypt

[note: if you build in a separate directory from the source, set the
source directory appropriately]).
 
> with GCC 3.3.4. Also, the error seems to come from the call to 
>  _gpgme_wait_on_condition (gpgme_ctx_t ctx, volatile int *cond)
> in wait-private.c. I stuck a couple debug statements in there, and it looks 
> like it goes through the while loop several times before bombing on 
>  err = item->handler (item->handler_value, ctx->fdt.fds[i].fd);
> (about line 120). 

You should specify what you mean by "bombing".  Does it segfault?  Or
does it just return an error here?  If it segfaults, include a
backtrace.  If you get an error, that may or may not be correct,
depending on which error occurs where.  Some tests are designed to
test the failing case, so an error here would be natural for them (but
the actual test should succeed of course!).

> Interestingly, the error value returned is 117440664, which 
> seems unusual to me.

No, that's fine:

$ gpg-error 117440664
117440664 = (7, 152) = (GPG_ERR_SOURCE_GPGME, GPG_ERR_DECRYPT_FAILED) = (GPGME, Decryption failed)

> The handler_value is 134528664, which also seems a bit 
> odd to my mind.

This is also fine:

$ bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
obase=16
134528664
804BE98

0x804BE98 is likely very well within the data area of your
application.  So that's just a normal pointer.

> Any ideas on what is causing this? I'm not well versed in the code, but the 
> values I just quoted seem like gibberish you might get from corrupted memory 
> or an overflowing uint or something.

One needs more information to say more.

Thanks,
Marcus