I have written a computer program in C++, compiled it and ran it within terminal using the command line. This program has run fine many times, but it appears that whenever its accumulated CPU time exceeds 60 minutes (which occurs after about 9 minutes as it runs at ~700% on eight threads) it is killed by the run-time system (at least that is suggested by monitoring it using top).

There is no error or other message, but merely the word "Killed" printed to the command line:

MacBook-Pro-8:~/directory> ./program_name options

Is there a limit on the accumulated CPU time for such processes? How can I find out what killed my process? How can I avoid this?

Following the suggestion to run this in a debugger, here is the result:

Process 90937 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGKILL
frame #0: 0x000000010001fc50 captureISO`tbb::interface9::internal::start_for<WDutils::Parallel::details::blocked_range_terminating<unsigned long>, (anonymous namespace)::simulations::sampleSome(bool)::$_2, tbb::auto_partitioner const>::run_body(WDutils::Parallel::details::blocked_range_terminating<unsigned long>&) [inlined] tbb::concurrent_vector<(anonymous namespace)::simulations::initialCondition, tbb::cache_aligned_allocator<(anonymous namespace)::simulations::initialCondition> >::push_back(this=0x00007fff5fbfebd0)::simulations::initialCondition const&) at concurrent_vector.h:846 [opt]
   843      iterator push_back( const_reference item )
   844      {
   845          push_back_helper prolog(*this);
-> 846          new(prolog.internal_push_back_result()) T(item);
   847          return prolog.return_iterator_and_dismiss();
   848      }

Thus, the error occurred within tbb_concurrent_vector.h in a call to placement new, suggesting a lack of memory. Though I'm still mystified why this should result in a kill signal. But this appears off topic here. I have asked on Stack Overflow.

  • In the code are you catching signals? – mmmmmm Jul 20 '19 at 13:07
  • @Mark No, I don't – Walter Jul 20 '19 at 14:11

In general there’s no limit on accumulated CPU time for processes on macOS.

It seems likely that your program stopped due to issues such as bugs in the program, lack of memory, or similar. In order to find out what happened, try starting your program in the debugger and look at the backtrace.

In addition you should replace the signal handler in the program with one, that prints out which signal it receives. You could potentially also change the program not to kill itself when receiving the signal, but instead do something - like for example freeing up memory. It depends on the signal you’re receiving whether or not it can be ignored.

| improve this answer | |
  • you should replace the signal handler in the program with one, that prints out which signal it receives -- how can I do that? – Walter Jul 20 '19 at 14:11
  • This is definitely not the immediate result of a bug, but perhaps due to lack of memory. However, in that case I'd expect the code to first start swapping. That is not happening, though. – Walter Jul 20 '19 at 14:13
  • 1
    @Walter You might need to ask that follow on question on a programming site since we’re focused on scripting and how the OS works. The on-topic answer here is the OS doesn’t log signals being sent. Also, enabling logging might be some work but running it in a debugger might help you catch the termination cause? – bmike Jul 20 '19 at 14:13
  • However the question re replace the signal handler in the program will be too broad for Stack Overflow as you should not just cut and paste code but also need some understanding of what signals are. – mmmmmm Jul 20 '19 at 15:02
  • Check out the edit @Mark - it’s getting sigkill and there is code - so this likely won’t get caught as non MCVE on SO. Walter is clearly skilled and getting right to the issue. – bmike Jul 20 '19 at 15:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .