seg fault in crypto.h code

Nikos Mavrogiannopoulos n.mavrogiannopoulos at gmail.com
Mon Apr 28 17:21:43 CEST 2008


Simon Josefsson wrote:

> The problem I see is that libgnutls could be used by libraries, and they
> may not be aware of each other.  Consider:
> 
> threaded application
> ---> library 1
>        -> register a crypto.h handler
>        -> gnutls_global_init
> ---> library 2
>        -> register a crypto.h handler
>        -> gnutls_global_init
> 
> I'm not sure what the expected behaviour should be in this situation.
> Any crashes should be avoidable, of course, but it may be (too?)
> surprising for library 1 to not use the crypto.h functions it
> registered.

Each one registering a handler, associates with a priority number. On
execution time the one with lowest priority is run. In case of a
conflict (priority number reuse or registering with higher priority than
an existing handler) the registration will fail.

> This was my reason for doing a compile-time (rather than run-time)
> decision via the gnulib gc-* stuff, but alas that was never finished for
> pk/mpi.

The approach I followed in pk/mpi will allow for both compile time and
runtime decision. Once finished I'll rewrite the logic in
hash/cipher/rnd to be similar in mind.






More information about the Gnutls-devel mailing list