Repository navigation
glTexImage2d crashes in libGLESv2_mtk.so. #103498
Description
In b/217143672 and it's duplicates, we are still seeing crashes in /vendor/lib/egl/libGLESv2_mtk.so (glTexImage2D+156) even after flutter-team-archive/engine#32106.
I don't think this will be actionable without a local repro to work from, but do we have any MediaTek devices in the device library to run the customer: money app on? @dnfield @jason-simmons.
Reacted by Miguel Beltran, Yang Chao, Nico:Roy, Mike, dodatw, kreativityapps, Hadi Santoso, KaelTeck and Jaween Ediriweera
Activity
dnfield commentedon May 11, 2022
Are you sure you linked the right engine PR? The stack trace in the internal bug doesn't look obviously related to it.
Here are some slightly sanitized traces:
And
In one case it looks like Skia is trying to run a shader the GPU/driver doesn't like. In the other it looks like Skia is trying to push pixels to the GPU and it's crashing.
zanderso commentedon May 11, 2022
@dnfield I could have been led astray by the possibly unrelated comment here #91962 (comment), on an issue closed by the linked PR =(
dnfield commentedon May 11, 2022
FWIW Wembley is a MediaTek device.
dnfield commentedon May 11, 2022
Why is that first one happening on the IO thread...
johnstiles-google commentedon May 11, 2022
The first crawl is invalid—it looks like two unrelated crawls mashed together.
apply_kernel_in_yis a leaf function that does math in a loop. It doesn't involve anything GL-related at all.jason-simmons commentedon May 11, 2022
Is there any way to get more info on the state of the app when these crashes happen? In particular, is the app midway through shutdown?
In both traces the crash is coming from a call to
glTexImage2Don the IO thread.(The
libflutter.sosymbolization in the first stack trace looks inaccurate and was probably done using the wrong binary.)There are a lot of potential races involving the
ConcurrentTaskRunner, IO thread, and UI thread during image decoding (see #103517).But I would expect the IO thread's
glTexImage2Dcall to happen when the decoded image is uploaded to a texture. That should only happen if the IO thread task verifies that theIOManageris still alive. In that case the SkiaGrDirectContextand EGL context will still be active and it should be safe to call OpenGL ES APIs.chinmaygarde commentedon May 16, 2022
I think we need to get our hands on this device and attempt to reproduce this issue. There isn't enough information here to make progress and we are speculating.
dchang109 commentedon Jul 4, 2022
dodatw commentedon Jul 28, 2022
I saw the same crash after upgrade to flutter 3.0.5 on Redmi 9/Android 10
ndahlquist commentedon Oct 18, 2022
The stacktrace here looks a bit different, so I apologize if it's not the same root cause, but we just had a customer report a crash in
glTexImage2DinlibGLESv2_mtk:Flutter 3.3.4
Device: Samsung Galaxy A03s TracFone (SM-S134DL)
blaugold commentedon Dec 10, 2022
Here are the symbolicated stack frames within
libflutter.sofrom a crash whereglTexImage2Dis eventually called:Full crash
The Flutter version of the crash is 2.10.3 but the same crash still happens with version 3.3.9.
bdezso commentedon Jan 1, 2023
I have 99.2% crash free user, all crash come from this:
backtrace:
#00 pc 0x000000000002bfcc /vendor/lib/egl/libGLESv2_mtk.so
#1 pc 0x0000000000041ddd /vendor/lib/egl/libGLESv2_mtk.so
#2 pc 0x000000000002bf71 /vendor/lib/egl/libGLESv2_mtk.so
#3 pc 0x000000000006c867 /vendor/lib/egl/libGLESv2_mtk.so
#4 pc 0x000000000006c3bd /vendor/lib/egl/libGLESv2_mtk.so (glTexImage2D+156)
#5 pc 0x000000000002ab8f /vendor/lib/egl/libGLES_meow.so
#6 pc 0x0000000000352e29 /data/app/com.mrkresz.app-hso0GB9shZmuPWncYOfUoA==/lib/arm/libflutter.so
#7 pc 0x000000000021a605 /data/app/com.mrkresz.app-hso0GB9shZmuPWncYOfUoA==/lib/arm/libflutter.so
#8 pc 0x00000000002f9dc7 /data/app/com.mrkresz.app-hso0GB9shZmuPWncYOfUoA==/lib/arm/libflutter.so
#9 pc 0x0000000000000438
chenenyu commentedon Jan 10, 2023
We are using flutter 3.3.x, 2% crashes are produced by this issue in my app. 😢 Any progress?
KaelTeck commentedon Jan 23, 2023
Any updates? Is there a solution to this problem?
SvenFang commentedon Mar 14, 2023
Any progress?
ronnieCodeWang commentedon Apr 3, 2023
Any progress?
zanderso commentedon Apr 3, 2023
This issue has been open for nearly a year, and since there is no new information about the device where it happens or repro steps, I'm going to close this as not actionable. In general, we are not able to take action on crash logs from crash reporting services without knowing the device where the crash happens and local repro instructions.
github-actions commentedon Apr 17, 2023
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.