0

I'm trying to build somebody else's C program on my Mac, using command line tools to build a command line program. Straightforward C program, should be as simple as anything. But I'm getting really strange memory access errors during declaration and initialization of variables in main(), so early that I really don't see how I could have messed anything up. This is basic core C language material, how it could be failing really beats me.

Ken$ gcc -std=c99 -ggdb srtm2stl.c geometry.c stlwriter.c -o srtm2stl
Ken$ gdb ./srtm2stl
. . .
(gdb) run
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00007fff5b74f6c0
0x0000000100000e37 in main (argc=10, argv=0x7fff5fbff990) at srtm2stl.c:195
195    char SolidName[132] = {' '};            // Optional name for solid (text format STL files)

(gdb) list 195
190 int main(int argc, char *argv[])
191 {
192    FILE *in = NULL;                        // input file
193    FILE *out = NULL;                       // output file
194 
195    char SolidName[132] = {' '};            // Optional name for solid (text format STL files)
196 //   char SolidName[132];            // Optional name for solid (text format STL files)
197    int Verbose = 0;                        // Flag: Verbose

The only thing that comes to mind is that it's building in 64-bit mode, and I've never built a 64 bit program before. Are there other command line arguments that need to be given to gcc to make this work properly? Or other theories?

Note line 196. If I comment out line 195 and use 196 instead, we get a little farther before a similar crash:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00007fff5b74f8e0
main (argc=1, argv=0x7fff5fbffa20) at srtm2stl.c:216
216    unsigned int i = 0;

(gdb) list 216
214    long Bias = 0; 
215    short grid[MAXROWS][MAXCOLS];    // Array to hold the elevations 
216    unsigned int i = 0;
217    short stemp;

Seems like there's something about arrays. MAXROWS and MAXCOLS are each 6001 in this build, that shouldn't be overwhelming with modern memory sizes. Right?

OSX 10.7.5, gcc version i686-apple-darwin10-llvm-gcc-4.2, GNU gdb 6.3.50-20050815

Joymaker
  • 1
  • 1
  • 6001 * 6001 * sizeof(short) = **68.7 MB** of continuous automatic memory (read: stack), assuming a 16bit short. I'm not the least bit surprised that thing can't run. And yes, its overwhelming. Automatic storage != Free Store Space. A dynamic allocation would be considerably more likely to work. Or move `grid` to be global; your call. – WhozCraig Jul 03 '15 at 05:05
  • You are almost certain to be overflowing the stack. 6000*6000*2 = ~70MB. I know nothing about the MAC environment but I'm guessing that's going too be too large to fit on the stack. – kaylum Jul 03 '15 at 05:09
  • Try to add the memory in heap dynamically and it will work.. This is a stack memory overflow problem.. I don't know how that someone whose code you are compiling have compiled his code.... This will give problem in any machine.. 8MB is the maximum stack limit.. Not more than that.. – Mayukh Sarkar Jul 03 '15 at 05:22
  • [Read this question and its answer](https://stackoverflow.com/questions/1847789/segmentation-fault-on-large-array-sizes?rq=1) – WhozCraig Jul 03 '15 at 06:03
  • Yes, WhozCraig, that was it. The program as I inherited it was using 1201*1201*sizeof(short), that was big but fit, I pushed it too far. Moving the array to global storage fixed everything. I'm just frustrated that I had to learn this at run time, it seems that a compile time warning would been highly appropriate. – Joymaker Jul 08 '15 at 00:24

2 Answers2

0
extern short grid; // global outside the main
grid  = malloc(sizeof(short) *6000*6000) // inside the main..

It seems you are using multiple files.. If you are using any header, then you can also extern the grid and use it in other places.. Detailed info can only be given once we can see the implementation.. Moreover if you are using OSX I will suggest you to use lldb instead of gdb.. Because gdb on Mac may have a code signing problem

Mayukh Sarkar
  • 2,289
  • 1
  • 14
  • 38
0

WhozCraig got it. (See his comment.) I was trying to allocate more on the stack than the stack could handle. Moving the array to global storage fixed everything.

Joymaker
  • 1
  • 1