Hello, I've got this failure I cannot really understand, it happens on armv7hl only (aarch64 and s390x were cancelled):
Checking for unpackaged file(s): /usr/lib/rpm/check-files /builddir/build/BUILDROOT/prusa-slicer-2.2.0-4.fc33.arm error: Installed (but unpackaged) file(s) found: /usr/bin/prusa-slicer.wrapped.gdb-index-9pY4kY Installed (but unpackaged) file(s) found: /usr/bin/prusa-slicer.wrapped.gdb-index-9pY4kY
The gdb-index-9pY4kY files are not created explcitiyl by anything in the package.
Most recent builds: https://koji.fedoraproject.org/koji/taskinfo?taskID=48609410 https://koji.fedoraproject.org/koji/taskinfo?taskID=48609410
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1865257
Does anybody know what this is?
* Miro Hrončok:
Hello, I've got this failure I cannot really understand, it happens on armv7hl only (aarch64 and s390x were cancelled):
Checking for unpackaged file(s): /usr/lib/rpm/check-files /builddir/build/BUILDROOT/prusa-slicer-2.2.0-4.fc33.arm error: Installed (but unpackaged) file(s) found: /usr/bin/prusa-slicer.wrapped.gdb-index-9pY4kY Installed (but unpackaged) file(s) found: /usr/bin/prusa-slicer.wrapped.gdb-index-9pY4kY
The gdb-index-9pY4kY files are not created explcitiyl by anything in the package.
This happens if debuginfo generation fails with a crash:
extracting debug info from /builddir/build/BUILDROOT/prusa-slicer-2.2.0-4.fc33.arm/usr/bin/prusa-slicer.wrapped ../../gdb/utils.c:691: internal-error: virtual memory exhausted: can't allocate 234696314 bytes. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) [answered Y; input not from terminal] This is a bug, please report it. For instructions, see: http://www.gnu.org/software/gdb/bugs/. /usr/bin/gdb-add-index: line 106: 22699 Aborted (core dumped) $GDB --batch -nx -iex 'set auto-load no' -ex "file $file" -ex "save gdb-index $dwarf5 $dir"
The crash is normally ignored.
Does anybody know what this is?
Not enough RAM, apparently.
Thanks, Florian
On 04. 08. 20 18:16, Florian Weimer wrote:
- Miro Hrončok:
Hello, I've got this failure I cannot really understand, it happens on armv7hl only (aarch64 and s390x were cancelled):
Checking for unpackaged file(s): /usr/lib/rpm/check-files /builddir/build/BUILDROOT/prusa-slicer-2.2.0-4.fc33.arm error: Installed (but unpackaged) file(s) found: /usr/bin/prusa-slicer.wrapped.gdb-index-9pY4kY Installed (but unpackaged) file(s) found: /usr/bin/prusa-slicer.wrapped.gdb-index-9pY4kY
The gdb-index-9pY4kY files are not created explcitiyl by anything in the package.
This happens if debuginfo generation fails with a crash:
extracting debug info from /builddir/build/BUILDROOT/prusa-slicer-2.2.0-4.fc33.arm/usr/bin/prusa-slicer.wrapped ../../gdb/utils.c:691: internal-error: virtual memory exhausted: can't allocate 234696314 bytes. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) [answered Y; input not from terminal] This is a bug, please report it. For instructions, see: http://www.gnu.org/software/gdb/bugs/. /usr/bin/gdb-add-index: line 106: 22699 Aborted (core dumped) $GDB --batch -nx -iex 'set auto-load no' -ex "file $file" -ex "save gdb-index $dwarf5 $dir"
The crash is normally ignored.
Does anybody know what this is?
Not enough RAM, apparently.
Thank you Florian, I wonder how can I workaround this issu. Usually this was to lower parallelism during build, but I suppose extracting debug info is not parallelized :/
On Tue, Aug 04, 2020 at 07:52:54PM +0200, Miro Hrončok wrote:
On 04. 08. 20 18:16, Florian Weimer wrote:
- Miro Hrončok:
Hello, I've got this failure I cannot really understand, it happens on armv7hl only (aarch64 and s390x were cancelled):
Checking for unpackaged file(s): /usr/lib/rpm/check-files /builddir/build/BUILDROOT/prusa-slicer-2.2.0-4.fc33.arm error: Installed (but unpackaged) file(s) found: /usr/bin/prusa-slicer.wrapped.gdb-index-9pY4kY Installed (but unpackaged) file(s) found: /usr/bin/prusa-slicer.wrapped.gdb-index-9pY4kY
The gdb-index-9pY4kY files are not created explcitiyl by anything in the package.
This happens if debuginfo generation fails with a crash:
extracting debug info from /builddir/build/BUILDROOT/prusa-slicer-2.2.0-4.fc33.arm/usr/bin/prusa-slicer.wrapped ../../gdb/utils.c:691: internal-error: virtual memory exhausted: can't allocate 234696314 bytes. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) [answered Y; input not from terminal] This is a bug, please report it. For instructions, see: http://www.gnu.org/software/gdb/bugs/. /usr/bin/gdb-add-index: line 106: 22699 Aborted (core dumped) $GDB --batch -nx -iex 'set auto-load no' -ex "file $file" -ex "save gdb-index $dwarf5 $dir"
The crash is normally ignored.
Does anybody know what this is?
Not enough RAM, apparently.
Thank you Florian, I wonder how can I workaround this issu. Usually this was to lower parallelism during build, but I suppose extracting debug info is not parallelized :/
I'll note that armv7 buildvm's have 24GB memory.
Trying to allocate 234GB doesn't seem very friendly to it working and sounds more like a bug somewhere to me.
kevin
On Tue, 2020-08-04 at 11:34 -0700, Kevin Fenzi wrote:
On Tue, Aug 04, 2020 at 07:52:54PM +0200, Miro Hrončok wrote:
On 04. 08. 20 18:16, Florian Weimer wrote:
- Miro Hrončok:
Hello, I've got this failure I cannot really understand, it happens on armv7hl only (aarch64 and s390x were cancelled):
Checking for unpackaged file(s): /usr/lib/rpm/check-files /builddir/build/BUILDROOT/prusa-slicer-2.2.0-4.fc33.arm error: Installed (but unpackaged) file(s) found: /usr/bin/prusa-slicer.wrapped.gdb-index-9pY4kY Installed (but unpackaged) file(s) found: /usr/bin/prusa-slicer.wrapped.gdb-index-9pY4kY
The gdb-index-9pY4kY files are not created explcitiyl by anything in the package.
This happens if debuginfo generation fails with a crash:
extracting debug info from /builddir/build/BUILDROOT/prusa-slicer-2.2.0-4.fc33.arm/usr/bin/prusa-slicer.wrapped ../../gdb/utils.c:691: internal-error: virtual memory exhausted: can't allocate 234696314 bytes. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) [answered Y; input not from terminal] This is a bug, please report it. For instructions, see: http://www.gnu.org/software/gdb/bugs/;. /usr/bin/gdb-add-index: line 106: 22699 Aborted (core dumped) $GDB --batch -nx -iex 'set auto-load no' -ex "file $file" -ex "save gdb-index $dwarf5 $dir"
The crash is normally ignored.
Does anybody know what this is?
Not enough RAM, apparently.
Thank you Florian, I wonder how can I workaround this issu. Usually this was to lower parallelism during build, but I suppose extracting debug info is not parallelized :/
I'll note that armv7 buildvm's have 24GB memory.
Trying to allocate 234GB doesn't seem very friendly to it working and sounds more like a bug somewhere to me.
Actually, isn't it "just" 234MB. Still I'm surprised why that failed. Do we have more than one build running at a time on those boxes?
jeff
* Jeff Law:
Actually, isn't it "just" 234MB. Still I'm surprised why that failed. Do we have more than one build running at a time on those boxes?
It's a 32-bit build. I assume it's not the first large allocation. (FWIW, GDB always prints “virtual memory exhausted”, even if the malloc failure has a different cause.)
Does LTO produce more complicated debugging information? Then maybe disabling LTO on armhfp is a workaround. There's also a way to disable debuginfo package generation altogether, something along these lines (untested):
%define debug_package %{nil} %define __debug_install_post %{nil} %global __debug_package %{nil} %undefine _debugsource_packages %undefine _debuginfo_subpackages %undefine _unique_debug_names %undefine _unique_debug_srcs
Thanks, Florian
On 04. 08. 20 21:36, Florian Weimer wrote:
Does LTO produce more complicated debugging information? Then maybe disabling LTO on armhfp is a workaround.
I've actually tried this before reading your e-mail and went to report back:
%ifarch %{arm} %global _lto_cflags %{nil} %endif
This makes it build.
On Tue, 2020-08-04 at 21:36 +0200, Florian Weimer wrote:
- Jeff Law:
Actually, isn't it "just" 234MB. Still I'm surprised why that failed. Do we have more than one build running at a time on those boxes?
It's a 32-bit build. I assume it's not the first large allocation. (FWIW, GDB always prints “virtual memory exhausted”, even if the malloc failure has a different cause.)
Does LTO produce more complicated debugging information? Then maybe disabling LTO on armhfp is a workaround. There's also a way to disable debuginfo package generation altogether, something along these lines (untested):
It doesn't really make it more complicated, but it does scramble it in fun an interesting ways. I'd hazard a guess it changed things in such a way as to confuse the bits that add the index.
Jeff
-
Florian Weimer -
Jeff Law -
Kevin Fenzi -
Miro Hrončok