Multiple snapshot error on cleanup

[Ronald Fenner]

I'm testing my sanpshotting process and I create multiple snapshots at one time. since the main app can have multiple runtimes that it could snapshot.

When i go to tear down the Isolates and creators i get this error

# Debug check failed: CurrentPerIsolateThreadData()->isolate_ == this.

I found after doing some testing that if i teardown the creators and isolates in the reverse order they were snapshotted in then there is no error.

It seems like the snapshoot process isn't fully restoring something and thus the error occurs.

I know I can code around it my destorying the isolate and creator as soon as i take the snapshot however this seems like a bug and I was planning on be able to have a app that can create snapshots while also having it's own runtime it's running and not sure if it would cause it problems.

The basics of the flow is a runtime class is created which if the runtime is going to be snapshoted the runtime and created are paired and stored within the class. 
When the snapshot process is called the runtimes are looped over and a snapshot is created of each. When the runtime is torn down the isolate and creator are then destroyed.

Note i'm storing the runtimes in a std::map so their order of iteration apparently can change so this creates the issue.

I was able to test the order since the app class has it's main runtime and then the additional and by changing the order in which the main and hte additional runtime were torn down it worked, however adding a third the problem reoccured most likely due a possibly different order of iteration on the map.

I looked for a way to try and pop the isolate or something and even tried entering and exiting but that didn't help.

[Jakob Gruber]

The SnapshotCreator is unfortunately not as flexible as you describe. Specifically:

1. taking a snapshot also mutates the snapshotted Isolate, and

2. snapshotting doesn't fully support arbitrary heap states. See here for a list of known test failures in our test variant that attempts to do just that.

The only workflow that is extensively tested on our side is essentially what mksnapshot does, i.e.: we take a single snapshot of a well-known, simple heap state and afterwards throw away the Isolate. You can always attempt more advanced scenarios, but I wouldn't be surprised if you soon run into trouble when snapshotting arbitrary heap states / continuing to use the Isolate after.

--
--
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 visit https://groups.google.com/d/msgid/v8-dev/5d6392f5-a26a-41a9-8d77-974032d0e69an%40googlegroups.com.

Jakob Gruber

Software Engineer

jgr...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

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.

[Ronald Fenner]

After digging through my code and looking at the comments for the creation of the SnapshotCreator i see it explicitly enter the isolate however it does not look like it exits until destroye. Thus my creating multiple snapshot creators ahead of time is where the issue arises due to the stack of entered isolates and why destroying them in the reverse order of snapshotting works doesn't hit the error.

This brings up some questions I think you may have hinted at.

My assumptions where isolates were entirely isolated and thus snapshotting should only affect that isolate itself thus my pairing and isolate and creator when i know the runtime is created for snapshotting, however it seems snapshotting may also affecte some shared data structures thus when snapshotting you can only do one per process run.

Could i take multiple snapshots but i would need to create->snapshot->destroy the creator before I snapshot another.

What is the reasoning behind having the creator explicitly entering the runtime rather than allowing for the embedder of telling  it when to enter it

Can I fix the issue with something as simple as calling Exit on the isolate after creation and resolve the issue or does it need to remain entered.

[Jakob Gruber]

On Fri, Nov 15, 2024 at 5:38 AM 'Ronald Fenner' via v8-dev <v8-...@googlegroups.com> wrote:

After digging through my code and looking at the comments for the creation of the SnapshotCreator i see it explicitly enter the isolate however it does not look like it exits until destroye. Thus my creating multiple snapshot creators ahead of time is where the issue arises due to the stack of entered isolates and why destroying them in the reverse order of snapshotting works doesn't hit the error.

This brings up some questions I think you may have hinted at.

My assumptions where isolates were entirely isolated and thus snapshotting should only affect that isolate itself thus my pairing and isolate and creator when i know the runtime is created for snapshotting, however it seems snapshotting may also affecte some shared data structures thus when snapshotting you can only do one per process run.

Hi Ronald, please excuse the late reply.

When the gn arg `v8_enable_extensible_ro_snapshot` is set, snapshotting can modify RO space which is shared between isolates. Otherwise, its effects should be limited to the snapshotted isolate. 

Again, snapshotting 1) mutates the isolate and 2) doesn't support arbitrary heap states. 

 

Could i take multiple snapshots but i would need to create->snapshot->destroy the creator before I snapshot another.

What is the reasoning behind having the creator explicitly entering the runtime rather than allowing for the embedder of telling  it when to enter it

Can I fix the issue with something as simple as calling Exit on the isolate after creation and resolve the issue or does it need to remain entered.

I don't think there's a reason besides SnapshotCreator being written with our main use cases in mind. Would it work for you to snapshot your isolates one after another, only having one SnapshotCreator active at a time?

 

To view this discussion visit https://groups.google.com/d/msgid/v8-dev/80b2bb0a-3f3f-4862-b891-f7f04ee21c56n%40googlegroups.com.

[Ronald Fenner]

I played around with some of my ideas and ended tracking the order they get created in a vector and then when the App is disposed of it iterates over the vector in reverse this solved the issue I was running into. 

For some reason even though the creator immediately called Enter on the isolate and I called Exit  after it's created I later ran into an error still when trying to reenter the isolate and destroying the creator.

Also I'm not trying to take a snapshot in a controlled manor so the app itself would know when it's doing a snapshot and the users would be able to run code designed to be snapshot vs just running stuff as a normal run of it.

[Ronald Fenner]

Sorry type I'm trying to take a snapshot in a controller manor.