1049585 - Error summary: Compile error that's visible in TBPL is not visible in Treeherder

Status: RESOLVED DUPLICATE of bug 1040418

(Tree Management :: Treeherder, defect, P1)

Description

[Nicholas Nethercote [inactive]]

Compare these links:
- https://tbpl.mozilla.org/?tree=Try&rev=65c27a0e7b04
- https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=65c27a0e7b04

In TBPL, when I click on the red 'B' for "Android 2.2 Debug", I get the following output in the blue pop-up window:

> /builds/slave/try-and-d-00000000000000000000/build/gfx/thebes/gfxFT2FontList.cpp:634:72: error: no matching function for call to 'PL_DHashTableInit(PLDHashTable*, PLDHashTableOps*, std::nullptr_t, unsigned int, int)'
> make[5]: *** [gfxFT2FontList.o] Error 1
> make[4]: *** [gfx/thebes/target] Error 2
> make[4]: *** Waiting for unfinished jobs....
> make[3]: *** [compile] Error 2
> make[2]: *** [default] Error 2
> make[1]: *** [realbuild] Error 2
> make: *** [build] Error 2

Importantly, the compile error is shown on the first line.

When I do the same thing for Treeherder, in the "Failure summary" window it doesn't show the first line, but does show lines 2 and onwards. But they're not nearly as interesting as the first line.

In contrast, the output for "Windows XP Opt" doesn't have this problem.

----

Also, Treeherder provides suggestion matches for every line. That's not very useful for generic make error lines, and it massively clutters up the "Failure summary" window.

----

Finally, and unrelatedly, I was unable to work out how to cancel all the unfinished jobs for a push.

Comment 1

[Mauro Doglio [:mdoglio]]

You can cancel all jobs for a push clicking on the second button on the result set bar (the one after the pin button) and then on the "Cancel all jobs" menu item. If you want to do it for just a job, there is a "stop" button in the bottom panel, close to the pin button.

Comment 2

[Mauro Doglio [:mdoglio]]

The error you reported is really weird, it will need further investigation. Thanks for noticing that.
The issue in the second observation can be probably fixed while we fix the first one

Comment 3

[Nicholas Nethercote [inactive]]

(In reply to Mauro Doglio [:mdoglio] from comment #1)
> You can cancel all jobs for a push clicking on the second button on the
> result set bar (the one after the pin button) and then on the "Cancel all
> jobs" menu item.

Thanks! I think the reason I didn't find that one is that the icon on that button suggests to me "open in a new tab". And three of the four choices within that button's menu do open something in a new tab. But "Cancel all jobs" doesn't... so it's an odd place for it. Maybe it should have its own button. I can file a new bug about this if you like.

> If you want to do it for just a job, there is a "stop"
> button in the bottom panel, close to the pin button.

I did find that one by myself! :)

Comment 4

[Ed Morley [:emorley]]

(In reply to Nicholas Nethercote [:njn] from comment #3)
> Thanks! I think the reason I didn't find that one is that the icon on that
> button suggests to me "open in a new tab". And three of the four choices
> within that button's menu do open something in a new tab. But "Cancel all
> jobs" doesn't... so it's an odd place for it. Maybe it should have its own
> button. I can file a new bug about this if you like.

I've filed bug 1059279 for improving the icon on that button. Depending on the outcome there, might also be worth splitting "cancel all" to somewhere else, but I'll save that for later.

Re the issue in the bug summary:

The raw log is no longer present on FTP, and I can't retrigger the build since try was reset in the meantime. The log line in comment 0 sadly is the trimmed line that TBPL displays in the blue popup, not the full log line with mozharness error levels and timestamps (which may be what is causing the problem here). 

As such I think we may have to close this as incomplete for now and open a new bug if we see similar in the future. On 17th July a fix landed [1] to the log parser that may have resolved this too (it's possible the fix hadn't been pushed to production before your push was parsed)

[1] https://github.com/mozilla/treeherder-service/commit/0a70cf6bf9b0b1d246f6901d2ce3536445eb7f88

Comment 5

[Ed Morley [:emorley]]

Actually I've just found another issue with the log parser - the regex that would have matched this instance was accidentally in the simple substring search term list, rather than the regex list. This is fixed in bug 1040418 part 3.