Breakpoints in Dartium causing crashes

[dgrove]

As discussed earlier today, we're seeing breakpoints causing crashes in Dartium very frequently.

(purely as FYI: I just tried this at r6117, and still see the problem)

[dgrove]

Anton, Pavel:

I misunderstood a comment from Ivan earlier - it's not clear whether this is crashing in the VM or in the bindings. The reason for this is that the crashes are only happening in release builds, which have no symbols.

Can you guys see if there's a way for us to build the release build with symbols?

[DartBot]

This comment was originally written by [email protected]

---

Release builds has symbols on linux by default.

For Mac OS see http://www.chromium.org/developers/debugging-on-os-x "Preserving symbols in Release builds".

Some useful tips for debugging multiprocess chrome on linux: http://code.google.com/p/chromium/wiki/LinuxDebugging.

[DartBot]

This comment was originally written by @mhausner

---

The crashes only happen on Release builds. What I've found so far is that while handling a breakpoint, WebCore calls back into the VM to retrieve a list of elements. One of the values it gets back is corrupted, or at least the class object it points to is corrupted. The vtable in that class is sometimes 0, sometimes -1, but when Dart_IsError calls the member function Object::IsError(), we crash.

See below for stack trace at crash. I'm investigating now how the raw object gets corrupted, or how we end up with a class that has no vtable entry.

#­1 0x41e4aafa in WebCore::inspectedListIndexedPropertyHandler ()
#­2 0x411582d9 in v8::internal::JSObject::GetElementWithInterceptor ()
#­3 0x411fe050 in v8::internal::KeyedLoadPropertyWithInterceptor ()
#­4 0x2780a336 in ?? ()
#­5 0x278402de in ?? ()
#­6 0x278160e9 in ?? ()
#­7 0x2783f887 in ?? ()
#­8 0x278160e9 in ?? ()
#­9 0x2783ef9f in ?? ()
#­10 0x27821984 in ?? ()
#­11 0x27821c7a in ?? ()
#­12 0x27812d0a in ?? ()
#­13 0x41098a53 in v8::internal::Invoke ()
#­14 0x41098c39 in v8::internal::Execution::New ()
#­15 0x410547a8 in v8::Object::CallAsConstructor ()
#­16 0x41e49b3a in WebCore::DartDebugServer::handleBreakpoint ()
#­17 0x41e48f5e in WebCore::DartDebugServer::breakpointHandler ()
#­18 0x4168c543 in dart::Debugger::BreakpointCallback ()
#­19 0x416726c1 in dart::DRT_BreakpointStaticHandler ()
#­20 0x237000e2 in ?? ()
#­21 0x23700704 in ?? ()

---

Added Started label.

[DartBot]

This comment was originally written by @mhausner

---

I think I know what it is. The debugger is getting bogus values from the stack when it is getting the value of a captured variable. It should read the value from the context instead. I even have a TODO in the code that captured variables are not handled yet.

[DartBot]

This comment was originally written by @mhausner

---

Crashes should be gone. The captured variables were indeed the culprit. For now, the name and value of captured variables is not displayed in the debugger. Working on a solution that handles captured variables corretly in a separate change.

---

Added Fixed label.