Changes between Version 5 and Version 6 of WikiStart/Troubleshooting


Ignore:
Timestamp:
11/21/11 17:02:52 (8 years ago)
Author:
sylvain.joyeux
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WikiStart/Troubleshooting

    v5 v6  
    22 
    33 * [./GitLocalChanges autoproj update complains about uncommitted changes (git)] 
    4  * [./DebuggingTechniques debugging techniques (some are not Rock specific !)] 
    54 
    6 ==  Debugging techniques == 
    7 The following section list some techniques that allow to investigate deeper: 
    8  
    9 === Improve logging and increase the logging level === 
    10 For Orocos components you can set the Orocos logging level via the enviroment variable ORO_LOGLEVEL to a value from 1 to 6.  
    11 Where 6 allows the DEBUG messages to the shown.  
    12 {{{ 
    13 export ORO_LOGLEVEL=6 
    14 }}} 
    15  
    16 For libraries its is recommended to use the base logging. In order to activate you can use the environment variable BASE_LOG_LEVEL. Unset the variable to deactivate logging. Otherwise you can set the logging level for the base logger the following log levels:  
    17 "DEBUG", "INFO", "WARN", "ERROR", "FATAL" 
    18 {{{ 
    19 export BASE_LOG_LEVEL="DEBUG" 
    20 }}} 
    21  
    22 If you haven't included any logger into your library use the one provided by base. You find the source in 
    23 base/types, i.e. if you are using the Rock Macros you will have to link to ''base-lib'' (yes, base-lib).  
    24 If you are not using Rock Macros but only CMake you have to do the following 
    25  
    26 {{{ 
    27 add_definitions(-DBASE_LOG_NAMESPACE=${PROJECT_NAME}) 
    28  
    29 include(FindPkgConfig) 
    30  
    31 pkg_check_modules(BASE REQUIRED "base-lib") 
    32 include_directories(${BASE_INCLUDE_DIRS}) 
    33 link_directories(${BASE_LIBRARY_DIRS}) 
    34  
    35 add_library(your_library ...) 
    36 target_link_libraries(your_library ... ${BASE_LIBRARIES}) 
    37 }}} 
    38  
    39 Include the logger in the .cpp files only 
    40 {{{ 
    41 #include <base/logging.h> 
    42 }}} 
    43  
    44 Then you can either use a printfstyle logging 
    45 {{{ 
    46 std::string test = "TEST"; 
    47 LOG_ERROR("This is a log message: %s", test.c_str()); 
    48 }}} 
    49  
    50 === C/C++ >> gdb (gnu debugger) and ddd === 
    51 The following steps allow you to perform post mortem analysis once your C/C++ program fails and generates a core dump. 
    52 Change the pattern of the core dump filename since the default is just ''core'' 
    53 {{{ 
    54 sudo su 
    55 echo "core.%e.%p.%h" > /proc/sys/kernel/core_pattern 
    56 }}} 
    57  
    58 In order to get a core dump, allow the core dump size to be unlimited, i.e. in the active shell: 
    59 {{{ 
    60 ulimit -c unlimited 
    61 }}} 
    62  
    63 Next time your program crashes you will get a properly (given your pattern) named core dump. Call gdb with it, i.e. 
    64 {{{ 
    65 gdb <name-of-your-executable> <core-dump-file> 
    66 bt 
    67 }}} 
    68  
    69 === Valgrind === 
    70 You can test your libraries directly with [http://valgrind.org/docs/manual/QuickStart.html valgrind].  
    71 Note that there are different tools available for valgrind, e.g. memcheck, cachegrind, callgrind, helgrind or massif, while memcheck is the default one applied.  
    72 {{{ 
    73 valgrind tools=helgrind <your-executable> 
    74 }}} 
    75  
    76 Once you use orocos.rb you can activate valgrind as well. 
    77 {{{ 
    78 require orocos 
    79 include Orocos 
    80 Orocos.initialize 
    81  
    82 Process.run 'your-deployment', 'valgrind' => true do 
    83  .... 
    84 end 
    85  
    86 }}} 
    87  
    88  
     5== General Programming == 
     6 * [./DebuggingTechniques debugging techniques for C++ libraries and oroGen components (some are not Rock specific !)]