On Mon, Jan 15, 2018 at 2:56 PM, Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> wrote: > Dmitry Vyukov wrote: >> > No problem. In the "tty: User triggerable soft lockup." case, I manually >> > trimmed the reproducer at https://marc.info/?l=linux-mm&m=151368630414963 . >> > That is, >> > >> > (1) Can the problem be reproduced even if setup_tun(0, true); is >> > commented out? >> > >> > (2) Can the problem be reproduced even if NONFAILING(A = B); is replaced >> > with >> > plain A = B; assignment? >> > >> > (3) Can the problem be reproduced even if install_segv_handler(); is >> > commented >> > out? >> > >> > (4) Can the problem be reproduced even if some syscalls (e.g. >> > __NR_memfd_create, >> > __NR_getsockopt, __NR_perf_event_open) are replaced with no-op? >> > >> > and so on. Then, I finally reached a reproducer which I sent, and the bug >> > was fixed. >> > >> > What is important is that everyone can try simplifying the reproducer >> > written >> > in plain C in order to narrow down the culprit. Providing a (e.g.) CGI >> > service >> > which generates plain C reproducer like gistfile1.txt will be helpful to >> > me. >> >> I am not completely following. You previously mentioned raw.log, which >> is a collection of multiple programs, but now you seem to be talking >> about a single reproducer. When syzbot manages to reproduce the bug >> only with syzkaller program but not with a corresponding C program, it >> provides only syzkaller program. It such case it can sense to convert. >> But the case you pointed to actually contains C program. So there is >> no need to do the conversion at all... What am I missing? >> > > raw.log is not readable for me. > I want to see C program even if syzbot did not manage to reproduce the bug. > If C program is available, everyone can try reproducing the bug with manually > trimmed C program.
If it did not manage to reproduce the bug, there is no C program. There is no program at all.
