gnutls-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: branch master?


From: Simon Josefsson
Subject: Re: branch master?
Date: Wed, 21 Apr 2010 23:26:14 +0200
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)

Nikos Mavrogiannopoulos <address@hidden> writes:

> Simon Josefsson wrote:
>> Nikos Mavrogiannopoulos <address@hidden> writes:
>> 
>>> Simon Josefsson wrote:
>>>> Another thing, running most of the self tests (including the easy to
>>>> debug mini.c) results in a valgrind warning -- I suspect this was
>>>> introduced with the new crypto code (the warning is in the MPI parts),
>>>> could you take a look?
>>> I don't see any warnings. Could you send me the warnings you see?
>>> It could be some 64/32 bit issue.
>> 
>> My system is 32bit.  Here is the error:
>
>> ==19676== Conditional jump or move depends on uninitialised value(s)
>> ==19676==    at 0x413E329: _gcry_mpi_print (mpicoder.c:584)
>> ==19676==    by 0x40F1268: gcry_mpi_print (visibility.c:308)
>> ==19676==    by 0x4066628: wrap_gcry_mpi_print (mpi-libgcrypt.c:77)
>> ==19676==    by 0x4063249: _gnutls_dh_common_print_server_kx
> (auth_dh_common.c:327)
>> ==19676==    by 0x404C142: gen_anon_server_kx (auth_anon.c:104)
>> ==19676==    by 0x4046D87: _gnutls_send_server_kx_message
> (gnutls_kx.c:207)
>> ==19676==    by 0x40436EF: _gnutls_handshake_server
> (gnutls_handshake.c:3022)
>> ==19676==    by 0x4043E19: gnutls_handshake (gnutls_handshake.c:2698)
>> ==19676==    by 0x80491AB: doit (mini.c:204)
>> ==19676==    by 0x80498AC: main (utils.c:149)
>
> This one is on libgcrypt and seems unrelated with any changes
> I've done. Are you sure this wasn't before?

I tried 2.9.9 and 2.8.6 and it also generates that warning -- seems like
a recently introduced libgcrypt bug to me?

>> That one is also not portable, it uses bash...  Would probably be
>> noticed when building on Solaris.  Maybe it can be rewritten using
>> standard /bin/sh constructs.
>
> Depends on what their purpose is. Maybe we split release time
> tests and tests that should be done on the downloader to avoid
> spending so much time on test portability (and perform the needed
> tests).

That could work -- configure could test for the necessary functionality
that is required by these non-portable scripts, and only enable them
when the features are available.

/Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]