gpgme test fail (more info)
Ryan P Bobko
ryan at ostrich-emulators.com
Sun Jun 26 15:30:32 CEST 2005
Thanks for the reply. It seems that adding
to my compile step fixed the problem. All the documentation I could find said
that's not necessary, but it worked like a charm.
On Monday 20 June 2005 03:34 pm, Marcus Brinkmann wrote:
> 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'.
> 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.
Health nuts are going to feel stupid someday, lying in hospitals dying
-- Redd Foxx
More information about the Gnupg-devel