Closed Bug 613516 (greenpocalypse) Opened 14 years ago Closed 14 years ago

xpcshell dump doesn't print newlines

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
blocker

Tracking

()

RESOLVED FIXED
mozilla2.0b8
Tracking Status
blocking2.0 --- beta8+

People

(Reporter: benjamin, Assigned: igor)

References

Details

(Keywords: dogfood, regression)

Attachments

(2 files)

dump("\n") in xpcshell used to print newlines to stdout. Now it prints "\n". This is a regression from bug 607695 and is an unwanted change in behavior because it makes reading xpcshell test output really hard.

jorendorff says we're using JS_FileEscapedString but really shouldn't.
blocking2.0: --- → beta9+
Keywords: regression
This is making it really hard to work on testcases for blockers
Keywords: dogfood
Attached patch v1Splinter Review
Comment on attachment 492054 [details] [diff] [review]
v1

The patch restore dump to print the string with no escapes.
Attachment #492054 - Attachment description: vq → v1
Attachment #492054 - Flags: review?(jorendorff)
Attachment #492054 - Flags: review?(jorendorff) → review+
Can we land this asap?  It's really annoying when it bites.
http://hg.mozilla.org/mozilla-central/rev/650ad3cd7e52
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
I backed this out because of the xpcshell test orange:

http://hg.mozilla.org/mozilla-central/rev/e96da44dcae1

Sample log:

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1291069330.1291071106.6580.gz
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
That's actually one of two failures, there's also http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1291070111.1291071714.9376.gz on Mac debug which is also failing on TraceMonkey, unlike the other which is apparently some not-yet-merged dependency.
(In reply to comment #7)
> I backed this out because of the xpcshell test orange:
Just to be sure, this isn't a case of tinderbox print now actually catching something that was orange before, right?
(In reply to comment #9)
> (In reply to comment #7)
> > I backed this out because of the xpcshell test orange:
> Just to be sure, this isn't a case of tinderbox print now actually catching
> something that was orange before, right?

Might be. The failure in Phil's log should have been failing since it landed.
http://mxr.mozilla.org/mozilla-central/source/netwerk/test/unit/test_bug468426.js#64

> do_timeout(1, "triggerNextTest();");

should just be

> do_timeout(1, triggerNextTest);
I've closed the tree.  We need to fix any xpcshell orange from this landing again as it looks like it is actually failure being caught by tinderbox now that all output from dump is not on one line.  That means the tree stays closed until these oranges are resolved.  Paul thinks he has a fix for the only issue that we saw last time (comment 10), and he's going to land that and this patch again.

Is it possible for us to get a test for this?
Given recent information, I think this actually needs to block beta 8.
blocking2.0: beta9+ → beta8+
Bumping the priority to blocker, as this has caused us to keep mozilla-central closed.
Severity: normal → blocker
Attached patch Bustage fixSplinter Review
this in combination with relanding the patch for this bug passes xpcshell tests for me (linux 64 debug).

Also, it seems that the broken dump has caused us to not have any orange xpcshell test on tinderbox (except for crashes, timeouts).
Landed:

http://hg.mozilla.org/mozilla-central/rev/9231797ba106
http://hg.mozilla.org/mozilla-central/rev/d1fe3a682617

Will keep the tree closed until we get green runs after this.
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Depends on: 615454
Blocks: 468426
Target Milestone: --- → mozilla2.0b8
Version: unspecified → Trunk
Alias: greenpocalypse
Blocks: 616295
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: