Printable View
have a weird bug, allow me a sanity check, please. consider:
if this is called concurrently by multiple threads, there is 1 instance of x per thread, correct? each thread has it's own stack, right?Code:void foo(const std::vector<int>&v,unsigned int start,unsigned int stop,unsigned int& sum)
{
unsigned int x;
for(x=start;x<stop;++x)
{
sum+=v[x];
}
}
i'm getting buffer overrun using code that was copied and pasted from a function that works fine.
Maybe your vector is modified while some threads are using this function?
It's easy to check if that's the case. Just pass the const std::vector<int> rather than the reference to the const std::vector<int>& and see if the same thing happens.
It might also be with the variable sum that the problem is occurring. Just keep an eye on that too.
as usual (for me), i had confused the names of the loop index variables in copy/paste.
What symptom are you observing that makes you think "buffer overrun?"
Each thread has its own stack, but thread stacks are typically a lot smaller than the stack for the main thread, and they lack the ability to expand on demand like the main thread's stack can do.
>> and they lack the ability to expand on demand like the main thread's stack can do
What platform? I've not heard of this limitation on Windows or *nix.
gg
On Linux the main stack can continue to expand downward until it bumps into some other region. A thread has a stack with a size fixed at thread creation time (well, you can put it anywhere you want if you're willing to fiddle the stack pointer). This is just because "the stack" is something owned by the process, not any particular thread and the OS only manages one of them per process.Quote:
Originally Posted by Codeplug
You could simulate the auto-expanding stack with appropriate signal handlers, probably.
>> ... "the stack" is something owned by the process, not any particular thread ...
From my platform/OS agnostic point of view, when looking at the entire virtual memory address space of a process, there is no single "one stack to rule them all" type of concept. I like Linus's mental model of "context of execution" (COE). Using that model I would say that a single virtual memory address space can support multiple COE's, and that each COE has its own unique stack space. So under this model, "a stack" is associated with each COE.
>> .. and the OS only manages one of them per process.
I think "one per COE" is a more accurate statement for most platforms/OS's.
On a particular architecture, there may something akin to a "stack segment" for which there is only one per virtual memory address space - but this is just an implementation detail to the OS. The typical conceptual model is "each thread of execution has its own stack space".
>> You could simulate the auto-expanding stack with appropriate signal handlers, probably.
Right - access to an mprotect()'d "guard page" triggers SIGSEGV - handler can then try to map in more contiguous memory, pushing the guard page down (or up). When there's no more contiguous VM, auto-expansion is done :)
>> and they lack the ability to expand on demand
I read "expand" in the wrong context originally.
I was thinking "expand" = "paging in real memory as needed".
Where I believe your intention was "expand" = "claiming contiguous VM pages in order to extend usable stack space".
>> ... like the main thread's stack can do
This is how Linux behaves, where the stack associated with the main() COE is the only stack with VM_GROWSDOWN. But that can only grow up to "ulimit -s" K, or getrlimit(RLIMIT_STACK). If you set this to "unlimited", then the main() COE stack is allowed to grow.
This will be nice once it mainstream: http://gcc.gnu.org/wiki/SplitStacks
gg
That's neat. You can do some cool stuff with support from the tool chain.Quote:
It would be interesting to put the return addresses on a completely different stack, and implement a software stack for local variables.