| ▲ | fsckboy 6 days ago | |||||||||||||||||||||||||
if somebody wants a "C lang/linux level" bug/puzzle to figure out (could be as simple as looking at the source), I just discovered it a couple days ago: if you use a large number to set up a board in untangle, the algo is extremely slow to set the board up, probably an O(N*2) or worse or something. You can see this slowness in the web version, put in a 600 or 2000 the bug: anyway, I was running the C version of the puzzle from cli (didn't want to slow my browser down) and I must have put a typo in for an even bigger number than I intended and the process went away for a long time. I got sick of looking at the little window and discovered that I couldn't kill it even with kill -9. I killed the window with xkill but the process was still chugging away in the background at 99% CPU. I finally managed to kill it with htop but I have a sense that I didn't really kill it, I think it just finished whatever long ops it was doing. I didn't test much more, but I did load up a board size 600 to play and confirmed while it was building the board, kill -9 didn't do anything, and after it finished it allowed me to play the game. the kill -9 was swallowed and gone. | ||||||||||||||||||||||||||
| ▲ | drdec 6 days ago | parent [-] | |||||||||||||||||||||||||
This sounds like an OS or kill bug not a with the program. Sending `kill -9`, aka `kill -KILL` is supposed to terminate the process immediately without giving it the opportunity to catch the signal and respond. (This is why you should start with `kill -TERM` and only resort to `kill -KILL` if that does not work.) So if the process is not terminated this is an OS or kill issue because the process itself is not given a chance to catch the signal. | ||||||||||||||||||||||||||
| ||||||||||||||||||||||||||