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.