This is sources Bugzilla
Bugzilla Version 2.17.5
Bugzilla Bug 10018
  malloc thread-safety issues Last modified: 2009-11-01 16:48
     Query page      Enter new bug
Bug#: 10018   Hardware:   Reporter: Clément Stenac <clement.stenac@exalead.com>
Host: Target: Build:
Product:     Add CC:
Component:   Version:   CC:
Remove selected CCs
Status: RESOLVED   Priority:  
Resolution: FIXED   Severity:  
Assigned To: Ulrich Drepper <drepper@redhat.com>   Target Milestone:  
Flags: Requestee:
  backport ()
  examined ()
  testsuite ()
Summary:
Keywords:

Attachment Description Type Created Actions
corruption.c Minimal test case exposing the problem text/plain 2009-03-31 07:30 Edit None
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 10018 depends on: Show dependency tree
Show dependency graph
Bug 10018 blocks:

Additional Comments:


Leave as RESOLVED FIXED
Reopen bug
Mark bug as VERIFIED

View Bug Activity   |   Format For Printing


Description:   Last confirmed: 0000-00-00 00:00 Opened: 2009-03-31 07:29
The attached program (corruption.c) exposes a memory corruption issue with
malloc running on multithread.

The corruption has been reproduced on several computers running various Linux
distributions, and with glibc ranging from 2.5 to 2.9. It has not been
reproduced on glibc 2.3

The corruption has been reproduced on 2,4 and 8 cores machines. It has not been
reproduced on monocore machines. It has only been reproduced on x86_64, not on x86

The attached program basically does:
 * malloc a buffer of size X
 * fill it with a memory pattern
 * realloc it to size 2X
 * check that the pattern is still ok on [0:X[

On the attached program, depending on X, the last Y bytes are corrupted, with Y
ranging from 0 to 8. Several runs of a few seconds might be required to expose
the bug.

Here is the complete matrix of reproduction cases.
Distro          Cpu 	Cores 	Libc 	GCC 	Kernel 	Vulnerable
Debian Etch 	x86-64 	8 	2.3 	4.1.2 	2.6.27 	No
Debian Lenny 	?? 	2 	2.7 	4.3.2 	? 	No
RH5 	        x86-64 	4 	2.5 	4.1.2 	2.6.18  Yes
Gentoo 	        x86-64 	4 	2.8 	4.1.2 	2.6.27 	Yes
CentOS 5.2 	x86-64 	4 	2.5 	4.1.2 	2.6.18 	Yes
Debian Sid 	x86 	1 	2.9 	4.3.3 	2.6.26 	No
RH4 	        x86-64  2       2.3     3.4     2.6.9 	No
Gentoo          x86-64 	4 	2.6.1 	4.1.2 	2.6.25 	Yes
Gentoo          x86-64  2       2.5 	4.1.1 	2.6.20 	Yes
Gentoo          x86-64  8       2.6.1   4.1.1 	2.6.28 	Yes
Debian Sid 	x86 	2 	2.9 	4.3.3 	2.6.26 	No
Debian Testing 	x86-64 	2 	2.7 	4.1.2 	2.6.26 	Yes 


This might be related to BUG 6952
(if it's related, then it probably produces an easier reproduction case)

------- Additional Comment #1 From Clément Stenac 2009-03-31 07:30 -------
Created an attachment (id=3858)
Minimal test case exposing the problem

------- Additional Comment #2 From Florian Douetteau 2009-04-04 14:39 -------
The corruption has also been reproduced on this system : 

Distro          Cpu 	Cores 	Libc 	GCC 	Kernel 	Vulnerable
Gentoo          x86-64  8       2.8   4.3.2 	2.6.27 	Yes

When compiling glibc 2.9 out of the box on this system, 
from
ftp://sources.redhat.com/pub/glibc/releases/glibc-libidn-2.9.tar.gz
and LD_PRELOADing it the corruption disappears.

When reverse applying this patch, on 2.9 sources 
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/malloc/malloc.c.diff?r1=1.189&r2=1.190&cvsroot=glibc


(comment: (public_rEALLOc): When new arena is used, copy really all bytes) 

and recompiling, the corruption reappers.


------- Additional Comment #3 From Ulrich Drepper 2009-11-01 16:48 -------
(In reply to comment #2)
> When reverse applying this patch, on 2.9 sources 
> and recompiling, the corruption reappers.

Which means the bug is fixed.  Why didn't you close it then?

     Query page      Enter new bug
Actions: New | Query | bug # | Reports | Requests   New Account | Log In