bnagy / crashwalk

Bucket and triage on-disk crashes. OSX and Linux.
Other
349 stars 37 forks source link

runtime/cgo: out of memory in thread_start #25

Open sanjeevk001 opened 6 years ago

sanjeevk001 commented 6 years ago

Hi, I am getting following error "runtime/cgo: out of memory in thread_start" Appreciate if anyone could help me to resolve this error.

$cwtriage -root . -tidy -afl

---CRASH SUMMARY--- Filename: syncdir3/fuzzer1/crashes/id:000046,sig:11,src:001292,op:flip1,pos:34 SHA1: 236d39b68f31df96b3a18f137b64c7515c3add8a Classification: PROBABLY_EXPLOITABLE Hash: dd4b5faef6857d28b473ce80ddc9299d.e7ea0f15a8da5c1bcb82f89895d16c14 Command: ./BUILD/pngtest syncdir3/fuzzer1/crashes/id:000046,sig:11,src:001292,op:flip1,pos:34 Faulting Frame: test_one_file @ 0x0000000000401df5: in /home/sd/Documents/fuzz/realworld-libs/fuzz-libpng/BUILD/pngtest Disassembly: Stack Head (3 entries): __sigsetjmp @ 0x00007ffff731c1b0: in (BL) test_one_file @ 0x0000000000401df5: in /home/sd/Documents/fuzz/realworld-libs/fuzz-libpng/BUILD/pngtest main @ 0x0000000000403dd9: in /home/sd/Documents/fuzz/realworld-libs/fuzz-libpng/BUILD/pngtest Registers: rax=0x0000000000000000 rbx=0x000000000044bdfd rcx=0x0000000000653b10 rdx=0x0000000000653b10 rsi=0x0000000000000000 rdi=0x0000000000000000 rbp=0x0000000000000002 rsp=0x00007fffffffd988 r8=0x00007fffffffd8d0 r9=0x0000000000000000 r10=0x000000000044c0a3 r11=0x0000000000000212 r12=0x0000000000000002 r13=0xfffffffffffffffc r14=0xfffffffffffffffc r15=0x00007fffffffe15e rip=0x00007ffff731c1b0 efl=0x0000000000010246 cs=0x0000000000000033 ss=0x000000000000002b ds=0x0000000000000000 es=0x0000000000000000 fs=0x0000000000000000 gs=0x0000000000000000 Extra Data: Description: Access violation near NULL on destination operand Short description: DestAvNearNull (15/22) Explanation: The target crashed on an access violation at an address matching the destination operand of the instruction. This likely indicates a write access violation, which means the attacker may control write address and/or value. However, it there is a chance it could be a NULL dereference. ---END SUMMARY--- runtime/cgo: out of memory in thread_start SIGABRT: abort PC=0x7f5a766fb428 m=2

goroutine 0 [idle]:

goroutine 1 [runnable]: syscall.Syscall(0x1, 0x1, 0xc82037b800, 0x748, 0x748, 0x748, 0x0) /usr/lib/go-1.6/src/syscall/asm_linux_amd64.s:18 +0x5 syscall.write(0x1, 0xc82037b800, 0x748, 0x800, 0x0, 0x0, 0x0) /usr/lib/go-1.6/src/syscall/zsyscall_linux_amd64.go:1064 +0x5f syscall.Write(0x1, 0xc82037b800, 0x748, 0x800, 0xc81ffd80ae, 0x0, 0x0) /usr/lib/go-1.6/src/syscall/syscall_unix.go:180 +0x4d os.(File).write(0xc820088008, 0xc82037b800, 0x748, 0x800, 0x0, 0x0, 0x0) /usr/lib/go-1.6/src/os/file_unix.go:249 +0xaa os.(File).Write(0xc820088008, 0xc82037b800, 0x748, 0x800, 0xc8200d0101, 0x0, 0x0) /usr/lib/go-1.6/src/os/file.go:136 +0x8a fmt.Fprintln(0x7f5a76ff6220, 0xc820088008, 0xc82004b9f8, 0x1, 0x1, 0x4106ae, 0x0, 0x0) /usr/lib/go-1.6/src/fmt/print.go:255 +0xa5 fmt.Println(0xc82004b9f8, 0x1, 0x1, 0x5f33c0, 0x0, 0x0) /usr/lib/go-1.6/src/fmt/print.go:264 +0x73 main.main() /home/sd/go/src/github.com/bnagy/crashwalk/cmd/cwtriage/main_unix.go:204 +0x18ba

goroutine 17 [syscall, 1 minutes, locked to thread]: runtime.goexit() /usr/lib/go-1.6/src/runtime/asm_amd64.s:1998 +0x1

goroutine 3 [runnable]: syscall.Syscall(0x0, 0x8, 0xc82026ea28, 0x8, 0x0, 0x8, 0x0) /usr/lib/go-1.6/src/syscall/asm_linux_amd64.s:18 +0x5 syscall.readlen(0x8, 0xc82026ea28, 0x8, 0x1b, 0x0, 0x0) /usr/lib/go-1.6/src/syscall/zsyscall_linux_amd64.go:1085 +0x51 syscall.forkExec(0xc8204fe4e0, 0xc, 0xc8204bba00, 0x1a, 0x1a, 0xc82026ebf8, 0x11cc1, 0x0, 0x0) /usr/lib/go-1.6/src/syscall/exec_unix.go:202 +0x567 syscall.StartProcess(0xc8204fe4e0, 0xc, 0xc8204bba00, 0x1a, 0x1a, 0xc82026ebf8, 0x2, 0x4, 0x0, 0x0) /usr/lib/go-1.6/src/syscall/exec_unix.go:240 +0x6b os.startProcess(0xc8204fe4e0, 0xc, 0xc8204bba00, 0x1a, 0x1a, 0xc82026ee30, 0xc8200c6900, 0x0, 0x0) /usr/lib/go-1.6/src/os/exec_posix.go:45 +0x33e os.StartProcess(0xc8204fe4e0, 0xc, 0xc8204bba00, 0x1a, 0x1a, 0xc82026ee30, 0x0, 0x0, 0x0) /usr/lib/go-1.6/src/os/doc.go:28 +0x69 os/exec.(Cmd).Start(0xc8204eaa00, 0x0, 0x0) /usr/lib/go-1.6/src/os/exec/exec.go:332 +0x761 github.com/bnagy/crashwalk/gdb.(Engine).Run(0x7fd3e0, 0xc8204f7780, 0x2, 0x2, 0xc8204f12c0, 0x4d, 0x32, 0x3c, 0x0, 0x0, ...) /home/sd/go/src/github.com/bnagy/crashwalk/gdb/gdb.go:446 +0x1028 github.com/bnagy/crashwalk.process(0xc82006b1e0, 0xc82001c120, 0xc82001c060, 0xc82000e290) /home/sd/go/src/github.com/bnagy/crashwalk/crashwalk.go:372 +0x161f created by github.com/bnagy/crashwalk.(*Crashwalk).Run /home/sd/go/src/github.com/bnagy/crashwalk/crashwalk.go:540 +0x490

goroutine 4 [chan send]: github.com/bnagy/crashwalk.(Crashwalk).Run.func2.1(0xc8204f1950, 0x45, 0x7f5a76ff62e0, 0xc8204fd040, 0x0, 0x0, 0x0, 0x0) /home/sd/go/src/github.com/bnagy/crashwalk/crashwalk.go:572 +0x239 path/filepath.walk(0xc8204f1950, 0x45, 0x7f5a76ff62e0, 0xc8204fd040, 0xc8200105a0, 0x0, 0x0) /usr/lib/go-1.6/src/path/filepath/path.go:349 +0x80 path/filepath.walk(0xc8202f89a0, 0x18, 0x7f5a76ff62e0, 0xc82031b040, 0xc8200105a0, 0x0, 0x0) /usr/lib/go-1.6/src/path/filepath/path.go:374 +0x4fc path/filepath.walk(0xc8203000d0, 0x10, 0x7f5a76ff62e0, 0xc82031ad00, 0xc8200105a0, 0x0, 0x0) /usr/lib/go-1.6/src/path/filepath/path.go:374 +0x4fc path/filepath.walk(0xc820300080, 0x8, 0x7f5a76ff62e0, 0xc82031ac30, 0xc8200105a0, 0x0, 0x0) /usr/lib/go-1.6/src/path/filepath/path.go:374 +0x4fc path/filepath.walk(0x7fff5e12a16a, 0x1, 0x7f5a76ff62e0, 0xc82006b790, 0xc8200105a0, 0x0, 0x0) /usr/lib/go-1.6/src/path/filepath/path.go:374 +0x4fc path/filepath.Walk(0x7fff5e12a16a, 0x1, 0xc8200105a0, 0x0, 0x0) /usr/lib/go-1.6/src/path/filepath/path.go:396 +0xe1 github.com/bnagy/crashwalk.(Crashwalk).Run.func2(0xc82006b1e0, 0xc82001c120) /home/sd/go/src/github.com/bnagy/crashwalk/crashwalk.go:586 +0x84 created by github.com/bnagy/crashwalk.(*Crashwalk).Run /home/sd/go/src/github.com/bnagy/crashwalk/crashwalk.go:590 +0x4c9

goroutine 5 [semacquire, 1 minutes]: sync.runtime_Semacquire(0xc82000e29c) /usr/lib/go-1.6/src/runtime/sema.go:47 +0x26 sync.(WaitGroup).Wait(0xc82000e290) /usr/lib/go-1.6/src/sync/waitgroup.go:127 +0xb4 github.com/bnagy/crashwalk.(Crashwalk).Run.func3(0xc82000e290, 0xc82009e1e0, 0xc82001c060, 0xc82006b1e0) /home/sd/go/src/github.com/bnagy/crashwalk/crashwalk.go:594 +0x21 created by github.com/bnagy/crashwalk.(*Crashwalk).Run /home/sd/go/src/github.com/bnagy/crashwalk/crashwalk.go:601 +0x50c

rax 0x0 rbx 0x7f5a766c4d68 rcx 0x7f5a766fb428 rdx 0x6 rdi 0x11853 rsi 0x11854 rbp 0x1 rsp 0x7f5a766c4b98 r8 0x2b r9 0x7f5a76a8b540 r10 0x8 r11 0x206 r12 0x2c r13 0x70458c r14 0x0 r15 0x8 rip 0x7f5a766fb428 rflags 0x206 cs 0x33 fs 0x0 gs 0x0

bnagy commented 6 years ago

On a quick look, maybe a go bug. You could try a newer go version?

sanjeevk001 commented 6 years ago

I tried the newer version go1.11.1. I am still getting same error. The error appears for some inputs only (for other inputs, it runs fine), which terminates crashwalk.

bnagy commented 6 years ago

Hm. OK, maybe it’s dying in goroutine 3 (in exec). If that’s the case then you should be able to repro the out of memory condition by manually running the target with that testcase under the debugger. It’s weird though because memory eaters usually get taken care of by gdb. :/ I would play around with that single case and try to understand what it makes the target do.

Just so you know, I am not able to spend any time trying to actually fix this for you, I’m just throwing out ideas!