Activity log for bug #1020210

Date Who What changed Old value New value Message
2012-07-02 17:27:18 Josh Pieper bug added bug
2012-07-02 17:27:18 Josh Pieper attachment added atomic_fastbin.cc https://bugs.launchpad.net/bugs/1020210/+attachment/3211072/+files/atomic_fastbin.cc
2012-09-18 19:22:02 Launchpad Janitor eglibc (Ubuntu): status New Confirmed
2012-10-02 14:20:48 Mike Zraly bug added subscriber Mike Zraly
2013-01-28 16:18:08 Josh Pieper bug watch added http://sourceware.org/bugzilla/show_bug.cgi?id=15073
2013-01-28 16:26:42 Marc Deslauriers bug task added eglibc
2013-01-30 14:12:27 Bug Watch Updater eglibc: status Unknown Confirmed
2013-01-30 14:12:27 Bug Watch Updater eglibc: importance Unknown Medium
2013-05-15 00:52:27 Bug Watch Updater eglibc: status Confirmed Incomplete
2013-10-22 21:05:27 Nate Gallaher attachment added Reproduction Recipe for Trusty Tahr https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1020210/+attachment/3887763/+files/atomic_fastbin.cc
2013-12-25 07:07:23 Bug Watch Updater eglibc: status Incomplete Fix Released
2014-01-02 04:02:31 Bug Watch Updater eglibc: status Fix Released Confirmed
2014-01-02 04:13:22 Dimitri John Ledkov eglibc (Ubuntu): assignee Adam Conrad (adconrad)
2014-01-09 04:04:45 Bug Watch Updater eglibc: status Confirmed Fix Released
2014-01-28 17:56:24 Adam Conrad eglibc (Ubuntu): status Confirmed In Progress
2014-01-28 17:56:37 Adam Conrad nominated for series Ubuntu Precise
2014-01-28 17:56:37 Adam Conrad bug task added eglibc (Ubuntu Precise)
2014-01-28 17:56:46 Adam Conrad eglibc (Ubuntu Precise): status New In Progress
2014-01-28 17:56:49 Adam Conrad eglibc (Ubuntu Precise): assignee Adam Conrad (adconrad)
2014-02-13 06:22:36 Bug Watch Updater cve linked 2012-4412
2014-02-13 06:22:36 Bug Watch Updater cve linked 2012-4424
2014-02-13 06:22:36 Bug Watch Updater cve linked 2013-4237
2014-02-13 06:22:36 Bug Watch Updater cve linked 2013-4332
2014-02-13 06:22:36 Bug Watch Updater cve linked 2013-4458
2014-02-13 06:22:36 Bug Watch Updater cve linked 2013-4788
2014-03-31 20:19:54 Adam Conrad eglibc (Ubuntu): status In Progress Fix Released
2014-09-15 08:49:48 dtsomp bug added subscriber dtsomp
2014-09-15 12:49:24 Mike Zraly removed subscriber Mike Zraly
2014-11-04 15:57:03 Dariusz Gadomski description We have an application which makes heavy allocation and de-allocation demands from multiple threads. We run this application continuously on many servers, and once every several CPU months or years, we were getting a crash in _int_free that did not look like vanilla heap corruption. I believe I have narrowed it down to a race condition in _int_free due to the ATOMIC_FASTBINS feature. Basically, in the lockless FASTBIN _int_free path, a chunk is pulled into a local variable with the intent to add it to the fastbins list. However, the heap consolidation/trim code can race with this, and can coalesce the entire block and/or give it back to the OS before _int_free has a chance to try and store it into the fastbins list. The problem is very challenging to reproduce in situ, but using gdb I have a recipe which demonstrates the crash 100% of the time on my 12.04 x64 system running eglibc 2.15. It relies on malloc_trim, although in our in situ data, the consolidation is triggered as a result of a normal free. malloc_trim is just easier to control. While I am not a glibc developer, I could not see any easy ways to fix the situation shy of disabling ATOMIC_FASTBINS. I am attaching the reproduction source. Other pertinent information follows: > jpieper@calculon:~/downloads$ lsb_release -rd > Description: Ubuntu 12.04 LTS > Release: 12.04 > jpieper@calculon:~/downloads$ apt-cache policy libc6 > libc6: > Installed: 2.15-0ubuntu10 > Candidate: 2.15-0ubuntu10 > Version table: > *** 2.15-0ubuntu10 0 > 500 http://us.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages > 100 /var/lib/dpkg/status What I expect: I expect the attached application, when run using the gdb script in the comments, to complete with no failures. What happened: A SIGSEGV after the final continue. [Impact] * This bug is likely to cause a crash with a SEGV in multithreading applications doing many memory deallocations with ATOMIC_FASTBINS feature enabled. [Test Case] * Since this is a race condition issue there is no simple path of reproducing it, however one could try to follow the instruction in the upstream bug (https://www.sourceware.org/bugzilla/show_bug.cgi?id=15073): https://www.sourceware.org/bugzilla/attachment.cgi?id=7331 [Regression Potential] * This issue has been merged upstream with no further issues reported. [Other Info] * Original bug description: We have an application which makes heavy allocation and de-allocation demands from multiple threads. We run this application continuously on many servers, and once every several CPU months or years, we were getting a crash in _int_free that did not look like vanilla heap corruption. I believe I have narrowed it down to a race condition in _int_free due to the ATOMIC_FASTBINS feature. Basically, in the lockless FASTBIN _int_free path, a chunk is pulled into a local variable with the intent to add it to the fastbins list. However, the heap consolidation/trim code can race with this, and can coalesce the entire block and/or give it back to the OS before _int_free has a chance to try and store it into the fastbins list. The problem is very challenging to reproduce in situ, but using gdb I have a recipe which demonstrates the crash 100% of the time on my 12.04 x64 system running eglibc 2.15. It relies on malloc_trim, although in our in situ data, the consolidation is triggered as a result of a normal free. malloc_trim is just easier to control. While I am not a glibc developer, I could not see any easy ways to fix the situation shy of disabling ATOMIC_FASTBINS. I am attaching the reproduction source. Other pertinent information follows: > jpieper@calculon:~/downloads$ lsb_release -rd > Description: Ubuntu 12.04 LTS > Release: 12.04 > jpieper@calculon:~/downloads$ apt-cache policy libc6 > libc6: > Installed: 2.15-0ubuntu10 > Candidate: 2.15-0ubuntu10 > Version table: > *** 2.15-0ubuntu10 0 > 500 http://us.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages > 100 /var/lib/dpkg/status What I expect: I expect the attached application, when run using the gdb script in the comments, to complete with no failures. What happened: A SIGSEGV after the final continue.
2014-11-04 15:58:23 Dariusz Gadomski attachment added precise_eglibc_2.15-0ubuntu10.8.debdiff https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1020210/+attachment/4252890/+files/precise_eglibc_2.15-0ubuntu10.8.debdiff
2014-11-04 15:58:44 Dariusz Gadomski bug added subscriber Ubuntu Sponsors Team
2014-11-04 15:58:55 Dariusz Gadomski bug added subscriber Ubuntu Stable Release Updates Team
2014-11-04 16:05:32 Dariusz Gadomski description [Impact] * This bug is likely to cause a crash with a SEGV in multithreading applications doing many memory deallocations with ATOMIC_FASTBINS feature enabled. [Test Case] * Since this is a race condition issue there is no simple path of reproducing it, however one could try to follow the instruction in the upstream bug (https://www.sourceware.org/bugzilla/show_bug.cgi?id=15073): https://www.sourceware.org/bugzilla/attachment.cgi?id=7331 [Regression Potential] * This issue has been merged upstream with no further issues reported. [Other Info] * Original bug description: We have an application which makes heavy allocation and de-allocation demands from multiple threads. We run this application continuously on many servers, and once every several CPU months or years, we were getting a crash in _int_free that did not look like vanilla heap corruption. I believe I have narrowed it down to a race condition in _int_free due to the ATOMIC_FASTBINS feature. Basically, in the lockless FASTBIN _int_free path, a chunk is pulled into a local variable with the intent to add it to the fastbins list. However, the heap consolidation/trim code can race with this, and can coalesce the entire block and/or give it back to the OS before _int_free has a chance to try and store it into the fastbins list. The problem is very challenging to reproduce in situ, but using gdb I have a recipe which demonstrates the crash 100% of the time on my 12.04 x64 system running eglibc 2.15. It relies on malloc_trim, although in our in situ data, the consolidation is triggered as a result of a normal free. malloc_trim is just easier to control. While I am not a glibc developer, I could not see any easy ways to fix the situation shy of disabling ATOMIC_FASTBINS. I am attaching the reproduction source. Other pertinent information follows: > jpieper@calculon:~/downloads$ lsb_release -rd > Description: Ubuntu 12.04 LTS > Release: 12.04 > jpieper@calculon:~/downloads$ apt-cache policy libc6 > libc6: > Installed: 2.15-0ubuntu10 > Candidate: 2.15-0ubuntu10 > Version table: > *** 2.15-0ubuntu10 0 > 500 http://us.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages > 100 /var/lib/dpkg/status What I expect: I expect the attached application, when run using the gdb script in the comments, to complete with no failures. What happened: A SIGSEGV after the final continue. [Impact]  * This bug is likely to cause a crash with a SEGV in multithreading applications doing many memory deallocations with ATOMIC_FASTBINS feature enabled. [Test Case]  * Since this is a race condition issue there is no simple path of reproducing it, however one could try to follow the instructions in the upstream bug (https://www.sourceware.org/bugzilla/show_bug.cgi?id=15073): https://www.sourceware.org/bugzilla/attachment.cgi?id=7331 [Regression Potential]  * This issue has been merged upstream with no further issues reported. [Other Info] * Original bug description: We have an application which makes heavy allocation and de-allocation demands from multiple threads. We run this application continuously on many servers, and once every several CPU months or years, we were getting a crash in _int_free that did not look like vanilla heap corruption. I believe I have narrowed it down to a race condition in _int_free due to the ATOMIC_FASTBINS feature. Basically, in the lockless FASTBIN _int_free path, a chunk is pulled into a local variable with the intent to add it to the fastbins list. However, the heap consolidation/trim code can race with this, and can coalesce the entire block and/or give it back to the OS before _int_free has a chance to try and store it into the fastbins list. The problem is very challenging to reproduce in situ, but using gdb I have a recipe which demonstrates the crash 100% of the time on my 12.04 x64 system running eglibc 2.15. It relies on malloc_trim, although in our in situ data, the consolidation is triggered as a result of a normal free. malloc_trim is just easier to control. While I am not a glibc developer, I could not see any easy ways to fix the situation shy of disabling ATOMIC_FASTBINS. I am attaching the reproduction source. Other pertinent information follows: > jpieper@calculon:~/downloads$ lsb_release -rd > Description: Ubuntu 12.04 LTS > Release: 12.04 > jpieper@calculon:~/downloads$ apt-cache policy libc6 > libc6: > Installed: 2.15-0ubuntu10 > Candidate: 2.15-0ubuntu10 > Version table: > *** 2.15-0ubuntu10 0 > 500 http://us.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages > 100 /var/lib/dpkg/status What I expect: I expect the attached application, when run using the gdb script in the comments, to complete with no failures. What happened: A SIGSEGV after the final continue.
2014-11-04 16:05:40 Dariusz Gadomski bug added subscriber Dariusz Gadomski
2014-11-04 16:26:31 Brad Martin removed subscriber Brad Martin
2015-01-09 16:55:13 Martin Pitt removed subscriber Ubuntu Sponsors Team
2015-01-16 14:56:15 Dariusz Gadomski attachment added precise_eglibc_2.15-0ubuntu10.10.debdiff https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1020210/+attachment/4299972/+files/precise_eglibc_2.15-0ubuntu10.10.debdiff
2015-01-16 14:56:36 Dariusz Gadomski attachment removed precise_eglibc_2.15-0ubuntu10.8.debdiff https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1020210/+attachment/4252890/+files/precise_eglibc_2.15-0ubuntu10.8.debdiff
2015-02-12 14:42:49 Dariusz Gadomski attachment added precise_eglibc_2.15-0ubuntu10.11.debdiff https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1020210/+attachment/4317996/+files/precise_eglibc_2.15-0ubuntu10.11.debdiff
2015-02-13 13:34:04 Dariusz Gadomski attachment removed precise_eglibc_2.15-0ubuntu10.11.debdiff https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1020210/+attachment/4317996/+files/precise_eglibc_2.15-0ubuntu10.11.debdiff
2015-02-13 13:36:05 Dariusz Gadomski attachment added precise_eglibc_2.15-0ubuntu10.11.debdiff https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1020210/+attachment/4318758/+files/precise_eglibc_2.15-0ubuntu10.11.debdiff
2015-02-20 16:53:23 Jorge Niedbalski bug added subscriber Ubuntu Sponsors Team
2015-03-26 19:05:03 Brian Murray eglibc (Ubuntu Precise): status In Progress Fix Committed
2015-03-26 19:05:06 Brian Murray bug added subscriber SRU Verification
2015-03-26 19:05:11 Brian Murray tags verification-needed
2015-03-26 19:27:29 Launchpad Janitor branch linked lp:ubuntu/precise-proposed/eglibc
2015-04-03 15:32:57 Sebastien Bacher removed subscriber Ubuntu Sponsors Team
2015-04-08 07:02:09 Adam Conrad tags verification-needed verification-done
2015-04-08 07:03:40 Launchpad Janitor eglibc (Ubuntu Precise): status Fix Committed Fix Released
2015-04-08 07:03:58 Adam Conrad removed subscriber Ubuntu Stable Release Updates Team
2015-04-08 07:27:45 Launchpad Janitor branch linked lp:ubuntu/precise-updates/eglibc