On 210307 2242, Alexander Bulekov wrote:
> My basic workflow for that is:
> QEMU_FUZZ_TIMEOUT=0 QTEST_LOG=1 FUZZ_SERIALIZE_QTEST=1 \
> ./qemu-fuzz-target \
>--fuzz-target=generic-fuzz-virtio-vga ./crash-... > /tmp/out
^
I see the problem. You only hit the breakpoint in the first forked
process? I was able to sort-of work around this, using detach-on-fork.
gdb -q --args ./qemu-fuzz-i386
(gef) set follow-fork-mode child
(gef) set detach-on-fork off
(gef) b generic_fuzz.c:667
(gef) r --fuzz-target=generic-fuzz-virt
On 210305 1551, Qiuhao Li wrote:
> On Thu, 2021-03-04 at 10:23 -0500, Alexander Bulekov wrote:
> > On 210304 1843, Yan Zhiqiang wrote:
> > > Hello Alex,
> > > I'm learning the fuzz in QEMU recently, I review the fuzz code
> > > under
> > > /tests/qtest/fuzz which is written by you.
> > > I learn a
On Thu, 2021-03-04 at 10:23 -0500, Alexander Bulekov wrote:
> On 210304 1843, Yan Zhiqiang wrote:
> > Hello Alex,
> > I'm learning the fuzz in QEMU recently, I review the fuzz code
> > under
> > /tests/qtest/fuzz which is written by you.
> > I learn a lot from it, but I stuck when I want to debug t
On 210304 1843, Yan Zhiqiang wrote:
> Hello Alex,
> I'm learning the fuzz in QEMU recently, I review the fuzz code under
> /tests/qtest/fuzz which is written by you.
> I learn a lot from it, but I stuck when I want to debug the fuzz code.
> I use the gdb with command as follows:
>
> > gdb -q --ar
