Particle mesh allocation fails for larger grid numbers

Hello all, I'm currently studying how particle mesh simulations work and they seem to be a 3D allocation of grid points equally spaced from each other. I figure an easy way to allocate this memory is to use a 3D array and fill it with structs. If there's a better way then now is the time to tell me.

If not, then yay for me and here's my code:

Code:

#include <stdlib.h> #include <stdio.h> typedef struct node { int type; } *node_ref; int main(int argc, char **argv) { int gl=128; node_ref omfg[gl][gl][gl]; for (int i=0; i<gl; i++) { for (int j=0; j<gl; j++) { for (int k=0; k<gl; k++) { omfg[i][j][k] = malloc(sizeof (node_ref)); omfg[i][j][k]->type = i; } } } for (int i=0; i<gl; i++) { for (int j=0; j<gl; j++) { for (int k=0; k<gl; k++) { free (omfg[i][j][k]); } } } return 0; }

So as you can see, it's not that complicated. But the funny thing is, it works for smaller gl than 128 in the sense that gl=128 segmentation faults the code. Using gl=64 works fine though valgrind does give me some odd errors (Warning: client switching stacks? SP change: 0x7ff0005a0 --> 0x7fee00590to suppress, use: --max-stackframe=2097168 or greater)

I don't actually know what that means but I have 8 GB of RAM and I doubt I'm eating up that much of it.

So what's wrong here?

Code:

node_ref omfg[gl][gl][gl];

What is 128^3? Static arrays are created on the stack.

Quote:

Originally Posted by Tclausex

Code:

node_ref omfg[gl][gl][gl];

What is 128^3? Static arrays are created on the stack.

So, 128^3 = 2,097,152 allocations of node structures. We give each structure 8 bytes so we wind up with 16,777,216 bytes total, not to mention the allocated memory given to the array itself, right? I think there's 32 bytes missing (something I noticed from valgrind output and my earlier calculations) so we should have 16,777,248 bytes total. So like 17 MB.

I'm sorry, I'm rather ignorant in most cases as I'm not formally educated but I'm not sure why stack size is an issue. I've tried using "ulimit -s unlimited" and other numbers and they haven't done anything.

I assume I should be able to write any structure that is allowed by my total RAM pool so if I wanted to, I could eat up like 6.5 GB (idle system is at 1.5 GB right now). But this stack size thing and heaps, what is this and why is it in my way?

The "stack" is a relatively small memory allocation for storing local variables, passing parameters and return values and calling functions. According to your warning above, your stack is 2048K. Your total system memory is not available as a stack - thus you need to use dynamic memory allocation for such amounts of data, which will allocate space outside the stack. By itself, your omfg 3D array is as big as your stack, leaving no room for anything else.

Okay, so I've got this now:

Code:

#include <stdlib.h> #include <stdio.h> typedef struct node { int type; } *node_ref; int main(int argc, char **argv) { int gl=128; node_ref ***omfg; omfg = (node_ref ***)malloc(gl*sizeof(node_ref**)); for (int i=0; i<gl; i++) { omfg[i] = (node_ref **)malloc(gl*sizeof(node_ref*)); for (int j=0; j<gl; j++) { omfg[i][j] = (node_ref *)malloc(gl*sizeof(node_ref)); } } for (int i=0; i<gl; i++) { for (int j=0; j<gl; j++) { free (omfg[i][j]); } free (omfg[i]); } free (omfg); return 0; }

But if I try to change the type value, I segmentation fault. Is this a correct way to allocate memory?

You shouldn't cast the return value of malloc

Also, check whether malloc was successful before using it.

Okay, so this should totally work and I must say, thank you guys for your help. I did want to kick and scream but I can only assume that it is a natural response. :)

Either way, it allocates, doesn't fault and frees all the memory! Yay, I wrote good code for once!!! Now all the particle mesh physics belong to me!!!

Code:

#include <stdlib.h> #include <stdio.h> typedef struct node { int type; } *node_ref; int main(int argc, char **argv) { int gl=128; node_ref **omfg = malloc(gl*sizeof(node_ref **)); for (int i=0; i<gl; i++) { omfg[i] = malloc(gl*sizeof(node_ref *)); for (int j=0; j<gl; j++) { omfg[i][j] = malloc(gl*sizeof(node_ref)); for (int k=0; k<gl; k++) { omfg[i][j][k].type = 0; } } } for (int i=0; i<gl; i++) { for (int j=0; j<gl; j++) { free (omfg[i][j]); } free (omfg[i]); } free (omfg); return 0; }

Quote:

Originally Posted by MutantJohn

Yay, I wrote good code for once!!!

I tend to disagree.

You typedef a pointer which makes your code harder to read. I would suggest something like:

Code:

typedef struct node { int type; } node_t; ... node_t ***omfg = malloc(gl * sizeof(*omfg));

which makes it clear that "omfg" is a pointer to pointer to pointer to node_t. (Actually I don't see a reason for the typedef at all instead of just using "struct xxx" as the type.)

Notice also how I use "omfg" with the sizeof operator. The basic idea is to always dereference the variable you are allocating memory for:

Code:

T *var_name; var_name = malloc(sizeof(*var_name));

Thus if you ever have to change the type of your pointer (T) you can do it at one single line.

The same works for your other two malloc() calls:

Code:

omfg[i] = malloc(gl * sizeof(*omfg[i])); omfg[i][j] = malloc(gl * sizeof(*omfg[i][j]);

Bye, Andreas

"The basic idea is to always dereference the variable you are allocating memory for:"

Okay, I don't know what this means, actually.

Consider this example.

int *p = malloc( 10 * sizeof(int) ); // make the coder do the work
vs.
int *p = malloc( 10 * sizeof(*p) ); // make the compiler do the work

Which are both equivalent until there is a change of mind, and the code gets edited to
double *p = malloc( 10 * sizeof(int) ); // oops, did you forget something?
vs.
double *p = malloc( 10 * sizeof(*p) ); // make the compiler do the work, automatically correct.