Your message dated Mon, 9 Jan 2017 22:29:13 +0100
with message-id <[email protected]>
and subject line Re: Bug#534687: libssl0.9.8: lh_retrieve modifies global data,
bug in valgrind or OpenSSL?
has caused the Debian Bug report #534534,
regarding libssl0.9.8: valgrind/helgrind reports Possible data race during write
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
534534: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534534
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libssl0.9.8
Version: 0.9.8g-15+lenny1
Severity: normal
==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.
http://etbe.coker.com.au/2009/06/22/valgrindhelgrind-and-stl-string/
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);
@@ -295,10 +297,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_ex_func(num,file,line);
--- End Message ---
--- Begin Message ---
On 2017-01-08 12:06:12 [+1100], Russell Coker wrote:
> On Saturday, 7 January 2017 10:23:56 PM AEDT Sebastian Andrzej Siewior wrote:
> > I am tempted to close this. Can you still reproduce this with current
> > openssl & valgrind? RSA_new_method() is no longer using the class thingy
> > / lhash so your old testcase won't do. And then 1.1.0c is using
> > pthread's locking functions so valgrind should know by now when a lock
> > is held.
>
> Yes close these ancient bugs.
Assuming this counts for #534534 and #534699, too.
Sebastian
--- End Message ---
