A typical debugger provides the ability to halt when specific conditions are encountered. It also offers sophisticated functions, such as running a program step by step, breaking or pausing the program for an examination based on breakpoints, and tracking the values of the variables at that state. RubyMotion Version 1.24 and above support debugging using GDB: the GNU project debugger (http://www.gnu.org/software/gdb/).
The RubyMotion debugger provides the following inbuilt debugging facilities:
- It stops the program at a specific line
- It examines the problem when the program has stopped
- It checks the value for the variables at a specific breakpoint
Note
The RubyMotion compiler implements the DWARF debugging format's metadata for the Ruby language. This allows external programs, such as the debugger in our case, to retrieve source-level information about the RubyMotion application. The metadata is saved under a
.dSYMbundle file at the same level as the.appbundle in the build directory of your project.
There are three ways in which we can start the debugger.
We can start the debugger with a simulator. The debugger will directly attach itself to the app and replace the interactive shell (REPL).
To start, just type:
$rake simulator debug=1
We can start debugging with the device running simultaneously. The build system will start the iOS debugging server on the device and then remotely attach the debugger on your shell right after the application has been deployed on the device.
$rake device debug=1
In the release mode, local variables might not be accessible in the debugger as they are optimized to fit into CPU registers.
We can put breakpoints at a specific location of our application code using the break command and then pass the location where the debugger should stop the execution of the code using the file_name:line_number notation.
Let's try putting a breakpoint in our current application. To do so, we need to start our HelloWorld application in debugging mode as follows:
$rake simulator debug=1 /Library/RubyMotion/lib/motion/project/config.rb:89: Build ./build/iPhoneSimulator-5.1-Development Simulate ./build/iPhoneSimulator-5.1-Development/HelloWorld.app Attaching to process 86665. Reading symbols for shared libraries . done 0x8fe6c030 in __dyld__dyld_start () Function "rb_exc_raise" not defined. Breakpoint 1 (rb_exc_raise) pending. Function "malloc_error_break" not defined. Breakpoint 2 (malloc_error_break) pending. Reading symbols for shared libraries .............................................................................................................. done Breakpoint 1 at 0x37136 Pending breakpoint 1 – "rb_exc_raise" resolved Breakpoint 2 at 0x97bdec97 Pending breakpoint 2 – "malloc_error_break" resolved Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries ... done (gdb)
Now let's set a breakpoint on the eighth line of the file app_delegate.rb as follows:
(gdb) break app_delegate.rb:8 Breakpoint 3 at 0x80085: file app_delegate.rb, line 8
With the preceding command, the execution of your application will halt at line number 8 of the app_delegate.rb file.
To list the breakpoints that have been set up in the current debugging environment, we use the info breakpoint command as follows:
(gdb) info breakpoint Num Type Disp Enb Address What 1 breakpoint keep y 0x000adff6 <rb_exc_raise+6> 2 breakpoint keep y 0x97bdec97 <malloc_error_break+6> 3 breakpoint keep y 0x00080085 in rb_scope__application:didFinishLaunchingWithOptions:__ at app_delegate.rb:8
We can see that the list of breakpoints created in the last section can also be seen in the list.
The continue command will continue the execution of the program until it reaches the next breakpoint.
(gdb) continue
We can also use its alias c as follows; it is more handy to use:
(gdb) c Breakpoint 3, rb_scope__application:didFinishLaunchingWithOptions:__ (self=0x9408440, application=0x9401750, launchOptions=0x4) at app_delegate.rb:8 8 alert.show
The next command will continue the execution of the program until the next source-level location. This is usually the very next line in the Ruby source code. You should have a look at the terminal for the relevant source code line.
(gdb) next
This is an important feature of debugging, to check the value of a variable at a specific breakpoint.
(gdb) pro alert #<UIAlertView:0x944b9b0>
This shows that the alert is an object of the UIAlertView class
Pro (print-ruby-object) accepts two parameters as follows:
- The object on which the variable will be retrieved.
- The variable name that you want to get.
We can also check the value of an instance variable during some breakpoint using pri (print-ruby-ivar) as follows:
pri self "@tweet"
pri accepts two commands as follows:
- The object on which the instance variable will be retrieved.
- The instance variable that you want to get. Make sure to include the
@character in the name.
To disable a breakpoint, use disable followed by the breakpoint number; it has to be disabled as follows:
(gdb) disable 3
Type quit to exit the debugger as follows:
(gdb) quit The program is running. Quit anyway (and detach it)? (y or n) y Detaching from process 6792.
Tip
Downloading the example code
You can download the example code files for all Packt books you have purchased, and the graphics bundle of this book from your account at http://www.packtpub.com.
If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.