[Wayland] glxtest broken on Weston
Categories
(Core :: Graphics, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox85 | --- | unaffected |
firefox86 | --- | disabled |
firefox87 | --- | disabled |
People
(Reporter: rmader, Assigned: rmader)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(1 file)
48 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta-
|
Details | Review |
Since bug 1640053 we do not fall back to GLX version in glxtest any more but only use EGL,PCI and Wayland APIs to determine graphics capabilities.
On my system, this fails on Weston and also does not properly fall back to GLX, result ing in a fallback to basic and no WebGL support. Gnome and Sway do work fine though, as does X11/GLX and X11/EGL.
Comment 1•4 years ago
|
||
Set release status flags based on info from the regressing bug 1640053
Assignee | ||
Comment 2•4 years ago
|
||
We don't ship Wayland by default yet, setting to disabled.
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
So glxtest crashes in the Wayland code - with a quite odd stack:
#01: arena_dalloc(void*, unsigned long, arena_t*) (./gecko-dev/memory/build/mozjemalloc.cpp:3359)
#02: PageFree(mozilla::Maybe<unsigned long> const&, void*) (./gecko-dev/memory/replace/phc/PHC.cpp:0)
#03: replace_free(void*) (./gecko-dev/memory/replace/phc/PHC.cpp:0)
#04: destroy_xdg_output_manager_v1_info(void*) (./gecko-dev/toolkit/xre/glxtest.cpp:974)
#05: childgltest (./gecko-dev/toolkit/xre/glxtest.cpp:1206)
#06: fire_glxtest_process() (./gecko-dev/toolkit/xre/glxtest.cpp:1254)
#07: XREMain::XRE_mainInit(bool*) (./gecko-dev/toolkit/xre/nsAppRunner.cpp:3574)
#08: XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) (./gecko-dev/toolkit/xre/nsAppRunner.cpp:5411)
#09: XRE_main(int, char**, mozilla::BootstrapConfig const&) (./gecko-dev/toolkit/xre/nsAppRunner.cpp:5501)
Assignee | ||
Comment 4•4 years ago
|
||
Certain fields are optional - if a compositor does not set it we
end up freeing uninitialized memory.
Comment 6•4 years ago
|
||
bugherder |
Assignee | ||
Comment 7•4 years ago
•
|
||
Comment on attachment 9201838 [details]
Bug 1690999: Initialize Wayland structs to zero, r=stransky
Beta/Release Uplift Approval Request
- User impact if declined: A small number of Wayland users will have all acceleration disabled, including WR and WebGL. These users are likely developers.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Only changing an uninitialized struct to 0-initialized, with no impact on logic otherwise. Only affects Wayland users.
- String changes made/needed:
Comment 8•4 years ago
|
||
Comment on attachment 9201838 [details]
Bug 1690999: Initialize Wayland structs to zero, r=stransky
We are ending our beta cycle and the impact on end users seems low, I think it should ride the trains.
Updated•4 years ago
|
Description
•