I've tried to reproduce the issue from your description but haven't been able to.
What you can do is trace the EXCEPTION_BAILOUT_CHECK. It will check various conditions to determine if it needs to clear the field and seeing why it decides not to might say something about what the problem is. -- Christian On Fri, Jun 26, 2009 at 11:48 PM, [email protected]<[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
