https://sourceware.org/bugzilla/show_bug.cgi?id=27399
--- Comment #7 from Sergio Durigan Junior ---
(In reply to Frank Ch. Eigler from comment #6)
> OK, my best guess is a transient low-memory condition. Just today we found
> bug #27405, which can cause some impressive momentary memory binges in
> elfutils. Reducing concurrency is one way to limit its impact, as you
> found. Giving the VM more memory is another: I run it on 16GB 8CPU class
> VMs, scanning even many huge debuginfo files, without a complaint.
I was also considering that this could be a temporarily low-memory thing, but I
don't think so anymore. I've expanded the VM memory to 32GB now, and I'm still
seeing the errors.
> It might also help reassure here is that if you let debuginfod keep going,
> it'll know that it didn't finish indexing those problematic files, and will
> just retry later. In the long term (past rescan time), such momentary
> ENOMEMs are not particularly harmful.
OK, good, I thought this would be the case but I did not know for sure. That's
good to know.
> I can't think of any debuginfod per se changes or bugs in effect here.
> Maybe scale the default concurrency more conservatively to machine RAM
> rather than solely CPU count?
My current plan is to use the "bsdtar" workaround above, which seems to work
even when I max out the concurrency. But the debugger in me still wants to
know what is happening...
Anyway, while I agree that this is not a high priority issue (since there are
two known workarounds for it), I think it may be worth mentioning the "bsdtar"
solution more explicitly in the documentation.
--
You are receiving this mail because:
You are on the CC list for the bug.
