Stack size is a matter of personal preference. Most programmers like large, well-endowed stacks that stretch the memory fabric to nearly overflowing. Others like to squeeze in smaller but perfectly formed ones with no wasted space. Whatever your predilection, handling an appropriately sized stack is usually done by feel instead of by the numbers. But that’s about to change.
Measuring stack size is the tricky part. It can be hard to get your arms around the problem. Most of us will just eyeball a passing stack and declare it too big, too small, or just right. But how do you quantify that decision? Without hands-on experience, it’s tough to know if a stack has room to grow or is bursting at the seams. Too big and you’re wasting memory; too small and you risk an embarrassing overflow.
From the sandy shores of San Diego comes the answer. Express Logic, the company that makes the ThreadX RTOS, has released StackX, a new tool for measuring and definitively quantifying stack size. With StackX, programmers can finally get a firm grasp on their stack measurements.
StackX works by analyzing a complete executable code stack, from top-level application down through operating system and drivers. Function calls, interrupt-service routines, stack pushes and pops, parameter passing: they all fall under StackX’s scrutiny. When the analysis is done you get a call-tree graph (which is helpful in itself) and a set of numbers detailing stack usage for each thread of execution. Any manual touch-up beyond that is up to you.
Stack overflows can be hideously difficult to debug because they so often occur in deeply nested routines. The routines themselves may not be buggy, so staring at the code won’t reveal any secrets. Instead, the fault often lies within the calling conventions or the level to which routines are nested – interrupts often play a role here – and those call chains can be much harder to tease out. As a precaution, most programmers simply over-allocate their stack to avoid such problems.
But what constitutes over-allocation? To know how much is too much, you first have to know how much is enough, and most of us have no idea. We run (or we simulate) the code in a variety of conditions, watch how deep the stack gets, then add a proprietary “fudge factor” that allows us to sleep at night. Or at least, to ship the product. More often than not, the correct stack size is just a SWAG.
StackX doesn’t need to see any source code; it analyzes the near-executable (.elf) file produced by most programming tools. That means it’s equally at home analyzing C code or most other languages. Moreover, you don’t need access to the source code at all, so commercial libraries, object files, or other bits of linked-in code are all treated equally.
What’s also nice is that StackX isn’t specific to Express Logic’s own RTOS. It works on code destined for any RTOS, or no RTOS at all. Naturally, StackX works better on ThreadX-based systems because it understands ThreadX’s calling conventions and stack usage, a bonus for existing Express Logic customers.
So let us heap praise on StackX for its ability to quantify a hitherto informal process. Any tool that improves code reliability is a good thing. If it decreases programmer frustration, so much the better. A well-proportioned stack is a thing of beauty, and StackX provides a way for interested programmers to stay abreast of their memory requirements.
