Open Bug 1641940 Opened 5 years ago Updated 5 years ago

Clock on a build log is not sync with the task

Categories

(Toolkit :: Crash Reporting, defect)

defect

Tracking

()

People

(Reporter: calixte, Unassigned)

References

(Blocks 1 open bug, )

Details

Attachments

(1 file)

Attached image image.png

In the log here:
https://firefoxci.taskcluster-artifacts.net/dVoX4Y2gTrOQPckI16U60g/0/public/logs/live_backing.log

search for string Beginning work for file: /builds/worker/workspace/obj-build/toolkit/library/build/libxul.so.
The total time spent for this stuff is 236.58s (see 4 lines after) and the two first columns show that almost no time has been spent here: the five lines are almost stuck on 10:17:26.
I'd expect to see almost 4 minutes between the beginning and the end.

Severity: -- → S4
Priority: -- → P4
Priority: P4 → P5

Forwarding to the component that actually owns this script.

A sys.stderr.flush() at the right moment would probably be in order to make the logs match up to reality here.

Severity: S4 → --
Component: General → Crash Reporting
Priority: P5 → --
Product: Firefox Build System → Toolkit

The severity field is not set for this bug.
:gsvelto, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(gsvelto)
Severity: -- → S4
Flags: needinfo?(gsvelto)

As we think we can save a lot of time, I would like to fix that bug asap to be able to evaluate the savings.

Assignee: nobody → sledru

Ricky, I tried to flush stderr in a bunch of places
https://hg.mozilla.org/try/rev/b27fed0a650c3ed65bab3db2a002844384907d50
https://hg.mozilla.org/try/rev/64e0fb458562cde1388b0a7ce059fc9069f7ee0e
https://hg.mozilla.org/try/rev/3d8541bb26568f8811a4b65255b3c6ec64f359b4
but no impact

https://treeherder.mozilla.org/#/jobs?repo=try&revision=fa0263d38f8c9cb6eca926bfaa00bd07db67edd8
[task 2020-06-25T09:56:02.131Z] 09:56:02     INFO -  /builds/worker/workspace/obj-build/_virtualenvs/init_py3/bin/python -m mozbuild.action.dumpsymbols /builds/worker/workspace/obj-build/toolkit/library/gtest/libxul.so /builds/worker/workspace/obj-build/toolkit/library/gtest/libxul.so_syms.track
[task 2020-06-25T09:56:02.131Z] 09:56:02     INFO -  Running: /builds/worker/workspace/obj-build/_virtualenvs/init_py3/bin/python /builds/worker/checkouts/gecko/toolkit/crashreporter/tools/symbolstore.py -c --vcs-info --install-manifest=/builds/worker/workspace/obj-build/_build_manifests/install/dist_include,/builds/worker/workspace/obj-build/dist/include -s /builds/worker/checkouts/gecko /builds/worker/workspace/obj-build/dist/host/bin/dump_syms /builds/worker/workspace/obj-build/dist/crashreporter-symbols /builds/worker/workspace/obj-build/toolkit/library/gtest/libxul.so
[task 2020-06-25T09:56:02.131Z] 09:56:02     INFO -  Beginning work for file: /builds/worker/workspace/obj-build/toolkit/library/gtest/libxul.so
[task 2020-06-25T09:56:02.132Z] 09:56:02     INFO -  Processing file: /builds/worker/workspace/obj-build/toolkit/library/gtest/libxul.so
[task 2020-06-25T09:56:02.132Z] 09:56:02     INFO -  /builds/worker/workspace/obj-build/dist/host/bin/dump_syms /builds/worker/workspace/obj-build/toolkit/library/gtest/libxul.so
[task 2020-06-25T09:56:02.132Z] 09:56:02     INFO -  Finished processing /builds/worker/workspace/obj-build/toolkit/library/gtest/libxul.so in 287.80s
[task 2020-06-25T09:56:02.132Z] 09:56:02     INFO -  make[4]: Leaving directory '/builds/worker/workspace/obj-build/toolkit/library/gtest'

any idea? merci!

Flags: needinfo?(Erich.Iseli)
Flags: needinfo?(Erich.Iseli) → needinfo?(rstewart)

on riot, Mike said:

like completely mixed output, with, in the worst case, lines from one process interrupting lines from another
the only viable alternative is --output-sync=line, which doesn't do what you'd think it does
it syncs per command line, as opposed to per output line
so when you have one target with multiple commands, it syncs each of them independently
but if one of them prints something, waits 10s and prints something else, both prints will appear at the end
the lesson is: don't rely on timestamps
they're a vague indicator
the only reliable thing they can tell you is when a command finishes
that said, with --output-sync=line, there's Entering directory and Leaving directory messages around each line, which is confusing, but those would actually have the right timestamps

Looks like my NI can be cleared since mike got to it?

Flags: needinfo?(rstewart)

No clue how to fix that

Assignee: sledru → nobody
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: