Bug 197804 - anaconda dies with: double free or corruption (fasttop): 0x600000000012ec40
anaconda dies with: double free or corruption (fasttop): 0x600000000012ec40
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
ia64 Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Mike McLean
: Regression
Depends On:
Blocks: fedora-ia64
  Show dependency treegraph
 
Reported: 2006-07-06 10:48 EDT by Doug Chapman
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-31 11:25:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Doug Chapman 2006-07-06 10:48:09 EDT
Description of problem:
I saw this last week and thought it was the same as 195749 but since that one is
just with http installs (I am using nfs) and that one should be fixed and I
still see this one it looks like this is a separate issue.

This is seen during a kickstart install on one of my HP Integrity (ia64)
servers.  Odd thing is I don't see this on my other systems.  I have not yet
seen this with interactive installs.  This is really odd since it had not yet
brought up the eth device so it would not have been able to get the kickstart
file yet so I don't know _why_ I am only seeing this with kickstart.  However,
when I do an interactive install this appears to be the point where it would ask
for the language and it doesn't do that for a KS intstall.

Last message seen from anaconda before the crash was "Loading cciss driver...".
 This is a serial console system so I am unable to get much info out of it (it
would be really cool if there were some way to store the logs from a failed
install in these situations).




 *** glibc detected *** /sbin/loader: double free or corruption (fasttop):
0x600000000012ec40 ***
======= Backtrace: =========
[0x40000000002c4cf0]
[0x40000000002ce2c0]
[0x4000000000030a40]
[0x4000000000036e70]
[0x400000000002b960]
[0x400000000001e3b0]
[0x4000000000008040]
[0x4000000000270710]
[0x4000000000000280]
======= Memory map: ========
00000000-00004000 r--p 00000000 00:00 0
2000000000030000-2000000000070000 rw-p 2000000000030000 00:00 0
2000000000100000-2000000000124000 rw-p 2000000000100000 00:00 0
2000000000124000-2000000000200000 ---p 2000000000124000 00:00 0
4000000000000000-400000000046c000 r-xp 00000000 00:01 29                
/sbin/loader
6000000000008000-6000000000034000 rw-p 00468000 00:01 29                
/sbin/loader
6000000000034000-6000000000200000 rw-p 6000000000034000 00:00 0          [heap]
60000fff7fffc000-60000fff80000000 rw-p 60000fff7fffc000 00:00 0
60000ffffe9e4000-60000ffffea38000 rw-p 60000ffffe9e4000 00:00 0          [stack]
a000000000000000-a000000000020000 ---p 00000000 00:00 0          [vdso]
install exited abnormally [0/0] -- received signal 6
sending termination signals...done
sending kill signals...done
disabling swap...
unmounting filesystems...
/proc/bus/usb done
/proc done
/dev/pts done
/sys done
/tmp/ramfs done
you may safely reboot your system



Version-Release number of selected component (if applicable):
rawhide-20060706
anaconda-11.1.0.53-1

How reproducible:
On one particular system (hplp2 on my private net) every time when I do a
kickstart install.  I have not seen this on 

Steps to Reproduce:
1. network boot with: append="ks=nfs:10.12.11.1:/export/10.12.11.41-kickstart
ksdevice=eth0 selinux=0"

(note, I also tried without the selinux=0 with same results)
Comment 1 Doug Chapman 2006-07-06 10:53:02 EDT
A little more info...

If I remove the ksdevice=eth0 argument (so that anaconda needs to prompt me) I
still see the traceback.  This seems to point to it happening before it tries to
bring up the eth device which might narrow this down a bit.
Comment 2 Jeremy Katz 2006-07-10 20:27:44 EDT
Does this still happen with newer trees?
Comment 3 Doug Chapman 2006-07-11 10:33:32 EDT
Yes, just verified that I still see this on rawhide-20060710 and
anaconda-11.1.0.54-1
Comment 4 Doug Chapman 2006-07-11 10:36:06 EDT
Addresses have changed a bit so here is the backtrace from the latest crash on
anaconda-11.1.0.54-1:

*** glibc detected *** /sbin/loader: double free or corruption (fasttop):
0x600000000012eee0 ***
======= Backtrace: =========
[0x40000000002c5d50]
[0x40000000002cf320]
[0x4000000000030a40]
[0x4000000000037c80]
[0x400000000002b960]
[0x400000000001e3b0]
[0x4000000000008040]
[0x4000000000271770]
[0x4000000000000280]
======= Memory map: ========
00000000-00004000 r--p 00000000 00:00 0
2000000000030000-2000000000070000 rw-p 2000000000030000 00:00 0
2000000000100000-2000000000124000 rw-p 2000000000100000 00:00 0
2000000000124000-2000000000200000 ---p 2000000000124000 00:00 0
4000000000000000-400000000046c000 r-xp 00000000 00:01 27                
/sbin/loader
6000000000008000-6000000000034000 rw-p 00468000 00:01 27                
/sbin/loader
6000000000034000-6000000000200000 rw-p 6000000000034000 00:00 0          [heap]
60000fff7fffc000-60000fff80000000 rw-p 60000fff7fffc000 00:00 0
60000fffff0b8000-60000fffff10c000 rw-p 60000fffff0b8000 00:00 0         
[stack]a000000000000000-a000000000020000 ---p 00000000 00:00 0          [vdso]
install exited abnormally [0/0] -- received signal 6
Comment 5 Bastien Nocera 2006-07-31 06:02:09 EDT
I believe it's similar to bug 200451
Comment 6 Doug Chapman 2006-07-31 11:05:08 EDT
This is now working in the rawhide-20060731 tree.

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