Nightly build opens a blank window just a few seconds and closes

[gaby2300]

Downloaded nightly build from: https://download.servo.org/nightly/windows-msvc/servo-latest.msi
Running servo.exe opens a blank window just a few seconds and closes.

@jonathandturner is trying to help me

[gaby2300]

@jonathandturner - I filed the issue and I would appreciate your help!

I don't know why someone closed it :(

[batmont]

can't enjoy new render engine too
I've tried on 3 different computers: laptop, pc, tablet pc
7 SP1 64-bit, 7 64-bit and 8.1 64-bit
They're all dual-core Intel CPU (with no Turbo Boost, no Hyperthreading and without virtualization?), and all (or 2 of them) have only integrated GPU (Intel HD Graphics)

[jonathandturner]

@gaby2300 - I'm currently on Easter break for the next four days, but we hope to be able to fix this. It sounds like a few other people are encountering similar issues.

[jonathandturner]

@gaby2300 can you tell us about your setup? What version of Windows are you using? What graphics card? How much RAM does your computer have?

[zeljic]

FYI. The same here, Windows 7 Ultimate 64bit, Intel Integrated Graphics + nVidia. Both drivers are installed. Latest drivers are installed, "standard software installed" chrome, firefox, c++ redistributable (2013/2015). RAM 8Gb. CPU Intel Core i7 2630QM

[gaby2300]

I use Windows 7 Ultimate 64 bit and Intel(R) HD Graphics. My PC has a RAM of 4GB

[voracity]

I've had the same issue since July. I've been trying it on Windows 7 without ever having success. But I also have a Windows 10 system --- initially, that had an identical problem, but it started working with the switchover to MSVC builds.

The Windows 7 system is 64 bit (i7 2630QM), 8GB RAM, Hybrid AMD Radeon/Intel HD 3000 graphics (but have forced to just Intel graphics or just Radeon graphics, and same issues with both). As far as I'm aware, it has the latest Windows updates and drivers for everything.

[NiLSPACE]

Since todays build it also crashes on my laptop. By capturing stdout (which cmd doesn't do by default) I managed to get the error message:

Failed to link shader program: Type mismatch: Type of _O;vClipMaskUvBounds;p0 different between shaders.
Type mismatch: Type of _O;vClipMaskUvBounds;p1 different between shaders.
Out of resource error.

called `Result::unwrap()` on an `Err` value: Link("Type mismatch: Type of _O;vClipMaskUvBounds;p0 different between shaders.
Type mismatch: Type of _O;vClipMaskUvBounds;p1 different between shaders.
Out of resource error.
") (thread main, at src\libcore\result.rs:859)

Specs:
CPU: I7 6500U @ 2.5GHz,
RAM: 16.0GB Dual-Channel,
GPU: Intel HD Graphics 520
OS: Windows 10 PRO 1607

[CAfromCA]

I'm seeing the same behavior: Servo opens for a brief moment, then immediately closes.

When I run from the command line with servo.exe > err.txt 2>&1, this is the content of the output file:

Failed to create window.: OsError("wglCreateContextAttribsARB failed: OS Error -1073274731 (FormatMessageW() returned error 317) (os error -1073274731)") (thread main, at src\libcore\result.rs:859)

That's identical to @NiLSPACE, so this may be a different issue. If anyone knows how to get more verbose logging out of Servo I'm happy to dig deeper.

Specs:
OS: Windows 7 Enterprise SP1 64-bit
CPU: i5 2520M @ 2.5 GHz
RAM: 12.0 GB (11.8 GB usable due to integrated graphics)
GPU: Intel HD Graphics 3000
GPU driver version: 9.17.10.4229

It looks like glutin and Piston have open issues with the same error in wglCreateContextAttribsARB as the one I got from Servo:

rust-windowing/glutin#515
PistonDevelopers/piston#1035

[lygstate]

So is me.

[wilt00]

I had the same error message as @NiLSPACE above.
The workaround I've found is to manually set servo.exe to use the discrete Nvidia graphics card in my laptop via the Nvidia Control Panel app, and then the program opens and runs (as far as I can tell) normally.

Specs:
OS: Windows 10 Pro 64-bit, version 1703, build 15063.138
CPU: i7 4500U
Integrated GPU: Intel HD Graphics 4400, Driver version 20.19.15.4549
Discrete GPU: Geforce GT 745M, Driver version 22.21.13.8165

[glennw]

@jrmuizel @staktrace Do you guys have any Windows machines in the office with some of the gfx cards listed? I'm thinking most of this would go away if/when Servo starts using ANGLE on Windows, but it'd be nice to repro and do some testing. There might be some simple fixes / workarounds.

[staktrace]

I'll let @jrmuizel respond about the office machines, I'm not sure offhand what they have. It might be worth trying a Firefox nightly build with the gfx.webrender.enabled pref set to true (or just get a QuantumRender build from the graphics branch (e.g. here) and see if it also crashes on startup. It will try to use webrender with ANGLE so if it starts up (or fails to) that might provide some useful information.

[NiLSPACE]

Firefox with Webrender starts without any problem.
I get this from stdout:

WebRender - OpenGL version new OpenGL ES 3.0 (ANGLE 2.1.0.dec065540d5f)
nsStringStats
 => mAllocCount:          17861
 => mReallocCount:          470
 => mFreeCount:           17861
 => mShareCount:          23239
 => mAdoptCount:           1717
 => mAdoptFreeCount:       1717
 => Process ID: 16428, Thread ID: 7968
nsStringStats
 => mAllocCount:            517
 => mReallocCount:           31
 => mFreeCount:             517
 => mShareCount:            394
 => mAdoptCount:              0
 => mAdoptFreeCount:          0
 => Process ID: 7908, Thread ID: 15292
nsStringStats
 => mAllocCount:          91263
 => mReallocCount:         2348
 => mFreeCount:           91263
 => mShareCount:          68604
 => mAdoptCount:           4079
 => mAdoptFreeCount:       4079
 => Process ID: 10436, Thread ID: 17012

[NiLSPACE]

After updating my Intel GPU drivers from 20.19.15.4483 to 21.20.16.4550 Servo is working again.

[jonathandturner]

Interesting, thanks @NiLSPACE.

For others who are having this issue, can you confirm that you have the latest drivers for your video card? Servo does use your video card quite a bit, similar to video games, so I'm not surprised that you need to keep the video drivers up to date.

[glennw]

Some drivers are having trouble with passing a struct through the VS -> FS interpolators. This PR (#16523) contains a workaround for that. When it lands, it should fix some of the issues above.

[Alhaitham]

The workaround by @wilt00 worked for me.

Using the external GPU made Servo start normally.

[CAfromCA]

@jonathandturner I appear to have the latest driver for the Intel HD 3000, which was released in June 2015.

That age is probably not surprising, since Sandy Bridge just turned 6 and Intel discontinued technical support for it in June 2016.

[crlf0710]

I had this issue yesterday but i pulled the newest code and updated my display driver just now.

It's working fine now.

[gaby2300]

I cannot update my video card drivers as my PC is quite old by now. Could someone explain me what does the gfx.webrender.enabled pref set to true have to do with Nightly's servo build please? I would greatly appreciate it! I would also appreciate undesrtanding how to proceed with the workaround mentioned by Glenn, and how to obtain a QuantumRender build from the graphics branch. Many thanks!

…

On 19 April 2017 at 10:04, CrLF0710 ***@***.***> wrote: I had this issue yesterday but i pulled the newest code and updated my display driver just now. It's working fine now. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#16393 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACDVaDIjO1QxILopkQ_YtTbKzqL7ULjzks5rxgZngaJpZM4M8GHe> .

[NiLSPACE]

WebRender is a component of Servo which is being moved to Firefox as part of the Quantum project. By setting gfx.webrender.enabled to true you tell Firefox to use that. I suggest creating a new profile first in about:profiles as the option is still really unstable.

[jdm]

The 4/19 Servo nightly should include the workaround mentioned by @glennw.

[2efPer]

Crashed too.
Intel Core i5-5200U
NVIDIA GeForce 940M
Windows 7 64bit

Failed to link shader program: Type mismatch: Type of _O;vClipMaskUvBounds;p0 different between shaders.
Type mismatch: Type of _O;vClipMaskUvBounds;p1 different between shaders.
Out of resource error.
called Result::unwrap() on an Err value: Link("Type mismatch: Type of _O;vClipMaskUvBounds;p0 different between shaders.\nType mismatch: Type of _O;vClipMaskUvBounds;p1 different between shaders.\nOut of resource error.\n") (thread main, at src\libcore\result.rs:859)

[CAfromCA]

Unfortunately, it looks like servo/webrender#1192 did not fix my issue, though it closed servo/webrender#1157.

I pulled the latest Servo code again this morning and did a fresh --dev build, and it was essentially identical to the one I posted above (other that a few line numbers changing slightly).

Should I open a new ticket for my specific error? If so, should I open it in the Servo or WebRender repo?

For whatever it's worth, I tried to run Servo with the -z command line argument to see if that made a difference, but the process still quits immediately. The backtrace is a little different than the one I get when running Servo normally, so I've included it in case it's interesting.

gl function was not loaded (thread main, at C:\servo\servo\target\debug\build\gleam-596504a3dd4a6e35\out/gl_bindings.rs:953)
stack backtrace:
   0:        0x14270b490 - backtrace::backtrace::trace<closure>
                        at C:\servo\servo\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.0\src\backtrace\mod.rs:41
   1:        0x142703c64 - backtrace::capture::Backtrace::new
                        at C:\servo\servo\target\debug\build\backtrace-6ddf4a4263d5dc15\out\capture.rs:79
   2:        0x13f24b1b8 - servo::main::{{closure}}
                        at C:\servo\servo\ports\servo\main.rs:123
   3:        0x143c845c0 - std::panicking::rust_panic_with_hook
                        at C:\projects\rust\src\libstd\panicking.rs:550
   4:        0x1439bb3f9 - std::panicking::begin_panic<&str>
                        at C:\projects\rust\src\libstd\panicking.rs:511
   5:        0x1439bc394 - gleam::ffi_gl::missing_fn_panic
                        at C:\servo\servo\target\debug\build\gleam-596504a3dd4a6e35\out\gl_bindings.rs:953
   6:        0x1439cd05f - gleam::ffi_gl::Gl::GetString
                        at C:\servo\servo\target\debug\build\gleam-596504a3dd4a6e35\out\gl_bindings.rs:2583
   7:        0x1439c37c6 - gleam::gl::{{impl}}::get_string
                        at C:\servo\servo\.cargo\registry\src\github.com-1ecc6299db9ec823\gleam-0.4.4\src\gl_fns.rs:1149
   8:        0x1429d284d - glutin_app::window::Window::new
                        at C:\servo\servo\ports\glutin\window.rs:297
   9:        0x142a19143 - glutin_app::create_window
                        at C:\servo\servo\ports\glutin\lib.rs:50
  10:        0x13f24a656 - servo::main
                        at C:\servo\servo\ports\servo\main.rs:140
  11:        0x143c85e12 - panic_unwind::__rust_maybe_catch_panic
                        at C:\projects\rust\src\libpanic_unwind\lib.rs:98
  12:        0x143c84b9a - std::rt::lang_start
                        at C:\projects\rust\src\libstd\rt.rs:51
  13:        0x13f24b72c - main
  14:        0x14455fd99 - __scrt_common_main_seh
                        at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253
  15:         0x77a359cd - BaseThreadInitThunk
Servo exited with return value 101

[jdm]

Servo is not using a version of Webrender that includes servo/webrender#1192 yet. We need another PR like #16684 that updates our copy.

[jdm]

And yes, please open a separate issue for output when using -z.

[jdm]

The next nightly should include servo/webrender#1192 since #16652 just merged. It would be worth testing to see if Windows nightly builds still exhibit the problem described here.

[jdm]

Sorry, I forgot that #16560 is preventing us from updating the Windows nightlies that are published. Only people who can make local builds will be able to test whether this problem has disappeared.

[CAfromCA]

I just re-synced and confirmed my local copy got #16652, but Servo dies with the same error.

[CAfromCA]

I saw several additional WebRender updates pulled into Servo, so I tried compiling a fresh copy. The issue persists.

[kvark]

Is the error message still the same?

vClipMaskUvBounds;p1 different between shaders.

If you search for this name in the current shaders, it only appears here:

flat varying vec4 vClipMaskUvBounds;

And there is nothing unique or wrong about that. I'd expect a problem elsewhere.

[CAfromCA]

My error is unchanged:

Failed to create window.: OsError("wglCreateContextAttribsARB failed: OS Error -1073274731 (FormatMessageW() returned error 317) (os error -1073274731)") (thread main, at src\libcore\result.rs:859)

My error has always been different than the "vClipMaskUvBounds" error that @NiLSPACE, @2efPer, and @recompileorg reported.

My issue could, be the same root cause as theirs, but at the very least it's presenting differently for me. They all have Broadwell or Skylake chips (late 2014 to late 2015) and I have a much older Sandy Bridge CPU/iGPU (mid-2011).

I don't know if any of them can pull the source and compile to see if the recent WR updates fix their issue. it might help resolve whether this is one issue or several.

[kvark]

Thanks @CAfromCA ! It does appear to me that multiple different issues got mixed here, and it's no longer about the GLSL shader linking, given that wglCreateContextAttribsARB happens way before that point.

[CAfromCA]

In that case, I'll create a new issue for my error and let the people seeing "vClipMaskUvBounds" errors figure out if this one is resolved.

[gaby2300]

Hello, I'm still having this issue with the newest build. Is it going to be fixed any time soon?

[jonathandturner]

Ping @glennw - any idea what the fix for this might be?

[glennw]

For the wglCreateContextAttribsARB error, I wonder if the GPU in question doesn't support OpenGL 3.2? I know that some of the 2011 range Intel GPUs only support 3.1 on Windows, but anything newer than that should be fine (and we plan to support 3.1 in the future anyway).

It would be worth opening up the Intel GPU driver control panel, and pasting the output of the OpenGL version information and any other information available here - that may offer some clues as to what is happening.

[CAfromCA]

Several people who commented on #16771 (and I) all seem to have Sandy Bridge-era Intel HD Graphics 3000 iGPUs. Per Wikipedia, at least, Intel only supports up to OpenGL 3.1 on Windows but supports OpenGL 3.3 on Linux and OS X.

https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units#Sixth_generation

I wasn't able to find a primary source on Intel's site to confirm this, but I installed "OpenGL Extensions Viewer" (a.k.a. GLview, I guess) and it does show my maximum OpenGL version as 3.1.

For whatever it's worth, the three OpenGL 3.2 features (of the 10 listed) this tool says are unsupported by my machine are:

• Shading language version 1.50
• GL_ARB_geometry_shader4
• GL_ARB_texture_multisample

If there's anything else I can get for you about what these GPUs support/lack, let me know!

[gaby2300]

I think it's my case too. Does this mean I won't be able to run these nightlies till I get a newer PC? Thanks for your help!

…

On 19 July 2017 at 16:15, CAfromCA ***@***.***> wrote: Several people who commented on #16771 <#16771> (and I) all seem to have Sandy Bridge-era Intel HD Graphics 3000 iGPUs. Per Wikipedia, at least, Intel only supports up to OpenGL 3.1 on Windows but supports OpenGL 3.3 on Linux and OS X. https://en.wikipedia.org/wiki/List_of_Intel_graphics_ processing_units#Sixth_generation I wasn't able to find a primary source on Intel's site to confirm this, but I installed "OpenGL Extensions Viewer" (a.k.a. GLview, I guess) and it does show my maximum OpenGL version as 3.1. For whatever it's worth, the three OpenGL 3.2 features (of the 10 listed) this tool says are unsupported by my machine are: - Shading language version 1.50 - GL_ARB_geometry_shader4 - GL_ARB_texture_multisample If there's anything else I can get for you about what these GPUs support/lack, let me know! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#16393 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACDVaMG0VEiOXX_Pgt_v2pKPmxXWECCzks5sPlXWgaJpZM4M8GHe> .

[CAfromCA]

I missed the "It would be worth opening up the Intel GPU driver control panel..." bit earlier, but I just opened mine and I don't see anything in there about OpenGL support.

I'm either looking in the wrong place, or else that's a newer feature that Intel didn't include in their final (and now 2 year-old) set of Sandy Bridge drivers.

Since that appears to be a bust, here's the report generated by the OpenGL Extensions Viewer.

[jonathandturner]

@gaby2300 @CAfromCA - unfortunately this is a limitation of the current system. We do plan to add support for that hardware, but to do so will be to move our OpenGL work over to ANGLE(https://github.com/google/angle). This work is still a ways out.

[gaby2300]

@jonathandturner Many thanks for letting me know about this! You saved me from trying and failing again and again! By still a ways out do you mean it will take a long time?

[jonathandturner]

@gaby2300 - I can only speculate on when the support will be available, unfortunately.

[CAfromCA]

@jonathandturner Given the cause seems to have been identified (Sandy Bridge doesn't support OpenGL 3.2 on Windows) and it sounds like there is a clear fix identified and planned (migrate Windows to use ANGLE), is it safe for me to update and close #16771?

[gaby2300]

@jonathandturner I understand! Thanks anyway!