an error while debug a program

Mario Charest postmaster@127.0.0.1 wrote:

Yes and no. The same thing about using all system memory can be said about
malloc and familly. There is no limit to how much a program can some memory
with malloc ( unless there is? ). That being said I’d rather deal with
malloc failling then running out of ram because the stack .

Yes, you can. But malloc() and family is more explicit.
Stack is just “automatic”.

-David

QNX Training Services
http://www.qnx.com/services/training/
Please followup in this newsgroup if you have further questions.

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:ctdjb9$anq$1@nntp.qnx.com

peter <> pweber@qnx.de> > wrote:
David, you talk about reserved space or alloced space ?

Reserved address space – this is then actually allocated as physical
RAM on first use. Since you mention the guard page, I assumed you must
have been talking about reserved space – the guard page never has RAM
allocated for it.

For all threads, including the main thread, RAM for stack is actually
allocated in 4K chunks on demand.

Is the RAM reserved when program starts up , if not then does that mean you
could actually run out of memory when stack allocating occurs?

-David

“David Gibbs” <> dagibbs@qnx.com> > schrieb im Newsbeitrag
news:ctb8as$2j5$> 1@nntp.qnx.com> …
peter <> pweber@qnx.de> > wrote:
ups, yes I thought it was a new thread and this would be 4k default
+4k
guard page.

New thread is 128K default, +4K guard page.

-David

QNX Training Services
http://www.qnx.com/services/training/
Please followup in this newsgroup if you have further questions.


\

QNX Training Services
http://www.qnx.com/services/training/
Please followup in this newsgroup if you have further questions.

Mario Charest postmaster@127.0.0.1 wrote:

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:ctdjb9$anq$> 1@nntp.qnx.com> …
peter <> pweber@qnx.de> > wrote:
David, you talk about reserved space or alloced space ?

Reserved address space – this is then actually allocated as physical
RAM on first use. Since you mention the guard page, I assumed you must
have been talking about reserved space – the guard page never has RAM
allocated for it.

For all threads, including the main thread, RAM for stack is actually
allocated in 4K chunks on demand.

Is the RAM reserved when program starts up , if not then does that mean you
could actually run out of memory when stack allocating occurs?

The RAM is not reserved, so you could run out of memory when the
allocation occurs. You could, also, run into unexpected latency on
a function call if that particular time you called the function you
happened to be deeper into the stack than you had on previous instances,
and needed to allocate (through a page fault, kernel traps it, allocates
a page, then lets you continue) the page of RAM.

If that is a concern, you could manually pre-touch the stack pages that
you expected to need. Kind of a hack, though.

-David

QNX Training Services
http://www.qnx.com/services/training/
Please followup in this newsgroup if you have further questions.

The RAM is not reserved, so you could run out of memory when the
allocation occurs. You could, also, run into unexpected latency on
a function call if that particular time you called the function you
happened to be deeper into the stack than you had on previous instances,
and needed to allocate (through a page fault, kernel traps it, allocates
a page, then lets you continue) the page of RAM.

So having a hard limit is to some degree useless, plus the latency thing is
bad IMHO ( i was worried about that). I think there should be a “standard”
way pre-of allocating the stack for the main thread. For other thread it
can be done since the stack memory can be allocated via malloc, nor sure if
that is supported for thread pool though.

If that is a concern, you could manually pre-touch the stack pages that
you expected to need. Kind of a hack, though.

-David

QNX Training Services
http://www.qnx.com/services/training/
Please followup in this newsgroup if you have further questions.

For data hiding purposes, I believe the following would also work:

#include <stdio.h>
int main(void)
{
static int var[4096000];
var[1] = 5;
printf(“var[1] is %d\n”, var[1] );
}


“David Gibbs” <dagibbs@qnx.com> wrote in message
news:ct96ne$2ie$1@nntp.qnx.com

Emily Jiang <> jmtree@ipp.ac.cn> > wrote:
Thanks. But the allowed array size is much smaller than 8M bytes. It is
about 4M bytes.

Arrays of any size are allowed. e.g. the following code runs fine:

#include <stdio.h
int var[4096000];
int main(void)
{
var[1] = 5;
printf(“var[1] is %d\n”, var[1] );
}

It happily runs and prints out:

var[1] is 5

The following will likely crash, due to overflowing the stack:

#include <stdio.h
int main(void)
{
int var[4096000];
var[1] = 5;
printf(“var[1] is %d\n”, var[1] );
}

Note the difference in where var is declared.

The default stack is 512K for the main thread (can be overridden
by command-line argument), the default stack for other threads in 128K.

Declaring huge stack variables is rarely a good choice.

(Note: on an ARM target, there may not be enough heap space for
such a large array, either.)

-David

QNX Training Services
http://www.qnx.com/services/training/
Please followup in this newsgroup if you have further questions.

Mario Charest postmaster@127.0.0.1 wrote:


The RAM is not reserved, so you could run out of memory when the
allocation occurs. You could, also, run into unexpected latency on
a function call if that particular time you called the function you
happened to be deeper into the stack than you had on previous instances,
and needed to allocate (through a page fault, kernel traps it, allocates
a page, then lets you continue) the page of RAM.

So having a hard limit is to some degree useless, plus the latency thing is
bad IMHO ( i was worried about that). I think there should be a “standard”
way pre-of allocating the stack for the main thread. For other thread it
can be done since the stack memory can be allocated via malloc, nor sure if
that is supported for thread pool though.

As I just learned, pthread_attr_setstacklazy( &attr, PTHREAD_STACK_NOLAZY )
will force the pre-allocation of the entire thread’s stack at thread
creation time.

For a thread pool, one of the entries in the thread_pool_attr_t is a
pthread_attr_t, which you could have filled in with the appropriate
flags to pre-allocate the stack to the appropriate size.

Now, the only tricky issue is the main thread – but you can always
have the main thread pthread_exit() and not worry about it any further.

For the main thread:

ldrel -S stacksize -f executable executable

Will give a stack create at process creation time of the specified size
(should probably be a multiple of 4K).

If that is a concern, you could manually pre-touch the stack pages that
you expected to need. Kind of a hack, though.

All of which are much cleaner than the pre-touching of stack pages
hack.

-David

QNX Training Services
http://www.qnx.com/services/training/
Please followup in this newsgroup if you have further questions.

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:cte534$qb4$1@nntp.qnx.com

Mario Charest postmaster@127.0.0.1 wrote:



The RAM is not reserved, so you could run out of memory when the
allocation occurs. You could, also, run into unexpected latency on
a function call if that particular time you called the function you
happened to be deeper into the stack than you had on previous instances,
and needed to allocate (through a page fault, kernel traps it, allocates
a page, then lets you continue) the page of RAM.

So having a hard limit is to some degree useless, plus the latency thing
is
bad IMHO ( i was worried about that). I think there should be a
“standard”
way pre-of allocating the stack for the main thread. For other thread it
can be done since the stack memory can be allocated via malloc, nor sure
if
that is supported for thread pool though.

As I just learned, pthread_attr_setstacklazy( &attr,
PTHREAD_STACK_NOLAZY )
will force the pre-allocation of the entire thread’s stack at thread
creation time.

For a thread pool, one of the entries in the thread_pool_attr_t is a
pthread_attr_t, which you could have filled in with the appropriate
flags to pre-allocate the stack to the appropriate size.

Now, the only tricky issue is the main thread – but you can always
have the main thread pthread_exit() and not worry about it any further.

For the main thread:

ldrel -S stacksize -f executable executable

Would be nice to have a nice and simple qcc option for that.

This topic is interesting. The project I’m working (QNX4) on specifies that
dynamic memory allocation can only be done at init time and not at run time.
The idea, i beleive, is to make sure system doesn’t fail at run time because
of lack of memory. This topic made me realize that this requirement is not
completely effective given that stack growth can results in system going out
of ram and/or application crash.

I beleive this issue deserve a mention in the documentation (latency and
all)

Will give a stack create at process creation time of the specified size
(should probably be a multiple of 4K).

If that is a concern, you could manually pre-touch the stack pages that
you expected to need. Kind of a hack, though.

All of which are much cleaner than the pre-touching of stack pages
hack.

-David

QNX Training Services
http://www.qnx.com/services/training/
Please followup in this newsgroup if you have further questions.

Mario Charest postmaster@127.0.0.1 wrote:

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
ldrel -S stacksize -f executable executable

Would be nice to have a nice and simple qcc option for that.

Yeah, I don’t even think you can get a qcc pass through for it.
(That is, I don’t think there is a -Wx,-S1024K, for some value of
x to get to ldrel – there is -Wl,-xxxx to get to the linker, but
that will probably drop the option to ld, not ldrel.)

This topic is interesting. The project I’m working (QNX4) on specifies that
dynamic memory allocation can only be done at init time and not at run time.

Interestingly, I think you’re better in QNX4 for that, than QNX6. A lot
of QNX6 managers use the resmgr framework that allocates OCBs when opens
come in. Whereas, I think Fsys pre-allocates its ocb table under QNX4.
Still, that might be tricky to guarantee with QNX os components.

The idea, i beleive, is to make sure system doesn’t fail at run time because
of lack of memory. This topic made me realize that this requirement is not
completely effective given that stack growth can results in system going out
of ram and/or application crash.

Hm… I don’t remember whether QNX4’s stack were lazy allocated or not.

I beleive this issue deserve a mention in the documentation (latency and
all)

Probably in the programmer’s guide somewhere. Not sure where, though.

-David

QNX Training Services
http://www.qnx.com/services/training/
Please followup in this newsgroup if you have further questions.

On Thu, 27 Jan 2005 18:05:44 -0500, Mario Charest wrote:

Yes and no. The same thing about using all system memory can be said about
malloc and familly. There is no limit to how much a program can some memory
with malloc ( unless there is? ). That being said I’d rather deal with
malloc failling then running out of ram because the stack .

Using setrlimit64() you can limit the per-process total memory usage
(RLIMIT_AS), the heap usage (RLIMIT_DATA), the stack usage (RLIMIT_STACK)
or the mapped address space usage (RLIMIT_VMEM). We have taken to using
RLMIT_AS to catch run-away processes before they consume all available
memory. It works well.

Rob Rutherford
Ruzz Technology