smcc
commented
4 years ago This problem sounds a bit mysterious and low-level, so it has the best chance of being fixed if it's reproducible. Using one of the supplied examples helps with that, but giving more details about how you compiled FuzzBALL would also be helpful. If you're mostly using the standard packages of a well-known Linux distribution, the distribution version would be the quickest shorthand.
The function call "flush stdout" isn't one that you would usually expect to cause a segfault. OCaml's memory safety catches most of the problems that would be segfaults in a C program, and flushing standard output (similar to the C "fflush(stdout)") shouldn't involve many dynamically-allocated pointers. What evidence led you to conclude that the call to flush is the cause of the problem? If you were lead to that based on running your test under GDB, it would be helpful to see more details like a full stack backtrace, the faulting instruction, and the values of its operands.
I mentioned I'm a bit skeptical of the flush being the true problem, but you could test that hypothesis by commenting out this call to flush and repeating your testing. The flushing shouldn't change FuzzBALL's behavior when it's executing normally: it just affects the order in which messages are printed including messages that might be missed if they are still buffered at the point of a crash.
when I run fuzzball, after entering fuzzball -linux-syscalls -fuzz-start-addr 0x080485af -symbolic-word 0xbfffcf4c=n simple -- ./simple 42 in the terminal,I encountered segmentation fault(core dumped).I found that the "flush out" statement in the "exec_run_common.ml" file caused this problem,but I don't know how to solve it.