On Thu, Feb 26, 2009 at 03:11:04PM -0500, James Carlson wrote: > Alexandre Chartre writes: > > > > That's a runtime problem so the compiler can not do anything (unless you > > allocate an obviously too large structure on the stack), but this will > > mainly depend on the code path and allocations on the stack by different > > function calls. > > Well, of course, and I noted that in my original message. > > However, it is specifically the "obviously too large" case that I'd > like to protect against, and that *IS* something that the compiler > knows. It's trivially easy to walk right into this without realizing > it, and when you do, debug becomes extremely difficult. > > The code path cases can actually be handled in a different fashion > (stack guard pages) *IF* you can guarantee that no function > accidentally allocates a gargantuan block of storage. If you can't > guarantee that, though, then you'll be hurt, because you can have > cases where the stack pointer jumps the guard and lands right in the > middle of the heap. As it did for me. :-< > > (Yes, I realize that both alloca and the newer VLAs will make a mess > of a plan like this. At best, I'd expect a tool that automatically > checks for bad functions to print a warning so that the user can > inspect carefully before driving on. There shouldn't be too many > cases of either alloca or VLAs in the mdb code itself.) > > > The tool Ed mentioned is a new dcmd command: ::stackinfo (available since > > Nevada build 102), which shows kernel thread stack usage. > > I'm talking about kmdb's stack itself. When that explodes, all is > lost.
There *is* a stack checking mode in the compiler, which we could probably turn on. The only catches is we'd have to implement the backend support, and an unknown performance degradation. Since it's based on guard pages, I *think* it would only effect routines which allocate more than a page (or just adds a blind read of the new stack pointer). Might be something to investigate. Cheers, - jonathan
