The re-entrant coder

As listed in my previous post, I’m looking at finding out more about coredumps. The page I found the info below on lists that the limit is the maximum size of a process image that a coredump would be generated from.

However, the file will not be created unless your “core dump size limit” is set high enough to accomodate the core dump file.

Unfortunately, it doesn’t refer to the Unix/Linux version used and the age of the information is also unknown. So further investigation ensues.

OK, so here’s an interesting one: I’m currently doing the architecture for a new embedded controller running Linux as its OS. It will use a SoftPLC for the actual control of the hardware and I want it to have a proper way of handling OS failures. We’ve looked at the glibc backtrace() functions and they would solve part of the problem.
Our main problem is the fact that the root fs of the controller will be on a read-only cramfs and that the writable flash partition is only limited in size. We will have more memory than flash, meaning that we cannot accomodate full coredumps. Of course, for this the ulimit -c command has been invented, but I wonder what happens if I set the limit to 1Mb for example. If the process image is larger than this, would the coredump not be generated at all? Or would the generated coredump be limited to this size? And if it is limited to a certain size, is there a coredump size you should not dip below risking that the coredump becomes useless due to missing stack information? The online documentation I found was inconclusive, so its on to experimentation. I’ll update this post with my findings…