Re: dumprendertree and plugin crashes

[Michael Nordman]

I'm not sure i can answer these questions... cc'ing chromium-dev.

As I understand it, a basic difference between DRT and test_shell is that DRT sources are housed upstream in webkit svn, and can be built interdependently of chromium sources, although there are some prebuilt chromium binaries that are needed for DRT. Also, the only thing DRT does is conduct layout tests in a faceless fashion. The test_shell runs layout tests too, but can also be used interactively as very simple browser (with a very ugly ui).

As for a missing call to gtk_init(), maybe somebody closer to DRT/linux can answer that?

On Thu, Jul 29, 2010 at 8:36 AM, Bryan McQuade <bmcq...@google.com> wrote:

Hi,

I've been hacking on my variant of DRT. What I find is that on linux,
when I load a page with flash, it crashes.

I believe that this is related to an issue where flash 10.1 needs the
host environment to call gtk_init.

See:
https://bugs.webkit.org/show_bug.cgi?id=40567
http://trac.webkit.org/changeset/61307
for the bug and recent fix applied to the qt webkit port.

What I noticed is that we have code to call gtk_init in
TestShellPlatformDelegate and that this is called by
test_shell_main.cc. However this code is not called by
DumpRenderTree's main().

Should we be calling this code in DumpRenderTree's main() as well? The
code I'm thinking of calling is:

 TestShellPlatformDelegate::PreflightArgs(&argc, &argv);
 CommandLine::Init(argc, argv);
 const CommandLine& parsed_command_line = *CommandLine::ForCurrentProcess();

 TestShellPlatformDelegate platform(parsed_command_line);

although I realize now that chromium DumpRenderTree may not be allowed
to use this code? I don't really understand the dependencies fully.

In any case I'm curious to hear what you think we should do to address
this issue, if anything, in DumpRenderTree. I've worked around the
issue on my project by inserting the code above into main().

BTW what's the difference between DumpRenderTree and test_shell_main?
Why would someone use one or the other?

Thanks,
Bryan

[Evan Martin]

>> I've been hacking on my variant of DRT. What I find is that on linux,
>> when I load a page with flash, it crashes.
>>
>> I believe that this is related to an issue where flash 10.1 needs the
>> host environment to call gtk_init.

Flash expects to be able to talk to an X server, and I think windowed
Flash expects to have an X window to parent on. Does DRT create an
OS-level window or does it just render into pixel buffers? In the
former case, you should be initializing GTK at startup already, while
in the latter case I don't think Flash will work.

[Bryan McQuade]

I think it's the former case but I'll defer to someone that knows DRT
better than I do.

I can report that without a call to gtk_init at startup, the DRT
process crashes when trying to render flash. Once I add a call to
gtk_init() the crash goes away. Whether flash is doing something
meaningful or not I don't know. I can look at a dumped screenshot to
find out if the flash gets rendered.

>

[Bryan McQuade]

chromium drt

On Thu, Jul 29, 2010 at 2:50 PM, Dimitri Glazkov <dgla...@google.com> wrote:
> I think it would be useful to find out which DRT are you working in.
> There are multiple implementations of DRT, one for each port --
> including Chromium.
>
> :DG<

>> --
>> Chromium Developers mailing list: chromi...@chromium.org
>> View archives, change email options, or unsubscribe:
>>    http://groups.google.com/a/chromium.org/group/chromium-dev
>>
>

[Dimitri Glazkov]

Awesome! Looking at the latest runs on build.webkit.org, we are indeed
crashing like drunk monkeys riding bicycles on all plugin tests:

http://build.webkit.org/builders/Chromium%20Linux%20Release%20(Tests)/builds/2870/steps/layout-test/logs/stdio

Can you fix that please? :)

:DG<

[Bryan McQuade]

sure i can #ifdef OS_LINUX a call to gtk_init() if that fixes it. or
is there a better way? can i use TestShellPlatformDelegate from
DumpRenderTree? i assume i can't.

[Evan Martin]

I don't know this code so I can't comment on the proper structure, but
if you have the Chrome build_config.h header available (for the
OS_LINUX) define, the appropriate test would be #if
defined(TOOLKIT_USES_GTK).

[Bryan McQuade]

I confirmed that it's a call to gtk_init that prevents the crashes in
chromium DRT. Without the call, crashes every time on my machine. With
the call, it no longer crashes.

I don't fully understand what gtk_init() does or whether we want to
call it. I assume so, since it prevents crashes, but if it has other
undesirable side effects for DRT maybe we don't want to call it unless
plugins are being loaded.

Can someone with DRT knowledge (especially knowledge on how to build
DRT in the webkit tree) help me to make sure I'm putting together a
change that's compatible with both chromium build and webkit build? As
I understand it this code needs to build in webkit land as well.

Thanks,
Bryan

[TAMURA, Kent]

Hi,

We have avoided to call gtk_init() in DRT because of no X server dependency.  However the NPAPI glue code of Chromium/GTK always needs a valid GDK_DISPLAY() value for any plugins, and WebKit layout test always run plugin tests.  So we had better add gtk_init() call at the beginning of DRT.

--
TAMURA Kent
Software Engineer, Google

[Bryan McQuade]

Ok. For my own project I'm going to investigate supporting 2 modes: no
plugin and no gtk, and plugin+gtk.

Let me know if you end up needing to support a gtkless DRT & I can
share that code with you.

Thanks,
Bryan

[Evan Martin]

To be clear, NPAPI is specified in terms of X, and Flash itself
expects GTK to be initialized, so you'll need at least X to run plugin
tests at all and GTK to run Flash plugin tests. Our buildbots use
Xvfb so it's not such a terrible thing.

PS: Xvfb is definitely the bottleneck for greater layout test
parallelization on Linux (that is, when running on a fast enough
machine Xvfb goes to 100% CPU and the test_shell processes contend for
its time). But that's because test_shell draws everything it renders;
hopefully DRT wouldn't be making X calls except when doing plugin
work, though that might be tricky to implement.

[Bryan McQuade]

Are there more efficient alternatives to xvfb? Is the bottleneck due
to inefficiencies in the xvfb implementation or is it inherent in any
X environment?

[Evan Martin]

Xvfb renders to memory rather than a screen, so I would expect it
would be faster than the alternatives.

I can imagine doing something like putting DRT into "needs X" mode for
the plugin tests, where it knows to do some extra work and talk to an
Xvfb for those tests. It would be similar to what we do for the HTTP
tests I think.

Another approach is to lazy-init all the X stuff in one of the first
plugin callbacks -- that is, as soon as a plugin is created, flip a
flag in DRT somewhere that makes it render via X, and then unflip the
flag as soon as the last plugin is destroyed.

[Evan Martin]

Sorry, I derailed the thread myself. What I really suggest for your
purposes is to just always use Xvfb for now; though it's a bottleneck,
the Linux layout tests are already significantly faster than the other
platforms. All this plugin-specific stuff I'm imagining is an
optimization. A simpler one would be to run two Xvfbs and have the
tests split between them. But again, you should probably first get
DRT working and then worry about these tricks.

Eyeballing the webkit builder cycle times at
http://build.chromium.org/buildbot/waterfall/stats
Linux ~ 7
Win ~ 13
Mac ~ 26

[Darin Fisher]

An X server is needed even for windowless plugins?  (Is the layout test plugin windowless?)

-Darin

[Tony Chang]

I had thought gtk_init() needed an X server, but it turns out that's not the case.  Kent just enabled gtk_init() for Linux DRT and it seems to be running ok (but still crashing on the plugin tests, probably because there's no X server).

http://trac.webkit.org/changeset/64463

[Darin Fisher]

OK.

And, it looks like the layout test plugin is windowless.

-Darin

[Evan Martin]

In this case, I guess since the layout test plugin doesn't have any
on-screen region, it probably doesn't get any drawing calls.

But in general, yep: since NPAPI is in terms of X handles, even
windowless drawing involves X server round-trips. We put some stuff
on the X server, we tell the plugin "hey go draw on the X server",
then we go fetch that stuff from the X server. Performance is not so
good. Hurry up with Pepper. ;)

Search for "targeting the pixmap" in
webkit/glue/plugins/webplugin_delegate_impl_gtk.cc .

On Mon, Aug 2, 2010 at 9:35 AM, Darin Fisher <da...@chromium.org> wrote: