It appears the object at WEAK_CELL_MAP_INDEX is the undefined constant, at least when this code runs. Is there some initialization I'm missing to be able to use it from Torque? Factory::NewWeakCell uses this map so it exists somehow...
On Thursday, 16 July 2020 at 18:18:48 UTC-5 [email protected] wrote: > I actually opened this bug earlier today: https > ://bugs.chromium.org/p/v8/issues/detail?id=10715 > <https://bugs.chromium.org/p/v8/issues/detail?id=10715> > > I guess my guess was wrong. I'll take a look at that map. > > On Thu, Jul 16, 2020, 18:15 'Seth Brenith' via v8-dev < > [email protected]> wrote: > >> Have you gotten any help with this yet? I don't have a full answer for >> you, but I implemented the ability to print out the list of nested Torque >> macros at a failure (CL >> <https://chromium-review.googlesource.com/c/v8/v8/+/2303598>), and see >> the following: >> >> abort: CSA_ASSERT failed: Torque assert 'Is<A>(o)' failed >> [src/builtins/cast.tq:622] [../../src/builtins/base.tq:1173] >> [../../src/builtins/finalization-registry.tq:166] >> >> So the UnsafeCast in GetWeakCellMap is the one that's failing: >> >> return UnsafeCast<Map>(LoadNativeContext(context) >> >> .elements[NativeContextSlot::WEAK_CELL_MAP_INDEX]); >> >> On Saturday, July 11, 2020 at 11:21:37 AM UTC-7, Gus Caplan wrote: >>> >>> I took a look around the disassembly. It seems (not 100% sure) like the >>> failure is happening as part of the `new (Pretenured) WeakCell{}` call. >>> Maybe I hooked the map up wrong? Not sure how allocating a T could fail >>> Is<T>(). >>> On Saturday, July 11, 2020 at 9:19:43 AM UTC-5 [email protected] >>> wrote: >>> >>>> I have two ideas. >>>> >>>> First, the real fix: instead of emitting the current file and line >>>> number in the generated CSA, Torque should emit the entire stack of files >>>> and line numbers for all macros that are currently entered. That way we >>>> wouldn't get a message from just some deeply-nested tiny macro like Is<T> >>>> and wonder what other code was including it. I can add this to the Torque >>>> backlog if it's not already there. >>>> >>>> Second, a possible workaround: assuming that gdb or lldb can at least >>>> tell you the name of the builtin and the current offset within it, you >>>> could try running mksnapshot with all of the normal args plus --print-code >>>> --code-comments, and looking at the disassembly for that builtin near that >>>> offset. Perhaps some nearby strings or code comments might give you a hint >>>> about the context. >>>> >>>> -- >> -- >> v8-dev mailing list >> [email protected] >> http://groups.google.com/group/v8-dev >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "v8-dev" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/v8-dev/YgaFjYulOB8/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/v8-dev/9cc21f3a-2c8a-4891-b2ac-a9f3ef694a08o%40googlegroups.com >> >> <https://groups.google.com/d/msgid/v8-dev/9cc21f3a-2c8a-4891-b2ac-a9f3ef694a08o%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- -- v8-dev mailing list [email protected] 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/0902505a-a938-4a02-a17c-c9159d27ca4en%40googlegroups.com.
