[Bug debuginfod/27399] dpkg-deb/lzma error when indexing .debs
https://sourceware.org/bugzilla/show_bug.cgi?id=27399 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com Status|NEW |WAITING --- Comment #1 from Frank Ch. Eigler --- Can you check whether dpkg-deb is decompressing all of its content onto some RAM-backed filesystem, and running out of space via that (or via consuming machine free ram)? You can try a few things: - run debuginfod with a smaller concurrency limit (-c NNN), because the decompression etc. activities aggressively use all your CPUs and thus #CPU * memory, if they can - instead of 'debuginfod -U' (which uses dpkg-deb as the decompression streamer), use % debuginfod -Z.deb="(bsdtar -O -x -f - data.tar.xz)<" which causes deb files to be processed with libarchive's frontend (or equivalently, temporarily rename /usr/bin/dpkg-deb while starting debuginfod, so it makes the same inference) - monitor resource usage - particularly ram - during the indexing process - try running elfutils 0.183 debuginfod, which does a touch more filesystem-space monitoring, related self-protection, more prometheus error metrics -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/27399] dpkg-deb/lzma error when indexing .debs
https://sourceware.org/bugzilla/show_bug.cgi?id=27399 --- Comment #2 from Frank Ch. Eigler --- Sergio, are the messages you're worried about happening AT THE MOMENT of a start / stop? Or just intermittently sometime during the normal operating lifetime of the process? -- You are receiving this mail because: You are on the CC list for the bug.
[PATCH] readelf, libdw: blocks aren't expressions for DWARF version 4
For DWARF version 4 or higher a block form really encodes a block,
not an expression location. Also constant offsets can be expressed
as DW_FORM_implicit_const in DWARF version 5.
Signed-off-by: Mark Wielaard
---
libdw/ChangeLog | 6 ++
libdw/dwarf_getlocation.c | 17 +
src/ChangeLog | 5 +
src/readelf.c | 4 +++-
4 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/libdw/ChangeLog b/libdw/ChangeLog
index b8038f00..f01bee39 100644
--- a/libdw/ChangeLog
+++ b/libdw/ChangeLog
@@ -1,3 +1,9 @@
+2021-02-12 Mark Wielaard
+
+ * dwarf_getlocation.c (attr_ok): For DWARF version 4 or higher
+ block forms are not expression locations.
+ (is_constant_offset): DW_FORM_implicit_const is also a constant.
+
2020-12-20 Dmitry V. Levin
* .gitignore: New file.
diff --git a/libdw/dwarf_getlocation.c b/libdw/dwarf_getlocation.c
index 4e582db2..5db3cf97 100644
--- a/libdw/dwarf_getlocation.c
+++ b/libdw/dwarf_getlocation.c
@@ -48,6 +48,22 @@ attr_ok (Dwarf_Attribute *attr)
if (dwarf_whatform (attr) == DW_FORM_exprloc)
return true;
+ if (attr->cu->version >= 4)
+{
+ /* Must be an exprloc (or constant), just not any block form. */
+ switch (dwarf_whatform (attr))
+ {
+ case DW_FORM_block:
+ case DW_FORM_block1:
+ case DW_FORM_block2:
+ case DW_FORM_block4:
+ __libdw_seterrno (DWARF_E_NO_LOC_VALUE);
+ return false;
+ default:
+ break;
+ }
+}
+
/* Otherwise must be one of the attributes listed below. Older
DWARF versions might have encoded the exprloc as block, and we
cannot easily distinguish attributes in the loclist class because
@@ -186,6 +202,7 @@ is_constant_offset (Dwarf_Attribute *attr,
case DW_FORM_data8:
case DW_FORM_sdata:
case DW_FORM_udata:
+case DW_FORM_implicit_const:
break;
}
diff --git a/src/ChangeLog b/src/ChangeLog
index e65620fd..61cd98f4 100644
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,3 +1,8 @@
+2021-02-12 Mark Wielaard
+
+ * readelf.c (attr_callback): Don't handle blocks as expression
+ blocks for DWARF version 4 or higher.
+
2021-02-03 Timm Bäder
* ar.c (do_oper_extract): Extract should_truncate_fname function
diff --git a/src/readelf.c b/src/readelf.c
index 11692bb5..9d2a25a4 100644
--- a/src/readelf.c
+++ b/src/readelf.c
@@ -7599,7 +7599,9 @@ attr_callback (Dwarf_Attribute *attrp, void *arg)
case DW_AT_GNU_call_site_data_value:
case DW_AT_GNU_call_site_target:
case DW_AT_GNU_call_site_target_clobbered:
- if (form != DW_FORM_data16)
+ if (form == DW_FORM_exprloc
+ || (form != DW_FORM_data16
+ && attrp->cu->version < 4)) /* blocks were expressions. */
{
putchar ('\n');
print_ops (cbargs->dwflmod, cbargs->dbg,
--
2.18.4
[PUSHED] elfutils.spec.in: Escape %%check in comment.
Signed-off-by: Mark Wielaard --- config/ChangeLog| 4 config/elfutils.spec.in | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/config/ChangeLog b/config/ChangeLog index d84d38c3..e877bdda 100644 --- a/config/ChangeLog +++ b/config/ChangeLog @@ -1,3 +1,7 @@ +2021-02-12 Mark Wielaard + + * elfutils.spec.in: Escape %%check in comment. + 2021-02-05 Mark Wielaard * elfutils.spec.in: Update for 0.183. diff --git a/config/elfutils.spec.in b/config/elfutils.spec.in index 46b404f9..9df92b38 100644 --- a/config/elfutils.spec.in +++ b/config/elfutils.spec.in @@ -35,7 +35,7 @@ BuildRequires: pkgconfig(libarchive) >= 3.1.2 # For tests need to bunzip2 test files. BuildRequires: bzip2 BuildRequires: zstd -# For the run-debuginfod-find.sh test case in %check for /usr/sbin/ss +# For the run-debuginfod-find.sh test case in %%check for /usr/sbin/ss BuildRequires: iproute BuildRequires: bsdtar BuildRequires: curl -- 2.20.1
[PATCH] readelf: Type DIE offset is from start of CU.
While inspecting some type units I noticed the type offset seemed off.
We were printing the offset as is, but it should include the offset of
the unit. There was actually a testcase for this, run-readelf-types.sh
but that had the same bug in the expected output. Fixed both.
Signed-off-by: Mark Wielaard
---
src/ChangeLog | 4
src/readelf.c | 3 ++-
tests/ChangeLog| 4
tests/run-readelf-types.sh | 2 +-
4 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/ChangeLog b/src/ChangeLog
index e65620fd..552002b0 100644
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,3 +1,7 @@
+2021-02-12 Mark Wielaard
+
+ * readelf.c (print_debug_units): Type DIE offset is from start CU.
+
2021-02-03 Timm Bäder
* ar.c (do_oper_extract): Extract should_truncate_fname function
diff --git a/src/readelf.c b/src/readelf.c
index 11692bb5..ccd59e39 100644
--- a/src/readelf.c
+++ b/src/readelf.c
@@ -7792,7 +7792,8 @@ print_debug_units (Dwfl_Module *dwflmod,
{
Dwarf_Die typedie;
Dwarf_Off dieoffset;
- dieoffset = dwarf_dieoffset (dwarf_offdie_types (dbg, subdie_off,
+ dieoffset = dwarf_dieoffset (dwarf_offdie_types (dbg, cu->start
+ + subdie_off,
&typedie));
printf (_(" Type unit at offset %" PRIu64 ":\n"
" Version: %" PRIu16
diff --git a/tests/ChangeLog b/tests/ChangeLog
index e22fa455..27827ed3 100644
--- a/tests/ChangeLog
+++ b/tests/ChangeLog
@@ -1,3 +1,7 @@
+2021-02-12 Mark Wielaard
+
+ * run-readelf-types.sh: Add CU start to type offset reference.
+
2021-02-08 Érico Nogueira
* run-debuginfod-find.sh: Check for cpio availability.
diff --git a/tests/run-readelf-types.sh b/tests/run-readelf-types.sh
index a7af5734..4f312697 100755
--- a/tests/run-readelf-types.sh
+++ b/tests/run-readelf-types.sh
@@ -97,7 +97,7 @@ DWARF section [32] '.debug_types' at offset 0x1260:
specification(ref4) [34]
Type unit at offset 67:
Version: 4, Abbreviation section offset: 0, Address size: 8, Offset size: 4
- Type signature: 0x18763953736e2de0, Type offset: 0x25 [25]
+ Type signature: 0x18763953736e2de0, Type offset: 0x25 [68]
[5a] type_unitabbrev: 1
language (data1) C_plus_plus (4)
GNU_odr_signature(data8) 16005269134005989797
--
2.20.1
Re: Buildbot failure in Wildebeest Builder on whole buildset
Hi,
On Tue, Feb 09, 2021 at 10:05:05AM +0100, Mark Wielaard wrote:
> On Tue, 2021-02-09 at 02:26 +, build...@builder.wildebeest.org
> wrote:
> > The Buildbot has detected a failed build on builder whole buildset
> > while building elfutils.
> > Full details are available at:
> > https://builder.wildebeest.org/buildbot/#builders/11/builds/667
> >
> > Buildbot URL: https://builder.wildebeest.org/buildbot/
> >
> > Worker for this Build: fedora-ppc64le
> >
> > Build Reason:
> > Blamelist: Érico Rolim
> >
> > BUILD FAILED: failed test (failure)
>
> Well, that is unfortunate. This couldn't really have been caused by
> your patch. But sadly the run-debuginfod-find.sh seems a little
> unstable :{ Full details here:
> https://builder.wildebeest.org/buildbot/#/builders/11/builds/667/steps/8/logs/test-suite_log
>
> Still looking at what is going wrong.
Interestingly enough the same test case now succeeded on
fedora-ppc64le, but failed on debian-i386...
They failed in the same way:
metric groom{statistic="file d/e"} never changed to 3 on port 9985
Still don't know why though :{
Cheers,
Mark
[Bug libdw/27405] New: libdw_get_srcfiles should not imply srclines
https://sourceware.org/bugzilla/show_bug.cgi?id=27405 Bug ID: 27405 Summary: libdw_get_srcfiles should not imply srclines Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: libdw Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- In debuginfod, we use _get_srcfiles to fetch file names only. We do not care about srclines, so libdw's effort in allocating all that memory, and filling it in, is just a waste. Let's make srcfiles great by skipping the per-line data. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/27405] libdw_get_srcfiles should not imply srclines
https://sourceware.org/bugzilla/show_bug.cgi?id=27405 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #1 from Mark Wielaard --- Note that the issue is here in libdw/dwarf_getsrcfiles.c: /* Let the more generic function do the work. It'll create more data but that will be needed in an real program anyway. */ res = INTUSE(dwarf_getsrclines) (cudie, &lines, &nlines); debuginfod shows that comment is wrong. There is also the internal __libdw_getsrclines function which is used in a couple of place to "only" get the srcfiles. -- You are receiving this mail because: You are on the CC list for the bug.
Buildbot failure in Wildebeest Builder on whole buildset
The Buildbot has detected a failed build on builder whole buildset while building elfutils. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/4/builds/713 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: debian-i386 Build Reason: Blamelist: Mark Wielaard BUILD FAILED: failed test (failure) Sincerely, -The Buildbot
Re: [PATCH] tests: Quote make variables in TESTS_ENVIRONMENT
Hi Alexander,
On Sun, 2021-02-07 at 16:48 +0100, Alexander Miller via Elfutils-devel
wrote:
> Commit eb922a1b8f3a ("tests: use ${CC} instead of 'gcc' in tests")
> exports ${CC} into the test environment, but doesn't quote the
> value for the assignment. That doesn't work properly if the value
> contains whitespace. In a multilib/biarch environment however, it's
> common to set CC="gcc -m32" or similar. That causes tests to print
> error messages: "/bin/sh: line 2: -m32: command not found".
>
> Fix that by adding quotes around all make variables (not just $CC)
> used in setting up TESTS_ENVIRONMENT.
Thanks, that works except for the valgrind_cmd (used when configuring
with --enable-valgrind), because that was already quoted. I removed the
quotes in the original variable assignment and pushed the patch as
attached.
Thanks,
Mark
From 7a5ea4591df5246124ac870c865939ea8f36ac4d Mon Sep 17 00:00:00 2001
From: Alexander Miller via Elfutils-devel
Date: Sun, 7 Feb 2021 16:48:17 +0100
Subject: [PATCH] tests: Quote make variables in TESTS_ENVIRONMENT
Commit eb922a1b8f3a ("tests: use ${CC} instead of 'gcc' in tests")
exports ${CC} into the test environment, but doesn't quote the
value for the assignment. That doesn't work properly if the value
contains whitespace. In a multilib/biarch environment however, it's
common to set CC="gcc -m32" or similar. That causes tests to print
error messages: "/bin/sh: line 2: -m32: command not found".
Fix that by adding quotes around all make variables (not just $CC)
used in setting up TESTS_ENVIRONMENT.
Signed-off-by: Alexander Miller
---
tests/ChangeLog | 5 +
tests/Makefile.am | 29 +++--
2 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/tests/ChangeLog b/tests/ChangeLog
index e22fa455..bc94512e 100644
--- a/tests/ChangeLog
+++ b/tests/ChangeLog
@@ -1,3 +1,8 @@
+2021-02-07 Alexander Miller
+
+ * Makefile.am (TESTS_ENVIRONMENT): Quote variables.
+ (valgrind_cmd): Unquote variable.
+
2021-02-08 Érico Nogueira
* run-debuginfod-find.sh: Check for cpio availability.
diff --git a/tests/Makefile.am b/tests/Makefile.am
index c145720c..852269a3 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -511,36 +511,37 @@ EXTRA_DIST = run-arextract.sh run-arsymtest.sh run-ar.sh \
if USE_VALGRIND
-valgrind_cmd='valgrind -q --leak-check=full --error-exitcode=1'
+valgrind_cmd=valgrind -q --leak-check=full --error-exitcode=1
endif
-installed_TESTS_ENVIRONMENT = libdir=$(DESTDIR)$(libdir); \
- bindir=$(DESTDIR)$(bindir); \
+installed_TESTS_ENVIRONMENT = libdir='$(DESTDIR)$(libdir)'; \
+ bindir='$(DESTDIR)$(bindir)'; \
LC_ALL=C; LANG=C; \
- VALGRIND_CMD=$(valgrind_cmd); \
- abs_srcdir=$(abs_srcdir); \
- abs_builddir=$(abs_builddir); \
- abs_top_builddir=$(abs_top_builddir); \
+ VALGRIND_CMD='$(valgrind_cmd)'; \
+ abs_srcdir='$(abs_srcdir)'; \
+ abs_builddir='$(abs_builddir)'; \
+ abs_top_builddir='$(abs_top_builddir)'; \
export abs_srcdir; export abs_builddir; \
export abs_top_builddir; \
export libdir; export bindir; \
export LC_ALL; export LANG; export VALGRIND_CMD; \
unset DEBUGINFOD_URLS; \
- NM=$(NM); export NM; \
- CC=$(CC); export CC;
+ NM='$(NM)'; export NM; \
+ CC='$(CC)'; export CC;
installed_LOG_COMPILER = $(abs_srcdir)/test-wrapper.sh \
installed $(tests_rpath) \
'$(program_transform_name)'
-TESTS_ENVIRONMENT = LC_ALL=C; LANG=C; VALGRIND_CMD=$(valgrind_cmd); \
- abs_srcdir=$(abs_srcdir); abs_builddir=$(abs_builddir); \
- abs_top_builddir=$(abs_top_builddir); \
+TESTS_ENVIRONMENT = LC_ALL=C; LANG=C; VALGRIND_CMD='$(valgrind_cmd)'; \
+ abs_srcdir='$(abs_srcdir)'; \
+ abs_builddir='$(abs_builddir)'; \
+ abs_top_builddir='$(abs_top_builddir)'; \
export abs_srcdir; export abs_builddir; \
export abs_top_builddir; \
export LC_ALL; export LANG; export VALGRIND_CMD; \
unset DEBUGINFOD_URLS; \
- NM=$(NM); export NM; \
- CC=$(CC); export CC;
+ NM='$(NM)'; export NM; \
+ CC='$(CC)'; export CC;
LOG_COMPILER = $(abs_srcdir)/test-wrapper.sh \
$(abs_top_builddir)/libdw:$(abs_top_builddir)/backends:$(abs_top_builddir)/libelf:$(abs_top_builddir)/libasm:$(abs_top_builddir)/debuginfod
--
2.18.4
Buildbot failure in Wildebeest Builder on whole buildset
The Buildbot has detected a failed build on builder whole buildset while building elfutils. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/10/builds/685 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-s390x Build Reason: Blamelist: Alexander Miller via Elfutils-devel BUILD FAILED: failed test (failure) Sincerely, -The Buildbot
Re: [PATCH - RFC] WIP: fix backtrace test to work on musl
Hi Érico, On Mon, 2021-02-08 at 20:37 -0300, Érico Nogueira via Elfutils-devel wrote: > Currently, the run-backtrace-native.sh test fails on musl systems. As > seen here in the test suite log, this appears to happen because > elfutils > expects raise() to be the last function in the stack trace, which it > isn't, because unlike glibc, which uses inline functions for setting > and > resetting the signal mask, musl chose to use a normal function. I think the testcase is way to specific indeed. It would good if it only checked some main symbol/frame names were in the backtrace. Maybe it should just check if the "raise", "main" and "_start" symbols appear in the backtrace in that order for the main thread, and "raise", "sigusr2", "stdarg", "bakctracegen" and "start"? I haven't really looked at the testcase too closely to know whether that is too simplistic. > 0x5572f06610000x5572f0666000 /builddir/elfutils- > 0.183/tests/backtrace-child > 0x7ff1dac680000x7ff1dad15000 /usr/lib/libc.so > 0x7fff70fc10000x7fff70fc2000 [vdso: 10694] > TID 10694: > # 0 0x7ff1dacbe3e7__restore_sigs > # 1 0x7ff1dacbe590 - 1raise > # 2 0x5572f0662240 - 1main > # 3 0x7ff1dac866fa - 1libc_start_main_stage2 > # 4 0x5572f0662329 - 1_start > TID 10697: > # 0 0x7ff1dacbe3e7__restore_sigs > frameno: 0 symname: __restore_sigs > # 1 0x7ff1dacbe590 - 1raise > frameno: 0 symname: raise > # 2 0x5572f066251b - 1sigusr2 > frameno: 1 symname: sigusr2 > # 3 0x5572f06625bc - 1stdarg > frameno: 4 symname: stdarg > # 4 0x5572f06625e2 - 1backtracegen > frameno: 5 symname: backtracegen > # 5 0x5572f06625fb - 1start > frameno: 6 symname: start > # 6 0x7ff1daccf7ee - 1start > frameno: 7 symname: start > # 7 0x7ff1dacdc91b - 1__clone > frameno: 8 symname: __clone > # 8 0x7ff1dacdc91b - 1__clone > frameno: 9 symname: __clone > # 9 0x7ff1dacdc91b - 1__clone > frameno: 10 symname: __clone > #10 0x7ff1dacdc91b - 1__clone > frameno: 11 symname: __clone > #11 0x7ff1dacdc91b - 1__clone > frameno: 12 symname: __clone > #12 0x7ff1dacdc91b - 1__clone > frameno: 13 symname: __clone > #13 0x7ff1dacdc91b - 1__clone > frameno: 14 symname: __clone > #14 0x7ff1dacdc91b - 1__clone > frameno: 15 symname: __clone > #15 0x7ff1dacdc91b - 1__clone > frameno: 16 symname: __clone > #16 0x7ff1dacdc91b - 1__clone > frameno: 17 symname: __clone > /builddir/elfutils-0.183/tests/backtrace: dwfl_thread_getframes: no > matching address range > /builddir/elfutils-0.183/tests/backtrace: Too many frames: 17 BTW. Here I think another issue is the __clone isn't recognized as terminating (starting?) frame. That might be a bug in musl CFI decorating of the __clone function. It should explicitly mark that function as terminating the call stack. > I have also thought about looping through stack frames until symname is > "raise", since other libcs (and possibly even glibc?) could one day add > a function call inside raise(), which would break this test. What do you > think of that solution? I think that is a better approach. Cheers, Mark
Re: Buildbot failure in Wildebeest Builder on whole buildset
On Fri, 2021-02-12 at 16:58 +0100, Mark Wielaard wrote:
> Hi,
>
> On Tue, Feb 09, 2021 at 10:05:05AM +0100, Mark Wielaard wrote:
> > On Tue, 2021-02-09 at 02:26 +, build...@builder.wildebeest.org
> > wrote:
> > > The Buildbot has detected a failed build on builder whole buildset
> > > while building elfutils.
> > > Full details are available at:
> > > https://builder.wildebeest.org/buildbot/#builders/11/builds/667
> > >
> > > Buildbot URL: https://builder.wildebeest.org/buildbot/
> > >
> > > Worker for this Build: fedora-ppc64le
> > >
> > > Build Reason:
> > > Blamelist: Érico Rolim
> > >
> > > BUILD FAILED: failed test (failure)
> >
> > Well, that is unfortunate. This couldn't really have been caused by
> > your patch. But sadly the run-debuginfod-find.sh seems a little
> > unstable :{ Full details here:
> > https://builder.wildebeest.org/buildbot/#/builders/11/builds/667/steps/8/logs/test-suite_log
> >
> > Still looking at what is going wrong.
>
> Interestingly enough the same test case now succeeded on
> fedora-ppc64le, but failed on debian-i386...
>
> They failed in the same way:
> metric groom{statistic="file d/e"} never changed to 3 on port 9985
>
> Still don't know why though :{
And now debian-i386 and fedora-ppc64 both succeeded, but fedora-s390x
failed! Gah. At least the error is again the same.
[Bug debuginfod/27399] dpkg-deb/lzma error when indexing .debs
https://sourceware.org/bugzilla/show_bug.cgi?id=27399 Sergio Durigan Junior changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Sergio Durigan Junior --- (In reply to Frank Ch. Eigler from comment #1) > Can you check whether dpkg-deb is decompressing all of its content onto some > RAM-backed filesystem, and running out of space via that (or via consuming > machine free ram)? It doesn't seem to be doing that. My /tmp is not mounted > You can try a few things: > > - run debuginfod with a smaller concurrency limit (-c NNN), because the > decompression etc. activities aggressively use all your CPUs and thus > #CPU * memory, if they can For completeness sake, I'm running my tests using a VM with 8GB RAM and access to 10 host CPUs. Having said that, I've tried specifying "-c 4", and it seems to have mitigated the problem. > - instead of 'debuginfod -U' (which uses dpkg-deb as the decompression > streamer), use > % debuginfod -Z.deb="(bsdtar -O -x -f - data.tar.xz)<" > which causes deb files to be processed with libarchive's frontend > (or equivalently, temporarily rename /usr/bin/dpkg-deb while starting > debuginfod, so it makes the same inference) This also seems to work, even without limiting the concurrency. So far, I think it's the best workaround/solution. > - monitor resource usage - particularly ram - during the indexing process I'm monitoring RAM usage, and it's interesting to notice that in the "normal case" (i.e., using "-U" and not limiting concurrency), the usage is pretty much the same as it is when using bsdtar, and it stays well below the limit of the VM. > - try running elfutils 0.183 debuginfod, which does a touch more > filesystem-space monitoring, related self-protection, more > prometheus error metrics Yeah, I'm using elfutils 0.183 here already. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/27399] dpkg-deb/lzma error when indexing .debs
https://sourceware.org/bugzilla/show_bug.cgi?id=27399 --- Comment #4 from Sergio Durigan Junior --- (In reply to Frank Ch. Eigler from comment #2) > Sergio, are the messages you're worried about happening AT THE MOMENT of a > start / stop? Or just intermittently sometime during the normal operating > lifetime of the process? I'm seeing the messages when debuginfod is indexing the files. They don't show up after I leave the service running. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Pull header reading code into libdwP.h
Hi Timm, On Tue, 2021-02-09 at 12:45 +0100, Timm Bäder via Elfutils-devel wrote: > There is quite a bit of code duplication between src/readelf.c and > libdw/dwarf_getsrclines.c when parsing header_length, unit_length, > etc. > > Pull the code out into libdwP.h and use it in both of those files. > > It doesn't save a much code as I'd hoped and I'm not sure about the > naming, but here's the patch. BTW. In these cases I really like having a ChangeLog entry to guide review. I think the struct should be named line_header_state. And the functions __libdw_line_header_state_parse and __libdw_line_header_get_increment to make clear they are internal __libdw functions. I think it would be nicer if __libdw_line_header_state_parse returned a bool (true on success, false on failure) and set any error itself using __libdw_seterrno when returning false. This might give read_srclines a more specific error and the readelf.c code can then add dwarf_errmsg (- 1) to its error message. This changes the readelf case a bit. It used to print the header even if some of the fields (version, address_size, segment_selector_size) weren't supported. It might be good if __libdw_line_header_state_parse would just set the values in the line_state_header and let the caller decide what to do with them. Cheers, Mark
[Bug debuginfod/27399] dpkg-deb/lzma error when indexing .debs
https://sourceware.org/bugzilla/show_bug.cgi?id=27399 --- Comment #5 from Sergio Durigan Junior --- (In reply to Sergio Durigan Junior from comment #3) > (In reply to Frank Ch. Eigler from comment #1) > > Can you check whether dpkg-deb is decompressing all of its content onto some > > RAM-backed filesystem, and running out of space via that (or via consuming > > machine free ram)? > > It doesn't seem to be doing that. My /tmp is not mounted ... using tmpfs. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/27399] dpkg-deb/lzma error when indexing .debs
https://sourceware.org/bugzilla/show_bug.cgi?id=27399 --- Comment #6 from Frank Ch. Eigler --- 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. 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. 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? -- You are receiving this mail because: You are on the CC list for the bug.
