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

  • Context: C/C++ 
  • Thread starter Thread starter Facktor
  • Start date Start date
  • Tags Tags
    Fault
Click For Summary

Discussion Overview

The discussion revolves around troubleshooting a segmentation fault encountered during the initialization of a large bidimensional matrix in C++. Participants explore potential causes, including memory allocation issues and the limitations of stack size, while considering different approaches to resolve the problem.

Discussion Character

  • Technical explanation
  • Debate/contested
  • Exploratory

Main Points Raised

  • One participant reports a segmentation fault when initializing a large matrix and expresses confusion about the cause.
  • Another participant suggests that the issue may stem from exceeding stack space limits and recommends dynamic memory allocation instead of stack allocation.
  • A different participant clarifies that the segmentation fault may not occur on the line where the error is reported, but rather due to insufficient memory being available on the stack.
  • One participant proposes a method to troubleshoot by testing smaller matrix sizes and gradually increasing them to identify the breaking point.
  • Another participant warns that even if a smaller matrix works, larger allocations may still lead to access violations or corrupted results later in the program.
  • A participant shares that they attempted a smaller matrix and still encountered issues, indicating that dynamic allocation might be necessary, but they no longer wish to store such a large matrix.
  • One participant emphasizes the importance of understanding stack size limits and suggests using command line tools to check these limits.

Areas of Agreement / Disagreement

Participants generally agree that stack size limitations are likely causing the segmentation fault, and there is a consensus on the need for dynamic allocation for large matrices. However, there are differing opinions on the best approach to troubleshoot and confirm the source of the error.

Contextual Notes

Some participants mention the potential for access violations or corrupted results when using large arrays, indicating that the discussion is limited by assumptions about memory management and compiler behavior.

Facktor
Messages
4
Reaction score
0
I've declared an unsigned long long bidimentional matrix:
Code:
//(...)
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
Code:
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!
 
Last edited:
Technology news on Phys.org
Hi Facktor, welcome to PF :smile:

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:

Code:
//(...)
typedef unsigned long long int64;
typedef int64 Row200[200];
//(...)
row = pow(2,17);
Row200* Z = new Row200[row];
Z[0][0] = 12345678;
 
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.
 
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.
 
Last edited:
Bill Simpson said:
Listen to what is going on inside my head.

Nice! :smile:

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! :wink:
 
Bill Simpson said:
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.
 
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!:smile:
 
D H said:
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.
 

Similar threads

  • · Replies 5 ·
Replies
5
Views
3K
  • · Replies 8 ·
Replies
8
Views
2K
  • · Replies 8 ·
Replies
8
Views
3K
  • · Replies 2 ·
Replies
2
Views
2K
  • · Replies 6 ·
Replies
6
Views
4K
  • · Replies 6 ·
Replies
6
Views
5K
  • · Replies 6 ·
Replies
6
Views
2K
  • · Replies 9 ·
Replies
9
Views
4K
  • · Replies 15 ·
Replies
15
Views
23K
  • · Replies 2 ·
Replies
2
Views
3K