default stack size on modern Linux?

Hi,
I am experiencing some random crashes in my program due to corruptions in apparently random places in the heap. I suspect it is because I am allocating fairly large blocks on the stack (globally), and it is extending into the heap. I am using in total about 150KB of stack space. Is it too much? Would someone please give me a bulk figure as to how big stacks are typically in a modern OS (I understand that it varies quite a bit, but is it something like several KBs or several MBs)? My Googling has been fruitless.

Also, how do I get the memory map from a core dump? (assuming it's recorded in there).
I couldn't seem to find anything in gdb documentation.
I want to see the core dump because valgrind reports an invalid read just before the program crashes, but I don't know where that address is in memory (doesn't seem to be in gdb's symbol table).

Thanks

No, the stack in linux is "far from the heap" with a page of memory that is called a "guard-page" - that page is always "invalid", so if you go outside the max stack size, it will walk into the guard-page, not the heap.

Your heap failures are highly likely just that - you overwrite the end of one or another heap allocation. Perhaps you can add some "crumble zone" to some of your common heap allocations and check if you "hit" the crumble zone when the memory is freed.

Edit: And to answer your direct question, the default max stack size is something like 8MB - depends on the settings in your particular system, but it's certainly more than a few hundred kilobytes. "rlimit" will show you the max stack size for any process, and since the stack in (modern) linux kernels start from the highest available user-space address (just the the "zero" side of 3GB, something like 0xBFFFF000), there is no reason why the stack can't grow to any size you like [until just before it hits some shared library, heap or some other part of "used memory").

--
Mats

On Fedora 8, "ulimit -s" shows 10240 KB.

Thanks for your helps!
Guess my problem is unrelated to stack overflow afterall.

Quote:

---

Your heap failures are highly likely just that - you overwrite the end of one or another heap allocation. Perhaps you can add some "crumble zone" to some of your common heap allocations and check if you "hit" the crumble zone when the memory is freed.

---

The "crumble zone" would be hard to do in my case as the corrupted memory seems to be inside vectors (since if I don't run the program in valgrind, it crashes with a "glibc detected..." when vector calls realloc internally).

I was thinking it's something to do with the stack because apparently valgrind is supposed to catch memory overrun on the heap, but not on the stack.

Quote:

---

On Fedora 8, "ulimit -s" shows 10240 KB.

---

on my Debian it's 8MB.