Red Hat Bugzilla – Bug 843449
rare coredump when running python script using threading module
Last modified: 2013-03-21 01:07:04 EDT
Description of problem:
I'm getting rare coredump when running python script using threading module.
Version-Release number of selected component (if applicable):
about one of 20 attempts
Steps to Reproduce:
1. Use threading module repeatedly
11861 Segmentation fault (core dumped)
Looking at this more, looks like issue is not so rare as noted in initial comment.
From log of our results, it looks like this issue first appeared 2012-07-19. Looks like errata RHSA-2012:0745 which contains python-2.4.3-46.el5_8.2 was released 2012-06-18 and errata RHSA-2012:1097 which have glibc-2.5-81.el5_8.4 was released 2012-07-18 => Adding "Regression" keyword and switching component to glibc.
This looks more like an openssl or python problem to me.
(gdb) x/i $pc
0x38d347ae4b <memcpy+347>: rep movsq %ds:(%rsi),%es:(%rdi)
(gdb) p/x $rcx
$12 = 0x711
So we're in the middle of a copy, with some bytes reamining.
(gdb) p/x $rsi
$13 = 0x38d6b51000
(gdb) x/x $rsi
0x38d6b51000: Cannot access memory at address 0x38d6b51000
The source address points to an unmapped page and in fact is right on a page boundary indicating we were probably iterating up through addresses until we hit the end of mapped addresses then immediately faulted.
#1 0x00000038d68dea8e in __memcpy_ichk (c=0x2aaaac0113a0, data_=0x38d6b51000,
len=18446744073709551611) at /usr/include/bits/string3.h:51
51 return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
#2 SHA1_Update (c=0x2aaaac0113a0, data_=0x38d6b51000,
len=18446744073709551611) at ../md32_common.h:316
316 memcpy (p+n,data,len);
(gdb) p data
$14 = (const unsigned char *) 0x38d6b50884 ""
And the address corresponds reasonably well to what we find in SHA1_Update from libcrypt.
(gdb) p len
$19 = 18446744073709551611
(gdb) p/x len
$25 = 0xfffffffffffffffb
Wow... OK, now that seems interesting.
#3 0x00000038d68db6d9 in ssleay_rand_add (buf=0x38d690be32, num=20, add=0)
(gdb) p j
$28 = <value optimized out>
(gdb) p k
$29 = 25
Damn, no value for "j". However, we might be able to recover it:
259 for (i=0; i<num; i+=MD_DIGEST_LENGTH)
262 j=(j > MD_DIGEST_LENGTH)?MD_DIGEST_LENGTH:j;
267 if (k > 0)
(gdb) p num
$33 = 20
(gdb) p i
$34 = 0
So the value of "j" is 20. 20 - 25 is -5, which is
Which corresponds to the len parameter in SHA1_Update and which is passed as the length to memcpy.
This is clearly not a glibc problem, but a problem higher up in the chain, most likely openssl. Reassigned to openssl.
I suppose it might be caused by improper locking (f. e. no locking callbacks initialized in openssl).
I suppose python is not setting up the thread locks properly when it uses OpenSSL.
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.