10

I am working on a game of Hex in C++ on a Unix platform (Currently running c shell). The AI for my game takes less than a minute to decide on its move (I'm using a sort of Monte Carlo algorithm), and after a few steps, the program terminates on its own, merely printing "Killed" before returning to my command prompt. Does anyone understand what is causing this to happen, and have any suggestions as to how I might go about changing my code to fix it? If it helps at all, I am not using my system. I am connected to my school's server using SSH Secure Shell. I should also point out that I don't think its something wrong with my algorithm because it works as I expect it to until the crash, but it consistently crashes while deciding its 7th move.

jbrahy
  • 4,228
  • 1
  • 42
  • 54
user2309865
  • 357
  • 2
  • 4
  • 14
  • 4
    It sounds like there is a deamon running that kills processes using up too much memory or which are resource intensive in some other way. The only thing we can know is that something on the system is killing your process. You should contact your sysadmin to find out why this is happening. – Alex V Jun 05 '13 at 23:20
  • 2
    If it's always at the same point in the game I wouldn't rule out that code just yet! Without seeing the relevant parts of the code all answers are just guesses. ;) – vdbuilder Jun 05 '13 at 23:22
  • 3
    You should learn to use the debugger. If you compile your program with debug information (the `-g` flag to gcc) then you can run the program in the debugger [gdb](http://www.gnu.org/software/gdb/) and it will stop when the program crashes. You can the check the call stack and examine variables to see where the crash occurred and what might have caused it. – Some programmer dude Jun 05 '13 at 23:25
  • 1
    The fact that always crashes at the same point sounds suspiciously like a bug. It's possible you enter some tight loop that sucks up the cpu long enough that a sysadmin or resource limitation just kills it. – Duck Jun 05 '13 at 23:25
  • Nearly one minute is too much for thinking. I think You wanted to make a smart AI and Your decision tree is very large. And after a few steps, it becomes even larger and the algorithm will be killed because of the high memory usage. –  Jun 05 '13 at 23:27
  • 1
    Probably a duplicate of http://stackoverflow.com/questions/726690/who-killed-my-process-and-why – DarioP Nov 07 '13 at 07:58
  • What is return code of your program in this case? `echo $?` immediately after it killed? – Vadim Key May 23 '16 at 20:10

2 Answers2

8

That's the out of memory manager that does that. Most likely you have some sort of memory leak. If you want to continue with the memory leak you can run a script like this in another session. Replace processname with the name of your binary.

#!/bin/bash
while true; do {
    pgrep -x "processname" | while read PID; do {
        echo -1000 > /proc/$PID/oom_score_adj; 
    } done;
} done;
jbrahy
  • 4,228
  • 1
  • 42
  • 54
  • 1
    Could you explain a bit more what does this script? Does it tell to the kernel to ignore the memory used by the process by some way? – stelios Sep 04 '17 at 18:36
  • 4
    When you have an out of memory error there's an election that happens and the one with the highest score gets killed. This script constantly updates the score of the process you want to protect to -1000 so it's always less than the other processes. – jbrahy Sep 05 '17 at 22:34
1

I don't think its something wrong with my algorithm because it works as I expect it to

I think this is the crux of the issue. There are many things that can be "wrong" with an algorithm besides it not meeting its functional requirements.

In particular, the time complexity or the space complexity can be infeasible for modern hardware.

In your case, your space usage is blowing up, triggering the OOM killer. As the original responder said, it's probably caused by a memory leak (but it could also just be a "bad" algorithm, which would exhibit the same behaviour).

Often new GUI programmers forget to clear old rendered screens so they just pile up on each other (a huge memory leak). That's the first thing I'd check.

DylanYoung
  • 2,423
  • 27
  • 30