Skip to content

[Android/iOS] Crash after onCreateWindow with supportMultiWindows enabled (EXC_BAD_ACCESS / SIGSEGV in native layer) #2620

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

Open
1 of 2 tasks
aniac0105 opened this issue May 14, 2025 · 0 comments
Labels
bug Something isn't working

Comments

@aniac0105
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

When using supportMultiWindows: true, the app crashes in the native layer shortly after successfully handling onCreateWindow and creating a new webview.

When it happens: Clicking a button that triggers window.open('', '_blank') (i.e., with a null or about:blank URL).

Crash timing: 1–2 seconds after the new webview is created and shown.

======
Key log excerpt:
Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
AddressSanitizer: DEADLYSIGNAL in libmonochrome.so

Environment:
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.29.0, on macOS 15.3.2 24D81 darwin-arm64, locale ko-KR)
[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
[✓] Xcode - develop for iOS and macOS (Xcode 16.2)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2024.1)
[✓] VS Code (version 1.98.2)
[✓] Connected device (5 available)
[✓] Network resources

Additional Context:

Notable: Other popups (with explicit URLs) on the same page work fine.

Workarounds attempted:

Added Future.delayed before returning from onCreateWindow

Used a data URI instead of about:blank

Upgraded inappwebview to the latest version

Questions for the maintainer:

Are there any special guidelines for memory management or windowId handling in this scenario?

Is there an additional initialization step required when handling about:blank or empty URLs?

Is this a known issue with Chromium/WebView itself?

Are there any recommended workarounds for this situation?

Thank you for your help! 🙏

Crash Log Excerpt

text
W/chromium( 4717): [WARNING:aw_contents_io_thread_client.cc(270)] No IoThreadClient associated with parent RenderFrameHost.
F/libc ( 4717): Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x11 in tid 4717 (afe24.cafe24pro), pid 4717 (afe24.cafe24pro)
Build fingerprint: 'google/sdk_gphone64_arm64/emu64a:14/UE1A.230829.050/12077443:userdebug/dev-keys'
Revision: '0'
ABI: 'arm64'
Timestamp: 2025-05-12 23:20:59.699301229+0900
Process uptime: 103s
Cmdline: com.cafe24.cafe24pro
pid: 4717, tid: 4717, name: afe24.cafe24pro >>> com.cafe24.cafe24pro <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0000000000000011
Cause: null pointer dereference

#00 pc 0000000003a127f4 /data/app/.../TrichromeLibrary.apk!libmonochrome_64.so (offset 0x8a9000)
#1 pc 000000000323ebb0 /data/app/.../TrichromeLibrary.apk!libmonochrome_64.so (offset 0x8a9000)
#2 pc 000000000323ead4 /data/app/.../TrichromeLibrary.apk!libmonochrome_64.so (offset 0x8a9000)
#3 pc 000000000323d628 /data/app/.../TrichromeLibrary.apk!libmonochrome_64.so (offset 0x8a9000)
#4 pc 0000000003430144 /data/app/.../TrichromeLibrary.apk!libmonochrome_64.so (offset 0x8a9000)
...
Lost connection to device. Exited.
Summary of key points:

Timestamp: 2025-05-12 23:20:59.699301229+0900

Signal: SIGSEGV (SEGV_MAPERR), null pointer dereference

Library: libmonochrome_64.so (TrichromeLibrary.apk, Android WebView/Chromium)

Device: Android 14 emulator, arm64 ABI

Process: com.cafe24.cafe24pro

Expected Behavior

App crash.

Steps with code example to reproduce

Steps with code example to reproduce
// Paste your code here

Stacktrace/Logs

Stacktrace/Logs
<Replace this line by pasting your stacktrace or logs here>

Flutter version

v3.29.0

Operating System, Device-specific and/or Tool

android , ios 15.6 +

Plugin version

v6.1.5, 6.2.0-beta.2

Additional information

No response

Self grab

  • I'm ready to work on this issue!
@aniac0105 aniac0105 added the bug Something isn't working label May 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant