Just to inject a comment here that isn't complaining about the post, I found it an interesting read! It's pretty rare for anyone working in these sorts of situ

Just to inject a comment here that isn't complaining about the post, I found it an interesting read! It's pretty rare for anyone working in these sorts of situations to explain anything at all and I'm grateful the author bothers to write them up. I inferred from context that "stackgap" was some sort of random memory space added to a process, but in case anyone else isn't familiar with it I found this presentation with a picture (the previous slide explains a bit more too): http://www.openbsd.org/papers/auug04/mgp00005.html http://www.openbsd.org/papers/auug04/mgp00005.html From there it suggests it's normally a random gap in the ~256kb range. The change mentioned in the post increased the range to up to 2mb, which explains why that, coupled with a 2mb stack limit, caused such problems. I'm a little surprised this didn't trigger problems earlier, since it would randomly causes processes to have half as much stack as they used to. I guess most processes don't use anywhere near 2mb (that's the 4mb limit - potential 2mb of gap) of stack?