Why does C++ program run differently on VxWorks?

Allen wrote:

This would imply that each instance of the class has a szMTreeBuff
member (part of relationship). This is valid c++.


Big difference - this would imply that the szMTreeBuff member is shared
between all instances of the class of which the member is a part. Also
valid c++.


Local? (as in not a member anymore...)


There are many reasons for this. Do you use the same platform? You
certainly use a different compiler (I'm assuming). I've found that
Windows are more leniant than VxWorks wrt. enforcing hardware traps
when one makes serious mistakes. I must mention that changing where the
buffer is stored in memory has nothing to do with your problem (I
think). This only highlights (in all probability) another problem, as
the memory layout of the program may differ drastically considering the
changes that you've made. I suggest you to induce the problem by
allocating the applicable buffer in a way that induces the problem (as
I understand you, make it part of a class instance - non-static
member): BTW. you may consider getting rid of the horrible sz prefix...
What does is stand for, size? ;-)

class x_c
{
private:
char buff_[1000]; //part of :-)
}

If this now induces the problem, good - leave it that way as it is not
the problem itself. Note that if buff is used as a string, it may
become a problem (as it is not NULL terminated). Also note that when
you copy into buff, to not over-index. You may also use a vector - but
before you do that - stick to one thing - induce the problem and try to
find it - good luck. You seem in over your head.

Werner

I think it depends on:
1) Where is the instance of the class created? stack or free storage?
2) If the instance is created on stack, is there enough stack size for
a process on target OS platform?
3) Is there enough memory for *static char szMTreeBuf[4096]* ? Because
this declaration leads to allocate memory on text section of a process,
after you add some function codes, these codes take some memery, in
result there maybe not enough memory to allocate 4096 chars.

Allen wrote:

Forest wrote:

Good point.


Especially in vxWks...


Now that you mention - the program stops working when he allocates in
as part of an instance (and works if he creates it as part of class -
static). If he creates enough instances, he may run out of either stack
or heap, depending on where he creates the class or sequence of classes
(16M memory does seem skimpy compared to Windowzzz).

W

"Allen" <chenal@naritech.cnwrote in message
news:1152680944.969884.243670@b28g2000cwb.googlegr oups.com...

You say it cannot run normally. What type of error do you get? Stack
overflow? Memory allocation?

One thing you might try is forcing it to use dynamic memory.

char* szMTreeBuf;

and in the constructor or initializaer
szMTreeBuf = new char[4096];

I suspect that will probably work.

It may also work the way you have it if you increase the stack size, you'll
have to look for settings for that in your compiler(s).

Forest wrote:

There is an only single global instance of the class.


Yes, I also think so. But Why cannot work on Windows XP? I will try to
change the
stack size in VC++ compiler.


How to adjust text section size? If I change the declaration to be
static int buffer[1024].
Will this declaration allocate memory on data section?

Jim Langston wrote:

Our HW has not MMU, therefore we do not allow dynamic memory
allocation.