Closed Bug 661343 Opened 13 years ago Closed 12 years ago

dump() doesnt seem to work anymore in mozmill.js

Categories

(Testing Graveyard :: Mozmill, defect)

Product:
Testing Graveyard
Component:
Mozmill
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: k0scist, Assigned: cmtalbert)

Details

(Whiteboard: [mozmill-2.0+])

Attachments

(3 files)

console output
8.70 KB, text/plain
Details
Fix v1
1.22 KB, patch
k0scist
: review+
whimboo
: feedback+
Details | Diff | Splinter Review
Upgrade to Mozrunner 5.4
367 bytes, text/html
whimboo
: review+
Details 
>>> This is for mozmill 2.0. It may also apply to older versions of
    mozmill. I Haven't tested yet.  Its probably actually an issue
    with nightly, as to my knowledge nothing in the mozmill codebase
    actually changed.

a bit ago (last week?) dump() statements in mozmill.js were
respected. That is, output went to the terminal.  Now, they seem to
vanish into the ether.  This is true with or without --debug on my
system.

As per https://developer.mozilla.org/en/DOM/window.dump , I have even
set the appropriate preference to no effect.  Note that previously I
did not have to do this

This is pretty important to me as I really need a way to have JS print
things as part of development.
OS: All → Linux
Hardware: All → x86
Does it work for you with 1.5.4b?
As said, I haven't tested in older versions.  I eventually will assuming the source of the problem does not assert itself in the interim
(In reply to comment #2)
> As said, I haven't tested in older versions.  I eventually will assuming the
> source of the problem does not assert itself in the interim

Have you tried other versions of Firefox too?
Not yet.
Same problem with Thunderbird:

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110601 Thunderbird/7.0a1

easy_install http://pypi.python.org/packages/source/j/jsbridge/jsbridge-2.3.7b1.tar.gz
easy_install http://pypi.python.org/packages/source/m/mozmill/mozmill-1.4.2b1.tar.gz
easy_install http://pypi.python.org/packages/source/m/mozrunner/mozrunner-2.5.2.tar.gz
Looks like a change in Gecko. Do we know what's the first version on 7.0 which shows this issue? A link to the pushlog would be great.
I am not sure if this is related, but exception messages are not shown on the console or the try server (comm-central) for Thunderbird anymore. I was told on IRC that they should show up. So this might be related to the dump bug.

Just some observations:
On Thunderbird comm-miramar tryserver it seems to work:
http://tinderbox.mozilla.org/showlog.cgi?log=Miramar/1306994684.1306997435.27483.gz&fulltext=1

On Thunderbird comm-aurora it might not work:
(2011/06/02)  http://tinderbox.mozilla.org/showlog.cgi?log=Thunderbird-Aurora/1306998755.1307000870.5981.gz&fulltext=1#err0
But here is much more output:
(2011/05/19) http://tinderbox.mozilla.org/showlog.cgi?log=Thunderbird-Aurora/1305843917.1305845835.8896.gz&fulltext=1

On Thunderbird try it seemed to work until about 2011/05/16 but started to not work correctly on 2011/05/18:
(2011/05/16) http://tinderbox.mozilla.org/showlog.cgi?log=ThunderbirdTry/1305580953.1305581742.3481.gz&fulltext=1#err0
(2011/05/18) http://tinderbox.mozilla.org/showlog.cgi?log=ThunderbirdTry/1305741961.1305742742.23061.gz&fulltext=1

Hope this helps somehow.
No, the exception issue has been fixed already on bug 650646 for Mozmill 1.5.4.

Please concentrate on the dump issue only. Thanks.
(In reply to comment #3)
> (In reply to comment #2)
> > As said, I haven't tested in older versions.  I eventually will assuming the
> > source of the problem does not assert itself in the interim
> 
> Have you tried other versions of Firefox too?

Tried with Firefox 4.0.1 last night.  It seems to have the same issue, ABICT
Jeff, can you please quickly check with 1.5.4b3? If it doesn't happen there we should search for the regression range on the master branch.
It turns out to be a red herring, but this doesn't help any:

https://github.com/mozautomation/mozmill/blob/master/mozmill/patches/httpd.patch
I have seen the same lately. After talking to Clint he mentioned to me that I should use the log method instead. That one is working perfectly fine and I wouldn't care about dump anymore.
So I can't get log() nor dump() to work with latest master. log() is reported to be not defined by the Error Console and dump() doesn't print anything to the console. We have to fix this ASAP otherwise I'm not able to debug any of the follow-up code we have to work on.
Severity: normal → critical
OS: Linux → All
Hardware: x86 → All
Whiteboard: [mozmill-2.0?]
Jeff would you have a chance to dig into this this week?
Whiteboard: [mozmill-2.0?] → [mozmill-2.0+]
I'll try to dig into this later this week, though probably Weds at the earliest.  Historically (though I'm unsure of the status of this bug) dumping problems have often been OS-specific, but I'll see what is up with linux anyway.  

Just to confirm, this is an issue on master?
Yes, master. But good pointer Jeff. Probably my comment 12 was for hotfix-2.0. I will check this tomorrow. Probably it can give us already the necessary information and I could check this already tomorrow.
Attached file console output — 
This is absolutely strange. Sometimes the output with dump() works and sometimes not. It's really unpredictable. I'm always using the same command line options.

Two things we have to fix though:
* Should be bind that output to DEBUG level only? In such a case we could leave those lines enabled and do not have to comment them out in the code
* We absolutely have to write the message immediately to the console and not at the end of the test!! The current behavior doesn't let me do any debugging in my code.
Jeff, would you be able to work on it this week, so that we are unblocked for all the upcoming Mozmill 2 work next week?
I will endeavor to do this this week.  We need a test for it.  Currently, python tests are broken.  See https://bugzilla.mozilla.org/show_bug.cgi?id=754443 . I would like to get our current tests working and runnable so that we have a sane baseline here.
I am looking at this but am currently having trouble getting mozmill working at all do to (presumedly) bug 696468 :( So while this is my top mozmill priority, it may be delayed
Jeff, does it only happen with Mutt or also when calling mozmill directly?
So I haven't tested mozmill.js but I can dump from a test file.
Likewise, I can dump from mozmill.js.  Maybe I'm missing something from this bug, but this seems to work for me with modern mozmill + mozprocess?  This is on linux

Henrik, can you describe what you're doing that doesn't work for you?  A test case would be even better.
Sounds like it could be OS X related then? I just call dump() e.g. the commented out lines in mozmill.js for the window events. Sometimes I see output but other times not. Also all output is added when the test has been finished and not immediately. If you want to have two separate bugs for it feel free to file a new one. I will not be able to until Monday.
Attached patch Fix v1 — — Splinter Review 
So, the issue here was that we were not asking mozprocess to read the output stream. We need to do that.  So I make a thread and query that process, which causes it to stream the output to stdout while the test is running.
Assignee: nobody → ctalbert
Status: NEW → ASSIGNED
Attachment #625622 - Flags: review?(jhammel)
Comment on attachment 625622 [details] [diff] [review]
Fix v1

Seems a bit magical, like everything in mozprocess, but if that's what we got to do
Attachment #625622 - Flags: review?(jhammel) → review+
Comment on attachment 625622 [details] [diff] [review]
Fix v1

>diff --git a/mozrunner/mozrunner/runner.py b/mozrunner/mozrunner/runner.py
>+    def __init__(self, prochandler):
>+        super(OutputThread, self).__init__()
>+        self.ph = prochandler

Instead of using super it will be more obvious to call the __init__ method of the Thread class directly:

Thread.__init__(self)

Otherwise great catch and I can't await to see it in.
Attachment #625622 - Flags: review?(jhammel)
Attachment #625622 - Flags: review+
Attachment #625622 - Flags: feedback+
Comment on attachment 625622 [details] [diff] [review]
Fix v1

wfm
Attachment #625622 - Flags: review?(jhammel) → review+
Fixed in mozbase! https://github.com/mozilla/mozbase/commit/ac0b07d3b47ed4ae51c40f4946336a7b736dbc7f
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
While this is fixed in mozbase we have to come up with a patch for Mozmill which then bumps the mozrunner version to 5.4. I will come up with a fix in a minute.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Pointer to Github pull-request
Attachment #625646 - Attachment description: Pointer to Github pull request: https://github.com/mozautomation/mozmill/pull/34# → Upgrade to Mozrunner 5.4
Attachment #625646 - Flags: review?(ctalbert)
Comment on attachment 625646 [details]
Upgrade to Mozrunner 5.4

Got the review over on Github. Landed as:
https://github.com/mozautomation/mozmill/commit/982b367119a69b1b33eee55df49da1b1417fc5b3
Attachment #625646 - Flags: review?(ctalbert) → review+
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Product: Testing → Testing Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: