Bug 25252 - dwz: returns exit status 1, causing FTBFS in deal.ii
Summary: dwz: returns exit status 1, causing FTBFS in deal.ii
Status: RESOLVED FIXED
Alias: None
Product: dwz
Classification: Unclassified
Component: default (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-12-06 10:43 UTC by Graham Inggs
Modified: 2021-03-04 09:01 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Graham Inggs 2019-12-06 10:43:42 UTC
As reported in Debian [1], recent changes to dwz cause a failure where it worked previously.

This appears to be a regression in Debian version 0.13-3, which includes PR24764 and PR25024.

I have prepared a testcase [2], around 550MB.


[1] https://bugs.debian.org/946255
[2] https://people.debian.org/~ginggs/dwz-deal.ii-testcase.tar.xz
Comment 1 Tom de Vries 2019-12-06 14:19:40 UTC
This still exits with 0 on dwz-0.13-branch, so presumably 0.13-3 is just some random recent trunk version.

I've bisected this on trunk to commit 48a78ec "Improve handling of running into both low-mem and max die-limits".

The commit makes the first dwz here return 1, which makes thisret 1, which makes ret 1, which gets us an exit status of 1:
...
          thisret = (low_mem_die_limit == 0
                     ? 2
                     : dwz (file, NULL, &resa[i - optind],
                            hardlinks ? resa : NULL, &argv[optind]));
          if (thisret == 2)
            {
              multifile_mode = MULTIFILE_MODE_LOW_MEM;
              thisret = dwz (file, NULL, &resa[i - optind],
                             hardlinks ? resa : NULL, &argv[optind]);
            }
          else if (resa[i - optind].res == 0)
            successcount++;
          else if (thisret == 1)
            ret = 1;
...
Without the commit, the second dwz returns 1, which is ignored, which is a bug, which should be fixed by this patch:
...
diff --git a/dwz.c b/dwz.c
index 313c317..af891ab 100644
--- a/dwz.c
+++ b/dwz.c
@@ -13525,7 +13525,7 @@ main (int argc, char *argv[])
            }
          else if (resa[i - optind].res == 0)
            successcount++;
-         else if (thisret == 1)
+         if (thisret == 1)
            ret = 1;
          if (hardlink
              && resa[i - optind].res >= 0
...

As for the exit status 1, that's currently the expected result when running into the max-die-limit.
Comment 2 Graham Inggs 2019-12-07 08:59:36 UTC
> This still exits with 0 on dwz-0.13-branch, so presumably 0.13-3 is
> just some random recent trunk version.

0.13 + cherry-picks from trunk, I believe. Debian's changelog [1] for reference.

> As for the exit status 1, that's currently the expected result when
> running into the max-die-limit.

Ah, thank you for the explanation.  Passing '-L 100000000' to dwz solves my problem.  Is there any reason I should not do this?  Or should I try to get close to the actual number of DIEs?


[1] https://metadata.ftp-master.debian.org/changelogs/main/d/dwz/unstable_changelog
Comment 3 Tom de Vries 2019-12-07 12:35:32 UTC
(In reply to Graham Inggs from comment #2)
> > This still exits with 0 on dwz-0.13-branch, so presumably 0.13-3 is
> > just some random recent trunk version.
> 
> 0.13 + cherry-picks from trunk, I believe. Debian's changelog [1] for
> reference.
> 

Actually, looking at the source, it's an _exact_ match for a recent trunk.

> > As for the exit status 1, that's currently the expected result when
> > running into the max-die-limit.
> 
> Ah, thank you for the explanation.  Passing '-L 100000000' to dwz solves my
> problem.  Is there any reason I should not do this?  Or should I try to get
> close to the actual number of DIEs?

Dwz has two limits, which are there for execution time/memory usage reasons.

Anything bigger than the max-die-limit (-L) is not optimized. Increasing that limit may make things slower, and consume more memory.

Anything bigger than the low-mem-die-limit (-l) is optimized in a slower and less memory hungry fashion.  Also, anything bigger than that is skipped in the multifile optimization, so the result will be less optimal.

In summary, bump the limits to where they're not hit (on trunk, we have -lnone and -Lnone for that), and if that is not a problem in terms of execution time and memory, you're done. If not, than you can tune the limits to reduce execution time/memory usage to acceptable levels.
Comment 4 Mark Wielaard 2021-02-18 23:55:25 UTC
There seems to have been 2 issues here.

One was the "Too many DIEs, not optimizing" which was solved by adding -L 100000000. The downstream debian bug was closed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946255

The second was the exit code being wrong. Comment #1 has a patch for that. Which doesn't seem to have been applied. But I don't know how to trigger that, so cannot check whether it is still needed.
Comment 5 Tom de Vries 2021-03-02 12:11:44 UTC
(In reply to Mark Wielaard from comment #4)
> There seems to have been 2 issues here.
> 
> One was the "Too many DIEs, not optimizing" which was solved by adding -L
> 100000000. The downstream debian bug was closed:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946255
> 

Ack.

> The second was the exit code being wrong. Comment #1 has a patch for that.
> Which doesn't seem to have been applied. But I don't know how to trigger
> that, so cannot check whether it is still needed.

Should be fixed by https://sourceware.org/pipermail/dwz/2021q1/001027.html