an error while debug a program

QNX Newsgroups (Archives) comp.os.qnx
1

Dear all,

I have a strange problem. I write a program with a class CSendData which
I write myself. I can compile it and run it. The program works very well.
But while I debug the program, several error accure.

the first error is :
/home/jm/workspace/Senddataclient/x86/o-g/Senddataclient_g at
127.0.0.1:8000:internal:static symbol ‘CSendData’ found in
/home/jm/workspace/Senddataclient/senddata.cpp psymtab but not in symtab.
CSendData may be an inlined function, or may be a template function
(if a template, try specifying an instantiation:CSendData)

The second error is :
/home/jm/workspace/Senddataclient/x86/o-g/Senddataclient_g at
127.0.0.1:8000:gdb-internal-error: ui_out:list depth exceeded; only 4 level
of lists can be nested.

What can I do ? Can I edit the the ui_out to change the list depth?

Another question: If I define a arry short data[4096000] , while I run
the program, it tells me: Memory fault(core dumped). It seems that QNX does
not permit to define such a large array. What can I do.
please help!

Emily

2

The second question is resolved now. It seems that qnx limits the array
size. So I cannot define the array as “short data[4096000]”, but I
dynamically allocate the memory “short *data=new short[4096000]”.

But the first problem is still unresolved.
I don’t know why.

“Emily Jiang” <jmtree@ipp.ac.cn> дÈëÏûÏ¢ÐÂÎÅ:ct70n4$504$1@inn.qnx.com…

Dear all,

I have a strange problem. I write a program with a class CSendData
which I write myself. I can compile it and run it. The program works very
well. But while I debug the program, several error accure.

the first error is :
/home/jm/workspace/Senddataclient/x86/o-g/Senddataclient_g at
127.0.0.1:8000:internal:static symbol ‘CSendData’ found in
/home/jm/workspace/Senddataclient/senddata.cpp psymtab but not in symtab.
CSendData may be an inlined function, or may be a template function
(if a template, try specifying an instantiation:CSendData)

The second error is :
/home/jm/workspace/Senddataclient/x86/o-g/Senddataclient_g at
127.0.0.1:8000:gdb-internal-error: ui_out:list depth exceeded; only 4
level of lists can be nested.

What can I do ? Can I edit the the ui_out to change the list depth?

Another question: If I define a arry short data[4096000] , while I run
the program, it tells me: Memory fault(core dumped). It seems that QNX
does not permit to define such a large array. What can I do.
please help!

Emily

3

Emily Jiang wrote:

The second question is resolved now. It seems that qnx limits the array
size. So I cannot define the array as “short data[4096000]”, but I
dynamically allocate the memory “short *data=new short[4096000]”.

Are you declaring the array on the stack? If so, that is correct, you
can’t declare ~8M worth of data on the stack. So you can either shove
it into a global variable or dynamically allocate and free it.

chris

4

Thanks. But the allowed array size is much smaller than 8M bytes. It is
about 4M bytes.

Emily

5

Uhm… A short is not a byte. You might want to recheck your calculations.
In any case, even 4 MB is not suitable for stack variables. Put it on the
heap.

Marty Doane
Siemens L&A

“Emily Jiang” <jmtree@ipp.ac.cn> wrote in message
news:ct7piq$mij$1@inn.qnx.com…

Thanks. But the allowed array size is much smaller than 8M bytes. It is
about 4M bytes.

Emily

6

“Emily Jiang” <jmtree@ipp.ac.cn> wrote in message
news:ct7piq$mij$1@inn.qnx.com…

Thanks. But the allowed array size is much smaller than 8M bytes. It is
about 4M bytes.

Chris was trying to tell you your stack isn’t big enough, I don’t recall
what the size by default but I doubt its 4M

Emily

7

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.

8

I see! Thanks.
I have never had such kind of problems in Windows and Linux. So it confused
me. Can you tell me what is the difference of the default stack size between
linux and qnx ?
Under linux declare short data[4096000] in main() is allowed.


“Emily Jiang” <jmtree@ipp.ac.cn> дÈëÏûÏ¢ÐÂÎÅ:ct7piq$mij$1@inn.qnx.com…

Thanks. But the allowed array size is much smaller than 8M bytes. It is
about 4M bytes.

Emily

9

A short is 2 bytes. While I declare short data[2048000], the program is ok.
But short data[3000000] is not allow. So I guess maybe the allow stack size
is about 4M bytes.
Actually I do not care what the size of the stack. I just want to know why
and how. Now I have known how to resolve the problem. Thanks for your help.

Emily

“Marty Doane” <martin.doane@siemens.com> дÈëÏûÏ¢ÐÂÎÅ:ct8kfa$cth$1@inn.qnx.com…

Uhm… A short is not a byte. You might want to recheck your calculations.
In any case, even 4 MB is not suitable for stack variables. Put it on the
heap.

Marty Doane
Siemens L&A

“Emily Jiang” <> jmtree@ipp.ac.cn> > wrote in message
news:ct7piq$mij$> 1@inn.qnx.com> …
Thanks. But the allowed array size is much smaller than 8M bytes. It is
about 4M bytes.

Emily
\

10

default stack size on NTO is 4k.

“Emily Jiang” <jmtree@ipp.ac.cn> schrieb im Newsbeitrag
news:ct9f5k$2ie$1@inn.qnx.com…

I see! Thanks.
I have never had such kind of problems in Windows and Linux. So it
confused
me. Can you tell me what is the difference of the default stack size
between
linux and qnx ?
Under linux declare short data[4096000] in main() is allowed.


“Emily Jiang” <> jmtree@ipp.ac.cn> > дÈëÏûÏ¢ÐÂÎÅ:ct7piq$mij$> 1@inn.qnx.com> …
Thanks. But the allowed array size is much smaller than 8M bytes. It is
about 4M bytes.

Emily
\

11

“Emily Jiang” <jmtree@ipp.ac.cn> wrote in message
news:ct9f5k$2ie$1@inn.qnx.com…

I see! Thanks.
I have never had such kind of problems in Windows and Linux. So it
confused me. Can you tell me what is the difference of the default stack
size between linux and qnx ?
Under linux declare short data[4096000] in main() is allowed.

It’s allowed under QNX as well , you just need to make the stack bigger.

Under Windows and Linux, stack size can grow dynamicaly.

“Emily Jiang” <> jmtree@ipp.ac.cn> > дÈëÏûÏ¢ÐÂÎÅ:ct7piq$mij$> 1@inn.qnx.com> …
Thanks. But the allowed array size is much smaller than 8M bytes. It is
about 4M bytes.

Emily
\

12

peter <pweber@qnx.de> wrote:

default stack size on NTO is 4k.

Um, no.

By default, stacksize, that is address space reserved for the stack for the
first (main) thread is 512K (plus a 4k guard page), which is allocated on
demand. At least 4K will be allocated for any thread, but initial allocation
can be larger.

-David

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

13

Emily Jiang <jmtree@ipp.ac.cn> wrote:

I see! Thanks.
I have never had such kind of problems in Windows and Linux. So it confused
me. Can you tell me what is the difference of the default stack size between
linux and qnx ?

QNX and Linux have some fairly important differences in memory management.

QNX does not do virtual memory, that is, it never pages or swaps
anything to disk – every bit of stack, code, data, or heap associated
with a process (running program) must have actual RAM committed to
it. (For real-time reasons (among others): it is difficult to get
predictable real-time behaviour if one time access to a variable is
just RAM, and the next time you access the variable you have to wait
on disk I/O.)

Because of these differences in philosophy and memory management,
QNX makes different assumptions about what is important in managing
a process’s stack, and lays out a process’s virtual address space
differently.

This can mean that things which are poor practice – e.g. putting huge
objects on the stack – can behave differently.

You can either work-around it by declaring it globally (as my example did)
or by increasing the stack size at compile time:

qcc -N 16384K big_stack_source.c -o big_stack_prog

-David

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

14

ups, yes I thought it was a new thread and this would be 4k default +4k
guard page.

“David Gibbs” <dagibbs@qnx.com> schrieb im Newsbeitrag
news:ctb25e$q1r$1@nntp.qnx.com…

peter <> pweber@qnx.de> > wrote:
default stack size on NTO is 4k.

Um, no.

By default, stacksize, that is address space reserved for the stack for
the
first (main) thread is 512K (plus a 4k guard page), which is allocated on
demand. At least 4K will be allocated for any thread, but initial
allocation
can be larger.

-David

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

15

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.

16

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:ctb2lj$q1r$2@nntp.qnx.com…

Emily Jiang <> jmtree@ipp.ac.cn> > wrote:
I see! Thanks.
I have never had such kind of problems in Windows and Linux. So it
confused
me. Can you tell me what is the difference of the default stack size
between
linux and qnx ?

QNX and Linux have some fairly important differences in memory management.

QNX does not do virtual memory, that is, it never pages or swaps
anything to disk – every bit of stack, code, data, or heap associated
with a process (running program) must have actual RAM committed to
it. (For real-time reasons (among others): it is difficult to get
predictable real-time behaviour if one time access to a variable is
just RAM, and the next time you access the variable you have to wait
on disk I/O.)

Because of these differences in philosophy and memory management,
QNX makes different assumptions about what is important in managing
a process’s stack, and lays out a process’s virtual address space
differently.

This can mean that things which are poor practice – e.g. putting huge
objects on the stack – can behave differently.

You can either work-around it by declaring it globally (as my example did)
or by increasing the stack size at compile time:

qcc -N 16384K big_stack_source.c -o big_stack_prog

David, in my last post I wanted to give a reason why stack cannot grow
dynamicaly and I couldn’t. I couldn’t find comfort in your explanation.

The way I see it swap file/virtual memory doesn’t have anything to do with
it, stack space or heap space ends eating memory just the same. I am still
not convience of the advantage of not letting a program dynamicaly growing
it’s stack size.

It is indeed a very bad practice to allocate lots of space on the stack
because it kind of assume you’ll never run out of ram (which Windows and
Linux programmer seems to always assume). It’s much hardware to handle and
out of memory condition when dealing with stack then with memory.


-David

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

17

Mario Charest postmaster@127.0.0.1 wrote:

David, in my last post I wanted to give a reason why stack cannot grow
dynamicaly and I couldn’t. I couldn’t find comfort in your explanation.

A philosophy of resiliency and process-limited resource growth.

Consider a program that has a bug in a recursive routine that recurses
forever… if stack grew dynamically, this would absorb ALL the free
memory on the system [for most systems] and quite possibly cause lots
of other things to fail when they couldn’t allocate memory. With a
limitted, fixed maximum, stack depth, the error will be limitted in
to that process. (Whereas, in a virtual memory system, the extra
allocated, but not currently in-use stack will be swapped/paged out
and not cause allocation failures elsewhere.)

You can’t have both pure dynamic stack growth, and the ability to detect
and handle (crash on) stack overflow.

Also, what happens when you have a multithreaded process – where do
you put the stacks for each thread. I don’t know how Linux lays out
the address space of the process, but we put the thread stack(s) in
the same address space as the rest of the process, and I expect they
probably have to as well. {I know trad Unix from way back, the address
space would be laid out with essentially code and data at bottom, heap
growing up from top of data, stack at top of address space, growing down
towards heap. In that model, where do you put multiple thread stacks?}
If you don’t have a boundary on the stack for the main thread, how do
you detect when it grows over into the stack for your next thread?
Now, maybe you could special-case the single threaded vs multi-threaded
programs… but even so, I don’t like it.

When working for a limitted-resource system, having hard boundaries,
that can be configured, is generally a better, more robust, way to
go.

Does that help?

(Of course, this is post-hoc justification, I wasn’t involved in the
actual design discussions where these decisions were made.)

-David

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

18

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:ctbk24$cef$1@nntp.qnx.com…

Mario Charest postmaster@127.0.0.1 wrote:

David, in my last post I wanted to give a reason why stack cannot grow
dynamicaly and I couldn’t. I couldn’t find comfort in your explanation.

A philosophy of resiliency and process-limited resource growth.

Consider a program that has a bug in a recursive routine that recurses
forever… if stack grew dynamically, this would absorb ALL the free
memory on the system [for most systems] and quite possibly cause lots
of other things to fail when they couldn’t allocate memory. With a
limitted, fixed maximum, stack depth, the error will be limitted in
to that process. (Whereas, in a virtual memory system, the extra
allocated, but not currently in-use stack will be swapped/paged out
and not cause allocation failures elsewhere.)

You can’t have both pure dynamic stack growth, and the ability to detect
and handle (crash on) stack overflow.

Also, what happens when you have a multithreaded process – where do
you put the stacks for each thread. I don’t know how Linux lays out
the address space of the process, but we put the thread stack(s) in
the same address space as the rest of the process, and I expect they
probably have to as well. {I know trad Unix from way back, the address
space would be laid out with essentially code and data at bottom, heap
growing up from top of data, stack at top of address space, growing down
towards heap. In that model, where do you put multiple thread stacks?}
If you don’t have a boundary on the stack for the main thread, how do
you detect when it grows over into the stack for your next thread?
Now, maybe you could special-case the single threaded vs multi-threaded
programs… but even so, I don’t like it.

When working for a limitted-resource system, having hard boundaries,
that can be configured, is generally a better, more robust, way to
go.

Does that help?

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 .

(Of course, this is post-hoc justification, I wasn’t involved in the
actual design discussions where these decisions were made.)

-David

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

19

David, you talk about reserved space or alloced space ?

“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.

20

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.

-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.