Closed
Bug 650646
Opened 14 years ago
Closed 14 years ago
Full error stack messages in frame are not exposed anymore due to non-enumerable Error properties
Categories
(Testing Graveyard :: Mozmill, defect)
Testing Graveyard
Mozmill
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: aaronmt, Assigned: harth)
References
Details
(Keywords: regression, Whiteboard: [mozmill-2.0+][mozmill-next?][mozmill-1.5.4+])
Attachments
(1 file)
837 bytes,
patch
|
cmtalbert
:
review+
|
Details | Diff | Splinter Review |
In debugging a test this morning, I noticed that my install of Mozmill 1.5.3 was not exposing fully detailed errors (regardless of type of issue) to console and regardless of the flags --show-errors and --show-all, no line numbers of issue, etc.
Output: ERROR | Test Failure: {"exception": {}}
I did a full cleanup and install of Mozmill 1.5.3
This commit looks suspicious
https://github.com/mozautomation/mozmill/commit/924ae27401c0bdf70b68b75671be2a7951f81840 -- did this land in 1.5.3?
Reporter | ||
Updated•14 years ago
|
Summary: Full error stack messages in frame are not exposed anymore → Full error stack messages in frame are not exposed anymore (1.5.3)
Reporter | ||
Comment 1•14 years ago
|
||
For what it's worth, after a clean 1.5.3 install, in my /Library/Python/2.6/site-packages/mozmill/extension/resource directory containing 1.5.3, I have a frame.js.orig and frame.js.rej reject file
Comment 2•14 years ago
|
||
Sounds to be the same as bug 627422.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 3•14 years ago
|
||
Not entirely sure, but I can reproduce by simply changing failing any assert or creating a typo in a function call, not be changing interface names.
Comment 4•14 years ago
|
||
Can you give a testcase please?
Reporter | ||
Comment 5•14 years ago
|
||
Example:
http://hg.mozilla.org/qa/mozmill-tests/file/cfa98c5dffdf/tests/functional/testTabbedBrowsing/testNewTab.js#l89
Change to '!='
mozmill -t tests/functional/testTabbedBrowsing/testNewTab.js -b ~/Downloads/Nightly.app/ --show-errors
TEST-START | /Users/AaronMT/Downloads/mozmill-tests/tests/functional/testTabbedBrowsing/testNewTab.js | setupModule
TEST-PASS | /Users/AaronMT/Downloads/mozmill-tests/tests/functional/testTabbedBrowsing/testNewTab.js | setupModule
TEST-START | /Users/AaronMT/Downloads/mozmill-tests/tests/functional/testTabbedBrowsing/testNewTab.js | testNewTab
ERROR | Test Failure: {"exception": {}}
TEST-UNEXPECTED-FAIL | /Users/AaronMT/Downloads/mozmill-tests/tests/functional/testTabbedBrowsing/testNewTab.js | testNewTab
INFO Passed: 1
INFO Failed: 1
INFO Skipped: 0
Reporter | ||
Comment 6•14 years ago
|
||
Guess it's something with my install somewhere on Mac. I cleanly tested on Ubuntu and I can't reproduce.
I'll post back if I find out what it is.
Reporter | ||
Comment 7•14 years ago
|
||
Note: Am able to reproduce as well in a virtualenv in Mac
Comment 8•14 years ago
|
||
Works fine for me. I would assume your Mozmill installation is broken. Some global installed files probably cause this behavior. Everything looks fine for me on OS X with 1.5.3.
Resolution: DUPLICATE → INVALID
Reporter | ||
Comment 9•14 years ago
|
||
yolk -l output under a virtualenv with --no-site-packages
(ENV)AaronMT@Aaron-Trains-MacBook-Pro~/Desktop/ENV: yolk -l
ManifestDestiny - 0.2.2 - active
Python - 2.6.1 - active development (/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload)
jsbridge - 2.4.3 - active
mozmill - 1.5.3 - active
mozrunner - 2.5.4 - active
pip - 1.0 - active
setuptools - 0.6c11 - active
wsgiref - 0.1.2 - active development (/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6)
yolk - 0.4.1 - active
Comment 10•14 years ago
|
||
I can reproduce this 100% in the latest nightly and mozmill master. I'm getting an empty 'Exception' no matter what error happens in the test.
The odd thing is that it works normally in Fx 3.6 but fails in the latest nightly. I'll try to find a better regression range in Firefox.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Comment 11•14 years ago
|
||
So this also works fine in fx4 and the latest Aurora. It looks like something landed in the nightlies around the 16th that caused this bustage.
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: [mozmill-2.0?][mozmill-next?]
Version: unspecified → Trunk
Comment 12•14 years ago
|
||
We got the regression range down to the nightly. The last working nightly was on the 13th. Started breaking on the 14th.
Changesets:
6bcaec19d09e - aa200a803e07
Comment 13•14 years ago
|
||
The offending changeset: http://hg.mozilla.org/mozilla-central/rev/9743d95d473e
Comment 14•14 years ago
|
||
(In reply to comment #10)
> I can reproduce this 100% in the latest nightly and mozmill master. I'm
> getting an empty 'Exception' no matter what error happens in the test.
Just as note, Aaron was testing with Mozmill 1.5.3 and not Mozmill 2.0. Whatever happened with his setup could it have mixed files from both versions? It's pretty unclear for the hotfix-1.5 state.
Comment 15•14 years ago
|
||
(In reply to comment #13)
> The offending changeset: http://hg.mozilla.org/mozilla-central/rev/9743d95d473e
As this changeset tells me this is really an issue on master only and not hotfix-1.5.
Aaron, can you really make sure that you have had mozmill 1.5.3 running and no 2.0 build?
Reporter | ||
Comment 16•14 years ago
|
||
(In reply to comment #15)
> (In reply to comment #13)
> > The offending changeset: http://hg.mozilla.org/mozilla-central/rev/9743d95d473e
>
> As this changeset tells me this is really an issue on master only and not
> hotfix-1.5.
>
> Aaron, can you really make sure that you have had mozmill 1.5.3 running and no
> 2.0 build?
I do not have master anywhere. In comment #9, I isolated mozmill into virtualenv with --no-site-packages, I have completely cleared all egg's and related files in /Library/Python/2.6/site-packages/, I dont know where else there could be anything.
Comment 17•14 years ago
|
||
Do we definitely have two different issues here and I think we should not use this bug for the regression we have on master. Andrew, can you please file a new bug? Thanks.
Comment 18•14 years ago
|
||
(In reply to comment #15)
> (In reply to comment #13)
> > The offending changeset: http://hg.mozilla.org/mozilla-central/rev/9743d95d473e
>
> As this changeset tells me this is really an issue on master only and not
> hotfix-1.5.
How does it tell you that? This is a firefox changeset.. not a mozmill one..
This should be an issue on all versions of Mozmill.. it's an intentional change in Firefox that's causing this. Basically Errors aren't allowed to be enumerable in Firefox anymore.
We'll have to fix on master and probably backport to 1.5 as well.
Comment 19•14 years ago
|
||
(In reply to comment #18)
> > As this changeset tells me this is really an issue on master only and not
> > hotfix-1.5.
>
> How does it tell you that? This is a firefox changeset.. not a mozmill one..
>
> This should be an issue on all versions of Mozmill.. it's an intentional change
> in Firefox that's causing this. Basically Errors aren't allowed to be
> enumerable in Firefox anymore.
Our daily tests are running fine for any 6.0 build. Same locally. IMO this failure comes from subclassing the Error class which we only have on 2.0.
Comment 20•14 years ago
|
||
(In reply to comment #19)
> Our daily tests are running fine for any 6.0 build. Same locally. IMO this
> failure comes from subclassing the Error class which we only have on 2.0.
I think you don't get the point of this bug... it's not that something is causing a failure.. it's that *if* there is a failure no information is getting dumped out. Try modifying one of your tests to have a syntax error, you'll see an empty exception instead of a stack trace.
Comment 21•14 years ago
|
||
Also when I say dumped out I don't mean in reporting, I mean in the terminal.
Comment 22•14 years ago
|
||
Oh wait. Looks like when I have tested it the last time I had an outdated Nighly build which didn't contain this change. So while testing it again, I can also see this behavior. Sorry for the noise.
So this is kinda important now and would also block us from investigation failures like what we have on bug 652799. We should try to get out 1.5.4 as soon as we can.
Blocks: 652799
Status: REOPENED → NEW
Whiteboard: [mozmill-2.0?][mozmill-next?] → [mozmill-2.0?][mozmill-next?][mozmill-1.5.4?]
Whiteboard: [mozmill-2.0?][mozmill-next?][mozmill-1.5.4?] → [mozmill-2.0+][mozmill-next?][mozmill-1.5.4+]
Assignee | ||
Updated•14 years ago
|
Assignee: nobody → fayearthur+bugs
Reporter | ||
Comment 23•14 years ago
|
||
Heather, were you able to look into this? It seems like there's a bunch of things relying on a hotfix 1.5.4 at the moment
Assignee | ||
Comment 24•14 years ago
|
||
Probably not until next week.
Assignee | ||
Comment 25•14 years ago
|
||
What we decided on though was creating a MozmillError class that inherits from Error and makes 'message', 'stack', etc. enumerable again.
Comment 26•14 years ago
|
||
(In reply to comment #24)
> Probably not until next week.
Clint, any change to get someone else working on it? We are blocked on getting our broken tests we currently have for Firefox 6 fixed.
Comment 27•14 years ago
|
||
(In reply to comment #26)
> (In reply to comment #24)
> > Probably not until next week.
>
> Clint, any change to get someone else working on it? We are blocked on getting
> our broken tests we currently have for Firefox 6 fixed.
Jhammel is sick, Harth's out the rest of the week. And that leaves either you (who is traveling) or me. If I can get to it this week I will. It's on the list.
Comment 28•14 years ago
|
||
Ok, so I will be back later today. If you have time it would be really appreciated. Otherwise I will help out later today - even when I will be totally tired.
Severity: normal → major
Comment 29•14 years ago
|
||
We are getting more and more test failures on trunk which we can't investigate due to this problem.
Heather, can you please give us an ETA when this issue will be fixed? We really need this fix ASAP.
Severity: major → critical
Assignee | ||
Comment 30•14 years ago
|
||
Okay, I tried making a new MozmillError class inheriting from Error, but I couldn't figure out how to make it not report the fileName/lineNumber as errors.js:4 (where I defined the MozmillError class and assigned the prototype to new Error()).
I ran through a lot of possibilities, but came to the conclusion that the best way to approach this is really to just check for Errors right before they're reported. This is an easy, one-place fix. Might be hacky, but errors will be reported from the mozmill file they were thrown from.
Attachment #531850 -
Flags: review?(ctalbert)
Comment 31•14 years ago
|
||
Comment on attachment 531850 [details] [diff] [review]
reattach exception properties before reporting
Awesome Harth! This works great, tested on Master. Can I get a patch for 1.5 as well?
Attachment #531850 -
Flags: review?(ctalbert) → review+
Assignee | ||
Comment 32•14 years ago
|
||
master:
https://github.com/mozautomation/mozmill/commit/198251db6273e5ec0d4b6dbd425c0519a9ab98ac
hotfix-1.5:
https://github.com/mozautomation/mozmill/commit/a139b30524b271510b9a6e523975de33e52f9614
Status: NEW → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Updated•14 years ago
|
Blocks: 637207
Summary: Full error stack messages in frame are not exposed anymore (1.5.3) → Full error stack messages in frame are not exposed anymore due to non-enumerable Error properties
Reporter | ||
Comment 33•14 years ago
|
||
Verified fixed with 1.5.4pre
Thanks Heather
Status: RESOLVED → VERIFIED
Comment 34•14 years ago
|
||
I think this needs to be back-ported to 1.4.2b1 because this is used on the try servers/builds of Thunderbird. See e.g. http://tinderbox.mozilla.org/showlog.cgi?log=ThunderbirdTry/1305741961.1305742742.23061.gz&fulltext=1
I patched my local installation of mozmill and it worked as expected.
(And then the update has to be installed on them, at least if they use mozilla-central)
Comment 35•14 years ago
|
||
Standard9 said on IRC that Thunderbird (tryservers) will be updated to mozmill 1.5 series, probably within the next two weeks. So I guess the backport is not necessary.
Comment 36•14 years ago
|
||
Ok cool.
Updated•8 years ago
|
Product: Testing → Testing Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•