You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think I'm running into issues where Angora might be failing because it is not reaping zombie child processes, filling up the process table, then unable to launch new processes. It appears that the fork server does read the status of the child processes, so there must be another invocation that doesn't check the exit codes?
Do you know where this might be originating from?
Here's an example with base64 from LAVA-M, the number of defunct processes just keeps growing over time.
And here's the error log from another instance on the same host:
WARN angora::executor::forksrv > Fail to read child_id -- Interrupted system call (os error 4)WARN angora::executor::forksrv > Fail to read child_id -- Interrupted system call (os error 4)WARN angora::executor::forksrv > Fail to read child_id -- Interrupted system call (os error 4)WARN angora::executor::forksrv > Fail to read child_id -- Interrupted system call (os error 4)ERROR angora::executor::forksrv > FATAL:Failed to spawn child.Reason:Resource temporarily unavailable(os error 11)
thread '<unnamed>' panicked at 'explicit panic', fuzzer/src/executor/forksrv.rs:66:17
stack backtrace:WARN angora::executor::forksrv > Unable to request new process from frok server! -1ERROR angora::executor::forksrv > FATAL:Failed to spawn child.Reason:Resource temporarily unavailable(os error 11)
thread '<unnamed>' panicked at 'explicit panic', fuzzer/src/executor/forksrv.rs:66:170: backtrace::backtrace::libunwind::trace
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:861:backtrace::backtrace::trace_unsynchronized
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:662:std::sys_common::backtrace::_print_fmt
at src/libstd/sys_common/backtrace.rs:783: <std::sys_common::backtrace::_print::DisplayBacktraceas core::fmt::Display>::fmt
at src/libstd/sys_common/backtrace.rs:594:core::fmt::write
at src/libcore/fmt/mod.rs:10765:std::io::Write::write_fmt
at src/libstd/io/mod.rs:15376:std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:627:std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:498:std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:1989:std::panicking::default_hook
at src/libstd/panicking.rs:21810:std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:48611:std::panicking::begin_panic
12: angora::executor::forksrv::Forksrv::new
13: angora::executor::executor::Executor::rebind_forksrv
14: angora::executor::executor::Executor::run
15: angora::search::afl::AFLFuzz::run
16: angora::fuzz_loop::fuzz_loop
note:Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:0: backtrace::backtrace::libunwind::trace
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:861:backtrace::backtrace::trace_unsynchronized
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:662:std::sys_common::backtrace::_print_fmt
at src/libstd/sys_common/backtrace.rs:783: <std::sys_common::backtrace::_print::DisplayBacktraceas core::fmt::Display>::fmt
at src/libstd/sys_common/backtrace.rs:594:core::fmt::write
at src/libcore/fmt/mod.rs:10765:std::io::Write::write_fmt
at src/libstd/io/mod.rs:15376:std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:627:std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:498:std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:1989:std::panicking::default_hook
at src/libstd/panicking.rs:21810:std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:48611:std::panicking::begin_panic
12: angora::executor::forksrv::Forksrv::new
13: angora::executor::executor::Executor::rebind_forksrv
14: angora::executor::executor::Executor::run_with_cond
15: angora::search::gd::GdSearch::cal_gradient
16: angora::search::gd::GdSearch::run
17: angora::fuzz_loop::fuzz_loop
note:Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
The text was updated successfully, but these errors were encountered:
I think I'm running into issues where Angora might be failing because it is not reaping zombie child processes, filling up the process table, then unable to launch new processes. It appears that the fork server does read the status of the child processes, so there must be another invocation that doesn't check the exit codes?
Do you know where this might be originating from?
Here's an example with base64 from LAVA-M, the number of defunct processes just keeps growing over time.
And here's the error log from another instance on the same host:
The text was updated successfully, but these errors were encountered: