Bug 247859
Summary: | "yum update" segmentation fault after "Cannot allocate memory" | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Kai Engert (:kaie) (inactive account) <kengert> |
Component: | yum | Assignee: | Jeremy Katz <katzj> |
Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | james.antill |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-07-11 20:56:37 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Kai Engert (:kaie) (inactive account)
2007-07-11 18:47:30 UTC
I'd bet it's really Python that just died due to ENOMEM, although why that happened isn't obvious is the machine doing something else taking a lot of RAM ... as assuming yum was in the high multi-100MB area there doesn't seem a lot of memory free. Assuming nothing obviously weird is going on the only real solution to this I can see is to have yum do a lot of small transactions, instead of one big one. Which might eventually be done upstream. There are also a bunch of people working on getting the memory usage down in general ... but if you are updating 500+ packages you might well still have problems. Can you replicate this? b/c I'd love to see when it explodes in size. (In reply to comment #2) > Can you replicate this? b/c I'd love to see when it explodes in size. I don't have that old snapshot any longer, but if the theory is correct and it's indeed caused by updating too many packages in one step.... then all you need is to install an old snapshot of rawhide and run yum update? I was using a 1 GB xen guest, only allocate 512 MB and you should be able to see the bug more easily? (In reply to comment #1) > is the machine doing something else taking a lot of RAM This xen guest is a plain installation, there was nothing running on the system besides the default daemons. I was logged in using ssh only, no X session running. my problem is I can't replicate it. I've done large updates on 512M xen instances and they've worked pretty well. No -ENOMEM at least. That's why I'm curious if something in particular was blowing up ram. Well I'd assumed something else was running, taking up RAM, because right after yum dies: MemTotal: 1033252 kB MemFree: 257320 kB Buffers: 145960 kB Cached: 186640 kB ...AIUI this means something is taking ~450MB. Also: SwapCached: 217936 kB SwapTotal: 1048568 kB SwapFree: 709448 kB ...implies something (probably the same thing) is _still_ taking ~100MB of swap, and swap had been upto ~300MB (implying that yum was taking ~450MB). If there was a lot of memory being used, something must have allocated it during the system update. The following is from after booting. Sorry, I can't find out what had been consuming that additional memory. I should have been smart enough to make a dump of processes and their consumption after the out-of-memory errors. [root@kaiexenrawhide ~]# cat /proc/meminfo MemTotal: 1033252 kB MemFree: 774544 kB Buffers: 11004 kB Cached: 119472 kB SwapCached: 0 kB Active: 83988 kB Inactive: 101820 kB SwapTotal: 1048568 kB SwapFree: 1048568 kB Dirty: 20 kB Writeback: 0 kB AnonPages: 55340 kB Mapped: 11640 kB Slab: 20876 kB SReclaimable: 8164 kB SUnreclaim: 12712 kB PageTables: 3976 kB NFS_Unstable: 0 kB Bounce: 0 kB CommitLimit: 1565192 kB Committed_AS: 140404 kB VmallocTotal: 34359738367 kB VmallocUsed: 3008 kB VmallocChunk: 34359734343 kB |