Fix a couple of JDWP bugs.
First, dalvikvm's behavior of just carrying on if it failed to set up JDWP was
the opposite of helpful. It's wasted loads of my time lately, and I've already
benefitted in the half hour since making this a hard stop.
Second, I was accidentally reporting upcall frames. I don't know why I wasn't
always seeing this -- because we always make an upcall to 'main' -- but it was
repeatable if the stack was short enough.
Change-Id: Iee14867f596436bed5ca0546db71e62b62d11f41
diff --git a/src/debugger.cc b/src/debugger.cc
index 7128fdc..37b02af 100644
--- a/src/debugger.cc
+++ b/src/debugger.cc
@@ -323,8 +323,10 @@
// debugger.
gJdwpState = JDWP::JdwpState::Create(&gJdwpOptions);
if (gJdwpState == NULL) {
- LOG(WARNING) << "debugger thread failed to initialize";
- return;
+ // We probably failed because some other process has the port already, which means that
+ // if we don't abort the user is likely to think they're talking to us when they're actually
+ // talking to that other process.
+ LOG(FATAL) << "debugger thread failed to initialize";
}
// If a debugger has already attached, send the "welcome" message.
@@ -1103,8 +1105,11 @@
ScopedThreadListLock thread_list_lock;
struct CountStackDepthVisitor : public Thread::StackVisitor {
CountStackDepthVisitor() : depth(0) {}
- virtual void VisitFrame(const Frame&, uintptr_t) {
- ++depth;
+ virtual void VisitFrame(const Frame& f, uintptr_t) {
+ // TODO: we'll need to skip callee-save frames too.
+ if (f.HasMethod()) {
+ ++depth;
+ }
}
size_t depth;
};
@@ -1120,8 +1125,9 @@
: found(false) ,depth(0), desired_frame_number(desired_frame_number), pFrameId(pFrameId), pLoc(pLoc) {
}
virtual void VisitFrame(const Frame& f, uintptr_t pc) {
+ // TODO: we'll need to skip callee-save frames too.
if (!f.HasMethod()) {
- return; // These don't count?
+ return; // The debugger can't do anything useful with a frame that has no Method*.
}
if (depth == desired_frame_number) {