Why does C++ program run differently on VxWorks?

[Allen]

I wrote many classes. In a class, there is a member variable which is
declared as char szMTreeBuf[4096]. On both Windows XP and VxWorks, it
cannot work. Then I try to declare the member variable as static char
szMTreeBuf[4096], it can work again. But when add some other function
codes, it cannot run normally. I modify the class delearation, and
change szMTreeBuf member variable to be local variable. Again it can
run now.

Why does C++ program run differently on VxWorks?

OS: VxWorks 5.5.1
Memory: 16M

 

[werasm]

I wrote many classes. In a class, there is a member variable which is
declared as char szMTreeBuf[4096].

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

On both Windows XP and VxWorks, it
cannot work. Then I try to declare the member variable as static char
szMTreeBuf[4096], it can work again.

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

But when add some other function
codes, it cannot run normally. I modify the class delearation, and
change szMTreeBuf member variable to be local variable.

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

Again it can run now.

Why does C++ program run differently on VxWorks?

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

 

[Forest]

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.

 

[werasm]

I think it depends on:
1) Where is the instance of the class created? stack or free storage?

Good point.

2) If the instance is created on stack, is there enough stack size for
a process on target OS platform?

Especially in vxWks...

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.

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

 

[Jim Langston]

I wrote many classes. In a class, there is a member variable which is
declared as char szMTreeBuf[4096]. On both Windows XP and VxWorks, it
cannot work. Then I try to declare the member variable as static char
szMTreeBuf[4096], it can work again. But when add some other function
codes, it cannot run normally. I modify the class delearation, and
change szMTreeBuf member variable to be local variable. Again it can
run now.

Why does C++ program run differently on VxWorks?

OS: VxWorks 5.5.1
Memory: 16M

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

 

[Allen]

I think it depends on:
1) Where is the instance of the class created? stack or free storage?

There is an only single global instance of the class.

2) If the instance is created on stack, is there enough stack size for
a process on target OS platform?

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

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.

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?

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.

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