process.c: try to workaroun SEGV by r65994

http://ci.rvm.jp/results/trunk-mjit-wait@silicon-docker/1480173

It tries to print C backtrace but fails. And core file on the server
seems to be stopping on the irrelevant place due to its own signal
handler for the dump.

And I failed to reproduce this SEGV on my machine.

I don't know why it's broken, so let me try this change to investigate
the reason of SEGV.

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65997 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This commit is contained in:
k0kubun 2018-11-26 14:45:39 +00:00
parent c8c265f42a
commit 0e6aba22c6
4 changed files with 35 additions and 16 deletions

View file

@ -2944,7 +2944,13 @@ rb_f_exec(int argc, const VALUE *argv)
execarg_obj = rb_execarg_new(argc, argv, TRUE, FALSE);
eargp = rb_execarg_get(execarg_obj);
if (mjit_enabled) mjit_finish(); /* do not leave files or leak children */
if (mjit_enabled) {
/* TODO: Use mjit_finish() here. We're not doing so because it leads SEGV
http://ci.rvm.jp/results/trunk-mjit-wait@silicon-docker/1480173 and we don't know why. */
mjit_pause(FALSE); /* do not leak children */
mjit_clean_files(); /* do not leave files. */
mjit_enabled = FALSE; /* MJIT won't work without files deleted above. never JIT-able after exec failure + rescue, for now. */
}
before_exec(); /* stop timer thread before redirects */
rb_execarg_parent_start(execarg_obj);
fail_str = eargp->use_shell ? eargp->invoke.sh.shell_script : eargp->invoke.cmd.command_name;