How to write reliable tests that involve inconsistent heap object state?

[Adam Klein]

The test cctest/test-unboxed-doubles/Regress436816 is currently failing on the arm64 nosnap bot. From a quick investigation, it seems the problem is that in this particular configuration, the call to JSObject::MigrateToMap in the test is triggering a GC (and an associated heap verification) before the test expects it to happen.

What's the right pattern here? I can think of some possibilities:

1) Should the test disable heap verification for its body and only turn it on at the end?

2) Should it try to collect garbage more aggressively in the test?

(1) seems relatively reasonable, except I worry it would result in losing coverage. (2) seems cludgy but likely effective.

Thoughts?

- Adam

[Yang Guo]

JSObject::MigrateToMap can allocate. In this test, it apparently leaves the heap in an inconsistent state. Sounds like a bug to me.

Cheers,

Yang

--
--
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.
For more options, visit https://groups.google.com/d/optout.

--

•  Yang Guo  •  Google Germany GmbH  •  Erika-Mann-Str. 33  •  80636 Munich  •  yan...@google.com

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank. This e-mail is confidential. If you are not the right addressee please do not forward it, please inform the sender, and please erase this e-mail including any attachments. Thanks.

[Jakob Gruber]

I've seen this a couple of times now that a change in memory layout after bootstrapping caused failures in tests that were written to rely on layout specifics. See e.g. https://codereview.chromium.org/2652933002.

So far, forcing 2 NEW_SPACE GCs to clear out new space at the beginning of the test seems to be a good fix.

On Tue, Apr 25, 2017 at 7:23 AM, Yang Guo <yan...@chromium.org> wrote:

JSObject::MigrateToMap can allocate. In this test, it apparently leaves the heap in an inconsistent state. Sounds like a bug to me.

Cheers,

Yang

On Tue, Apr 25, 2017 at 1:48 AM Adam Klein <ad...@chromium.org> wrote:

The test cctest/test-unboxed-doubles/Regress436816 is currently failing on the arm64 nosnap bot. From a quick investigation, it seems the problem is that in this particular configuration, the call to JSObject::MigrateToMap in the test is triggering a GC (and an associated heap verification) before the test expects it to happen.

What's the right pattern here? I can think of some possibilities:

1) Should the test disable heap verification for its body and only turn it on at the end?

2) Should it try to collect garbage more aggressively in the test?

(1) seems relatively reasonable, except I worry it would result in losing coverage. (2) seems cludgy but likely effective.

Thoughts?

- Adam

--
--
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+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

•  Yang Guo  •  Google Germany GmbH  •  Erika-Mann-Str. 33  •  80636 Munich  •  yan...@google.com

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank. This e-mail is confidential. If you are not the right addressee please do not forward it, please inform the sender, and please erase this e-mail including any attachments. Thanks.

--

--
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+unsubscribe@googlegroups.com.

[Igor Sheludko]

Given that we don't have a switch for (1) and already do (2) in a number of tests, I think (2) is the way to go. Thanks for fixing the test!

On Tue, Apr 25, 2017 at 7:56 AM Jakob Gruber <jgr...@google.com> wrote:

I've seen this a couple of times now that a change in memory layout after bootstrapping caused failures in tests that were written to rely on layout specifics. See e.g. https://codereview.chromium.org/2652933002.

So far, forcing 2 NEW_SPACE GCs to clear out new space at the beginning of the test seems to be a good fix.

On Tue, Apr 25, 2017 at 7:23 AM, Yang Guo <yan...@chromium.org> wrote:

JSObject::MigrateToMap can allocate. In this test, it apparently leaves the heap in an inconsistent state. Sounds like a bug to me.

Cheers,

Yang

On Tue, Apr 25, 2017 at 1:48 AM Adam Klein <ad...@chromium.org> wrote:

The test cctest/test-unboxed-doubles/Regress436816 is currently failing on the arm64 nosnap bot. From a quick investigation, it seems the problem is that in this particular configuration, the call to JSObject::MigrateToMap in the test is triggering a GC (and an associated heap verification) before the test expects it to happen.

What's the right pattern here? I can think of some possibilities:

1) Should the test disable heap verification for its body and only turn it on at the end?

2) Should it try to collect garbage more aggressively in the test?

(1) seems relatively reasonable, except I worry it would result in losing coverage. (2) seems cludgy but likely effective.

Thoughts?

- Adam

--
--
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.

For more options, visit https://groups.google.com/d/optout.

--

•  Yang Guo  •  Google Germany GmbH  •  Erika-Mann-Str. 33  •  80636 Munich  •  yan...@google.com

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank. This e-mail is confidential. If you are not the right addressee please do not forward it, please inform the sender, and please erase this e-mail including any attachments. Thanks.

--
--
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.

For more options, visit https://groups.google.com/d/optout.

--

Igor Sheludko

Software Engineer
ish...@google.com

Google Germany GmbH

Erika-Mann-Str. 33

80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

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.

[Adam Klein]

I don't think it's MigrateToMap itself that's causing the problem in this case (I tried doing a GC right before MigrateToMap and _that_ GC triggered a verification failure), but rather the setup code, which synthesizes a descriptor array and a JSObject before initializing it.

I ended up doing (2) in https://chromium-review.googlesource.com/c/486062/ for both tests (and it sounds like, from Jakob and Igor's comments, that's the right way to go generally).

On Mon, Apr 24, 2017 at 10:23 PM, Yang Guo <yan...@chromium.org> wrote:

JSObject::MigrateToMap can allocate. In this test, it apparently leaves the heap in an inconsistent state. Sounds like a bug to me.

Cheers,

Yang

On Tue, Apr 25, 2017 at 1:48 AM Adam Klein <ad...@chromium.org> wrote:

The test cctest/test-unboxed-doubles/Regress436816 is currently failing on the arm64 nosnap bot. From a quick investigation, it seems the problem is that in this particular configuration, the call to JSObject::MigrateToMap in the test is triggering a GC (and an associated heap verification) before the test expects it to happen.

What's the right pattern here? I can think of some possibilities:

1) Should the test disable heap verification for its body and only turn it on at the end?

2) Should it try to collect garbage more aggressively in the test?

(1) seems relatively reasonable, except I worry it would result in losing coverage. (2) seems cludgy but likely effective.

Thoughts?

- Adam

--
--
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+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

•  Yang Guo  •  Google Germany GmbH  •  Erika-Mann-Str. 33  •  80636 Munich  •  yan...@google.com

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank. This e-mail is confidential. If you are not the right addressee please do not forward it, please inform the sender, and please erase this e-mail including any attachments. Thanks.

--

--
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+unsubscribe@googlegroups.com.