On 2009-06-25 15:59:32 [+1000], Russell Coker wrote:
> ==32465== Possible data race during write of size 4 at 0x55D7CE8
> ==32465== at 0x52CD88D: CRYPTO_malloc (mem.c:298)
> ==32465== by 0x534AC75: asn1_item_ex_combine_new (tasn_new.c:191)
> ==32465== by 0x534E184: ASN1_item_ex_d2i (tasn_dec.c:399)
> ==32465== by 0x534E253: ASN1_item_d2i (tasn_dec.c:134)
> ==32465== by 0x5344B7E: d2i_PUBKEY (x_pubkey.c:388)
> ==32465== by 0x40D580: SelectorInfo::Parse(char*) (dkimverify.cpp:1312)
>
> Above is a helgrind error I get on my AMD64 system.
Is valgrind still complaining here?
> Below is a patch I wrote which appears to solve this problem. According to
> the comments on my above blog post it seems possible that this patch will also
> slightly improve performance on SMP systems when under heavy load.
>
> --- ../t/openssl-0.9.8g/crypto/mem.c 2003-12-01 23:06:15.000000000 +1100
> +++ crypto/mem.c 2009-06-25 10:42:03.000000000 +1000
> @@ -254,10 +254,12 @@
>
> if (num <= 0) return NULL;
>
> - allow_customize = 0;
> + if(allow_customize)
> + allow_customize = 0;
> if (malloc_debug_func != NULL)
> {
> - allow_customize_debug = 0;
> + if(allow_customize_debug)
> + allow_customize_debug = 0;
> malloc_debug_func(NULL, num, file, line, 0);
> }
> ret = malloc_locked_ex_func(num,file,line);
The code is mostly the same in 1.1.0c. The variable is always to 0 so
there is no problem if two threads do it at the same time.
I see no reason not to close this report. There might be room for
improvement to safe a few cycles and not alays set allow_customize to
zero.
Sebastian
