Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 642329 - invalid fastbin entry (free)
Summary: invalid fastbin entry (free)
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: glibc
Version: 5.6
Hardware: All
OS: Linux
medium
high
Target Milestone: rc
: ---
Assignee: Andreas Schwab
QA Contact: qe-baseos-tools
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-12 15:23 UTC by Petr Muller
Modified: 2016-11-24 12:04 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 593396
Environment:
Last Closed: 2011-08-17 11:35:45 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Petr Muller 2010-10-12 15:23:58 UTC
+++ 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@gmail.com 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@redhat.com on 2010-05-19 09:17:04 EDT ---

http://brewweb.devel.redhat.com/brew/taskinfo?taskID=2455013

--- Additional comment from sghosh@redhat.com 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@redhat.com on 2010-05-20 02:49:20 EDT ---

Yes indeed, thanks very much!

--- Additional comment from releng-rhel@redhat.com 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@redhat.com 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@redhat.com on 2010-06-24 10:41:21 EDT ---

*** Bug 586972 has been marked as a duplicate of this bug. ***

--- Additional comment from releng-rhel@redhat.com 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.

Comment 1 Petr Muller 2010-10-12 15:30:38 UTC
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

Comment 2 Petr Muller 2010-10-12 15:32:59 UTC
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

Comment 3 Andreas Schwab 2010-10-13 12:34:52 UTC
Why do you think this has anything to do with bug #593396?  This error check does not even exist in RHEL-5.

Comment 4 Andreas Schwab 2010-10-13 15:32:09 UTC
That appears to be just a case of transient out-of-memory situation.

Comment 5 RHEL Product and Program Management 2011-06-20 22:11:28 UTC
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.

Comment 6 Andreas Schwab 2011-08-17 07:34:45 UTC
Doesn't look like this is a bug.

Comment 7 Miroslav Franc 2011-08-17 09:12:17 UTC
(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.


Note You need to log in before you can comment on or make changes to this bug.