Bug 85085

Summary: [chromium] svg/custom/clip-path-referencing-use2.svg fails in "drt mode" in DRT
Product: WebKit Reporter: Dirk Pranke <dpranke>
Component: Tools / TestsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WONTFIX    
Severity: Normal CC: dglazkov, eric, pdr, schenney, tkent, tony
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   

Description Dirk Pranke 2012-04-27 11:18:58 PDT
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.
Comment 1 Eric Seidel (no email) 2012-04-27 11:49:03 PDT
I suspect this is a bug about our handling of stderr output in one or the other modes.
Comment 2 Dirk Pranke 2012-04-27 11:50:40 PDT
(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.
Comment 3 Eric Seidel (no email) 2012-04-27 11:51:35 PDT
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?)
Comment 5 Dirk Pranke 2012-04-27 11:53:39 PDT
I don't believe the logging is being configured any differently.
Comment 6 Philip Rogers 2012-04-27 11:55:59 PDT
(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.
Comment 7 Eric Seidel (no email) 2012-04-27 11:56:45 PDT
I wonder if the ChromeClients are configured differently for Chrome DRT in DRT mode vs. TS mode.
Comment 8 Dirk Pranke 2012-04-27 11:58:18 PDT
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?
Comment 9 Philip Rogers 2012-04-27 12:06:08 PDT
(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.
Comment 10 Dirk Pranke 2012-04-27 12:40:47 PDT
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.
Comment 11 Dirk Pranke 2012-04-27 13:13:16 PDT
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?
Comment 12 Eric Seidel (no email) 2012-04-27 13:35:39 PDT
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. :)
Comment 13 Dirk Pranke 2012-04-27 13:42:11 PDT
(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).
Comment 14 Stephen Chenney 2012-06-28 13:13:23 PDT
Committed r121457: <http://trac.webkit.org/changeset/121457>
Comment 15 Stephen Chenney 2012-06-28 13:14:11 PDT
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.
Comment 16 Stephen Chenney 2013-04-09 17:06:06 PDT
Marked LayoutTest bugs, bugs with Chromium IDs, and some others as WontFix. Test failure bugs still are trackable via TestExpectations or disabled unit tests.