Mike Hommey [:glandium] Reporter
	Description • 7 years ago

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.

	(not currently active) Ted Mielczarek
	Comment 1 • 7 years ago

Can you link the build log here?

	Mike Hommey [:glandium] Reporter
	Comment 2 • 7 years ago

https://queue.taskcluster.net/v1/task/Ai15DzLmTnawUGc1-AlWiw/runs/0/artifacts/public/logs/live_backing.log

	Mike Hommey [:glandium] Reporter
	Comment 3 • 7 years ago

Note that this is a build with clang trunk, with similarly verbose dsymutil output:
https://public-artifacts.taskcluster.net/bkh7_XJIRUilmTkjfSQA0w/0/public/logs/live_backing.log

... but where we do get XUL symbols
https://public-artifacts.taskcluster.net/bkh7_XJIRUilmTkjfSQA0w/0/public/build/target.crashreporter-symbols.zip

	(not currently active) Ted Mielczarek
	Comment 4 • 7 years ago

(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.

	(not currently active) Ted Mielczarek
	Comment 5 • 7 years ago

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.