Stale Read — Known Codegen Bug?

[Daryl Haresign]

I have evidence of what I would call an impossibility, but it's supported by explicit logs that came out of running code, so I'm going to believe the logs.  This is from v8 12.2, so I'm interested to know whether a) anyone has seen anything like this, b) whether there have been any recent fixes in this space, c) if not whether anyone knows what might be up.

Thanks,

Daryl.

Code (not the exact code, but functionally equivalent):

  function f(blob) {

    let logs = [];

    let bits = 0;

    function e() {

      bits -= 6;

      logs.push(`e(), bits = ${bits}`);

    }

    blob.bytes() // native function that returns an array of integers

      .forEach(function (byte) {

        logs.push(`bytes forEach #0, bits = ${bits}`);

        bits += 8;

        logs.push(`bytes forEach #1, bits = ${bits}`);

        e();

        logs.push(`bytes forEach #2, bits = ${bits}`);

        if (6 <= bits) {

          logs.push(`bytes forEach #3, bits = ${bits}`);

          e();

          logs.push(`bytes forEach #4, bits = ${bits}`);

        }

      });

    console.log(logs);

  }

and the logs look like:

  <many occurrences where everything is fine>

  bytes forEach #0, bits = 4
  bytes forEach #1, bits = 12
  e(), bits = 6
  bytes forEach #2, bits = 6
  bytes forEach #3, bits = 6
  e(), bits = 0
  bytes forEach #4, bits = 0
  bytes forEach #0, bits = 0
  bytes forEach #1, bits = 8
  e(), bits = 2
  bytes forEach #2, bits = 8  // <- STALE READ!!
  bytes forEach #3, bits = 8  // <- STALE READ!!
  e(), bits = -4              // <- CORRECT READ
  bytes forEach #4, bits = -4 // <- CORRECT READ

  bytes forEach #0, bits = -4 // <- CORRECT READ
  bytes forEach #1, bits = 4  // <- CORRECT READ
  e(), bits = -2              // <- CORRECT READ

  bytes forEach #2, bits = 4  // <- STALE READ!!

  bytes forEach #0, bits = -2 // <- CORRECT READ
  bytes forEach #1, bits = 6  // <- CORRECT READ
  e(), bits = 0               // <- CORRECT READ
  bytes forEach #2, bits = 6  // <- STALE READ!!
  bytes forEach #3, bits = 6  // <- STALE READ!!
  e(), bits = -6              // <- CORRECT READ
  bytes forEach #4, bits = -6 // <- CORRECT READ

  <from this point, logs #2 and #3 are stale every iteration>

[Jakob Kummerow]

Hi Daryl,

That looks like a compiler bug. There have been significant changes as well as follow-up fixes recently. If it's still happening with 12.8, we'd be super interested in a repro (that's sufficiently complete that we can run it locally to see the bug happening). 12.2 is too old to be worth anyone's time, yours or ours.

Sorry for the trouble.

Cheers,

Jakob

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/681a3f93-83be-48c9-ae07-55db28509b9fn%40googlegroups.com.

[Marja Hölttä]

Sounds weird (and interesting)!

You could try disabling optimization tiers, so we see whether the bug occurs when we tier up to some of the optimization tiers.

You can run d8 with:

--no-maglev --no-turbofan

or

--no-turbofan

and use "--js-flags=--no-maglev --no-turbofan" etc. when running with Chrome.

(And for completeness: --no-sparkplug --no-maglev --no-turbofan for disabling the lowest-after-interpreter tier too, although it would be weird if this bug was there.)

You can also pass --trace-opt --trace-deopt-verbose to get a printout when the tierup occurs, and see whether things start going wrong right after.

On Fri, Jul 26, 2024 at 10:07 PM Daryl Haresign <da...@haresign.com> wrote:

--

--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/681a3f93-83be-48c9-ae07-55db28509b9fn%40googlegroups.com.

--

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian.

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[Daryl Haresign]

I haven't yet managed to figure out a smaller reproduction case, but running the code in production seems to reproduce the bug with ease.  I can confirm that the bug does not occur if I run with `--no-maglev`.  I looked at the various maglev flags available to see if I could further narrow it down.  The first one I tried also seemed to stop it from occurring: `--no-maglev-inlining`.  This is all with 12.2.  I should be able to try with 12.4 soon.