{"id":5838,"date":"2015-03-26T20:07:08","date_gmt":"2015-03-27T03:07:08","guid":{"rendered":"https:\/\/visualgdb.com\/w\/?p=5838"},"modified":"2020-03-26T20:07:17","modified_gmt":"2020-03-27T03:07:17","slug":"visualgdb-debugging-app-startup","status":"publish","type":"post","link":"https:\/\/visualgdb.com\/documentation\/appstartup\/","title":{"rendered":"VisualGDB &#8211; Debugging App Startup"},"content":{"rendered":"<p>One big problem with debugging NDK-based Android code is the impossibility to debug code that runs during App startup. E.g. if your native function is called from an <strong>onCreate()<\/strong> method of your Java app, you won&#8217;t be able to stop at a breakpoint when the function is called if you are using normal <strong>ndk-gdb<\/strong> script.<\/p>\n<p>This article explains why those breakpoints are missed normally and how VisualGDB fixes it.<\/p>\n<p>When you start debugging your app with <strong>ndk-gdb<\/strong> or other NDK-based tools, the events shown on the diagram below happen:<a href=\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/03\/sequence-normal.gif\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-5839\" src=\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/03\/sequence-normal.gif\" alt=\"\" width=\"701\" height=\"457\" \/><\/a><\/p>\n<ol>\n<li><strong>ndk-gdb<\/strong> deploys and launches your app. The app starts running immediately and the startup code gets executed.<\/li>\n<li><strong>ndk-gdb<\/strong> queries the PID of your app and starts gdbserver.<\/li>\n<li>Finally, <strong>ndk-gdb<\/strong> starts gdb and connects it to the server. Only at this point the breakpoints are set.<\/li>\n<\/ol>\n<p>If your startup code is executed fast enough, it will finish running before gdb manages to attach and set any breakpoints. Thus, the breakpoints will be missed.<\/p>\n<h2>The VisualGDB Solution<\/h2>\n<p>VisualGDB provides a special Startup debugging mode (select<strong> Anrdoid -&gt; Debug App Startup<\/strong> in Visual Studio). In this mode the app is launched in a suspended mode and is only resumed after all breakpoints are set:<a href=\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/03\/sequence-vgdb.gif\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-5840\" src=\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/03\/sequence-vgdb.gif\" alt=\"\" width=\"701\" height=\"457\" \/><\/a><\/p>\n<h2>Restrictions<\/h2>\n<ol>\n<li>The App Startup debugging is a special debugging mode. To start it, use <strong>Android -&gt; Debug App Startup<\/strong> command. The normal <strong>Debug Android App<\/strong> command will still work just like <strong>ndk-gdb<\/strong> without trying to suspend your app.<a href=\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/03\/startupdbg.png\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-5841\" src=\"https:\/\/visualgdb.com\/w\/wp-content\/uploads\/2020\/03\/startupdbg.png\" alt=\"\" width=\"406\" height=\"248\" \/><\/a>\n<ol>\n<li value=\"2\"><span class=\"warning\"><strong>Do not let Eclipse or DDMS run in background!<\/strong><\/span> VisualGDB uses a special internal tool based on DDMS back-end that resumes the suspended Android apps. Due to restrictions of DDMS back-end, running Eclipse ADT or DDMS itself in the background will interfere with the app resuming tool and will prevent you from debugging your apps. <strong>If you encounter problems, double-check everything and ensure that there are no leftover java.exe instances in Task Manager.<\/strong><\/li>\n<li>Use gdb 7.x provided with VisualGDB. The older gdb 6.6 that comes with Android NDK does not support pending breakpoints and will not be able to set them correctly. The gdb 7.x is enabled by default when you use VisualGDB and can be disabled in VisualGDB project settings.<\/li>\n<\/ol>\n<p>As using the App Startup debugging mode imposes additional restrictions, VisualGDB does not enable it by default. When you use the normal <strong>Debug Android App<\/strong> command, the startup breakpoints will be missed (just like with <strong> ndk-gdb<\/strong>), but running Eclipse in parallel or using an older gdb won&#8217;t interfere with your debugging.<\/li>\n<\/ol>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>One big problem with debugging NDK-based Android code is the impossibility to debug code that runs during App startup. E.g.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/5838"}],"collection":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/comments?post=5838"}],"version-history":[{"count":1,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/5838\/revisions"}],"predecessor-version":[{"id":5842,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/5838\/revisions\/5842"}],"wp:attachment":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/media?parent=5838"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/categories?post=5838"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/tags?post=5838"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}