[ARM] GPU acceleration seems broken on armhf since 1738814
Categories
(Core :: Graphics: WebRender, defect)
Tracking
()
People
(Reporter: merlijn, Assigned: rmader, NeedInfo)
Details
(Keywords: leave-open)
Attachments
(1 file)
On Debian Bullseye with Firefox 102.7.0esr, GPU acceleration is gone for some time now. I believe it used to be there. This change seems suspect:
https://hg.mozilla.org/mozilla-central/rev/c1245a74819a71fdcbdf0196d65552a582d98295#l1.41
Which basically assumes that every platform uses OpenGL, not OpenGLES, unless it's arm64. I am not sure where that leaves armhf, but I think it leaves it without GPU:
$ firefox-esr -P
[GFX1-]: glxtest: eglCreateContext returned an error
[GFX1-]: glxtest: GLX extension missing
[GFX1-]: glxtest: eglCreateContext returned an error
[GFX1-]: No GPUs detected via PCI
Even though the system has working hardware acceleration, and to my knowledge, this used to work.
es2info:
$ es2_info | egrep -i '(renderer|version)'
EGL_VERSION: 1.4
GL_VERSION: OpenGL ES 2.0 build 1.17@4948957
GL_RENDERER: PowerVR SGX 540
eglinfo:
$ eglinfo | egrep -i '(vendor|version)'
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4
Given that the change landed in 105, I'm wondering if it was maybe backported to the ESR release?
Reporter | ||
Comment 1•2 months ago
|
||
Looking at the changeset more closely, it looks like it was already checking for another form of arm64 bit, so the code might not have worked before then for a while too on armhf, but I'm having trouble trying to use git-blame to go back further and see when this arm64 specific was introduced.
Reporter | ||
Comment 3•2 months ago
|
||
I am running this on a Motorola Droid 4 phone, running Linux 6.1.0 and Mesa 21.2.5. Running Xorg/X11 with EGL and OpenGLES support. But I think this probably more widely applies to other ARM devices too, unless the ARM device has a OpenGL (not OpenGLES) implementation as well.
Comment 4•2 months ago
|
||
I didn't think Mesa supported PowerVR SGX 540. Can you attach your whole glxinfo output?
Reporter | ||
Comment 5•2 months ago
|
||
Thank you for the switch reponses.
glxinfo:
$ glxinfo
name of display: :0.0
Error: couldn't find RGB GLX visual or fbconfig
eglinfo:
$ es2_info
EGL_VERSION: 1.4
EGL_VENDOR: Mesa Project
EGL_EXTENSIONS:
EGL_CHROMIUM_sync_control, EGL_EXT_create_context_robustness,
EGL_EXT_image_dma_buf_import, EGL_EXT_image_dma_buf_import_modifiers,
EGL_KHR_config_attribs, EGL_KHR_create_context, EGL_KHR_fence_sync,
EGL_KHR_get_all_proc_addresses, EGL_KHR_gl_renderbuffer_image,
EGL_KHR_gl_texture_2D_image, EGL_KHR_gl_texture_cubemap_image,
EGL_KHR_image, EGL_KHR_image_base, EGL_KHR_image_pixmap,
EGL_KHR_no_config_context, EGL_KHR_reusable_sync,
EGL_KHR_surfaceless_context, EGL_EXT_pixel_format_float,
EGL_KHR_wait_sync, EGL_MESA_configless_context, EGL_MESA_drm_image,
EGL_MESA_image_dma_buf_export, EGL_NOK_swap_region,
EGL_NOK_texture_from_pixmap, EGL_NV_post_sub_buffer,
user@maindroid:~$ eglinfo
EGL client extensions string:
EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query
EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses
EGL_EXT_client_extensions EGL_KHR_debug EGL_EXT_platform_device
EGL_EXT_platform_wayland EGL_KHR_platform_wayland
EGL_EXT_platform_x11 EGL_KHR_platform_x11 EGL_MESA_platform_xcb
EGL_MESA_platform_gbm EGL_KHR_platform_gbm
EGL_MESA_platform_surfaceless
GBM platform:
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4
EGL client APIs: OpenGL OpenGL_ES
EGL extensions string:
EGL_ANDROID_blob_cache EGL_EXT_buffer_age EGL_KHR_cl_event2
EGL_KHR_config_attribs EGL_KHR_create_context
EGL_KHR_create_context_no_error EGL_KHR_fence_sync
EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace
EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image
EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image
EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap
EGL_KHR_no_config_context EGL_KHR_reusable_sync
EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float
EGL_KHR_wait_sync EGL_MESA_configless_context
EGL_MESA_image_dma_buf_export EGL_MESA_query_driver
Configurations:
bf lv colorbuffer dp st ms vis cav bi renderable supported
id sz l r g b a th cl ns b id eat nd gl es es2 vg surfaces
---------------------------------------------------------------------
0x01 32 0 8 8 8 8 0 0 0 0 0x34325241-- y y y win
0x02 32 0 8 8 8 8 16 0 0 0 0x34325241-- y y y win
0x03 32 0 8 8 8 8 24 0 0 0 0x34325241-- y y y win
0x04 32 0 8 8 8 8 24 8 0 0 0x34325241-- y y y win
0x05 32 0 8 8 8 8 32 0 0 0 0x34325241-- y y y win
0x06 32 0 8 8 8 8 0 0 4 1 0x34325241-- y y y win
0x07 32 0 8 8 8 8 16 0 4 1 0x34325241-- y y y win
0x08 32 0 8 8 8 8 24 0 4 1 0x34325241-- y y y win
0x09 32 0 8 8 8 8 24 8 4 1 0x34325241-- y y y win
0x0a 32 0 8 8 8 8 32 0 4 1 0x34325241-- y y y win
0x0b 24 0 8 8 8 0 0 0 0 0 0x34325258-- y y y win
0x0c 24 0 8 8 8 0 16 0 0 0 0x34325258-- y y y win
0x0d 24 0 8 8 8 0 24 0 0 0 0x34325258-- y y y win
0x0e 24 0 8 8 8 0 24 8 0 0 0x34325258-- y y y win
0x0f 24 0 8 8 8 0 32 0 0 0 0x34325258-- y y y win
0x10 24 0 8 8 8 0 0 0 4 1 0x34325258-- y y y win
0x11 24 0 8 8 8 0 16 0 4 1 0x34325258-- y y y win
0x12 24 0 8 8 8 0 24 0 4 1 0x34325258-- y y y win
0x13 24 0 8 8 8 0 24 8 4 1 0x34325258-- y y y win
0x14 24 0 8 8 8 0 32 0 4 1 0x34325258-- y y y win
0x15 16 0 5 6 5 0 0 0 0 0 0x36314752-- y y y win
0x16 16 0 5 6 5 0 16 0 0 0 0x36314752-- y y y win
0x17 16 0 5 6 5 0 24 0 0 0 0x36314752-- y y y win
0x18 16 0 5 6 5 0 24 8 0 0 0x36314752-- y y y win
0x19 16 0 5 6 5 0 32 0 0 0 0x36314752-- y y y win
0x1a 16 0 5 6 5 0 0 0 4 1 0x36314752-- y y y win
0x1b 16 0 5 6 5 0 16 0 4 1 0x36314752-- y y y win
0x1c 16 0 5 6 5 0 24 0 4 1 0x36314752-- y y y win
0x1d 16 0 5 6 5 0 24 8 4 1 0x36314752-- y y y win
0x1e 16 0 5 6 5 0 32 0 4 1 0x36314752-- y y y win
Wayland platform:
eglinfo: eglInitialize failed
X11 platform:
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4
EGL client APIs: OpenGL_ES
EGL extensions string:
EGL_CHROMIUM_sync_control EGL_EXT_create_context_robustness
EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers
EGL_KHR_config_attribs EGL_KHR_create_context EGL_KHR_fence_sync
EGL_KHR_get_all_proc_addresses EGL_KHR_gl_renderbuffer_image
EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image
EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap
EGL_KHR_no_config_context EGL_KHR_reusable_sync
EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float
EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image
EGL_MESA_image_dma_buf_export EGL_NOK_swap_region
EGL_NOK_texture_from_pixmap EGL_NV_post_sub_buffer
EGL_WL_bind_wayland_display
Configurations:
bf lv colorbuffer dp st ms vis cav bi renderable supported
id sz l r g b a th cl ns b id eat nd gl es es2 vg surfaces
---------------------------------------------------------------------
0x01 32 0 8 8 8 8 0 0 0 0 0x21TC a y y win,pb,pix
0x02 32 0 8 8 8 8 0 0 4 1 0x21TC a y y win,pix
0x03 32 0 8 8 8 8 24 8 0 0 0x21TC a y y win,pb,pix
0x04 32 0 8 8 8 8 24 8 4 1 0x21TC a y y win,pix
0x05 24 0 8 8 8 0 0 0 0 0 0x21TC y y y win,pb,pix
0x06 24 0 8 8 8 0 0 0 4 1 0x21TC y y y win,pix
0x07 24 0 8 8 8 0 24 8 0 0 0x21TC y y y win,pb,pix
0x08 24 0 8 8 8 0 24 8 4 1 0x21TC y y y win,pix
0x09 32 0 8 8 8 8 0 0 0 0 0x22DC a y y win,pb,pix
0x0a 32 0 8 8 8 8 0 0 4 1 0x22DC a y y win,pix
0x0b 32 0 8 8 8 8 24 8 0 0 0x22DC a y y win,pb,pix
0x0c 32 0 8 8 8 8 24 8 4 1 0x22DC a y y win,pix
0x0d 24 0 8 8 8 0 0 0 0 0 0x22DC y y y win,pb,pix
0x0e 24 0 8 8 8 0 0 0 4 1 0x22DC y y y win,pix
0x0f 24 0 8 8 8 0 24 8 0 0 0x22DC y y y win,pb,pix
0x10 24 0 8 8 8 0 24 8 4 1 0x22DC y y y win,pix
Device platform:
eglinfo: eglInitialize failed
And you're right that plain mesa does not support the PowerVR, we have patches to use the Texas Instruments provided driver in Mesa, based on work done by Google on ChromiumOS: https://github.com/maemo-leste-upstream-forks/mesa/commits/maemo/chimaera
Those blobs support OpenGLES, but not OpenGL (as used to be common on many armhf/armv7a devices). As such, our Mesa only exposes OpenGLES, not OpenGL. This is probably true for armhf as much as it is for aarch64?
Reporter | ||
Comment 6•2 months ago
|
||
Apologies, it looks like I pasted es2_info
, not eglinfo
. here it is:
$ eglinfo
EGL client extensions string:
EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query
EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses
EGL_EXT_client_extensions EGL_KHR_debug EGL_EXT_platform_device
EGL_EXT_platform_wayland EGL_KHR_platform_wayland
EGL_EXT_platform_x11 EGL_KHR_platform_x11 EGL_MESA_platform_xcb
EGL_MESA_platform_gbm EGL_KHR_platform_gbm
EGL_MESA_platform_surfaceless
GBM platform:
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4
EGL client APIs: OpenGL OpenGL_ES
EGL extensions string:
EGL_ANDROID_blob_cache EGL_EXT_buffer_age EGL_KHR_cl_event2
EGL_KHR_config_attribs EGL_KHR_create_context
EGL_KHR_create_context_no_error EGL_KHR_fence_sync
EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace
EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image
EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image
EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap
EGL_KHR_no_config_context EGL_KHR_reusable_sync
EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float
EGL_KHR_wait_sync EGL_MESA_configless_context
EGL_MESA_image_dma_buf_export EGL_MESA_query_driver
Configurations:
bf lv colorbuffer dp st ms vis cav bi renderable supported
id sz l r g b a th cl ns b id eat nd gl es es2 vg surfaces
---------------------------------------------------------------------
0x01 32 0 8 8 8 8 0 0 0 0 0x34325241-- y y y win
0x02 32 0 8 8 8 8 16 0 0 0 0x34325241-- y y y win
0x03 32 0 8 8 8 8 24 0 0 0 0x34325241-- y y y win
0x04 32 0 8 8 8 8 24 8 0 0 0x34325241-- y y y win
0x05 32 0 8 8 8 8 32 0 0 0 0x34325241-- y y y win
0x06 32 0 8 8 8 8 0 0 4 1 0x34325241-- y y y win
0x07 32 0 8 8 8 8 16 0 4 1 0x34325241-- y y y win
0x08 32 0 8 8 8 8 24 0 4 1 0x34325241-- y y y win
0x09 32 0 8 8 8 8 24 8 4 1 0x34325241-- y y y win
0x0a 32 0 8 8 8 8 32 0 4 1 0x34325241-- y y y win
0x0b 24 0 8 8 8 0 0 0 0 0 0x34325258-- y y y win
0x0c 24 0 8 8 8 0 16 0 0 0 0x34325258-- y y y win
0x0d 24 0 8 8 8 0 24 0 0 0 0x34325258-- y y y win
0x0e 24 0 8 8 8 0 24 8 0 0 0x34325258-- y y y win
0x0f 24 0 8 8 8 0 32 0 0 0 0x34325258-- y y y win
0x10 24 0 8 8 8 0 0 0 4 1 0x34325258-- y y y win
0x11 24 0 8 8 8 0 16 0 4 1 0x34325258-- y y y win
0x12 24 0 8 8 8 0 24 0 4 1 0x34325258-- y y y win
0x13 24 0 8 8 8 0 24 8 4 1 0x34325258-- y y y win
0x14 24 0 8 8 8 0 32 0 4 1 0x34325258-- y y y win
0x15 16 0 5 6 5 0 0 0 0 0 0x36314752-- y y y win
0x16 16 0 5 6 5 0 16 0 0 0 0x36314752-- y y y win
0x17 16 0 5 6 5 0 24 0 0 0 0x36314752-- y y y win
0x18 16 0 5 6 5 0 24 8 0 0 0x36314752-- y y y win
0x19 16 0 5 6 5 0 32 0 0 0 0x36314752-- y y y win
0x1a 16 0 5 6 5 0 0 0 4 1 0x36314752-- y y y win
0x1b 16 0 5 6 5 0 16 0 4 1 0x36314752-- y y y win
0x1c 16 0 5 6 5 0 24 0 4 1 0x36314752-- y y y win
0x1d 16 0 5 6 5 0 24 8 4 1 0x36314752-- y y y win
0x1e 16 0 5 6 5 0 32 0 4 1 0x36314752-- y y y win
Wayland platform:
eglinfo: eglInitialize failed
X11 platform:
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4
EGL client APIs: OpenGL_ES
EGL extensions string:
EGL_CHROMIUM_sync_control EGL_EXT_create_context_robustness
EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers
EGL_KHR_config_attribs EGL_KHR_create_context EGL_KHR_fence_sync
EGL_KHR_get_all_proc_addresses EGL_KHR_gl_renderbuffer_image
EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image
EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap
EGL_KHR_no_config_context EGL_KHR_reusable_sync
EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float
EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image
EGL_MESA_image_dma_buf_export EGL_NOK_swap_region
EGL_NOK_texture_from_pixmap EGL_NV_post_sub_buffer
EGL_WL_bind_wayland_display
Configurations:
bf lv colorbuffer dp st ms vis cav bi renderable supported
id sz l r g b a th cl ns b id eat nd gl es es2 vg surfaces
---------------------------------------------------------------------
0x01 32 0 8 8 8 8 0 0 0 0 0x21TC a y y win,pb,pix
0x02 32 0 8 8 8 8 0 0 4 1 0x21TC a y y win,pix
0x03 32 0 8 8 8 8 24 8 0 0 0x21TC a y y win,pb,pix
0x04 32 0 8 8 8 8 24 8 4 1 0x21TC a y y win,pix
0x05 24 0 8 8 8 0 0 0 0 0 0x21TC y y y win,pb,pix
0x06 24 0 8 8 8 0 0 0 4 1 0x21TC y y y win,pix
0x07 24 0 8 8 8 0 24 8 0 0 0x21TC y y y win,pb,pix
0x08 24 0 8 8 8 0 24 8 4 1 0x21TC y y y win,pix
0x09 32 0 8 8 8 8 0 0 0 0 0x22DC a y y win,pb,pix
0x0a 32 0 8 8 8 8 0 0 4 1 0x22DC a y y win,pix
0x0b 32 0 8 8 8 8 24 8 0 0 0x22DC a y y win,pb,pix
0x0c 32 0 8 8 8 8 24 8 4 1 0x22DC a y y win,pix
0x0d 24 0 8 8 8 0 0 0 0 0 0x22DC y y y win,pb,pix
0x0e 24 0 8 8 8 0 0 0 4 1 0x22DC y y y win,pix
0x0f 24 0 8 8 8 0 24 8 0 0 0x22DC y y y win,pb,pix
0x10 24 0 8 8 8 0 24 8 4 1 0x22DC y y y win,pix
Device platform:
eglinfo: eglInitialize failed
Assignee | ||
Comment 7•2 months ago
•
|
||
I believe it used to be there.
Hm yeah, there was a certain time frame where we used EGL+GLES for the check on all platforms. Before that we always used GLX+GL, after it EGL+GL - and then, with the mentioned commit, preferring GLES on arm64 again. So acceleration was never deliberately supported on devices like this with GLES 2.0 but no GL 2.0 support - and the breaking commit was earlier than the one mentioned.
I see two possible solutions here:
- prefer GLES on armhf as well.
- extend the fallback path in glxtest to trying both APIs.
P.S.: the later approach has the advantage of also allowing Intel Gen 3?/4? devices to have some WebGL support.
Reporter | ||
Comment 8•2 months ago
|
||
If there is a FOSS mesa driver, it usually implements both GLES and GL, so I would imagine that preferring OpenGLES on armhf is probably a safe bet (as historically those devices only supported GLES, not GL). Trying both APIs is probably worthwhile nonetheless, though.
Comment 9•2 months ago
|
||
Just as a reference, this is how it used to work in version 78
http://uvos.xyz/maserati/videos/IMGP0534.m4v
http://uvos.xyz/maserati/videos/firefox-demonstration.mp4
as of version 91, it takes few seconds per frame (I don't have video but can capture one if needed)
We believe it might be related to the $subject. It could be something else ofc, but there is a big regression in newer versions performance wise.
Comment 10•2 months ago
|
||
Ivaylo can you file a separate bug for that?
Comment 11•2 months ago
|
||
Merlijn, can you post the Graphics section of about:support from the earlier version that did have GPU acceleration?
Assignee | ||
Comment 12•2 months ago
|
||
We already do so on ARM64 and chances are high that drivers have better
GLES support than GL.
Updated•2 months ago
|
Assignee | ||
Comment 13•2 months ago
|
||
Went with a minimal solution as I don't think enabling WebGL on Intel Gen3 is really a good idea, given that the Mesa driver was removed from the main repo already.
Merlijn, unfortunately I can't trigger try builds for 32bit arm - can you build the patch above and check if it solves your issue?
Comment 14•2 months ago
|
||
(In reply to Merlijn B.W. Wajer from comment #0)
https://www.notebookcheck.net/PowerVR-SGX540.115806.0.html
The GPU supports OpenGL ES 2.0 and was announced in November of 2007.
WebRender hardware rendering and WebGL 2 require OpenGL 3.3 or GLES 3.
But gfx.webrender.software.opengl=true (software rendering+hardware compositing like Firefox' old OpenGL compositor) should support GLES2.
On non-Android, you need to enable it manually on about:config and to restart Firefox: Compositing should be "WebRender (Software OpenGL)" on about:support.
Comment 15•2 months ago
|
||
(In reply to Jeff Muizelaar [:jrmuizel] from comment #11)
Merlijn, can you post the Graphics section of about:support from the earlier version that did have GPU acceleration?
Graphics
Features
Compositing: Basic
Asynchronous Pan/Zoom: wheel input enabled; touch input enabled; scrollbar drag enabled; keyboard enabled; autoscroll enabled
WebGL 1 Driver WSI Info: -
WebGL 1 Driver Renderer: WebGL creation failed: * Refused to create native OpenGL context because of blacklist entry: FEATURE_FAILURE_GLXTEST_FAILED * Exhausted GL driver options.
WebGL 1 Driver Version: -
WebGL 1 Driver Extensions: -
WebGL 1 Extensions: -
WebGL 2 Driver WSI Info: -
WebGL 2 Driver Renderer: WebGL creation failed: * Refused to create WebGL2 context because of blacklist entry: FEATURE_FAILURE_GLXTEST_FAILED
WebGL 2 Driver Version: -
WebGL 2 Driver Extensions: -
WebGL 2 Extensions: -
Window Protocol: x11
Target Frame Rate: 60
GPU #1
Active: Yes
Description: GLXtest process failed (exited with status 1): X error occurred in GLX probe, error_code=8, request_code=151, minor_code=5
RAM: 0
This is the info from the last version (in debian repos that is) that has good performance. Unfortunatley, it seem that even there GPU is not used.
Comment 16•2 months ago
|
||
(In reply to Jeff Muizelaar [:jrmuizel] from comment #10)
Ivaylo can you file a separate bug for that?
Sure, will do.
Comment 17•2 months ago
|
||
What's the version number for the fast version?
Comment 18•2 months ago
|
||
Yeah, sorry about that:
Application Basics
Name: Firefox
Version: 78.15.0esr
Build ID: 20210927121355
Distribution ID:
User Agent: Mozilla/5.0 (X11; Linux armv7l; rv:78.0) Gecko/20100101 Firefox/78.0
OS: Linux 6.1.0-rc8
Updated•2 months ago
|
Assignee | ||
Comment 19•2 months ago
|
||
Compositing: Basic
That unfortunately looks like not being about acceleration at all - but simply that the old software renderer worked better on this devices and the new one, software webrenderer, appears to be too heavy. I don't see high chances that anyone will spend a lot of time to try to further optimize for such low-end devices any more though :/
Assignee | ||
Updated•2 months ago
|
Comment 20•2 months ago
|
||
Pushed by robert.mader@posteo.de: https://hg.mozilla.org/integration/autoland/rev/1d73612d3ac2 Also use GLES in glxtest on ARM 32bit, r=gfx-reviewers,nical
Comment 21•2 months ago
|
||
bugherder |
Comment 22•2 months ago
|
||
Ivaylo, if you can get a profile (https://profiler.firefox.com/) of Firefox Nightly using the "Graphics" preset on your hardware it would be interesting to see where the time is being spent.
Comment 23•2 months ago
|
||
(In reply to Jeff Muizelaar [:jrmuizel] from comment #22)
Ivaylo, if you can get a profile (https://profiler.firefox.com/) of Firefox Nightly using the "Graphics" preset on your hardware it would be interesting to see where the time is being spent.
I was not able to find any armhf builds of Firefox (Nightly or not) besides the ones in debian repos (maybe other distros provide such builds as well, didn't check).
Trying to capture profile with 102.7.0esr from debian repo ends up with a crash of the auto-opened tab after capture is stopped. Crash report seems to be sent.
If there is any way to get the profile data with 'from-browser' tab crashing, please let me know.
Comment 24•2 months ago
|
||
What's the url for the crash report?
Comment 25•2 months ago
|
||
Comment 26•2 months ago
|
||
Shall I try to get more useful backtrace by installing debug symbols?
Comment 27•2 months ago
|
||
With debug symbols installed, not that I see any difference:
https://crash-stats.mozilla.org/report/index/a68e871a-faf8-4c0b-a650-4fd370230125
Comment 28•2 months ago
|
||
Yeah, I don't think installing the debug symbols will help us get a better stack. Given the brokeness of both crash reporting and profiling it's going to be hard to make much progress.
Comment 29•2 months ago
|
||
Well, hopefully gdb still works, will try to get backtrace
Comment 30•2 months ago
|
||
No dice:
Thread 18 "DOM Worker" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xa6fff440 (LWP 30449)]
0x24aa80bc in ?? ()
(gdb) bt
#0 0x24aa80bc in ()
#1 0x24a85c48 in ()
(gdb) info threads
Id Target Id Frame
1 Thread 0xb6f52220 (LWP 30285) "Isolated Web Co" 0xaec6e09c in nsCycleCollectionParticipant::NoteJSChild(JS::GCCellPtr, char const*, void*) () from /usr/lib/firefox-esr/libxul.so
2 Thread 0xae3d8440 (LWP 30290) "IPC I/O Child" __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
3 Thread 0xa9b70440 (LWP 30298) "Socket Thread" __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
4 Thread 0xb6f18440 (LWP 30301) "JS Watchdog" __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
5 Thread 0xa95ff440 (LWP 30303) "BackgroPool #1" __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46ller #0" __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
6 Thread 0xa95be440 (LWP 30304) "Timer" __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
7 Thread 0xa957d440 (LWP 30305) "RemVidChild" __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
8 Thread 0xa93d0440 (LWP 30312) "ImageIO" __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
9 Thread 0xa9109440 (LWP 30313) "TaskCon
10 Thread 0xa8f0a440 (LWP 30314) "TaskCon~ller #1" __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
11 Thread 0xa9345440 (LWP 30321) "ImageBridgeChld" __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
12 Thread 0xa8c85440 (LWP 30322) "ProcessHangMon" __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
13 Thread 0xa8c44440 (LWP 30323) "ProfilerChild" __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
14 Thread 0xa8afa440 (LWP 30411) "Worker Launcher" __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
15 Thread 0xa8ab5440 (LWP 30416) "HTML5 Parser" __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
16 Thread 0xa79ff440 (LWP 30446) "RemoteLzyStream" __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
- 18 Thread 0xa6fff440 (LWP 30449) "DOM Worker" 0x24aa80bc in ?? ()
19 Thread 0xa799b440 (LWP 30455) "StreamTrans #3" __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
20 Thread 0xa74ff440 (LWP 30456) "StreamTrans #4" __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
Seems debian maintainers, for some reason, decided that they should provide empty dbgsym package for armhf firefox :(
Will try to do local build with debug symbols enabled.
Description
•