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. On Thursday, November 14, 2024 at 6:30:32 PM UTC+8 jgr...@chromium.org wrote: > 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 > <https://source.chromium.org/chromium/chromium/src/+/main:v8/test/mjsunit/mjsunit.status;l=1906;drc=981ce1e8f82050b33153a9c4652f2ad1cefabff1> > 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. > > On Wed, Nov 13, 2024 at 7:18 AM 'Ronald Fenner' via v8-dev < > v8-...@googlegroups.com> wrote: > >> 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. >> >> -- >> -- >> 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 >> >> <https://groups.google.com/d/msgid/v8-dev/5d6392f5-a26a-41a9-8d77-974032d0e69an%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > 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. > -- -- v8-dev mailing list v8-dev@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+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/v8-dev/80b2bb0a-3f3f-4862-b891-f7f04ee21c56n%40googlegroups.com.
