There are two flags that control code collection: --code_collection_interval_in_us, which you can set to 0, and --always_drop_code, which causes code to be dropped regardless of the functions use count.

Do you encounter the same problem when you run with those flags?

Added NeedsInfo label.

Yes, I know. None of our tests are run with these flags.

I found this test code_collection_test.dart, but it seems that overwriting the code with a random value on GC does not make it crash as it should.

Could you explain a bit more what you mean by "overwriting the code with a random value on GC", or maybe paste a small patch here? Thanks.

I tried the following diff: I think the test does not actually call foo after code GC happened. Othwerwise, it would fine 123 as the code pointer. I do get a crash when running test.py with --vm-options="--code_collection_interval_in_us=0", but that flag in not on by default.

Index: runtime/vm/gc_marker.cc
===================================================================

--- runtime/vm/gc_marker.cc (revision 34110)
+++ runtime/vm/gc_marker.cc (working copy)
@@ -249,8 +249,8 @­@
         // If the code wasn't strongly visited through other references
         // after skipping the function's code pointer, then we disconnect the
         // code from the function.

•    func->ptr()->code_ = Code::null();
  

•    func->ptr()->unoptimized_code_ = Code::null();
  

•    func->ptr()->code_ = reinterpret_cast<RawCode*>(123); //Code::null();
  

•    func->ptr()->unoptimized_code_ = reinterpret_cast<RawCode*>(456); // Code::null();
  

           if (FLAG_log_code_drop) {
             // NOTE: This code runs while GC is in progress and runs within
             // a NoHandleScope block. Hence it is not okay to use a regular Zone
  Index: tests/standalone/io/code_collection_test.dart
  ===================================================================

--- tests/standalone/io/code_collection_test.dart (revision 34110)
+++ tests/standalone/io/code_collection_test.dart (working copy)
@@ -34,6 +34,7 @­@
       timer.cancel();
       // foo is called again to make sure we can still run it even after
       // its code has been detached.

•  throw 123;
  

         foo(2);
       }
     });
  @@ -57,6 +58,7 @­@
       // Code drops are logged with --log-code-drop. Look through stdout for the
       // message that foo's code was dropped.
       var found = false;
• print(pr.stdout);
       pr.stdout.split("\n").forEach((line) {
         if (line.contains("Detaching code") && line.contains("foo")) {
           found = true;

Any updates on this?

Florian, apparently you did have a test setup that was covering the problem. Why did you not submit that version of the test?

It seems that the test is not checking the return code of the dart process it spawned.

Added Accepted label.

I don't remember precisely, but I don't think I have a fixed version of the test (or I can't find it anymore). The patch set above just illustrates the issue (i.e. foo is not called after code GC)

The test is now checking the exit code of the spawned process, and has otherwise been hardened.