6

I have been trying for months to get my debugger to break on my own code, with no success. Every uncaught exception breaks in the ZygoteInit.run() method.

Here is a list of actions I've taken.

  1. Added debug { debuggable true } to my app module's build.gradle file
  2. Manually added debuggable="true" to my AndroidManifest.xml file
  3. Checked the Any exception checkbox in the Breakpoints window
  4. Added relevant class filter patterns to the Any exception breakpoint
    • this causes the debugger to completely skip all uncaught exceptions

I have been debugging by looking at the stack trace in Logcat, which does show my classes in the stack trace.

I have seen this version on current & previous builds in the stable AND canary channels.

Is there something here I'm missing?

EDIT: Just to clarify for people, the issue was that I had the "Caught exception" box unchecked. Checking this box fixed my issue.

Here is the relevant part of my Gradle file, if it helps at all.

android {
    compileSdkVersion 22
    buildToolsVersion '22.0.0'

    defaultConfig {
        applicationId "com.--redacted--"
        minSdkVersion 15
        targetSdkVersion 22
        versionCode 30
        versionName "0.0.30"
        multiDexEnabled true
    }
    packagingOptions {
        exclude 'META-INF/LICENSE'
        exclude 'META-INF/LICENSE.txt'
        exclude 'META-INF/NOTICE'
        exclude 'META-INF/beans.xml'
    }
    buildTypes {
        debug {
            debuggable true
        }
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
    dexOptions {
        javaMaxHeapSize "4g"
    }
}

Here is a screenshot of my Breakpoints window.

Breakpoints window

Jeremy White
  • 2,818
  • 6
  • 38
  • 74
  • Can't you just add try/catch blocks everywhere to narrow down where the exception is happening, then just put a break point in and debug the code once you've narrowed it down to a specific block of code? – Daniel Nugent Mar 19 '15 at 06:16
  • @Fahim that did not address my question. That link doesn't mention exception breakpoints in any detail. – Jeremy White Mar 19 '15 at 22:05
  • @DanielNugent my codebase is quite large. That is not a realistic solution. I was hoping the debug tools would just work as advertised. – Jeremy White Mar 19 '15 at 22:06
  • 1
    To ask the stupid but necessary questions, you're clicking the debug button rather than the run button right? And you're using a debuggable build variant? – nasch Mar 20 '15 at 00:30
  • Haha, yes I am doing both of those things. Thanks for checking, though! Sometimes it is the stupid things... – Jeremy White Mar 20 '15 at 03:53
  • @nasch I've added the relevant part of my gradle file. – Jeremy White Mar 20 '15 at 03:56
  • I think you need a `debug` build type. `release` isn't debuggable, and I don't know that you can override that with other settings (nor would it be a good idea to do it that way). – nasch Mar 21 '15 at 16:22
  • The default gradle settings include a debug build type with debuggable set to true. – Jeremy White Mar 21 '15 at 18:33

2 Answers2

10

A couple more things to ensure:

  • Suspend set to all
  • Notifications on:
    • Caught exception if exceptions that have error handling defined are to be caught
    • Uncaught exceptions if exceptions that are not handled are to be caught
  • Set the class filters to restrict to include only your code, Android code, and Java code

See more detailed instructions here: https://stackoverflow.com/a/28862538/3063884

Breakpoints dialog

This approach catches all exceptions that are raised (when 'caught' and 'uncaught' are checked). Thus all internal exceptions are raised. The specification of a class filter restricts this by excluding some of these exceptions. For example, in the screen-dump above, the ClassNotFoundException, which is raised frequently during start-up, is ignored.

A small downside of this approach is that during app start-up, there may be a message indicating "Cannot find source class for current stack frame". This is because not all of the source code has been loaded yet. This will only occur once during start-up and can safely be ignored. An alternative approach to avoid this (if there are no exceptions expected during app start-up) is to 'Run' Run the application (as opposed to starting 'Debug'), and then manually attach the app to the debugger via Run -> Attach debugger to Android process ... or by pressing the Attach button in the toolbar.

Community
  • 1
  • 1
CJBS
  • 15,147
  • 6
  • 86
  • 135
  • There is no way to do this without breaking on caught exceptions? – Jeremy White Mar 24 '15 at 16:26
  • Yes there is - in the dialog above, uncheck "Caught exception" under Notifications. – CJBS Mar 24 '15 at 16:27
  • 1
    I think that may be what is causing my inability to break in my own code. Since all exceptions in Android are caught in ZygoteInit.run() – Jeremy White Mar 24 '15 at 16:29
  • Are you able to start with debugging, put breakpoint somewhere in your init code, and have it break on that code (i.e. before any exception occurs)? Is this in your own code or an included library where exceptions are not being caught properly? – CJBS Mar 24 '15 at 16:32
  • Yes, I am able to catch at Method Breakpoints. I am not able to break at my own code or libraries. – Jeremy White Mar 24 '15 at 16:33
  • Adding that suspend condition produces the following error: "Problem processing VM event: Breakpoint: 'Any exception' Error: Failed to evaluate breakpoint condition '!(this instanceof java.lang.ClassNotFoundException)' Reason: Cannot find source class for current stack frame Would you like to stop at the breakpoint?" – Jeremy White Mar 24 '15 at 16:33
  • RE: '!(this instanceof java.lang.ClassNotFoundException)' -- I usually get that the first time I start the app, but then not afterwards. It does't occur if starting in 'run mode', and then attaching the debugger. – CJBS Mar 24 '15 at 16:34
  • For detailing the dialog with all its parts and checkboxes +1 –  Mar 24 '15 at 16:54
  • @JeremyWhite same problem with Zygote and I finally got it working. I checked the other stuff under "java ex bp" called "exception breakpoints" in that page you have "when thrown". This in combination with "suspend all" gives a workable call stack ! phew... damn Android... – v.oddou Sep 07 '16 at 14:04
1

You need to attach the debugger to a running process

You don't always have to restart your app to debug it.
To debug an app that you're already running:

  1. Click Attach debugger to Android proccess
  2. In the Choose Process window, select the device and app you want to attach the debugger to
  3. To open the Debug tool window, click Debug

    To view and configure the breakpoints settings, click View Breakpoints on the left side of the Debug tool window. The Breakpoints window appears, and there you could configure them.

There are three main types of Exceptions:

  1. Checked execptions: which have to be handled by the code. These represent avoidable exceptional conditions which can be handled and recovered from.

  2. Runtime Exceptions: which need not be handled by the code. These represent unexpected exceptional conditions which can be handled but not necessarily recover from.

  3. Errors: which need not be handled by the code. These represent severe unexpected exceptional conditions which shud not be attempted to handle.

  • I am attached to the process, as I have clicked the debug icon and can stop at method breakpoints while running the app. – Jeremy White Mar 24 '15 at 16:16
  • Yes I did, I think I outlined that in the question above. – Jeremy White Mar 24 '15 at 16:30
  • With all the checkboxes like the caught exceptions and uncaught Exceptions ticks? –  Mar 24 '15 at 16:32
  • No. To be clear, the answer from CJBS is what solved my issue. I was asking for more explanation within his answer. – Jeremy White Mar 24 '15 at 16:44
  • Regardless who did what faster, CJBS's post is what ultimately helped me fix the issue. Your answer did not make any reference to breaking at Caught Exceptions before his answer did. – Jeremy White Mar 24 '15 at 16:49
  • 1
    The description describing how to check basics, with an explanation, will be useful to someone though. +1 – CJBS Mar 24 '15 at 16:50