Debugging hints I
Being an Engineer one need to resolve problems and sending a mail to a mailinglist and asking for help is most of the time not the problem solving skill you should use. So here is a list of some easy hints…
- Finding a build error (using make) in a log file. You might use a tool like OpenEmbedded that keeps the log file around and you have a build failure. First of all check the end of the file, but one might have compiled with -j X and the failure was a bit earlier. The best way to find the error is to search for ‘***’. E.g. inside or less or vi type (/***) and it will bring you to the first compile error… GNU make is kind enough to flag the error.
- The compiler is bitching about something that might not make any sense. With C languages a program called CPP, the C PreProcessor, is ran over your code and it might include funny headers changing your code. What I normally do is to use the compile line as seen in the terminal and replace the -c with a -E as this will only preprocess and then look at the code. The pre processed code is long, search for includes from places you don’t expect and such…
- If a program points you to a log file, read it. In the case of autoconf (configure) a config.log is written, now the bad news is that the error is not at the bottom of the file. What I do is to look at the text of the last test and search for that inside the config.log, it brings me to the failing test…
- Dealing with remote crashes. You have a segfault but don’t know when/where it is happen and it is hard to reproduce? Just use ulimit -c unlimited in a shell and run your script/applications, the kernel will place a core dump in the directory and you can use gdb and your binary to inspect it.
- Running a libtool based binary/lib from inside the build directory. You can use libtool –mode=execute gdb tests/sms/sms_test and then libtool will setup the environment and invoke your command..
more hints at a later time…