Welcome to the MacNN Forums.

BlackGriffen · Apr 4, 2002, 10:09 AM

<BLOCKQUOTE>code:<HR><pre>
int main (int argc, const char * argv[]) {

int bitmap[800][800][3];

return 0;
}
[/code]

Where is the bug? When I try to compile this and run it, the program seg faults. According to gdb, it segfaults on the line int main. Commenting out int bitmap fixes the program, of course, but the program should be working just fine. I have cc 2.95.2, and I get the crash whether I compile in the command line with cc main.c or in Project Builder (really the same thing, I suppose). Is this a bug in my code or a compiler bug, or maybe even a bug in the memory manager? I have tried restarting my computer, and recompiling, but no joy. Any help will be appreciated.

Thanx

BlackGriffen

IUJHJSDHE · Apr 4, 2002, 10:37 AM

Ok I am not very good at this stuff but...

What does this program ment to DO?!?

 <EDIT>: Stupid quote ****es up the colors, I just took it out.

[ 04-04-2002: Message edited by: IUJHJSDHE ]

BlackGriffen · Apr 4, 2002, 11:23 AM

Originally posted by IUJHJSDHE:
Ok I am not very good at this stuff but...

What does this program ment to DO?!?

 <EDIT>: Stupid quote ****es up the colors, I just took it out.

[ 04-04-2002: Message edited by: IUJHJSDHE ]

There's another entire function that I'm trying to construct that will simply write the contents of the array to a binary file. I eventually intend to construct a .tiff image from a bunch of data points, and the write function will simply be the last step. The problem is that I've been getting these stinking errors, and I've found that even this much code will trigger the bug. This code, specifically, does nothing but allocate the array, and it still triggers the problem. I can even delete the arguments to main() and the bug will still hit. I just presented the smallest amount of code necessary to trigger the seg-fault. So, the short answer, I suppose, is that the program I put up on the forums is just supposed to allocate an array and exit without error.

BlackGriffen

mdcarter1 · Apr 4, 2002, 11:55 AM

Does it still do it if you make the array 2-dimensional? ie

int bitmap[800][800];

BlackGriffen · Apr 4, 2002, 12:26 PM

Yep. It also seg faults if I try to make it one dimensional (i.e. bitmap[1920000], with enough space to hold an 800 by 800 bit map that has one cell per color). Am I simply trying to alloc too much memory to one contiguous block (7500 KB)? I suppose I could break the bitmap up in to pieces, that is, an array of arrays instead of one array.

Thanx

BlackGriffen

kamprath · Apr 4, 2002, 01:22 PM

Originally posted by BlackGriffen:
<BLOCKQUOTE>code:<HR><pre>
int main (int argc, const char * argv[]) {

int bitmap[800][800][3];

return 0;
}
</pre><HR></BLOCKQUOTE>

Where is the bug? When I try to compile this and run it, the program seg faults. According to gdb, it segfaults on the line int main.

There is no bug in your syntax, but making such a large block of memory on the stack is your problem. Large backs of data should always be declared dynamically. In order to allocate the memory in on shot, do this:

int main (int argc, const char * argv[]) {

const int kInnerDimension = 800;
const int kMiddleDimension = 800;
const int kOuterDimension = 3;
int *pBitmap;

pBitmap = new int[ kInnerDimension * kMiddleDimension * kOuterDimension ];

return 0;
}

Of course, you'll have to transpose the "3-dimensional" coordinates into a 1-dimensional vector (not diffcult, but annoying). Your best bet is to write a 3-D array wrapper class to managethe coordinate transformation.

Michael

[ 04-04-2002: Message edited by: kamprath ]

[ 04-04-2002: Message edited by: kamprath ]

davecom · Apr 4, 2002, 02:34 PM

Read up on malloc() and calloc() in a good C book. I don't think you can use new() in C, only C++. I could be mistaken however, since I don't do a lot of plain C.

Amorph · Apr 4, 2002, 06:03 PM

Originally posted by davecom:
Read up on malloc() and calloc() in a good C book. I don't think you can use new() in C, only C++. I could be mistaken however, since I don't do a lot of plain C.

The new operator is exclusive to C++.

The plain C code would be:

<BLOCKQUOTE>code:<HR><pre>int *bitmap = malloc(800 * 800 * 3 * sizeof(int));[/code]

(Note that C doesn't require a cast for this assignment, like C++ does.) You can, of course, use #defined constants, variables, function calls, etc. in place of the hard-coded numbers.

Be sure to check that bitmap != NULL before using it.

If you want the array zero'd, use calloc() instead.

BlackGriffen · Apr 4, 2002, 07:49 PM

So memory that gets alloced at the beginning of a function is put in the stack. What does that mean? Is it a special section of memory? This is something that was never explained to me in my programming class, so any sort of brief explanation would be helpful.

Thanx

BlackGriffen

theolein · Apr 4, 2002, 10:09 PM

Actually I was going to say the same thing about doing malloc. However I'm also not sure when to start using malloc. As far as I know basic memory is allocated from the stack (in processor memory?) and for anything more you need to allocate from the heap which is RAM, or is this a load of crap?

...Perhaps I could just go and do a search on google hey?

mdcarter1 · Apr 4, 2002, 10:17 PM

I will try to give you a basic explanation. You are right about the stack being a special part of memory. A stack is a piece of memory that grows larger as you add things to it. Now everytime a function call is made in your program, the memory needed for that function is "added" to the top of the stack. Some other things like the program counter are added there as well, but you dont need to know about that for now. So in your example, when the main() function call gets made, the memory for your array would be
put on the top of the stack. If then you would have made another function call from within main() say to foo() then the memory required for foo() would be placed on top of the stack. When foo() is done and returns, it's memory is "removed" from the stack and now the main() memory is at the top again.

So you can see how when function calls make other function calls, the stack begins to "grow". So in your program, you asked for a lot of memory to be put on the stack and the OS didn't like that.

I should also mention that one of the reasons for having a stack is that we as programmers dont have to worry about deallocating the stack memory, it gets done for us when the function returns.

Putting memory on the heap is another matter. I have probably done a horrible job of describing the stack, but if you want i will explain the heap as well.

Amorph · Apr 5, 2002, 03:58 PM

Originally posted by BlackGriffen:
So memory that gets alloced at the beginning of a function is put in the stack. What does that mean? Is it a special section of memory?

Local variables are stored on the stack. The above explanations aren't bad. The stack is basically how the runtime keeps track of where it is in your program. Every block (including all functions - and main() is a function) that hasn't returned yet is on the stack, in the order they called each other. The currently executing block is on the top.

Since local variables are created when a block is entered and destroyed when a block is exited, it makes sense to keep them on the stack. However, in all implementations that I'm aware of, there's a limit placed on how big the stack can get, and if it exceeds that limit your program blows up. Allocating an immense local array will tend to chew up the amount of space reserved for the stack rather quickly.

You should generally only declare simple variables and small arrays as local variables, and use malloc() for anything large.

The rest of the (virtual and/or actual) memory available to your program is known as the heap. All dynamic memory is allocated from the heap.

Note that malloc() - and, in fact, any kind of dynamic memory allocation - is never fast. In some circumstances it can be very slow. So you don't want to use it in a tight loop, or in a frequently-called function, if you can help it. Also, you should free() any memory you malloc(). For example, this:

<BLOCKQUOTE>code:<HR><pre>
for (i = 0; i < 100; ++i)
int *arr = malloc(100000 * sizeof(int));
[/code]

will "leak" memory all over the place: It reserves a block of memory sufficient to hold 100,000 ints, assigns its location to arr, and then assigns another block, assigns its location to arr, and so forth. Note that the location of the previously malloc'd memory is forever lost, but the memory is still allocated and it's not available for use. It won't become free until your program terminates (not even then, on some platforms). This:

<BLOCKQUOTE>code:<HR><pre>
for (i = 0; i < 100; ++i) {
int *arr = malloc(100000 * sizeof(int));
free(arr);
}
[/code]

might not do anything useful, but at least it doesn't leak memory.

This:

<BLOCKQUOTE>code:<HR><pre>
int *arr = malloc(100000 * sizeof(int));
for (i = 0; i < 100; ++i) {
/* do stuff with arr */
}
free(arr);
[/code]

Is probably a much more sensible construction, unless you really need 100 distinct arrays of 100,000 ints.

Hmm. I hope this is clear.

int69h · Apr 6, 2002, 02:00 AM

Amorph's description is very good. I recommend reading Smashing the Stack for Fun and Profit by Aleph1. It should be mandatory reading for all coders.

kamprath · Apr 6, 2002, 03:11 AM

Originally posted by davecom:
Read up on malloc() and calloc() in a good C book. I don't think you can use new() in C, only C++. I could be mistaken however, since I don't do a lot of plain C.

Doh! My bad. Yes, operator new() is a C++ only function. It's been a decade since I programed pure C . . . . .

Michael

mattcunnane · Apr 7, 2002, 10:30 PM

Originally posted by Amorph:

However, in all implementations that I'm aware of, there's a limit placed on how big the stack can get, and if it exceeds that limit your program blows up.

Granted the compiler can't know (in general) how big the stack is going to get, but surely it would be a good idea to issue a warning if one tries to allocate a block of memory larger than the limit!?!

[Has an idea and fires up google...]

Okay, going to answer my own question! The stack limit is not known at compile time since it can be altered with outsetrlimit().

Matt

Amorph · Apr 8, 2002, 12:24 AM

Originally posted by mattcunnane:


Granted the compiler can't know (in general) how big the stack is going to get, but surely it would be a good idea to issue a warning if one tries to allocate a block of memory larger than the limit!?!

[Has an idea and fires up google...]

Okay, going to answer my own question! The stack limit is not known at compile time since it can be altered with outsetrlimit().

It's even trickier than that: C (and C++) has no built-in notion of a stack - it's just a common implementation - and so there are no built-in functions to handle a stack. outsetrlimit() is a vendor-specific extension, not an intrinsic part of C (or C++, or Objective-C).

There need not even be a stack size defined at compile time. For example, in older versions of MacOS, within the allotted memory the application grew "up" and the stack grew "down" - toward each other, in other words. So the more you malloc()'d, the less room you had on the stack, and vice versa! There were clever ways around that, but it was a pretty fundamental problem. This is (one reason) why significantly increasing the memory allocation of a classic MacOS application frequently makes it more stable: The stack is less likely to overrun the heap, and vice versa.

This is not a problem in OS X.

nobody · Apr 8, 2002, 06:39 PM

If the array is really used in the main() function,why dont declare it global?

-------------
int bitmap[800][800][3];

int main (int argc, const char * argv[]) {

return 0;
}

or static inside main()

[ 04-08-2002: Message edited by: nobody ]