+-- On Feb 11, Jerry Asher said:
It might not solve the problem of one thread still corrupting
another thread's memory or stack, but assuming a page was larger than
several stack frames, it would certainly catch most typical stack
overflows. Wouldn't it?
Yes, it would catch most
Note that each time you create a stack from (or otherwise dynamically
extend the stack), you need to compare the SP to a thread-specific
limit, which means using TLS. I'm not sure how long Linux (for example)
has supported TLS, and I'm pretty sure that its support has changed over
time, so
Rob Mayoff wrote:
Note that each time you create a stack from (or otherwise dynamically
extend the stack), you need to compare the SP to a thread-specific
limit, which means using TLS. I'm not sure how long Linux (for example)
has supported TLS, and I'm pretty sure that its support has changed
+-- On Feb 12, Jerry Asher said:
I am trying to understand where the thread-specific limit is involved
but I can't.
Heap----stack3 --stack2 --stack1
Stack 3's limit is the top of the heap. Stack 2's limit is the bottom of
stack 3. Stack 1's limit is the bottom of stack 2.
If
If as a thread, I ask for a new thread to be created and hence a new
stack, I would guess (but I don't know) that the base for all stack
pointers are stored in some global, locked, table, along perhaps with
the limits of the stack which are either stored in that table, or
local to the stack
What's your stacksize? Try increasing it.
Brian
-Original Message-
From: Jerry Asher [mailto:[EMAIL PROTECTED]]
Sent: 11 February 2003 09:25
To: [EMAIL PROTECTED]
Subject: [AOLSERVER] aolserver 3.3ad13 on RedHat 8.0
I am consistently (a few times a day) receiving a segv in an AOLserver
Brian Fenton wrote:
What's your stacksize? Try increasing it.
Brian
Yeah, I've done that one. It's currently 500K.
???
Jerry
That's interesting. My copy of stack.test doesn't include anything like
that. The openacs lore has been that 500K has been the appropriate
stacksize. I have increased it to 4M. Let's see what happens.
I added that warning in myself after getting enough reports. I narrowed
the size to
On Tue, Feb 11, 2003 at 02:40:11AM -0800, Jeff Hobbs wrote:
I added that warning in myself after getting enough reports. I narrowed
the size to 2400K to match the default Tcl eval stack recursion limit of
1000. I think 4M is more than you need, 1M will likely do it, and 2400K
covers all the
Andrew Piskorski wrote:
On Tue, Feb 11, 2003 at 02:40:11AM -0800, Jeff Hobbs wrote:
I added that warning in myself after getting enough reports. I narrowed
the size to 2400K to match the default Tcl eval stack recursion limit of
1000. I think 4M is more than you need, 1M will likely do it,
Rob Mayoff wrote:
+-- On Feb 11, Jerry Asher said:
Sigh, that must've been some sort of computing golden age Oh for
the renaissance!
Yep, the golden age - before multithreaded programming.
I don't believe that's true, in large part because at the time I was
doing multithreading
I'll do the easy but ugly top posting thing
I understand your model, and as usual you have explained your model very
clearly. But I think there are some assumptions in your model that need
to be addressed.
Your argument is basically that it's hard to allocate multiple stacks in
a single
12 matches
Mail list logo
