Last modified: 2014-04-11 13:09:15 UTC
The Jenkins job running MediaWiki core unit tests under hhvm produces files such as /tmp/stacktrace\d+.log which are filling out /tmp on the Jenkins slaves. Looking at hhvm source code, the path can apparently be configured with CoreDumpReportDirectory. It should probably be set to the current working directory. $ git grep --before-context 1 stacktrace.*\.log hphp/doc/debug.server- hphp/doc/debug.server:Normally a crash generates /tmp/stacktrace.<pid>.log file that has stacktrace -- hphp/runtime/base/crash-reporter.cpp- char tracefn[RuntimeOption::CoreDumpReportDirectory.length() hphp/runtime/base/crash-reporter.cpp: + strlen("/stacktrace..log") + strlen(pid) + 1]; hphp/runtime/base/crash-reporter.cpp: sprintf(tracefn, "%s/stacktrace.%s.log", -- hphp/util/stack-trace.h- /** hphp/util/stack-trace.h: * Add extra information to log together with a crash stacktrace log. $
Assuming these are opt-in for debug, can we disable them entirely?
Change 124313 had a related patch set uploaded by Hashar: point hhvm stacktraces to workspace log dir https://gerrit.wikimedia.org/r/124313
Change 124313 merged by jenkins-bot: point hhvm stacktraces to workspace log dir https://gerrit.wikimedia.org/r/124313
Can this be closed?
Still had to verify that Gerrit change #124313 did put the stack trace to the workspace (which is cleaned on each build) instead of in /tmp/. Looked on both slaves integration-slave1001.eqiad.wmflabs and integration-slave1002.eqiad.wmflabs and the workspaces log dir does not have stacktrace currently. I am not sure whether they are generated on each run or only on failure. So yeah /tmp/ no more has stack traces but I am not sure what happens with them.
The stack traces no more show up in /tmp/ \O/
