Hi Christian, Thanks for the reply. Sorry for not getting back to you sooner. I was trying to think of how I can give you a simple case for reproduction but was not able to do so.
Basically, I was working with webkit code similar to Chrome. In v8_proxy.cpp, there's a CallFunction() function where it calls into v8 to execute JS code. In my copy of v8_proxy.cpp, I added a v8::TryCatch block around the call into JS. After the call, I invoke HasCaught() on the TryCatch instance. Now, in my JS code, I deliberately trigger an infinite recursion to test v8's handling of a StackOverflowError. The error is thrown, and eventually, execution returns to this TryCatch block in CallFunction() in v8_proxy.cpp. That's where I inspect (using gdb) the value of Top::external_caught_exception_ and found that it is not NULL. That's why I'm looking for a way to clear it there. Regards, Mark On Thu, Jun 11, 2009 at 1:22 AM, Christian Plesner Hansen<[email protected]> wrote: > > When external_caught_exception_ is true it means that an exception was > thrown, the exception handler that caught it was a v8::TryCatch and > we're currently bailing out until we reach that v8::TryCatch. The > flag gets cleared automatically just before v8 returns from the > nearest api call to the v8::TryCatch, through the > EXCEPTION_BAILOUT_CHECK macro which calls > optional_reschedule_exception. > > If you can return to the v8::TryCatch that caught the last thrown > exception and external_caught_exception_ is still set then that is a > bug. If it happens in your code can you give me some more information > about what it is doing and which api calls are involved? > > On Wed, Jun 10, 2009 at 1:08 AM, [email protected]<[email protected]> wrote: >> >> What is the purpose of (meaning behind) >> Top::external_caught_exception_? Does it mean that: >> 1. an exception has been thrown but has not been handled yet (i.e. yet >> to be caught / exception is pending)? >> 2. an exception has been thrown and we are now executing in the >> handler code (i.e. has been caught, but we're still in an exception >> handler)? >> >> From grepping the code, I see that it is used for assertions in >> api.cc, and execution.cc. These assertions seem to imply that the >> flag refers to meaning 1 above, and every place that executes JS >> code / accessors is verifying that there isn't a pending exception >> before executing. Is that right? >> >> If the flag does mean that there is a pending exception that is to be >> caught by a handler in the C++ code (presumably by a v8::TryCatch >> instance?), then shouldn't there be some means to clear this flag once >> we have "caught" the exception in the C++ code, presumably by checking >> HasCaught() on the TryCatch object? >> >> However, I don't see any methods in the TryCatch object that will >> allow C++ code to clear this flag. The only method that might be the >> right place to clear this flag is TryCatch::Reset() but I see that the >> flag isn't currently cleared there. >> >> One way to clear this flag is by calling Top::clear_pending_exception >> () followed by Top::setup_external_caught(). Is it OK to add those 2 >> calls in v8::TryCatch::Reset()? Or would that break something? >> Please advise. >> >> Thanks. >> >> >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
