| Summary: | Erroneous "(core dumped)" in process death message | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Valentin Nechayev <netch> |
| Component: | kern | Assignee: | Robert Watson <rwatson> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
Responsible Changed From-To: freebsd-bugs->rwatson I'll grab ownership of this one. State Changed From-To: open->patched Committed to 5.3-CURRENT as kern_sig.c:1.266; I went with EFBIG since it's the error number used in other places due to resource limits placing bounds on file allocation. As you point out, it makes no difference as the actual value is lost. I'll merge to RELENG_4 after a short waiting period. Thanks for the patch! State Changed From-To: patched->feedback I've merged this patch to RELENG_4, and the result should appear in the next 4.x release. I've left the PR open so you can let me know if it resolved the problem for you. I'll close it in a couple of weeks if I don't hear anything. State Changed From-To: feedback->closed Closed as bug is believed fixed; no further feedback from submitter. |
On mortal signal, sigexit() in sys/kern/kern_sig.c calls coredump() for some signals (with SA_CORE flag in property table) and marks exit status with WCOREFLAG if it returned 0. coredump() in the same source file returns 0 on successful core write, and errno codes in most cases, but not when core dump is prohibited by resource limit (p->p_rlimit[RLIMIT_CORE].rlim_cur), instead returning 0. I think it is simply typo. As result, kernel says "process exited on signal N (core dumped)" when no core was even supposed to be dumped. Fix: For 5.2: I selected ENOSPC, but really error code doesn't matter while it is !=0.--9a1ur1QzAjKX9WD4xy8NqIGFI1BAJ9kwidIdc8xQ1NG1Q9U8 Content-Type: text/plain; name="file.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="file.diff" --- kern_sig.c.0 Mon Nov 3 14:09:06 2003 +++ kern_sig.c Thu Dec 18 16:20:00 2003 @@ -2546,7 +2546,7 @@ limit = p->p_rlimit[RLIMIT_CORE].rlim_cur; if (limit == 0) { PROC_UNLOCK(p); - return 0; + return (ENOSPC); } PROC_UNLOCK(p); For 4.8, the same patch is to be apply in some different context (without PROC_UNLOCK). How-To-Repeat: ulimit -Sc 0 (in sh/bash) and run something which deads on SIGSEGV.