[Webkit-unassigned] [Bug 15743] run-webkit-tests hangs when WebCore tries to log too much

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=15743





--- Comment #8 from Shinichiro Hamaji <hamaji at chromium.org>  2009-08-18 16:32:11 PDT ---
(In reply to comment #6)
> (From update of attachment 35030 [details])
> I do think the original issue may have been blocked write(2) calls due to too
> much STDERR output.  Do you have an easy way to reproduce this?  Can you just
> add a "fprintf(stderr, "Blah\n");" to a function in WebKit that's called a lot
> to see the bad behavior?

Yeah, the only way to reproduce the bug is the way you mentioned. Specifically,
I've added showTree(newChild) into rendering/CounterNode.cpp:108 to see the
behavior of CSS counter and felt this bug is annoying.

> It's an interesting strategy to read a line of STDERR with a line of STDOUT
> from DumpRenderTree, but what guarantees that all of STDERR is read before
> going to the next test?  Would reading all STDERR each time work as well?

I misunderstood the behavior of DumpRenderTree here. It outputs #EOF even for
stderr. So, the best way to ensure that we've read all stderr is checking #EOF
in stderr just like my previous patch was doing for stdout.

> If any STDERR is printed at the same time as the "Content-Type" line or the
> "#EOF" line, it appears that whatever is in $lineError will be discarded.  I
> think the logic here should be restructured to use if () {} elif () {} else {}
> within if (defined($lineIn)) so that $lineError always gets appended to @error
> if it's defined.

Oops. I've fixed this as you said.

I've updated my patch and I checked that I was seeing all stderrs of each test
cases properly by adding fpritnf into the beginning and ending of
DumpRenderTree.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.