-
Notifications
You must be signed in to change notification settings - Fork 279
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
crash: cannot allocate any more memory! #36
Comments
When you see that error, there should have been a dump of the memory allocation crash> help -b There are 31 static buffers that get used first, and if those are exhausted, it starts using (1) it calls calloc() more than 2000 times, or The buffers are for temporary usage. After session intialization and prior to the first "crash> " prompt, So if (1) were true, then the "mallocs:" and "frees:" counts above would be totally out of whack, |
Thanks for responding. I did attach my entire printout from a 'crash -d4'. But since crash doesn't actually start, I cannot use the 'help -b'. Based upon your explanation, one thing I did observe is the 'largest' 'buf_inuse[5]' is much, much bigger than what you showed: buf_inuse[5]: [3][0][0][0][0] Maybe there is a memory leak going on? -----------------attached output ------------------- [jfreyensee@fedora-virtualfedora Documentation]$ sudo crash -d4 crash 7.2.1-2.fc28 find_booted_kernel: search for [Linux version 5.0.16-100.fc28.x86_64 ([email protected]) (gcc version 8.3.1 20190223 (Red Hat 8.3.1-2) (GCC)) #1 SMP Tue May 14 18:22:28 UTC 2019] gdb /usr/lib/debug/lib/modules/5.0.16-100.fc28.x86_64/vmlinux WARNING: kernel relocated [528MB]: patching 101832 gdb minimal_symbol values <readmem: ffffffffa31827d8, KVADDR, "page_offset_base", 8, (FOE), 55b05788fc68> verify_namelist: <readmem: ffffffffa3185820, KVADDR, "__per_cpu_offset", 8192, (FOE), 55b057876068> ZONE NAME SIZE MEM_MAP START_PADDR START_MAPNR NR SECTION CODED_MEM_MAP MEM_MAP PFN kmem_cache_downsize: 8536 to 352 crash: cannot allocate any more memory! "crash" module loaded: [crash][16384][0] |
It's this "largest" allocation size that's failing: [jfreyensee@fedora-virtualfedora Documentation]$ sudo crash -d4 However, before going any further, crash-7.2.1-2.fc28 has little or no chance of working with https://koji.fedoraproject.org/koji/packageinfo?packageID=307 Given that it's happening during module initialization, the problem you're seeing would appear to https://bugzilla.redhat.com/show_bug.cgi?id=1623127 But since you say it also happens with a compiled github source tree, it's hard to know exactly |
Yes, I see the same issue by pulling crash source code and compiling the 'master' branch in my environment. I would say it's a good chance I'm hitting that bugzilla entry. |
Unfortunately the issue in that bugzilla was addressed in crash-7.2.4. So I don't have a clue as to |
This is in crash 7.2.1-2 and from compiling the source from 'master' branch (pulled today)
I get the 'crash: cannot allocate any more memory!' error. I have 8GB and 2 CPUs dedicated to my Fedora VM, I thought that would be plenty of memory as when I start up crash I don't see 8GB being used up in system monitor.
I searched around with Google and it seems like when this error shows up its associated with a bugzilla entry, so maybe this is a real problem with crash? I certainly cannot find any suggested command-line startups to use to try and work around this.
All I am doing is typing 'crash' on command-line and hitting enter. I was trying to use:
'crash vmlinux vmcore'
in which the vmcore is 214MB but I get that same error regardless if I type 'crash' on the command-line or try and load a vmcore file.
The text was updated successfully, but these errors were encountered: