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

[Jeffrey Walton]

Hi Aleksander (and Jose),

> 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.
> [SNIP]

Thanks for the help. It's nice to see it was not something dumb on my part.

> 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.
How are you guys debugging routines? Do you have a small test harness
that links against the lib after a 'make install'? I ask because I
found the test program using libgnupdf the easiest for my limited
skill set. But using libgnupdf may change things enough so that former
problems no longer appear.

Jeff

On Tue, Feb 9, 2010 at 5:58 AM, Aleksander Morgado
<address@hidden> wrote:
>
>>
>> >> 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
>