Is there certain restriction on how much resource ...
# general
r
Is there certain restriction on how much resource pants is allowed to use when running certain goal e.g. when running tests? I see quite a lot of OOM related exit code (-11) when running tests using pants locally on my laptop but not in our CI/CD
e
-11 is SIGSEGV! not OOM That's bad.
😮 1
In an OOM condition, on Linux at least, you'd see -9.
r
This is on a Macbook (no M1/M2)
e
They may use -9 for OOM as well, but definitely not -11. You should be able to run
kill -l
to get a list of signals on a UNIX machine.
For me on Linux:
Copy code
$ kill -l
 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP
 6) SIGABRT      7) SIGBUS       8) SIGFPE       9) SIGKILL     10) SIGUSR1
11) SIGSEGV     12) SIGUSR2     13) SIGPIPE     14) SIGALRM     15) SIGTERM
16) SIGSTKFLT   17) SIGCHLD     18) SIGCONT     19) SIGSTOP     20) SIGTSTP
21) SIGTTIN     22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ
26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO       30) SIGPWR
31) SIGSYS      34) SIGRTMIN    35) SIGRTMIN+1  36) SIGRTMIN+2  37) SIGRTMIN+3
38) SIGRTMIN+4  39) SIGRTMIN+5  40) SIGRTMIN+6  41) SIGRTMIN+7  42) SIGRTMIN+8
43) SIGRTMIN+9  44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9  56) SIGRTMAX-8  57) SIGRTMAX-7
58) SIGRTMAX-6  59) SIGRTMAX-5  60) SIGRTMAX-4  61) SIGRTMAX-3  62) SIGRTMAX-2
63) SIGRTMAX-1  64) SIGRTMAX
r
Yeah I'm definitely not well versed in all these exit Code. So I would agree with you. I only added mac part to provide more context.
e
Basically, on Linux, the kernel OOMKiller issues kill -9 agains a process. Thus the -9.
Right, so a segmentation fault (SIGSEGV) is not good.
That represents a native code bug. Maybe in CPython, maybe in Pants Rust.
r
It only happens with certain tests. Tried some ldebug etc and all keep sandbox but haven't figured out yet
e
I have no clue how to turn on core dumps on Mac or where they are dumped to, but if you can figure that out and get a core dump, it can then be loaded with
gdb
and the like to see which thread crashed where.
r
So I figured out the issue. It was a custom wheel we had built for prophet but it was for an older version of macos. With recent update to macos it created the issue. I just updated the lockfile and it works.