Recent Notes

Displaying keyword search results 1 - 4
Created by voodoo on September 17, 2012 15:02:15    Last update: September 17, 2012 15:02:15
Start gdb with the executable and coredump: $ gdb <path to executable> core While in the debugger, use the following commands: (gdb) where ("shows a summary of the stack") ... Example debug session from Debugging Under Unix: gdb Tutorial : Use backtrace (or bt ) to see the callstack: (gdb) backtrace #0 Node<int>::next (this=0x0) ... Inspect the value of item_to_remove at address 0xffbef014 (the value is 1): (gdb) x 0xffbef014 0xffbef014: 0x00000001 (g... Note: The program must be compiled with the debug switch -g in order to see the source code. More resources: Linux software debugging with GDB Debugging with gdb
Created by freyo on September 07, 2011 16:46:14    Last update: September 07, 2011 19:23:00
The Android unit test framework is based on JUnit 3 , not JUnit 4. Test cases have to extend junit.framework.TestCase or a subclass (such as android.test.InstrumentationTestCase ). Tests are identified by public methods whose name starts with test , not methods annotated with @Test (as in JUnit 4). An Android test suite is packaged as an APK, just like the application being tested. To create a test package, first you need to identify the application package it is testing. Google suggests to put the test package source in a directory named tests/ alongside the src/ directory of the main application. At runtime, Android instrumentation loads both the test package and the application under test into the same process. Therefore, the tests can invoke methods on...
Created by freyo on August 25, 2011 09:07:40    Last update: August 25, 2011 20:45:43
This is a list of built-in Android permission values: Permission Description Since API Level android.permission.ACCESS_CHECKIN_PROPERTIES Allows read/write access to the "properties" table in the checkin database, to change values that get uploaded. 1 android.permission.ACCESS_COARSE_LOCATION Allows an application to access coarse (e.g., Cell-ID, WiFi) location 1 android.permission.ACCESS_FINE_LOCATION Allows an application to access fine (e.g., GPS) location 1 android.permission.ACCESS_LOCATION_EXTRA_COMMANDS Allows an application to access extra location provider commands 1 android.permission.ACCESS_MOCK_LOCATION Allows an application to create mock location providers for testing 1 android.permission.ACCESS_NETWORK_STATE Allows applications to access information about networks 1 android.permission.ACCESS_SURFACE_FLINGER Allows an application to use SurfaceFlinger's low level features 1 android.permission.ACCESS_WIFI_STATE Allows applications to access information about Wi-Fi networks 1 android.permission.ACCOUNT_MANAGER Allows applications to call into AccountAuthenticators. Only the system can get this permission. 5 android.permission.AUTHENTICATE_ACCOUNTS...
Created by Dr. Xi on October 06, 2008 22:48:08    Last update: October 06, 2008 22:50:11
A first attempt would be to create an input file like this: userid password shell_command1 shell_... and feed the lines to the telnet client: cat telnet_input.txt | telnet remote_host #... However, you'll learn soon enough that it doesn't work. You get output like this: Trying 192.168.159.128... Connected to bash... What's happening? The telnet client depleted all input before the remote host had a chance to respond. Since there's no more input, the telnet client initiated to close the connection. Adding a delay between the commands makes it work: (echo userid sleep 10 echo password ... How much time to sleep between commands is just guesswork. You can use Expect to provide more control over the automated session: #!/usr/bin/expect # timeout script aft......