Open Bug 1407944 Opened 5 years ago Updated 5 years ago

Some failure modes of llvm-dsymutil don't lead to a build failure

Categories

(Firefox Build System :: General, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

People

(Reporter: glandium, Unassigned)

Details

While working on bug 1381043, I did a test build of firefox using clang 4 with a backport of llvm r313872, and that led to a green build, but XUL completely missing from the crashsymbols archives.

Example:
https://queue.taskcluster.net/v1/task/Ai15DzLmTnawUGc1-AlWiw/runs/0/artifacts/public/build/target.crashreporter-symbols.zip

(beware that try artifacts expire quickly)

We should ensure the build fails if we end up with no symbols for some library.
Can you link the build log here?
(In reply to Mike Hommey [:glandium] from comment #2)
> https://queue.taskcluster.net/v1/task/Ai15DzLmTnawUGc1-AlWiw/runs/0/
> artifacts/public/logs/live_backing.log

This log has:
[task 2017-10-12T02:25:40.333Z] 02:25:40     INFO -  /builds/worker/workspace/build/src/obj-firefox/_virtualenv/bin/python -m mozbuild.action.dumpsymbols /builds/worker/workspace/build/src/obj-firefox/toolkit/library/XUL /builds/worker/workspace/build/src/obj-firefox/toolkit/library/XUL_syms.track
[task 2017-10-12T02:25:40.334Z] 02:25:40     INFO -  Starting Mac pre-processing on file: /builds/worker/workspace/build/src/obj-firefox/toolkit/library/XUL
[task 2017-10-12T02:25:40.334Z] 02:25:40     INFO -  Running Mac pre-processing on file: /builds/worker/workspace/build/src/obj-firefox/toolkit/library/XUL
[task 2017-10-12T02:25:40.334Z] 02:25:40     INFO -  /builds/worker/workspace/build/src/clang/bin/llvm-dsymutil --arch=x86_64 /builds/worker/workspace/build/src/obj-firefox/toolkit/library/XUL

<... lots of warnings from dsymutil ...>

[task 2017-10-12T02:25:44.259Z] 02:25:44     INFO -  Finished processing /builds/worker/workspace/build/src/obj-firefox/toolkit/library/XUL in 127.28s
[task 2017-10-12T02:25:44.260Z] 02:25:44     INFO -  Beginning work for file: /builds/worker/workspace/build/src/obj-firefox/toolkit/library/XUL
[task 2017-10-12T02:25:44.260Z] 02:25:44     INFO -  Processing file: /builds/worker/workspace/build/src/obj-firefox/toolkit/library/XUL
[task 2017-10-12T02:25:44.260Z] 02:25:44     INFO -  /builds/worker/workspace/build/src/obj-firefox/dist/host/bin/dump_syms -a x86_64 -g /builds/worker/workspace/build/src/obj-firefox/toolkit/library/XUL.dSYM /builds/worker/workspace/build/src/obj-firefox/toolkit/library/XUL
[task 2017-10-12T02:25:44.260Z] 02:25:44     INFO -  Finished processing /builds/worker/workspace/build/src/obj-firefox/toolkit/library/XUL in 1.81s

That seems way to short to have done anything useful, for sure.

When we run dump_syms we currently discard stderr:
https://dxr.mozilla.org/mozilla-central/rev/bc7a5be76b723cf6aac1a919156e74997c5f4902/toolkit/crashreporter/tools/symbolstore.py#533

we also seem to just blissfully ignore things if it doesn't generate any output:
https://dxr.mozilla.org/mozilla-central/rev/bc7a5be76b723cf6aac1a919156e74997c5f4902/toolkit/crashreporter/tools/symbolstore.py#602

We should fix the latter to error if dump_syms doesn't produce anything on stdout, and probably also have it write stderr to a `BytesIO` that we could dump in that situation.
For a simple test you could just remove the `stderr=...` bit from that dump_syms invocation and see what errors it produces. It's possible it just doesn't deal with some newer DWARF construct or something like that.
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.