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

111–120 of 320 posts

Re: fork() can fail

#111

Post by nuxi »

pachydermic wrote: post #56
stinos wrote: post #14

Earlier quoted context omitted.

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. Ov…

There's a good reason you can't rely on CWD other than root - the directory can be on a different mountpoint and possibly even on a remote mountpoint. If the remote server goes down or the mountpoint is forcefully unmounted, what would your CWD point to then? Root is the only directory guaranteed to always exist, that's why you'd see a chdir('/') as one of the first steps in properly written unix daemons.

Re: fork() can fail

#112

Post by brazzy »

marcosdumay wrote: post #99
brazzy wrote: post #73

And this right there is why exceptions are a superior mechanism of announcing errors...

Except that exceptions and non-garbage collected languages don't work that well toguether.

I'll have to admit I'm not very familiar with such languages, but shouldn't finally clauses and RAII be sufficient to deal with any necessary cleanup?

Re: fork() can fail

#114

Post by jjnoakes »

nuxi wrote: post #111
pachydermic wrote: post #56

Earlier quoted context omitted.

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. Ov…

There's a good reason you can't rely on CWD other than root - the directory can be on a different mountpoint and possibly even on a remote mountpoint. If the remote server goes down or the mountpoint is forcefully unmounted, what would your CWD point to then? Root is the only directory guaranteed to always exist, that's why you'd see a chdir('/') as one of the first steps in properly written unix daemons.

Almost - the main reason for the chdir('/') is so that if you do happen to be in a mounted file system (locally or remotely), your daemon doesn't prevent the system administrator from gracefully unmounting that file system for whatever reason.

Re: fork() can fail

#115

Post by jleader »

rosser wrote: post #87
cperciva wrote: post #16

Earlier quoted context omitted.

I usually use switch with fork: if (daemon && !test_mode) { int pid; switch (pid = fork()) { case -1: /* Error */ fatal_error("Failed to fork"); case 0: /* In child */ break; default: /* In parent */ write_pid(pid_file, pid, !test_mode); exit(0); } } else { write_pid(pid_file, getpid(), !test_mode); }

I'm kinda surprised that the assignment-during-test thing doesn't generate a warning in the case of a switch statement. It does in other cases (if and while do under gcc and clang, at least).

Assignment-during-test is flagged because it's common for a typo to conflate assignment and equality-testing. Equality-testing is very common in an if or while, so an assignment inside an if or while has a fairly high likelihood of actually being a mis-typed equality-test. Switch, on the other hand, is very rarely used with an equality-test (since equality-test only returns true or false, why would you use a switch when an if would suffice?). So an assignment inside a switch is much less likely to be a mis-typed equality-test.

Re: fork() can fail

#116

Post by loup-vaillant »

klodolph wrote: post #74
samspot wrote: post #72

Earlier quoted context omitted.

Annoyingly, that article refers to the One True Brace Style but doesn't bother to define it or link to it!

The "One True Brace Style" is actually a specific style with that name. It is based on the K&R style, with the additional stipulation that all `if`, `else`, `for`, and `while` statements use braces.

Here: https://en.wikipedia.org/wiki/Indent_style#Variant:_1TBS

Re: fork() can fail

#117

Post by jjnoakes »

Aurel1us wrote: post #10

Just as a reminder: "So, malloc on Linux only fails if there isn’t enough memory for its control structures. It does not fail if there isn’t enough memory to fulfill the request." - http://scvalex.net/posts/6/

malloc() can fail in other ways.

One is if you set a lower process limit.

Another is if you are allocating lots of memory with alternating mprotect() permissions. On some systems (AIX for example) this uses up all of the memory for control structures WAY before hitting the address space limit (I've seen it fail after just a couple of GB).

Re: fork() can fail

#118

Post by loup-vaillant »

cperciva wrote: post #93
rosser wrote: post #87

Earlier quoted context omitted.

I'm kinda surprised that the assignment-during-test thing doesn't generate a warning in the case of a switch statement. It does in other cases (if and while do under gcc and clang, at least).

If it creates warnings, you can silence them by adding extra parentheses, e.g., if ((buf = malloc(buflen)) == NULL) goto outofmemory;

Careful with that example. The parentheses here don't just remove the warning. They remove a bug. This code:

  if (buf = malloc(buflen) == NULL)
      goto outofmemory;
is actually equivalent to that code:

  if (buf = (malloc(buflen) == NULL))
      goto outofmemory;
So, malloc gives you a pointer, which is compared to the null pointer, giving you either 0 or 1. And that is assigned to buf. Hopefully your compiler will warn you about the type error that spawns from such dark magic.

Re: fork() can fail

#120

Post by loup-vaillant »

AnimalMuppet wrote: post #78
cperciva wrote: post #42

Earlier quoted context omitted.

You mean, after exit(0) returns?

Not after exit(0) returns, no. Instead, you're going to want it after some programmer removes exit(0) six months from now.

I'm going to write a pre-processor which adds the appropriate `break` statements automatically. No more fall-through bug.

(And if you really want to fall through, I could add a `fallthrough` keyword.)

Post reply on HN