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. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
