85085 2012-04-27 11:18:58 -0700 [chromium] svg/custom/clip-path-referencing-use2.svg fails in "drt mode" in DRT 2013-04-09 17:06:06 -0700 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) Unspecified Unspecified RESOLVED WONTFIX P2 Normal --- 1 dpranke webkit-unassigned dglazkov eric pdr schenney tkent tony oldest_to_newest 611710 0 dpranke 2012-04-27 11:18:58 -0700 For some reason, we get different output in --test-shell mode and non-test-shell (aka drt) mode in DumpRenderTree (on Linux and Mac, at least; haven't tried win yet). Specifically, when run without the --test-shell flag, we don't get "CONSOLE MESSAGE: line 1: Error: Not allowed to use indirect reference in <clip-path>". I know nothing about SVG , clip-path, or indirect references, so I have no idea if this is a bug, or a bug fix. I have confirmed that the code path doesn't even execute in DRT mode, so this isn't some sort of logging/console diff. Anyone have any ideas? My only guess is that it has something to do with --test-shell mode getting the test as a file:/// URL and drt mode getting the test as a path, and that somehow triggering different behavior. 611741 1 eric 2012-04-27 11:49:03 -0700 I suspect this is a bug about our handling of stderr output in one or the other modes. 611745 2 dpranke 2012-04-27 11:50:40 -0700 (In reply to comment #1) > I suspect this is a bug about our handling of stderr output in one or the other modes. I don't think so;I actually instrumented the code and that code path flat out isn't being executed in drt mode. 611748 3 eric 2012-04-27 11:51:35 -0700 Do we have logging configured differently for one or the other? (WebCore logging I mean). Do we know where this message comes from? (Could you post the trac link?) 611753 4 dpranke 2012-04-27 11:53:18 -0700 http://trac.webkit.org/browser/trunk/Source/WebCore/svg/SVGUseElement.cpp#L562 611754 5 dpranke 2012-04-27 11:53:39 -0700 I don't believe the logging is being configured any differently. 611759 6 pdr 2012-04-27 11:55:59 -0700 (In reply to comment #3) > Do we have logging configured differently for one or the other? (WebCore logging I mean). Do we know where this message comes from? (Could you post the trac link?) The error comes from http://trac.webkit.org/browser/trunk/Source/WebCore/svg/SVGUseElement.cpp#L562 and is a legitimate error to be thrown. I wonder if this is the only case in SVG where we're throwing errors at a specific time, or whether it's just the logging level/configuration as Eric pointed out. 611761 7 eric 2012-04-27 11:56:45 -0700 I wonder if the ChromeClients are configured differently for Chrome DRT in DRT mode vs. TS mode. 611763 8 dpranke 2012-04-27 11:58:18 -0700 Either I'm missing something, or I'm not making myself clear here ... that line of code is not being executed. In fact, IIRC, that whole function isn't executing. How could loging being configured differently affect that? 611767 9 pdr 2012-04-27 12:06:08 -0700 (In reply to comment #8) > Either I'm missing something, or I'm not making myself clear here ... > > that line of code is not being executed. In fact, IIRC, that whole function isn't executing. > > How could loging being configured differently affect that? (In reply to comment #8) > Either I'm missing something, or I'm not making myself clear here ... > > that line of code is not being executed. In fact, IIRC, that whole function isn't executing. > > How could loging being configured differently affect that? I misunderstood that the function wasn't running at all, and now I'm confused as well. 611785 10 dpranke 2012-04-27 12:40:47 -0700 Okay, maybe I was stoned when I was debugging this last night :( It looks like the code is executing, and for some reason the message isn't getting logged, as you suggested. I will try and figure out what's going on. 611818 11 dpranke 2012-04-27 13:13:16 -0700 Okay, I figured it out ... that line of code is getting executed. Although I'm sure it wasn't the other night when I was first testing this, I have no explanation for what I was doing then; probably running the wrong test or something :( At any rate, this ends up working its way around into WebCore::Console where we call client()->addMessageToConsole(). For whatever reason, that ends up printing the message *after* we've dumped the renderTree. in "drt mode", that means that it shows up after the #EOF signifying the end of the text input (and before the pixel input), so we drop the string on the floor. "test shell mode" is not so lenient, and we get the string included in stdout. I'm not sure where to go from here. One answer would be to just rebaseline the text and call it a day, but it kinda seems like a bug in DRT that this error message is getting dropped. Thoughts? 611852 12 eric 2012-04-27 13:35:39 -0700 We've had this type of bug in DRT for a very long time. DRT instances have to work hard to make sure they don't print anything after the #EOF. I suspect we'll need to make some adjustments to Chromium's DRT to make sure it's not leaking stderr like this. I thought we used to have asserts/error messages in NRWT to catch this kind of "dropped a log on the floor" problem? In ORWT those logs used to end up in the next test output. :) 611858 13 dpranke 2012-04-27 13:42:11 -0700 (In reply to comment #12) > We've had this type of bug in DRT for a very long time. DRT instances have to work hard to make sure they don't print anything after the #EOF. I suspect we'll need to make some adjustments to Chromium's DRT to make sure it's not leaking stderr like this. I thought we used to have asserts/error messages in NRWT to catch this kind of "dropped a log on the floor" problem? In ORWT those logs used to end up in the next test output. :) This is stdout, not stderr (which is why the test is failing). stderr works fine (and we output the -stderr.txt files you're talking about). 659732 14 schenney 2012-06-28 13:13:23 -0700 Committed r121457: <http://trac.webkit.org/changeset/121457> 659733 15 schenney 2012-06-28 13:14:11 -0700 I've updated the expectations because we would like to find out about any changes to this output and work is active in this code. 872408 16 schenney 2013-04-09 17:06:06 -0700 Marked LayoutTest bugs, bugs with Chromium IDs, and some others as WontFix. Test failure bugs still are trackable via TestExpectations or disabled unit tests.