gpgme test fail (more info)

[Ryan P Bobko]

Hi Marcus,
Thanks for the reply. It seems that adding 
 -D_FILE_OFFSET_BITS=64 
 -DLARGEFILE_SOURCE
to my compile step fixed the problem. All the documentation I could find said 
that's not necessary, but it worked like a charm.

ry

On Monday 20 June 2005 03:34 pm, Marcus Brinkmann wrote:
> 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

-- 
Health nuts are going to feel stupid someday, lying in hospitals dying
of nothing.
 -- Redd Foxx