3 ms·
1. By creating and closing process very rapidly, one could easily reproduce this problem. I used something like `while true; do sh -c "exit 0"; done`. The en
by saulrh 9y ago
1. By creating and closing process very rapidly, one could easily reproduce
this problem. I used something like `while true; do sh -c "exit 0"; done`.
The entire OS dying to rapidly spawned/exited processes permits a pretty nasty DoS. Good thing that nobody ever uses macs as servers or shared machines.
- btown 9y agoGeez; does this mean it could do the same when compiling a large codebase with Make?
- saulrh 9y agoDunno; I don't have any apple devices. Might ask a coworker to try to repro it on monday. :P (I suspect that recursive makes do enough compute in between invocations to slow down and avoid this bug. If the OS was dying in everyday compile jobs it'd be much bigger news.) EDIT: I think that I might've misread this - it might be that spawning processes pushes htop through codepaths that can cause the bug. So it's more like "a malicious app could kill your system the instant you open htop". In which case, yes, a recursive make while you have htop would would do it. Rather less significant.
- ReverseCold 9y agoWhen I read the headline I didn't think I had run into this bug. Now I remember my OS freezing twice when quickly opening and closing some chrome tabs. Could possibly be the same issue.
- dingo_bat 9y agoJust tried it on Ubuntu (Windows) for fun. 5 minutes later the fans have come on but no freezing yet.
- evanslify 9y agoAuthor of comment here: Doing this alone doesn’t do any harm unless running htop in background, also this only makes the bug happen more quickly. If one has Activity Monitor running prior to crash, it’s still possible to kill htop with it and would make OS useable again.