+++ This bug was initially created as a clone of Bug #593396 +++ Created attachment 414918 [details] test case Description of problem: Seeing 'invalid fastbin entry (free)' errors for a test program that appears to have no bug in it that would legitimately cause such an error. Suspect this may be a bug in the fastbin verification logic. Version-Release number of selected component (if applicable): glibc-2.12-1.1.el6.x86_64 How reproducible: Easily Steps to Reproduce: 1. compile and run attached test case Actual results: Get a crash due to an invalid fastbin within a minute. Expected results: No crash. Additional info: --- Additional comment from gsim on 2010-05-18 13:59:01 EDT --- Created attachment 414920 [details] A smaller test case This requires use of the -std=c++0x option when compiling but cuts out some of the noise in the test case by replacing the trivial pthread wrapper classes in the previous attachement. Exhibits the same symptoms. --- Additional comment from pm-rhel on 2010-05-18 14:04:30 EDT --- Since this issue was entered in bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release. --- Additional comment from jneedle on 2010-05-18 14:41:31 EDT --- This is a test blocker for us because it causes significant instability in the messaging broker on RHEL6. --- Additional comment from snagar on 2010-05-18 16:23:54 EDT --- Flagging as Beta 2 blocker as this is impeding testing of the messaging broker we plan to provide in RHEL 6. --- Additional comment from drepper.fsp on 2010-05-18 17:20:12 EDT --- Before anything else is tried, this patch should be added to the RHEL6 glibc and then all tests repeated: http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=5f24d53acb2cd02ffb4ac925c0244e4f1f854499;hp=d84acf388ed8b3f162dda0512139095bfc268beb --- Additional comment from schwab on 2010-05-19 09:17:04 EDT --- http://brewweb.devel.redhat.com/brew/taskinfo?taskID=2455013 --- Additional comment from sghosh on 2010-05-19 17:27:39 EDT --- https://bugzilla.redhat.com/show_bug.cgi?id=589706#c6 Gordon notes that patch fixes fastbin free error. Thanks for the quick work. --- Additional comment from gsim on 2010-05-20 02:49:20 EDT --- Yes indeed, thanks very much! --- Additional comment from releng-rhel on 2010-05-21 08:09:37 EDT --- Fixed in 'glibc-2.12-1.2.el6', included in compose 'RHEL6.0-20100520.0'. Moving to ON_QA. --- Additional comment from pmuller on 2010-06-08 12:34:47 EDT --- Both testcases ran simmultaneously on all architecture boxes for hours without a single problem. Glibc version: glibc-2.12-1.2.el6. Moving to VERIFIED. --- Additional comment from schwab on 2010-06-24 10:41:21 EDT --- *** Bug 586972 has been marked as a duplicate of this bug. *** --- Additional comment from releng-rhel on 2010-07-02 15:09:21 EDT --- Red Hat Enterprise Linux Beta 2 is now available and should resolve the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you.
We are seeing this both in 5.5 and 5.6 candidate glibc. Given that this issue was quite urgent for RHEL6, I'm proposing this to be fixed in RHEL5 too. We are actually seeing these aborts on i386 architecture only, and in about 30-40% of testcase runs: we run it in a loop and if the testcase does not crash in 30 seconds, we kill it and re-run: #!/bin/bash PASS=0 FAIL=0 for index in `seq 20` do echo "=== Launching ===" ./test1 & echo "=== Sleeping ===" sleep 30 echo "=== Killing ===" kill $! if [ "$?" == "0" ] then PASS=$(( PASS + 1)) else FAIL=$(( FAIL + 1)) fi sleep 2 done echo "PASSES: $PASS" echo "FAILES: $FAIL" gives something like this in few iterations: === Launching === === Sleeping === terminate called after throwing an instance of 'terminate called after throwing an instance of 'std::bad_alloc' std::bad_alloc' what(): St9bad_alloc what(): St9bad_alloc loopa.sh: line 6: 14590 Aborted ./test
I forgot to mention the glibc version: We saw this on: glibc-2.5-49.el5_5.5.i686 glibc-2.5-54.i686 Also, please note that on RHEL5, you need to use g++44 to compile the second testcase, because the original RHEL5 gcc does not know the required -std=c++0x
Why do you think this has anything to do with bug #593396? This error check does not even exist in RHEL-5.
That appears to be just a case of transient out-of-memory situation.
This request was evaluated by Red Hat Product Management for inclusion in Red Hat Enterprise Linux 5.7 and Red Hat does not plan to fix this issue the currently developed update. Contact your manager or support representative in case you need to escalate this bug.
Doesn't look like this is a bug.
(In reply to comment #6) > Doesn't look like this is a bug. I agree. IMHO the test case completely exhaust virtual address space. It doesn't happen every time only because of random function. Feel free to close it.