Closed Bug 1130905 Opened 9 years ago Closed 9 years ago

Intermittent test.TestMozInstall.test_get_binary | TypeError: not enough arguments for format string

Categories

(Testing :: Mozbase, defect)

Product:
Testing
Component:
Mozbase
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox36 unaffected, firefox37 fixed, firefox38 fixed, firefox-esr31 unaffected)

Status:
RESOLVED FIXED
Milestone:
mozilla38
Tracking Flags:
Tracking Status
firefox36 --- unaffected
firefox37 --- fixed
firefox38 --- fixed
firefox-esr31 --- unaffected

People

(Reporter: philor, Assigned: whimboo)

References

Details

(Keywords: intermittent-failure, regression)

Attachments

(1 file)

Patch v1
3.47 KB, patch
ahal
: review+
Details | Diff | Splinter Review 
Well, not intermittent, permanent whenever the test fails with either src or ex null, I'd think, but failing that way is intermittent.

https://treeherder.mozilla.org/logviewer.html#?job_id=6393693&repo=mozilla-inbound

TEST-START | test.TestMozInstall.test_get_binary
TEST-UNEXPECTED-ERROR | test.TestMozInstall.test_get_binary | TypeError: not enough arguments for format string
Traceback (most recent call last):
File "/builds/slave/m-in-osx64_g-d-000000000000000/build/testing/mozbase/mozinstall/tests/test.py", line 56, in test_get_binary
installdir = mozinstall.install(self.dmg, self.tempdir)
File "/builds/slave/m-in-osx64_g-d-000000000000000/build/testing/mozbase/mozinstall/mozinstall/mozinstall.py", line 129, in install
error = InstallError('Failed to install "%s (%s)"' % src, str(ex))
TEST-INFO took 1328ms
TEST-START | test.TestMozInstall.test_get_binary_error
TEST-PASS | test.TestMozInstall.test_get_binary_error | took 1ms
TEST-START | test.TestMozInstall.test_install
TEST-UNEXPECTED-ERROR | test.TestMozInstall.test_install | TypeError: not enough arguments for format string
Traceback (most recent call last):
File "/builds/slave/m-in-osx64_g-d-000000000000000/build/testing/mozbase/mozinstall/tests/test.py", line 127, in test_install
installdir = mozinstall.install(self.dmg, self.tempdir)
File "/builds/slave/m-in-osx64_g-d-000000000000000/build/testing/mozbase/mozinstall/mozinstall/mozinstall.py", line 129, in install
error = InstallError('Failed to install "%s (%s)"' % src, str(ex))
TEST-INFO took 1240ms
TEST-START | test.TestMozInstall.test_invalid_source_error
TEST-PASS | test.TestMozInstall.test_invalid_source_error | took 1ms
TEST-START | test.TestMozInstall.test_is_installer
TEST-PASS | test.TestMozInstall.test_is_installer | took 1ms
TEST-START | test.TestMozInstall.test_uninstall
TEST-UNEXPECTED-ERROR | test.TestMozInstall.test_uninstall | TypeError: not enough arguments for format string
Traceback (most recent call last):
File "/builds/slave/m-in-osx64_g-d-000000000000000/build/testing/mozbase/mozinstall/tests/test.py", line 154, in test_uninstall
installdir = mozinstall.install(self.dmg, self.tempdir)
File "/builds/slave/m-in-osx64_g-d-000000000000000/build/testing/mozbase/mozinstall/mozinstall/mozinstall.py", line 129, in install
error = InstallError('Failed to install "%s (%s)"' % src, str(ex))
TEST-INFO took 1210ms
The change to this code came in via the patch as landed on bug 1005856. I don't see how this can be related to src being None, given that it should already fail outside of the try/except in is_installer() and raise a InvalidSource exception. The the only situation here should be that str(ex) is None.

https://dxr.mozilla.org/mozilla-central/source/testing/mozbase/mozinstall/mozinstall/mozinstall.py#109

The only place I can see this exception coming from is _install_dmg():

https://dxr.mozilla.org/mozilla-central/source/testing/mozbase/mozinstall/mozinstall/mozinstall.py#231

But what can lead str(ex) or maybe ex to be None here?
Blocks: 1005856
Hardware: x86 → All
I was able to see the same failure on my OS X box. It's pretty obvious what's failing here. We simply miss an extra pair of brackets around the arguments. Patch upcoming.
Assignee: nobody → hskupin
Status: NEW → ASSIGNED
Keywords: regression
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Whether or not it's a single slave which hits the underlying failure (which is probably the classic "mozinstall bustage"), this is still harness bustage, with an assignee, not a duplicate of the bug about that one slave.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Attached patch Patch v1 — — Splinter Review 
Simple fix with two more side-drive fixes. Patch pushed also to try:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=b127b45ffad4
Attachment #8561495 - Flags: review?(ahalberstadt)
Comment on attachment 8561495 [details] [diff] [review]
Patch v1

Review of attachment 8561495 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks!
Attachment #8561495 - Flags: review?(ahalberstadt) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/b7a61f34185e
Flags: in-testsuite+
Target Milestone: --- → mozilla38
https://hg.mozilla.org/mozilla-central/rev/b7a61f34185e
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
status-firefox38: --- → fixed
Resolution: --- → FIXED
Phil, with this bug fixed do we get some more detailed information about the underlying problem with the affected machine? I kinda would like to know that before I release a new version of mozinstall. Thanks.
Flags: needinfo?(philringnalda)
Thanks Ryan, we got the problem investigated and hopefully permanently fixed. See bug 922783 for details.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: