C/C++ How to troubleshoot segmentation fault in C++ matrix initialization?

[Facktor]

I've declared an unsigned long long bidimentional matrix:

//(...)
typedef unsigned long long int64;
//(...)
row = pow(2,17);
col = 200;
int64 Z[row][col];
Z[0][0] = 12345678;

When the program is initializing Z[0][0], I got a "segmentation fault" message. The Insight Debugger suggests the segmentation fault is on the line

Z[0][0] = 12345678;

I have no idea how to solve this, since I don't even know what the problem is. I mean, I thought "segmentation fault" was supposed to indicate a memory issue. And I can't see any problems here.

I'm using Linux (Ubuntu) - g++ compiler - and the "Insight" debugger.

What can I do to fix this?

Thank you, guys!

 

[I like Serena]

Hi Facktor, welcome to PF

I expect that your problem is your amount of stack space.
Depending on your compiler it's not always possible to simply declare arrays that are this large.
In that case it needs to be dynamically allocated.

Try:

//(...)
typedef unsigned long long int64;
typedef int64 Row200[200];
//(...)
row = pow(2,17);
Row200* Z = new Row200[row];
Z[0][0] = 12345678;

 

[D H]

The error is not the line before the line where you got the segfault. Your computer / language implementation doesn't have 800 megabytes of memory on the stack. The error manifested as a fault on the first line where you tried to use that non-existent memory.

Edit:
I like Serena beat me to it.

 

[Bill Simpson]

Listen to what is going on inside my head.
Humm... Is it the size of the array? Is it a syntax issue with typedef? Is it using pow?
Can I quickly refute or confirm that? Yes
Eliminate some of those possible sources of error by changing to
unsigned long long z[200][200];
z[0][0]=2;
The problem went away!
Now put back say pow{2^7) and check again. Then the typedef and check again.
If it is then gently increase the row size and see if it breaks.
If it does then see about how big the size of the array is that breaks this.
Then go looking for limitations on how big an array your cpu/os/compiler can handle.

Note: This was trying to describe how you might think about the next problem, not just giving you the answer to the last problem.

 

[I like Serena]

Listen to what is going on inside my head.

Nice!

Be careful though, you may find that even though Z[0][0] = 2 succeeds, you'll still get an access violation if you try to assign all the elements.
Or perhaps everything will seem to work, but then, after a number of calculations, your results become corrupted and you can't find why that is!

 

[D H]

Listen to what is going on inside my head.
Humm... Is it the size of the array? Is it a syntax issue with typedef? Is it using pow?
Can I quickly refute or confirm that? Yes
Eliminate some of those possible sources of error by changing to
unsigned long long z[200][200];
z[0][0]=2;
The problem went away!
Now put back say pow{2^7) and check again. Then the typedef and check again.
If it is then gently increase the row size and see if it breaks.
If it does then see about how big the size of the array is that breaks this.
Then go looking for limitations on how big an array your cpu/os/compiler can handle.

Note: This was trying to describe how you might think about the next problem, not just giving you the answer to the last problem.

Too much work!

Just type "limit stacksize" on the command line, and voila! There's the default limit on the size of a program's stack. Unless you have an insane sys admin you will see a rather small number (e.g., I see 8192 kbytes on my computer). Type "limit -h stacksize" and you will see the hard limit on the stack size. This is typically bigger than the default, but is hardly ever unlimited. Or 800 meg.

 

[Facktor]

Thank you, guys!

I've tried to do that:

unsigned long long Z[2][2];
Z[0][0] = 12345678;

And the problem remains! The solution would be dynamic allocation. But nevermind, I don't want to store 2^17*200 elements anymore!

Typing "limitstacksize" on the command line was a great tip!

Thanks, all of you!

 

[Bill Simpson]

Too much work!

A fine example of "if you already know the answer then just type the magic line." That is so much easier than learning how to think so he can debug his next problem when he doesn't already know the answer.