dvyukov/go-fuzz

Program hanged

sitilge opened this issue · 5 comments

I'm using go-fuzz and gofuzz to fuzz functions of a package which is built on top of NFF-Go and DPDK. The program hangs after the default timeout. I read a related issue: #21 , and as @dvyukov mentioned

this usually happens when the test is very slow

which might be this case as the DPDK setup (EAL phase) takes roughly 1 second. Is there a way to overcome the problem? The crasher output is

program hanged (timeout 10 seconds)
 
------------***-------- Initializing DPDK --------***------------
EAL: Detected 7 lcore(s)
EAL: Detected 1 NUMA nodes
EAL: Selected IOVA mode 'PA'
EAL: Probing VFIO support...
EAL: PCI device 0000:00:03.0 on NUMA socket -1
EAL:   Invalid NUMA socket, default to 0
EAL:   probe driver: 1af4:1000 net_virtio
EAL: PCI device 0000:00:08.0 on NUMA socket -1
EAL:   Invalid NUMA socket, default to 0
EAL:   probe driver: 1af4:1000 net_virtio
EAL: PCI device 0000:00:09.0 on NUMA socket -1
EAL:   Invalid NUMA socket, default to 0
EAL:   probe driver: 1af4:1000 net_virtio
------------***------ Initializing scheduler -----***------------
DEBUG: Scheduler can use cores: [0 1 2 3 4 5 6]
------------***---------- Creating ports ---------***------------
DEBUG: Port 0 MAC address: 08:00:27:00:0a:a1
DEBUG: Port 1 MAC address: 08:00:27:00:0b:a1
DEBUG: Port 2 MAC address: 08:00:27:00:0b:a2
------------***------ Starting FlowFunctions -----***------------
SIGABRT: abort
PC=0x512621 m=0 sigcode=0
 
goroutine 0 [idle]:
runtime.futex(0x116d7e8, 0x80, 0x0, 0x0, 0x3000000000, 0x7ffcca4baa20, 0x7ffcca4ba960, 0x8435ee042abf8200, 0x7ffcca4ba998, 0x4b870f, ...)
    runtime/sys_linux_amd64.s:567 +0x21
runtime.futexsleep(0x116d7e8, 0x0, 0xffffffffffffffff)
    runtime/os_linux.go:44 +0x46
runtime.notesleep(0x116d7e8)
    runtime/lock_futex.go:151 +0x9f
runtime.stopm()
    runtime/proc.go:1828 +0xc0
runtime.findrunnable(0xc000030000, 0x0)
    runtime/proc.go:2360 +0xa0d
runtime.schedule()
    runtime/proc.go:2520 +0x2fc
runtime.exitsyscall0(0xc000000180)
    runtime/proc.go:3263 +0x116
runtime.mcall(0x0)
    runtime/asm_amd64.s:318 +0x5b
 
goroutine 1 [runnable]:
runtime.Gosched(...)
    runtime/proc.go:269
github.com/intel-go/nff-go/flow.(*scheduler).systemStop(0xc0000220f0)
    /home/vagrant/go/pkg/mod/github.com/intel-go/nff-go@v0.9.2/flow/scheduler.go:350 +0x71
github.com/intel-go/nff-go/flow.SystemStop(0xc00021e060, 0xc00021e000)
    /home/vagrant/go/pkg/mod/github.com/intel-go/nff-go@v0.9.2/flow/flow.go:833 +0x49
github.com/intel-go/nff-go/flow.SystemReset()
    /home/vagrant/go/pkg/mod/github.com/intel-go/nff-go@v0.9.2/flow/flow.go:859 +0x3a
git.sitilge.id.lv/sitilge/ecublens/test/router/arp.FuzzARPExpireEntries(0x7f9250735000, 0x0, 0x0, 0x4)
    /home/vagrant/ecublens/test/router/arp/fuzz.go:89 +0x41d
go-fuzz-dep.Main(0xc000163f68, 0x2, 0x2)
    go-fuzz-dep/main.go:36 +0x1ad
main.main()
    git.sitilge.id.lv/sitilge/ecublens/test/router/arp/go.fuzz.main/main.go:17 +0x5d
 
rax    0xca
rbx    0x116d6a0
rcx    0x512623
rdx    0x0
rdi    0x116d7e8
rsi    0x80
rbp    0x7ffcca4ba960
rsp    0x7ffcca4ba918
r8     0x0
r9     0x0
r10    0x0
r11    0x286
r12    0x3
r13    0x116cf00
r14    0xcc0c6c
r15    0x39
rip    0x512621
rflags 0x286
cs     0x33
fs     0x0
gs     0x0
exit status 2

What is your question?
Try to increase the default timeout. Or run the reproducer manually and see what happens -- does it unstuck? Or hang forever?

Increased to 20 seconds, nothing changed.

My question is - could the program hang because of the slowdown of setting up DPDK?

Just trying to learn here, forgive me for my wrongs :)

What go-fuzz detects is that the test case on the given input did not finish in 10/20 seconds. Usually it means a bug/infinite hang in the program. That's it. I know nothing about DPDK. If it can legitimately run for minutes/hours on a single input, then you need to increase the timeout. Otherwise it may be a bug in DPDK.
Run the input manually and measure time. Or increase timeout to something you would consider as a bug for sure, e.g. 10 minutes.

Is the DPDK setup (whatever that is) something that is one-time or every-time? If the former, you could do it in an init function.

@dvyukov @josharian yes, I discovered the problem is not in go-fuzz. Thank you for support.