Currently if a Linux machine dumps a core file when it encounters a crash, it will dump a core file with the name "core" by default, and the value of /proc/sys/kernel/core_uses_pid is 0. Ideally, it should be core.<pid> (e.g. core.1234) when the value of /proc/sys/kernel/core_uses_pid is set to 1. This value change, however, requires admin privs to change. This will ensure that multiple fuzzing processes with multiple cores trying to dump at the same time won't conflict with each other by trying to dump to the same file named "core". Thoughts?

Seems to set to 1 already: $ ssh linux64-ix-slave18 cat /proc/sys/kernel/core_uses_pid 1 $ ssh linux-ix-slave18 cat /proc/sys/kernel/core_uses_pid 1 $ ssh bld-centos5-32-vmw-014 cat /proc/sys/kernel/core_uses_pid 1

This is weird. I don't get .<pid> extensions at all. After fixing the gzip'ed files' permissions in bug 776414, extracting https://pvtbuilds.mozilla.org/fuzzing/js-mozilla-central-linux-debug/foundat1343734504_4_lines_reduced/w21-core.gz gets me w21-core instead. Maybe it got renamed prior to being gzip'ed? Anyway I don't really have an issue here now, might be a problem somewhere else. I'll file another bug then if that's the case.

> extracting w21-core.gz gets me w21-core Right, because gzip files don't contain filenames. (That's why the unix equivalent of ".zip" is ".tar.gz".) > Maybe it got renamed prior to being gzip'ed? Yes, grabCrashLog (in subprocesses.py) renames it from "core" or "core.<pid>" to "w<iter>-core".

I dug further and core.<pid> is indeed generated. Example: core.13216