Is this a memory problem?

[syang8]

hi, folks,

I use Kdevelop to build some scientific simulation on Linux. If I set
the size of an array N = 8000, the program works fine. However, if I
set the array N some number greater than 10000 (actually, what I need
is 80000), the program has segmentation error. The intersting thing is
that the positions reporting segmentation error are different if I set
N to be different values.

What problem is this usually? I guess must be some memory error. I use
Valgrind to check the memory, at the line with segmentation error, it
reports "Access not within mapped region at address 0xxxxxxxx".

Anyone know the solution? How cound I handle this problem? Thanks.

-Steve

[syang8]

Thank you guys. Problem solved :-).

Robbie Hatley wrote:

"syang8" <sy****@gmail.c omwrote:

hi, Alf, sandy and Robbie,

The suggestions that you gave to me is really helpful. Now I have a
better understanding of local variables and stacks. However, I still
have a problem. I don't know exactly what the size of the array should
be. Therefore, "N" is designed as a parameter in the function call as

fuction(int N, ...)
{
int big_array[N];
}

I cannot change the array to be static. Maybe a good way is to
allocated the array dynamically, any other suggestions?

Yes. I have 3 suggestions for you, in descending order of
advisibility:

Suggestion #1 (the "C++" way):

Use "std::vecto r".

If you want the vector to still exist between calls to the function
in which it is declared, then you'll have to declare it "static":

#include <vector>
class MyClass {/* stuff */};
MyClass& MyFunction(int ContainerSize)
{
static std::vector<MyC lassMyContainer (ContainerSize) ;
// ... a bunch of code ...
return MyContainer;
} // MyContainer still exists at this point.

But if MyContainer doesn't need to exist between calls to
your function, then you can leave off the "static":

#include <vector>
class MyClass {/* stuff */};
int MyFunction(int ContainerSize)
{
std::vector<MyC lassMyContainer (ContainerSize) ;
// ... a bunch of code ...
return 0;
} // MyContainer dies here.

Suggestion #2 (a more-dangerous "C++" way):

Use "new[]" and "delete[]".

This is dangerous. Memory leaks can result if you "new[]" some
memory and forget to "delete[]" it, and program crashes can
result if you "delete[]" some memory which you didn't "new[]".

But on the other hand, it is a very flexible way of handling
memory.

// Make a dynamic array of MyClass objects:
MyClass* Ptr = new MyClass[ContainerSize];

// Assign stuff to the memory you now own:
Ptr[3756] = Whatever;

// Free-up the memory, later:
delete[] Ptr;

Suggestion #3 (the "C" way):

Dynamically allocate a block of raw memory using malloc().
When you're done with it, free it using free().

Warning: this is VERY dangerous. If you do it wrong, you'll
cause bugs, memory leaks, system crashes, etc.

But it's conceptually the simplest, lowest-level way of handling
memory, so it's alluring because of that:

// Get memory block to hold N copies of MyClass:
MyClass* Ptr = (MyClass*)mallo c(ContainerSize * sizeof(MyClass) );

// Assign stuff to the memory you now own:
Ptr[3756] = Whatever;

// Free-up the memory, later:
free(Ptr);

--
Cheers,
Robbie Hatley
Tustin, CA, USA
lonewolfintj at pacbell dot net
(put "[usenet]" in subject to bypass spam filter)
http://home.pacbell.net/earnur/

[Joe Van Dyk]

Robbie Hatley wrote:

"syang8" wrote:

>>I use Kdevelop to build some scientific simulation on Linux.

What's "Kdevelop", and what does it have to do with C++? If
this is some sort of software-writing software, be aware that
such programs are very mechanistic and may do stupid things
that a human programmer wouldn't do.

>>If I set the size of an array N = 8000, the program works fine.

If it has a large stack, yes. Arrays of what, by the way?
What is sizeof(ArrayEle ment)? If you have a 100-byte struct,
and you make a local array of 8000 of that, you're piling
800,000 bytes of data onto the stack.

>>However, if I set the array N some number greater than
10000 (actually, what I need is 80000)

EWWWWW. Don't do that.

>>the program has segmentation error.

Of course.

>>The intersting thing is that the positions reporting segmentation
error are different if I set N to be different values.

Of course.

>>What problem is this usually?

You're almost certainly overflowing your stack with a huge local
array, like so:

int DorkyFunction(d ouble trouble)
{
BigStruct big_mess[80000]; // dump eight million bytes onto stack
...
}

Instead, declare your array "static" to get it off the stack:

int SmartFunction(d ouble trouble)
{
static BigStruct big_mess[80000];
...
}

What's too much data to put on the stack? Is there a rule of thumb for
when to use the stack and when not to?

Joe

[Default User]

syang8 wrote:

Thank you guys. Problem solved :-).

Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes. See the newsgroup FAQ:

<http://www.parashift.c om/c++-faq-lite/how-to-post.html#faq-5.4>


Brian

[Robbie Hatley]

"Joe Van Dyk" <jo********@boe ing.comwrote:

What's too much data to put on the stack? Is there a rule of
thumb for when to use the stack and when not to?

When your program crashes, you put too much stuff on the stack.
:-) I know that sounds like a very crude answer, but it's the
best. Experiment and see what it takes to crash YOUR system.
This kind of thing is dependent on the CPU, the motherboard,
the amount of RAM, the OS, the compiler, etc.

If you had some way to determine that "programs compiled by
my compiler on my system can safely store exactly X bytes of
local data on the stack", that would give you a more exact
answer; but I don't know how to determine that.

The (ultra-rough) rule of thumb I use is, if I need to store
more than about 10KB of data, then I make sure it's not on
the stack. But this number may be way too small or way to
large for your system.

Here's an extreme example: My company sells circuit boards
with embedded controlllers using a Motorola CPU with 512
bytes of RAM. So, how much data can we safely store on
the stack? About 150 bytes. No, not 150MB. No, not 150KB.
150 bytes.

On the opposite extreme, utility programs I write at home
for the Windows 32 command prompt can probably put about
a half-billion bytes of stuff on the stack, because I've
got a gigabyte of RAM in my machine.
--
Cheers,
Robbie Hatley
Tustin, CA, USA
lonewolfintj at pacbell dot net
(put "[usenet]" in subject to bypass spam filter)
http://home.pacbell.net/earnur/

[Diego Martins]

Robbie Hatley wrote:

Instead, declare your array "static" to get it off the stack:

int SmartFunction(d ouble trouble)
{
static BigStruct big_mess[80000];
...
}

and never get the array deallocated :(

[Robbie Hatley]

"Diego Martins" <jo********@gma il.comwrote:

Robbie Hatley wrote:

Instead, declare your array "static" to get it off the stack:

int SmartFunction(d ouble trouble)
{
static BigStruct big_mess[80000];
...
}

and never get the array deallocated :(

Why do you say that? The array you quote will by deallocated
at the point marked "HERE" in the program:

int SmartFunction(d ouble trouble)
{
static BigStruct big_mess[80000];
...
}

int main(void)
{
...
SmartFunction(3 7.04);
...
return 0; // big_mess is deallocated HERE!!!
}

Exception: embedded systems. In that case, big_mess is deallocated
when you turn the power off or unplug the battery. :-)

Either way, it DOES get deallocated.

If you want it deallocated when SmartFunction exits,
make it a local std::vector:

int SmartFunction(d ouble trouble)
{
std::vector<Big Structbig_mess (80000);
...
}

(But in that case, don't expect old contents of big_mess to still be
there on re-entry to SmartFunction.)
--
Cheers,
Robbie Hatley
Tustin, CA, USA
lonewolfintj at pacbell dot net
(put "[usenet]" in subject to bypass spam filter)
http://home.pacbell.net/earnur/