Re: [pdf-devel] gdb breakpoints in scripts?

[Aleksander Morgado]

>> I was able load and run the script under gdb as stated in [1]. I set a
>> BP on the function of interest. gdb responded as expected with a file
>> and line number (which were correct).
>>
>> However, when I run the script, the BP is never hit. I do see the
>> results of the failed test, so I know the function where the BP was
>> set executed.
>>
>> Is there anything special for debugging under gdb and the script wrapper?
>>
> Did you tell GDB to follow child processes?
>
> (gdb)set follow-fork-mode child

No. But after doing so, still no joy. It appears to follow the first
child (alloc in the tests), but no others.

Jose and me tried on weekend to run under GDB all torture tests, playing with "follow-fork-mode" and "detach-on-fork" options; but no success.

* If "set follow-fork-mode child", only the first forked child will run under GDB, and parent is "detached" from GDB, so no other new forks will get run under GDB as parent itself is not run under GDB.
* If "set follow-fork-mode child" AND "set detach-on-fork off", then both parent and child are run under GDB: the first child is executed under GDB properly, and the parent gets 'on hold'. After the first child finishes its execution under GDB, you then need to change to the on-hold parent process, which is an "inferior" in GDB (see http://sources.redhat.com/gdb/current/onlinedocs/gdb.html#Inferiors-and-Programs), and tell it to continue execution. Once parent continues, next test case will get forked again under GDB, and you need to repeat the whole process. Thus, this is not a good method to follow if you want to debug test #300, as you may need to do it 300 times.

Then, the best way to try to debug all these tests under GDB, is to avoid forking in Check, setting the CK_FORK env variable as this, before running GDB:
$> export CK_FORK=no

This will tell the 'check' library not to fork in each process, and thus, GDB will manage all the tests. The problem with this approach is that if any of the previous tests executed before the one you want to debug crashes, like with a segfault, then all the test suites & cases get crashed at that point and there is no way to continue. Of course, if the crashed tests are always the same ones, you can 'disable' them temporarily in the source code and repeat the execution.

Jose pushed a change to the 'check' library last week, which is being reviewed by its developers (the current feedback to the patch is quite good)  so that you can tell the library to run a single test instead of the whole set of test suites and test cases. When that improvement is pushed into the official check library we will be able to run & debug one single test of your choice at a time, either forking and setting follow-fork-mode to child, or directly not forking in check.

Cheers,
- Aleksander