Those frames after "v8::internal::`anonymous namespace'::Invoke" are indeed generated code frames. We have some GDB integration to make it easier to inspect them, but I don't know about any Visual Studio tooling. If you can invoke functions from your interactive debugging session, you can call _v8_internal_Print_Code with any PC to print the entire Code object containing that PC, which contains the function name.
On the API, there is a function called RequestInterrupt, whose purpose is to let the embedder interrupt long/endless loops. There's also the static function Message::PrintCurrentStackTrace which lets you print a stack trace. On Thu, Sep 5, 2019 at 7:25 PM <[email protected]> wrote: > Hello, > > I am working with software that is utilizing CEF3 and therefore V8. I am > trying to diagnose an issue that might be caused by an infrequent > JavaScript infinite loop. Furthermore I would like to understand a process > generating reasonable diagnostic logging when such an issue occurs. > (Some more detail can be found in the CEF forums thread here: > https://magpcss.org/ceforum/viewtopic.php?f=6&t=17033&p=43123#p43123) > > It would be ideal if I could invoke a CEF method to stop the JavaScript > thread's execution and generate a callstack of the thread, but this doesn't > seem to be currently possible. > > It was suggested that I might be able to get more information by debugging > the CEF renderer process. As such I've introduce an infinite loop for > testing purposes and debugged. However I am not able to get understandable > information from the debugger as the callstack seems to become > incomprehensible near the calls into V8/javascript execution. > > That is in visual studio I see a callstack like: > // The first entry is the code location, the second is the language. There > are many more Unknown language items above this point omitted for clarity. > ... > 5bb0cb1d() Unknown > 5bb108a4() Unknown > 5bb0bd31() Unknown > libcef.dll!v8::internal::`anonymous > namespace'::Invoke(v8::internal::Isolate * isolate, bool is_construct, > v8::internal::Handle<v8::internal::Object> target, > v8::internal::Handle<v8::internal::Object> receiver, int argc, > v8::internal::Handle<v8::internal::Object> * args, > v8::internal::Handle<v8::internal::Object> new_target, > v8::internal::Execution::MessageHandling message_handling, > v8::internal::Execution::Target execution_target) Line 155 C++ > libcef.dll!v8::internal::Execution::Call(v8::internal::Isolate * > isolate, v8::internal::Handle<v8::internal::Object> callable, > v8::internal::Handle<v8::internal::Object> receiver, int argc, > v8::internal::Handle<v8::internal::Object> * argv) Line 202 C++ > ... > > Is there some way to get more information about the Unknown language items > in the call stack? I can see the disassembly, but that is not very > understandable. > > Or perhaps there is some other suggestion on how I might generate a call > stack of a JavaScript execution that runs too long? > > Many thanks, > Grant Baltare > > -- > -- > 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/0e50db10-daea-4082-9770-438741fb9074%40googlegroups.com > <https://groups.google.com/d/msgid/v8-dev/0e50db10-daea-4082-9770-438741fb9074%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/CAKSzg3S6SOaLRVQ53cKpLYkq2_YRtwxHO4fxDaWMDZ0GrcsncA%40mail.gmail.com.
