EXC_BAD_ACCESS in ScavengerVisitorBase<true>::ProcessRoots
#48843
Comments
|
Seems like corrupt heap. Possible bug in |
mraleph
added
the
area-vm
|
It's all open-source, so I can share the exact setup to reproduce this.
git clone https://github.com/blaugold/embedded_db_benchmark --depth 1 -b gc-crash-repro
cd embedded_db_benchmark/packages/app
flutter pub get
flutter run -d macos --profile
If there is too much going on, I can try to find a simpler setup. |
|
I can reproduce this with multiple tries: I can only reproduce this on the x64 Macbook, not on the m1, I haven't figured out how to build a Flutter app there. I can see if I can reproduce this in Dart standalone, that would be easier to diagnose. |
|
I have been able to reproduce this issue on an M1, but on the Flutter master channel. |
I can't seem to find any use of
It only reproduces one in every 10-20 runs here. Things that would make it simpler:
off-topic: I can't seem to run on arm64 even on the master channel:
|
Sorry about that. I should have explained that better. The finalizer is in the I'll try and see if I can do something about the points you mentioned.
Maybe a |
👍 😅 Though on the last master It does also reproduce on
Cool! Let me know if you make any progress. |
On a Mac mini M1 and the Flutter beta channel with
I have updated the repro branch so that the
I'll try to isolate the problem more. Since I'm using FFI there's also a chance that the native database library is somehow corrupting memory. Is this commit related to this issue at all?
I can repro the issue with a debug build, but only with a different dev build of the database C library. This dev build has an optimization which cuts down execution time of a few operations significantly, which seems to change the timing so that the issue is also observable with a debug build. I did not run in to any other asserts, though. |
No, It still happens on the last master channel, which includes that commit
Same here, even with the same db. Same crash report in the Console. (Bad access generates a crash report, hitting the invalid cid prints in the console and hangs or exits.) This means it happens both in JIT and AOT.
On the Macbook with M1 it does crash more often than on the x64 Macbook indeed (but still only once in a couple of runs).
I have no reproductions either. I tried running the debug/release/product(profile) standalone dart built from the main branch, both with Even with running the GC verification flags (e.g. Lines 237 to 244 in a5a7b4c
Unfortunately we cannot pass the same flags to flutter: I can try to work around that my making a local build with the flags enabled. It might be something related to Flutter, but it could also be that the timing is just slightly different in standalone. As far as I can see, Flutter uses the same Scavenger settings: Lines 141 to 143 in a5a7b4c The crash is always happening on the second thread. Lines 156 to 159 in a5a7b4c Lines 167 to 169 in a5a7b4c Also the heap size defaults seem to not be overwritten in the Flutter code base.
👍 |
|
I have updated I have also been able to isolate the issue a bit more and frame scheduling seems to play into it somehow, not sure whether it's just influencing the timing in a way that makes the issue more probable, though. The Flutter app now just runs the benchmark (no call to // packages/app/lib/main.dart
...
await runBenchmark(
onProgress: WidgetsBinding.instance.scheduleForcedFrame,
);
...
|
|
@zanderso I'm trying to build arm64 mac on an arm64 mac host. I took the command from flutter/flutter#84453 and https://flutter-review.googlesource.com/c/recipes/+/25800/2/recipes/engine.py#1113 But it seems that one of our dependencies doesn't support arm64. if (current_cpu == "x64") {
defines += [
"SZTARGET=X8664",
"SUBZERO_TARGET=X8664",
]
} else if (current_cpu == "x86") {
defines += [
"SZTARGET=X8632",
"SUBZERO_TARGET=X8632",
]
} else {
assert(false, "Unsupported platform.")
}Did you see this before? Are you cross-compiling from x64 instead of compiling on arm64? My goal is to do Edit: turns out we don't have support for build Mac arm64 on Mac arm64 just yet. |
@blaugold Thanks! With this I've been able to use a local engine build on Mac x64 with
I think this is rather unlikely with the new information. Every crash is trying to read memory where used to be a Any chance you could make your repro project run on Linux? |
It should already work on Ubuntu x86, but I haven't tried it yet and don't know whether it reproduces there. I'll finally have to get my Linux box running again. 😅 |
|
Okay, I am now able to repro the issue in a unit test. 🎉 @blaugold while I work on a fix, a temporary workaround would be to create a new finalizer object for every time you want to attach a finalizer. This will be less efficient, but should prevent the crash for the time being. |
|
Fix underway: https://dart-review.googlesource.com/c/sdk/+/243262 |
`MournFinalized` runs during marking and can add objects to the store buffer. These objects are stored in the threads' store buffer block. This block needs to be released to the central store buffer in order for the objects' addresses to be updated during compacting. TEST=runtime/vm/object_test.cc TEST=tools/test.py vm/cc/Finalizer_Regress_48843 Closes: #48843 Change-Id: Ib2424929c86fee730d3f09fbd2f9f6c97f31abfd Cq-Include-Trybots: luci.dart.try:vm-canary-linux-debug-try,vm-kernel-linux-debug-x64-try,vm-kernel-linux-debug-x64c-try,vm-kernel-mac-debug-x64-try,vm-kernel-win-debug-x64-try,vm-kernel-linux-release-x64-try,vm-kernel-linux-product-x64-try,vm-kernel-linux-debug-ia32-try,vm-kernel-linux-release-ia32-try Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243262 Reviewed-by: Slava Egorov <vegorov@google.com> Commit-Queue: Daco Harkes <dacoharkes@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com>
|
Can this be closed ? |
|
It is closed? |
I recently started experimenting with using
Finalizerand I am now seeing crashes on iOS and macOS that seem to be GC related. I have not tested other platforms. The included back traces are from an iPhone 8.The crashes occur during a benchmark where thousands of objects per second are created, then attached to a
Finalizerand become quickly unreachable again.Back traces of the two threads performing GC:
Back traces of all threads
Update
I was able to capture this back trace on macOS:
The text was updated successfully, but these errors were encountered: