Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

fork() can fail

rachelbythebay.com

Post reply on HN
Print view View original

51–60 of 320 posts

Re: fork() can fail

#51

Post by Alupis »

swah wrote: post #29
cperciva wrote: post #7

This reminds me of one of the most epic bugs I've ever run into: mkdir("/foo", 0700); chdir("/foo"); recursively_delete_everything_in_current_directory(); Running as root, this usually worked fine: It would create a directory, move into it, and clean out any garbage left behind by a previous run before doing anything new. Running as non-root, the mkdir failed, the chdir failed, and it started eating my home directory…

In those times I wish I could use the emacs lisp way: (let (dir "/foo") (create-directory dir) (with-current-directory dir (delete-all-files-recursively))) Factor recognized the value of dynamically scoped variables: http://concatenative.org/wiki/view/Factor/FAQ/What's%20Facto... A lot of code became much simpler because of that decision.

This isn't really fork() failing per se -- but rather a failed program/script that did not understand the well defined and clearly documented behavior of fork().

Re: fork() can fail

#52

Post by [deleted] »

kazinator wrote: post #36
zxcdw wrote: post #27

Earlier quoted context omitted.

Who even wants that? When I am coding, sure as hell some compiler vendor won't be telling me what to use my bits for! I identify myself as an atypical coder.

If you tell yourself what the bits are for and stick to it, that is still type. Real chaos is when even you don't.

[deleted]

Re: fork() can fail

#53

Post by cperciva »

quotemstr wrote: post #47
cperciva wrote: post #46

Earlier quoted context omitted.

Even if VM overcommit is enabled, you shouldn't be forking from large processes, because the necessary kernel VM manipulation will kill your performance.

Yep. For that problem, there's vfork.

Which is great, albeit easy to use wrong; but it's not portable, unfortunately.

Re: fork() can fail

#54

Post by CSDude »

I'm a teaching assistant of an OS course, I grade projects. I constantly remind students to check the return values of the system calls and it is mostly the main issue in their codes.

Re: fork() can fail

#55

Post by X-Istence »

tdicola wrote: post #12
runarb wrote: post #8

Easy to test out to. In C: #include int main(void) { while(1) { fork(); } }

Haha too cruel. I remember in one of my early college CS classes the professor told us about fork bombs and wasn't sure if they still worked on the Sun Fire servers we were using. About 5 minutes later someone piped up and confirmed that yep they still worked at bringing the server down. :)

That's why user accounts should have appropriate resource limits set per user.

Re: fork() can fail

#56

Post by pachydermic »

stinos wrote: post #14
cperciva wrote: post #7

This reminds me of one of the most epic bugs I've ever run into: mkdir("/foo", 0700); chdir("/foo"); recursively_delete_everything_in_current_directory(); Running as root, this usually worked fine: It would create a directory, move into it, and clean out any garbage left behind by a previous run before doing anything new. Running as non-root, the mkdir failed, the chdir failed, and it started eating my home directory…

When you see chdir, or any notion of the current working directory being used for anything: run as fast as you can. (or refactor if it's not too late). Things I've seen because of software relying on it.. Sometimes it's just directories/files it creates popping up all over the place, sometimes it's 'just' crashing, but yes sometimes it starts to erase and all hell really breaks loose.

If you can't rely on current working directories then you have to specify any file locations absolutely? That doesn't seem like a good idea because then your code quickly turns into a hot mess if you ever have to change where stuff lives.

This is such a stupid problem I run into a lot. Both alternatives (doing things with absolute paths vs doing things entirely with relative paths) seem to have a lot of downsides. Overall relative paths seems to be way better, but then you leave yourself open to problems which "rhyme" with the one OP was talking about.

Re: fork() can fail

#57

Post by Alupis »

cperciva wrote: post #7

This reminds me of one of the most epic bugs I've ever run into: mkdir("/foo", 0700); chdir("/foo"); recursively_delete_everything_in_current_directory(); Running as root, this usually worked fine: It would create a directory, move into it, and clean out any garbage left behind by a previous run before doing anything new. Running as non-root, the mkdir failed, the chdir failed, and it started eating my home directory…

Could you have not just checked to see if you actually created the directory and/or check to make sure you moved into the directory before proceeding with your destructive function?

(Defensive Programming 101 really).

Re: fork() can fail

#58

Post by dllthomas »

Alupis wrote: post #51
swah wrote: post #29

Earlier quoted context omitted.

In those times I wish I could use the emacs lisp way: (let (dir "/foo") (create-directory dir) (with-current-directory dir (delete-all-files-recursively))) Factor recognized the value of dynamically scoped variables: http://concatenative.org/wiki/view/Factor/FAQ/What's%20Facto... A lot of code became much simpler because of that decision.

This isn't really fork() failing per se -- but rather a failed program/script that did not understand the well defined and clearly documented behavior of fork().

The man page says, "On failure, -1 is returned in the parent, no process is created, and errno is set appropriately."

So if fork is behaving as documented, returning -1 is because of "fork failing".

Re: fork() can fail

#60

Post by bodyfour »

stinos wrote: post #14
cperciva wrote: post #7

This reminds me of one of the most epic bugs I've ever run into: mkdir("/foo", 0700); chdir("/foo"); recursively_delete_everything_in_current_directory(); Running as root, this usually worked fine: It would create a directory, move into it, and clean out any garbage left behind by a previous run before doing anything new. Running as non-root, the mkdir failed, the chdir failed, and it started eating my home directory…

When you see chdir, or any notion of the current working directory being used for anything: run as fast as you can. (or refactor if it's not too late). Things I've seen because of software relying on it.. Sometimes it's just directories/files it creates popping up all over the place, sometimes it's 'just' crashing, but yes sometimes it starts to erase and all hell really breaks loose.

The real problem with chdir is when that code ends up refactored into a library and ends up used in a multithreaded program. Then you've got an ugly bug.
Post reply on HN