On Mon, 2010-07-19 at 14:25 +0200, Stephen Henson via RT wrote: > > [[email protected] - Mon Jul 19 11:07:34 2010]: > > > > Here is the backtrace. The table was not empty, this is the content: > > > > (gdb) print **table > > $3 = {piles = {b = 0x7ffff861ea70, comp = 0x7ffff1e7d602 > > <engine_pile_cmp_LHASH_COMP>, hash = 0x7ffff1e7d5e0 > > <engine_pile_hash_LHASH_HASH>, num_nodes = 8, num_alloc_nodes = 16, > > p = 0, pmax = 8, up_load = 512, down_load = 256, num_items = 12, > > num_expands = 0, num_expand_reallocs = 0, num_contracts = 0, > > num_contract_reallocs = 0, num_hash_calls = 25, num_comp_calls = 1, > > num_insert = 12, num_replace = 0, num_delete = 0, num_no_delete = > > 0, num_retrieve = 1, num_retrieve_miss = 12, num_hash_comps = 10, > > error = 0}} > > > > Maybe I was accessing it incorrectly before, at wrong time or from > > wrong frame. > > > > I have Intel(R) Core(TM) i7 CPU M 620; there is aes among the cpu > > flags and a kernel module aesni_intel loaded and used, so I suppose > > the AES-NI is supported. > > > > > > Ah, OK. I can't check that here.
If you want to give me a SSH public key, I can give you an account on a suitable machine. > It looks like the cipher_table isn't being cleared properly or some > random reference is still about. > > I'd suggest you trace ENGINE_register_ciphers() and > ENGINE_unregister_ciphers(). Also check the value of &cipher_table to > see if it changes after OpenSSL is unloaded. Is this related to http://rt.openssl.org/Ticket/Display.html?id=2045&user=guest&pass=guest ? The patch in Debian almost certainly includes that (since without it, the whole thing is pointless and the algorithms never get used). -- David Woodhouse Open Source Technology Centre [email protected] Intel Corporation ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
