I used truss to try to identify what syscall caused the kernel to SIGKILL a jvm and log "out of swap space" to the console while plenty of space was still available in the swap. (This behavior nor this bug report are java-related, I previously observed it with different commands, I desired to understand that behavior and had a ready test case at hand.) I was unable to observe the curlpit syscall because truss triggered an assertion failure before printing anything related. The assertion is: Assertion failed: (LIST_NEXT(info->curthread, entries) == NULL), function find_exit_thread, file /usr/src/usr.bin/truss/setup.c, line 337. The system was compiled from svn revision 329283.
Can you please provide steps to reproduce the bug, and the full output of `uname -a` ?
This bug can be reproduced by truss'ing this process: #include <sys/types.h> #include <pthread.h> #include <signal.h> #include <unistd.h> void *thread_fun(void *arg) { (void)arg; sleep(5); return NULL; } int main() { pthread_t thread; if (pthread_create(&thread, NULL, thread_fun, NULL) != 0) { return 1; } kill(getpid(), SIGKILL); sleep(1); } I suspect the reason is that threads killed by "thread_single()" in "exit1()" don't send a ptrace notification.
I can reproduce this on 11.2-RELEASE and TrueOS-Desktop-201803131015, but not 12.0-ALPHA9.
Sorry, I forgot to mention that I'm running FreeBSD 12.0-ALPHA9 amd64 with some local patches: FreeBSD 12.0-ALPHA9 FreeBSD 12.0-ALPHA9 #3 r339331+0547250df758(test-suspend48)-dirty: Sat Oct 13 13:47:25 CEST 2018 With the program I posted it is reproducible ~80-90% of the time on my laptop. I've found that adding a "usleep(50000);" between the pthread_create() and kill() increases this number. This makes sure that "truss -H" gets the new thread notification (like "101702: <new thread 101702>").
(In reply to Jan Kokemüller from comment #2) Jan, your program do trigger the assertion failure, maybe one time in ten. I have nothing better to provide as the bug was discovered when runing a huge job on Open Street Map data (mkgmap), it occured after more than 30 minutes of compulation. (In reply to Alan Somers from comment #1) Alan, the system on which this was spotted on is identified as follows (an upgrade to 11.2 is planed). FreeBSD memo3.<...> 11.1-STABLE FreeBSD 11.1-STABLE #0: Thu Feb 15 06:58:47 CET 2018 <...>@memo3.<...>:/home/elrond/syswork/FreeBSD-work/11-LOCAL/obj/home/elrond/syswork/FreeBSD-work/11-LOCAL/src/sys/MEMO3 amd64 Source tree taken from svn r329283