Memory leak (71768558)

[yaml]

Memory leak (71768558)

[ingydotnet]

Thank you for your report. I was able to run your reproduction strategy and get the leak report.

We will look into fixing this bug.

You should note that there is a bug in your repro code. You reported the bug against commit d050fe3 but the reproduction uses 01f3a87 (HEAD).

Is there a public repository where we can report issues about the autofuzzing project. There are a few things I'd like to report.

[ingydotnet]

@Google-Autofuzz I appreciate your work, but I find your reproduction methodology to be unnecessarily complicated. I took the liberty of streamlining some things so that it is simple and exact to reproduce. Here is how I would have reported this strategy:

---

You can reproduce our findings by running the following commands in a terminal:

wget https://github.com/yaml/libyaml/files/1794405/autofuzz-libyaml-111.zip
unzip autofuzz-libyaml-111.zip
cd autofuzz-libyaml-111
docker build --tag=autofuzz-libyaml-111 .
docker run -t autofuzz-libyaml-111

To run this interactively, use:

docker run -it autofuzz-libyaml-111 bash

Then run this command in the container:

./repro.sh ./reproducer

---

Take a look at that zip file. The changes I made are:

• Put the files in a wrapper directory
• Added 4 commands to the end of your Dockerfile
• Added a symlink to your reproducer file
• Added a ReadMe file

Here is the benefit:

• The reproduction commands are exact. You can literally cut/paste all the commands into a terminal at once, and they will run exactly. Try it!
• It is common courtesy to zip or tar a single directory, rather than a bunch of files. But in addition, now the user doesn't need to do your mkdir step. They just unzip and the build directory is there.
• No reason to copy over the reproducer file in a separate step and in a separate terminal session. This makes people think your setup is going to be a pain in the butt, when it's really not. The file is copied over in the build step. All the user needs to do is a docker build ... and a docker run.
• I found this line to be a doozy:

  docker cp /path/to/attached/reproducer running_container_hostname:/fuzzing/reproducer
  

  You give the user all these fake paths that are probably obvious to you, but totally confusing to the user. WTH is /path/to/attached/reproducer?? I had to guess that it was poc-9b6dc82a78647c1c2c906f1d29f81ac93777df493f5f6dee87aa16b045bb37ed_min
  Now the commands and paths are all exact and literal. No guessing as to what you are trying to say.

I hope this helps you come up with a better way to report your bugs. If you are interested, I have more ideas on how to polish this process. For now I just concentrated on a clean end-user experience.