flutter-intellij
flutter-intellij copied to clipboard
flutter
crash when tap on right panel in android-studio
DevTools version: 2.42.3 IDE: Android-Studio
A fatal error has been detected by the Java Runtime Environment: SIGABRT (0x6) at pc=0x00007dabb369eb1c (sent by kill), pid=1257131, tid=1259032 JRE version: OpenJDK Runtime Environment (21.0.5) (build 21.0.5+-13047016-b750.29) Java VM: OpenJDK 64-Bit Server VM (21.0.5+-13047016-b750.29, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) Problematic frame: C [libc.so.6+0x9eb1c] pthread_kill+0x11c Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/bigi/Desktop/core.1257131) If you would like to submit a bug report, please visit: https://youtrack.jetbrains.com/issues/JBR The crash happened outside the Java Virtual Machine in native code. See problematic frame for where to report the bug.
Host: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz, 20 cores, 31G, Ubuntu 24.04 LTS Time: Sun Apr 6 21:44:01 2025 +03 elapsed time: 259.194567 seconds (0d 0h 4m 19s)
--------------- S Y S T E M ---------------
OS: DISTRIB_ID=Ubuntu DISTRIB_RELEASE=24.04 DISTRIB_CODENAME=noble DISTRIB_DESCRIPTION="Ubuntu 24.04 LTS" uname: Linux 6.8.0-31-generic flutter/devtools#31-Ubuntu SMP PREEMPT_DYNAMIC Sat Apr 20 00:40:06 UTC 2024 x86_64 OS uptime: 8 days 4:54 hours libc: glibc 2.39 NPTL 2.39 rlimit (soft/hard): STACK 8192k/infinity , CORE 0k/infinity , NPROC 127471/127471 , NOFILE 1048576/1048576 , AS infinity/infinity , CPU infinity/infinity , DATA infinity/infinity , FSIZE infinity/infinity , MEMLOCK 4099092k/4099092k load average: 4,33 4,33 3,82
/proc/meminfo: MemTotal: 32792760 kB MemFree: 477912 kB MemAvailable: 15197296 kB Buffers: 576204 kB Cached: 13266288 kB SwapCached: 12604 kB Active: 14375352 kB Inactive: 15185584 kB Active(anon): 12894684 kB Inactive(anon): 3109064 kB Active(file): 1480668 kB Inactive(file): 12076520 kB Unevictable: 320 kB Mlocked: 320 kB SwapTotal: 16777244 kB SwapFree: 16319772 kB Zswap: 0 kB Zswapped: 0 kB Dirty: 64492 kB Writeback: 0 kB AnonPages: 15701900 kB Mapped: 2020428 kB Shmem: 285304 kB KReclaimable: 1631408 kB Slab: 2161868 kB SReclaimable: 1631408 kB SUnreclaim: 530460 kB KernelStack: 44080 kB PageTables: 131864 kB SecPageTables: 0 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 33173624 kB Committed_AS: 53370564 kB VmallocTotal: 34359738367 kB VmallocUsed: 108236 kB VmallocChunk: 0 kB Percpu: 32160 kB HardwareCorrupted: 0 kB AnonHugePages: 45056 kB ShmemHugePages: 0 kB ShmemPmdMapped: 0 kB FileHugePages: 0 kB FilePmdMapped: 0 kB Unaccepted: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB Hugetlb: 0 kB DirectMap4k: 951720 kB DirectMap2M: 31490048 kB DirectMap1G: 3145728 kB
/sys/kernel/mm/transparent_hugepage/enabled: always [madvise] never /sys/kernel/mm/transparent_hugepage/hpage_pmd_size: 2097152 /sys/kernel/mm/transparent_hugepage/defrag (defrag/compaction efforts parameter): always defer defer+madvise [madvise] never
Process Memory: Virtual Size: 41033872K (peak: 41034972K) Resident Set Size: 1979208K (peak: 1979208K) (anon: 1462756K, file: 516268K, shmem: 184K) Swapped out: 0K C-Heap outstanding allocations: 624177K, retained: 9538K glibc malloc tunables: (default)
/proc/sys/kernel/threads-max (system-wide limit on the number of threads): 254943 /proc/sys/vm/max_map_count (maximum number of memory map areas a process may have): 1048576 /proc/sys/vm/swappiness (control to define how aggressively the kernel swaps out anonymous memory): 60 /proc/sys/kernel/pid_max (system-wide limit on number of process identifiers): 4194304
container (cgroup) information: container_type: cgroupv2 cpu_cpuset_cpus: not supported cpu_memory_nodes: not supported active_processor_count: 20 cpu_quota: no quota cpu_period: 100000 cpu_shares: no shares memory_limit_in_bytes: unlimited memory_and_swap_limit_in_bytes: unlimited memory_soft_limit_in_bytes: unlimited memory_usage_in_bytes: 18772556 k memory_max_usage_in_bytes: not supported memory_swap_current_in_bytes: 281268 k memory_swap_max_limit_in_bytes: unlimited maximum number of tasks: unlimited current number of tasks: 1677
Steal ticks since vm start: 0 Steal ticks percentage since vm start: 0,000
CPU: total 20 (initial active 20) (10 cores per cpu, 2 threads per core) family 6 model 62 stepping 4 microcode 0x42e, cx8, cmov, fxsr, ht, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, tsc, tscinvbit, avx, aes, erms, clmul, vzeroupper, clflush, rdtscp, f16c CPU Model and flags from /proc/cpuinfo: model name : Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts vnmi md_clear flush_l1d
Online cpus: 0-19 Offline cpus: BIOS frequency limitation: <Not Available> Frequency switch latency (ns): 20000 Available cpu frequencies: <Not Available> Current governor: schedutil Core performance/turbo boost: <Not Available>
Memory: 4k page, physical 32792760k(15197296k free), swap 16777244k(16319772k free) Page Sizes: 4k
vm_info: OpenJDK 64-Bit Server VM (21.0.5+-13047016-b750.29) for linux-amd64 JRE (21.0.5+-13047016-b750.29), built on 2025-02-11T21:24:04Z by "builder" with clang Android (12328485, +pgo, +bolt, +lto, +mlgo, based on r530567) Clang 19.0.0 (https://android.googlesource.com/toolchain/llvm-project 97a699bf4812a18fb657c2779f5296a4ab2694d2)
END.
@alexbigi: could you give us any pointers on how we might reproduce this? Does it happen consistently?
@alexbigi: could you give us any pointers on how we might reproduce this? Does it happen consistently?
it happens after update to meerkat. if downgrade to koala, all works fine. i'm upgrade ubuntu to 24.10, but problem not gone. i'm clear all studio setting i'm install-uninstall meerkat from snap|deb package|direct zip|maarten-fonville repos reproduce: install studio meerkat with installed flutter. add flutter plugin. tap on flutter dev tools on right panel. and crash.
i'm found temporary solution, create android emulator and start it, after that flutter dev tools is started without crash. but if restart studio i have troble agan. for repar it need delete emulator, create new and start it.
how it work. i don't understand)
With M85 yesterday we did intentionally push to Koala (but not earlier). A stack trace or even confirmation that the issue is not in Koala, but is in Ladybug would be useful here. By "right panel" what do you mean? A screenshot would be fine.
With M85 yesterday we did intentionally push to Koala (but not earlier). A stack trace or even confirmation that the issue is not in Koala, but is in Ladybug would be useful here. By "right panel" what do you mean? A screenshot would be fine.
you dont understand me. troubles ONLY IN MEERKAT and only on ubuntu, on downgraded studios all right.
this button on right panel
@alexbigi @solody Can you guys try this? https://github.com/flutter/flutter-intellij/issues/8196#issuecomment-2884354662
@alexbigi @solody Can you guys try this? #8196 (comment)
Thank you, this fixes the issue on Fedora 42
Thank you, @debuggerx01!
According to @vlad-lubenskyi, the jxbrowser team is on it (https://github.com/flutter/flutter-intellij/issues/8196#issuecomment-2886619678).
Same issue started happening for me on Ubuntu 24.04 with AS Meerkat after updating Flutter version and clicking on Flutter related tabs in AS.
We can't reproduce the issue with 21.0.7 beta, so that's it.
@vlad-lubenskyi will JX Browser be making changes to be compatible with the problematic version of JBR, or should we close this issue since users will likely be migrating off the problematic version soon?
We can't reproduce the issue with 21.0.7 beta, so that's it.
@vlad-lubenskyi will JX Browser be making changes to be compatible with the problematic version of JBR, or should we close this issue since users will likely be migrating off the problematic version soon?
I know you mean well here, so please accept that I mean the same here: comments/positions like this are in large part why the developer community is wary and frustrated doing any development on Google platforms and frameworks.
To presume that users will 'just migrate off the problematic version soon' comes across as dismissive of the time investment we as developers ultimately have to make over and over and over again to supplicate Google's constant onslaught of broken, poorly documented, and incompatible releases.
Specifically because of this bug I have been using Jellyfish exclusively and haven't even looked at any later releases. My last experience with Lovebug was that It Was Broken and I have development to do, so I need Something That Works. And just now, to provide the benefit of the doubt to the team, I upgraded to Meerkat in hopes that I could move forward.
But I can't just move forward. Opening my project in the latest version of AOSP has triggered some sort of new AGP upgrade/incompatibility that means a lot of modals imploring me to update to SDK 35 and now having made ZERO changes to my project it won't even compile. And it's not a complex app. It's not loading any external libraries, it's entirely on Google Run Stuff, and, well, it just doesn't work. So now I will have to spend X number of minutes or hours deciphering glyphs and greek to discern what has changed in my IDE just so I can write basic code. And this happens over and over and over and over. So it's incredibly frustrating to see such a flippant remark from the team that we should just continue to carry water for broken releases and builds. It's our time your asking for and our time is at a premium.
Your comment also dismisses the value of tool familiarity. Each new release risks new UI/UX, changed/reverted configurations, broken/deprecated plugins, new behaviors, etc...etc...It's a lot of often unnecessary noise that we have to attend to in the middle of handling our clients and employers. Once upon a time, we had respected versioning semantics to help navigate that, but Google has long abandoned the principle and so we often must avoid updates in favor of deadlines.
So I understand that what you mean to say here is well meaning, but please consider that it may in fact be received less than favorably.
We can't reproduce the issue with 21.0.7 beta, so that's it.
@vlad-lubenskyi will JX Browser be making changes to be compatible with the problematic version of JBR, or should we close this issue since users will likely be migrating off the problematic version soon?
I know you mean well ...
Just a brief follow-up for the void: Opening my app in Meerkat has completely borked my project. It's only seen as an 'Android' project, the Gradle Upgrade failed and has left my project files in an in-determinant state. The upgrade assistant said it was going to 8.10.2 and the error says the minimum required is 8.11. I now have four main folders, compilation is a foregone conclusion giving me nothing but errors and it looks as if by-practice-unversioned gradle files were changed so rolling back isn't an option. The IDE no longer seems to show my main branch, but maybe that's a UX change so perhaps in the settings somewhere....
So what should have been an innocuous bug that should have been caught in smoke testing is now a personal problem that I can't even do anything about if I wanted to b/c we as a community can't build AOSP from source b/c of the lack of documentation and well, it's just really frustrating sometimes trying to be a Flutter developer...
@vlad-lubenskyi I don't totally understand this issue and how many people may be / may have been affected. It sounds like there was one particular version of Java included with a certain distribution of Linux that was causing this problem, but it no longer existed in the next version of Java, with no intervention from JX Browser? Or would we benefit from installing a later version of JX Browser because your team has made some changes that protect against the issue even with the originally problematic version of Java?
@strangedreamsNY Sorry, I made a flippant comment regarding versioning, which is a complex problem for a lot of users. I'll keep in mind for future replies not to imply that version issues are easy or a user responsibility. I think some of these issues are outside of our control (e.g. Java/operating system/Android platform versioning), but within this project we're working on how to clarify what Flutter versions are supported and verify our support with better testing. Compatibility with Android is another spot we're hoping to make progress on. Sorry I don't have more concrete steps for what you're describing; if you'd like to file bugs for these issues we can try to untangle.
I had the same issue.
This helped me: https://intellij-support.jetbrains.com/hc/en-us/articles/206544879-Selecting-the-JDK-version-the-IDE-will-run-under
changed to 21.0.7+9-895.130-jcef JetBrains Runtime
Restart and no crashes.
It seems that the fixed JBR v21.0.7 has been the default for a few months now for 2025.1 and 2025.2, so updating Android Studio should fix the problem. If the JBR remains 21.0.6, we recommend manually changing it as in https://github.com/flutter/flutter-intellij/issues/8196#issuecomment-2884354662