478761 - CompareLeakLogs.createSummary crashed

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[Axel Hecht [:Pike]]

For whatever reason, a build didn't generate a leak log, and the CompareLeakLogs step crashed on createSummary.

It shouldn't be as picky, and probably report that as a an for via result and TinderboxPrint::

Comment 1

[[e-mail] (:bhearsum)]

Can you provide more specifics? This sounds like bug 465505, but that was fixed before this was filed..so I'm not sure.

Comment 2

[Axel Hecht [:Pike]]

Seems like it tries to generate a summary for the failed step, and throws again.

Comment 3

[Chris AtLee [:catlee]]

E.g. http://production-master.build.mozilla.org:8010/builders/OS%20X%2010.5.2%20mozilla-1.9.1%20leak%20test%20build/builds/1377

Comment 4

[[e-mail] (:bhearsum)]

OK, that helps a lot.

Comment 5

[[e-mail] (:bhearsum)]

Attachment: always make sure leakStats['new'] members are set

I think this will do the trick...

Comment 6

[Chris AtLee [:catlee]]

Comment on attachment 363128 [details] [diff] [review]
always make sure leakStats['new'] members are set

putting 'continue' in those else: blocks will prevent the following regexps from being checked.

How about you fill out all the default values when leakStats[resultSet] is created, and then if they're not set when looking through the log, then the defaults will show up.

Also, does formatBytes handle 'ERR'?

Comment 7

[[e-mail] (:bhearsum)]

Attachment: bail early if we can't parse leakstats output

Here's a more minimalistic, and working approaching.

Comment 8

[[e-mail] (:bhearsum)]

Comment on attachment 363140 [details] [diff] [review]
bail early if we can't parse leakstats output

changeset:   197:ca9f7b4fecc2

Comment 9

[[e-mail] (:bhearsum)]

Master reconfig'ed for this.