Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Headless testing (webdriver) fails to fully render on 4th page load #18606

Closed
kanaka opened this issue Sep 23, 2017 · 12 comments
Closed

Headless testing (webdriver) fails to fully render on 4th page load #18606

kanaka opened this issue Sep 23, 2017 · 12 comments

Comments

@kanaka
Copy link
Contributor

@kanaka kanaka commented Sep 23, 2017

After loading 3 pages successfully with headless/webdriver servo, the 4th page loads renders the background color of the page but no other content.

I'm running servo (built in release mode from 5a6b90b) like this:

$ ./mach run --release -z --webdriver 7002 --resolution 400x300
VMware, Inc.
Gallium 0.4 on softpipe
3.3 (Core Profile) Mesa 17.2.0-devel

I have the follow simple test case web page:

<html><body style="background: #12890f">
        <div>This is a test of the emergency broadcast system.</div>
</body></html>

I then create a webdriver session:

SESSIONID=$(curl -X POST -d "{}" http://localhost:7002/session | jq -r ".value.sessionId")

Then I load the test page and screenshot it like this:

curl -v -X POST -d '{"url": "http://localhost:9080/test.html"}' http://localhost:7002/session/${SESSIONID}/url
curl -v http://localhost:7002/session/${SESSIONID}/screenshot | jq -r ".value" | base64 -d > test1.png

The first three times I do that the screenshot looks like this:

test1

The fourth time (and thereafter), the screenshot looks like this:

test4

Note that if I change the background color in the html, the color in the screenshot changes so I know it's picking up the file and parsing it to get the background color.

@kanaka
Copy link
Contributor Author

@kanaka kanaka commented Jan 10, 2018

I tested this in 5f4f355 (Dec 9, 2017) and the problem still exists.

@kanaka
Copy link
Contributor Author

@kanaka kanaka commented Jan 10, 2018

I just built e5a0bb9 (Jan 9, 2018) and the problem appears to have gotten worse because it now stops rendering on the third attempt.

In fact, I just discovered by accident that even if the web server is not running, I'll will get two white error pages with "Could not load the requested page: connection refused" and the third will just be an empty white page.

Also, I verified that it is not just loading the same address that causes the problem. I created four test pages (each with a different message and background color). The third page loaded (and fourth and so on) shows the correct bgcolor for the page but has no other content.

@glennw
Copy link
Member

@glennw glennw commented Jan 10, 2018

Any ideas @jgraham @jdm ?

@glennw
Copy link
Member

@glennw glennw commented Jan 10, 2018

@kanaka
Copy link
Contributor Author

@kanaka kanaka commented Jan 10, 2018

As another data-point, if I run (still e5a0bb9) without headless

./mach run --release --webdriver 7002

and then do the same test above, it render only the background on the second load and on the third load servo panics. Not sure if it's useful or even related to the original issue but here is the stack:

Stack trace for thread "main"
stack backtrace:
   0:     0x55baff9eb69c - backtrace::backtrace::trace::ha2f9b48d840fa9e7
   1:     0x55baff9eb6d2 - backtrace::capture::Backtrace::new::hb1ab3a81fa7b7528
   2:     0x55bafe2103fb - servo::install_crash_handler::handler::hff4ff6eb041eb392
   3:     0x55bb0036f363 - AsmJSFaultHandler
                        at /home/joelm/tmp/servo.git/.cargo/registry/src/github.com-1ecc6299db9ec823/mozjs_sys-0.50.0/mozjs/js/src/asmjs/WasmSignalHandlers.cpp:1171
   4:     0x7fbf0eee738f - <unknown>
   5:     0x7fbf0d4b4e5d - <unknown>
   6:     0x7fbf062fe123 - <unknown>
   7:     0x7fbf063022c5 - <unknown>
   8:     0x7fbf060e0427 - <unknown>
   9:     0x7fbf060a055f - <unknown>
  10:     0x7fbf060a05f4 - <unknown>
  11:     0x55baff74d85c - webrender::renderer::Renderer::draw_instanced_batch::h16d05f0fe6337642
  12:     0x55baff74e3d1 - webrender::renderer::Renderer::submit_batch::h2440cbfa0e6e9118
  13:     0x55baff74f10f - webrender::renderer::Renderer::draw_color_target::h490898d89cc125db
  14:     0x55baff74ab40 - webrender::renderer::Renderer::render::{{closure}}::h070df3797c8cfc13
  15:     0x55baff743216 - webrender::renderer::Renderer::render::hd8a689a4a9ecfd13
  16:     0x55bafe2059e7 - <compositing::compositor::IOCompositor<Window>>::composite_specific_target::ha220d79cc3ebf8b7
  17:     0x55bafe20937e - <compositing::compositor::IOCompositor<Window>>::composite::h6db964ee2d3a4fa1
  18:     0x55bafe1ecc79 - <servo::Servo<Window>>::handle_events::h2489c77a8e7b2250
  19:     0x55bafe2127c5 - servo::main::h7ac48a4a2f2fe0f4
  20:     0x55bb005e958e - panic_unwind::__rust_maybe_catch_panic
                        at /checkout/src/libpanic_unwind/lib.rs:99
  21:     0x55bb005e140b - std::panicking::try<(),closure>
                        at /checkout/src/libstd/panicking.rs:459
                         - std::panic::catch_unwind<closure,()>
                        at /checkout/src/libstd/panic.rs:365
                         - std::rt::lang_start
                        at /checkout/src/libstd/rt.rs:58
  22:     0x7fbf0d43682f - __libc_start_main
  23:     0x55bafe1e61d8 - _start
  24:                0x0 - <unknown>
Stack trace for thread "main"
stack backtrace:
   0:     0x55baff9eb69c - backtrace::backtrace::trace::ha2f9b48d840fa9e7
   1:     0x55baff9eb6d2 - backtrace::capture::Backtrace::new::hb1ab3a81fa7b7528
   2:     0x55bafe2103fb - servo::install_crash_handler::handler::hff4ff6eb041eb392
   3:     0x7fbf0d44b4af - <unknown>
   4:     0x55bafe210483 - servo::install_crash_handler::handler::hff4ff6eb041eb392
   5:     0x55bb0036f363 - AsmJSFaultHandler
                        at /home/joelm/tmp/servo.git/.cargo/registry/src/github.com-1ecc6299db9ec823/mozjs_sys-0.50.0/mozjs/js/src/asmjs/WasmSignalHandlers.cpp:1171
   6:     0x7fbf0eee738f - <unknown>
   7:     0x7fbf0d4b4e5d - <unknown>
   8:     0x7fbf062fe123 - <unknown>
   9:     0x7fbf063022c5 - <unknown>
  10:     0x7fbf060e0427 - <unknown>
  11:     0x7fbf060a055f - <unknown>
  12:     0x7fbf060a05f4 - <unknown>
  13:     0x55baff74d85c - webrender::renderer::Renderer::draw_instanced_batch::h16d05f0fe6337642
  14:     0x55baff74e3d1 - webrender::renderer::Renderer::submit_batch::h2440cbfa0e6e9118
  15:     0x55baff74f10f - webrender::renderer::Renderer::draw_color_target::h490898d89cc125db
  16:     0x55baff74ab40 - webrender::renderer::Renderer::render::{{closure}}::h070df3797c8cfc13
  17:     0x55baff743216 - webrender::renderer::Renderer::render::hd8a689a4a9ecfd13
  18:     0x55bafe2059e7 - <compositing::compositor::IOCompositor<Window>>::composite_specific_target::ha220d79cc3ebf8b7
  19:     0x55bafe20937e - <compositing::compositor::IOCompositor<Window>>::composite::h6db964ee2d3a4fa1
  20:     0x55bafe1ecc79 - <servo::Servo<Window>>::handle_events::h2489c77a8e7b2250
  21:     0x55bafe2127c5 - servo::main::h7ac48a4a2f2fe0f4
  22:     0x55bb005e958e - panic_unwind::__rust_maybe_catch_panic
                        at /checkout/src/libpanic_unwind/lib.rs:99
  23:     0x55bb005e140b - std::panicking::try<(),closure>
                        at /checkout/src/libstd/panicking.rs:459
                         - std::panic::catch_unwind<closure,()>
                        at /checkout/src/libstd/panic.rs:365
                         - std::rt::lang_start
                        at /checkout/src/libstd/rt.rs:58
  24:     0x7fbf0d43682f - __libc_start_main
  25:     0x55bafe1e61d8 - _start
  26:                0x0 - <unknown>
Servo exited with return value -4
@glennw
Copy link
Member

@glennw glennw commented Jan 10, 2018

I'm not sure if that's related or not - it might be. It's a little hard to tell from that backtrace, but I suspect that might be a crash occurring inside the GPU driver, with all the <unknown> entries after draw_instanced_batch which is where WR calls into the GL driver to draw a batch of vertices.

@jdm
Copy link
Member

@jdm jdm commented Jan 24, 2018

To reproduce the original problem, all I need to do is load the page once and then take three screenshots of it. By the third, I am only seeing the background colour.

@jdm
Copy link
Member

@jdm jdm commented Jan 24, 2018

I don't reproduce the crashes when running without headless mode enabled. The page still keeps displaying correctly in the browser, but the screenshots only show the background colour per the original description.

@glennw
Copy link
Member

@glennw glennw commented Jan 30, 2018

I can reproduce the screenshot issue locally - I'll take a look today at the WR side.

@glennw
Copy link
Member

@glennw glennw commented Jan 30, 2018

Interestingly enough, if I run the servo exe with -Z wr-stats, which shows a debug overlay on each frame with profile stats, the rendering is correct. I can see in the debug stats that the frame number is advancing, and the text content is rendered correctly.

glennw pushed a commit to glennw/servo that referenced this issue Jan 31, 2018
I *think* this is a bug in OSMesa, as the fix here makes no
sense to me. But nonetheless, this change does seem to reliably
fix the headless output issues as reported.

Fixes servo#18606.
@glennw
Copy link
Member

@glennw glennw commented Jan 31, 2018

#19910 fixes this.

bors-servo added a commit that referenced this issue Jan 31, 2018
Add a workaround for headless output sometimes being blank.

I *think* this is a bug in OSMesa, as the fix here makes no
sense to me. But nonetheless, this change does seem to reliably
fix the headless output issues as reported.

Fixes #18606.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/19910)
<!-- Reviewable:end -->
@kanaka
Copy link
Contributor Author

@kanaka kanaka commented Feb 10, 2018

@glennw thanks for fixing this! I have confirmed that this behavior no longer occurs for me. In the process of confirming however, I discovered a new one, this time a crashing bug after 12 loads: #20015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants
You can’t perform that action at this time.