Code::blocks max iterations [duplicate] - c

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Max Array Size in C
My question is: Does Code::blocks have a max number of iterations for a loop?
I am running a monte carlo and I would like to run a million particles through a for loop. But the max it seems to go without crashing is 110000.
Thanks!
Some more info:
I am using a random number generator seeded by time:
srand(time(NULL));
I then want to create a million particles (random)
for(k=0; k<M; k++){
R[k] = rand()*(1)/(double)RAND_MAX;
z[k] = -log(1 - R[k])/(1000*U);
where M = Num/10 (I want to #define N 1000000)
This is the only thing I can think of that is creating the problem?
Here is an example code that will not work.
#include <stdio.h>
#include <math.h>
#include <time.h>
#include <stdlib.h>
int main(){
srand(time(NULL));
int j=0;
int i;
double A[1000000];
for(i=0;i<1000000;i++){
A[i] = rand()*(1.0)/(double)RAND_MAX;
if (A[i] == 1.0){
printf("Wow!\n");
}
}
return 0;
}
Could this be due to my settings of Code::blocks by any chance?

There's no max number of iterations, but there is a limit on stack size.
When you declare a local variable, the memory is allocated from the stack. The size of A is too big to fit in the stack. (e.g. typical stack size on Windows is 1MB, 1000000 * sizeof(double) is far bigger.)
You can try changing A to a global variable or allocate it by malloc.

Edit: this is because the default maximum stack size is 1MB on Windows (but 8MB on Linux).
I don't have a final answer, but I do know:
a) It runs fine from a Linux command-line.
b) Valgrind gives tons of errors of this form:
==2465== Invalid write of size 8
==2465== at 0x804851D: main (test2.c:16)
==2465== Address 0xbe4480e4 is on thread 1's stack
==2465==
==2465== Invalid write of size 4
==2465== at 0x8048521: main (test2.c:16)
==2465== Address 0xbe4480e0 is on thread 1's stack
==2465==
==2465== Invalid read of size 4
==2465== at 0x4081D69: printf (printf.c:35)
==2465== by 0x8048528: main (test2.c:16)
==2465== Address 0xbe4480e0 is on thread 1's stack
==2465==
==2465== Invalid read of size 8
==2465== at 0x407AC05: vfprintf (vfprintf.c:1622)
==2465== by 0x4081D7F: printf (printf.c:35)
==2465== by 0x8048528: main (test2.c:16)
==2465== Address 0xbe4480e4 is on thread 1's stack
c) The errors are clearly related to reading and writing from the array. This simpler version of the program does not cause any Valgrind errors:
#include <stdio.h>
#include <math.h>
#include <time.h>
#include <stdlib.h>
int main(){
srand(time(NULL));
int i;
for(i=0;i<1000000;i++){
if (rand()*(1.0)/(double)RAND_MAX == 1.0){
printf("Wow!\n");
}
}
return 0;
}

Related

Program break doesnt change after calling malloc in a loop?

Running this piece of code is supposed to cause program break to increase by about malloc_counts * _SC_PAGESIZE instead I get fixed program break each time, so why is this. malloc is supposed to call brk or sbrk which itself round up size passed to next page (with some extra work). So what's happening ?
#include <stdio.h>
#include <malloc.h>
#include <unistd.h>
int main(){
const long malloc_counts = 10;
printf("PAGE SIZE: %ld\n", sysconf(_SC_PAGESIZE));
void* allocated_pool[malloc_counts];
for(int counter=0; counter < malloc_counts; counter++)
{
printf("program brk: %p\n",sbrk(0));
allocated_pool[counter] = malloc(127*4096);
}
}
which i guess of course using optimizations
Your compiler optimizes the calls to malloc out, because they are unused. Because malloc calls are removed, nothing changes and the heap is not moved.
And glibc overallocates a lot, so the value has to be large enough for it to see it. And the default M_MMAP_THRESHOLD seem to be 128 * 1024. So you have to pick a value large enough, but below mmap threshold to see a difference in glibc.
Disable your compiler optimizations and allocate a lot and heap will be moved. Try the following:
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
int main() {
printf("PAGE SIZE: %ld\n", sysconf(_SC_PAGESIZE));
#define malloc_counts 20
void *allocated_pool[malloc_counts];
for(int counter = 0; counter < malloc_counts; counter++) {
printf("program brk: %p\n", sbrk(0));
allocated_pool[counter] = malloc((size_t)127 * 1024);
*(void *volatile *)&allocated_pool[counter];
}
}

counting lines of input using memchr fails

I wrote a program to count lines of input given by stdin :
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <stdio.h>
#define BUFF_SIZE 8192
#define RS '\n'
int
main(int argc, char **argv)
{
char buff[BUFF_SIZE];
ssize_t n;
char *r;
int c = 0;
readchunk:
n = read(0, buff, BUFF_SIZE);
if (n<=0) goto end; // EOF
r=buff;
searchrs:
r = memchr(r, RS, n);
if(r!=NULL) {
c++;
if((r-buff)<n) {
++r;
goto searchrs;
}
}
goto readchunk;
end:
printf("%d\n", ++c);
return 0;
}
I compiled it with gcc, with no options.
When run, it gives unstable result, not far from truth but false. Sometimes it segfaults. The bigger is the buffer size the more often it segfaults.
What am I doing wrong ?
Building your program with -fsanitize=address and feeding it sufficiently long input produces:
==119818==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffedbba1500 at pc 0x7fc4d56fd574 bp 0x7ffedbb9f4a0 sp 0x7ffedbb9ec50
READ of size 8192 at 0x7ffedbba1500 thread T0
#0 0x7fc4d56fd573 (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x40573)
#1 0x563fdf5f4b90 in main /tmp/t.c:23
#2 0x7fc4d533e2b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#3 0x563fdf5f49c9 in _start (/tmp/a.out+0x9c9)
Address 0x7ffedbba1500 is located in stack of thread T0 at offset 8224 in frame
#0 0x563fdf5f4ab9 in main /tmp/t.c:11
This frame has 1 object(s):
[32, 8224) 'buff' <== Memory access at offset 8224 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x40573)
Line 23 is the call to memchr.
When you increment r, you should probably decrement n.

Unknown Segmentation Fault (Core Dumped) in multithread initialization

I've had three different lab TAs look at my code and none of them have been able to help me, so I've decided to try here. Unless I delete all code relating to both gettimeofday and any semaphores, I get a "Segmentation fault (core dumped)​" error. I've boiled down my code to only the main thread with simple declarations to attempt to get to the root of the problem.
My code:
#include <pthread.h>
#include <semaphore.h>
#include <sys/types.h>
#include <stdio.h>
#include <string.h>
#include <sys/shm.h>
#include <sys/time.h>
void *threadN (void *); /* thread routines */
pthread_t tid[1]; /* array of thread IDs */
int main()
{
int i,j;
/* here create and initialize all semaphores */
int mutex = sem_create(777777, 1);
int MatrixA[6000][3000];
for (i=0; i < 6000; i++) {
for (j=0; j < 3000; j++) {
MatrixA[i][j]=i*j;
}
}
int MatrixB[3000][1000];
for (i=0; i < 3000; i++) {
for (j=0; j < 1000; j++) {
MatrixB[i][j]=i*j;
}
}
int MatrixC[6000][1000];
struct timeval tim;
gettimeofday(&tim, NULL);
float t1=tim.tv_sec+(tim.tv_usec/1000000.0);
gettimeofday(&tim, NULL);
float t2=tim.tv_sec+(tim.tv_usec/1000000.0);
printf("%.2lf seconds elapsed\n", t2-t1);
sem_rm(sem_open(777777, 1));
return 0;
}​
I'm completely stumped here.
You eat your stack. See Radix sort for 10^6 array in C, comment from #Joachim Pileborg:
Local variables are usually stored on the stack, and the stack is usually limited to single-digit megabytes. On Windows for example, the default is 1MB per process, on Linux the default is 8MB...
I tried your code on Windows and it was dead with just MatrixA defined: 6000*3000*4 (for int)...
So you will have to move matrix data out of stack: define matrix as static or allocate on heap.
A useful thing I have found for tracking seg faults is with using gdb.
gcc -g -o a.out -c program.c
-g generates source level debug information
gdb a.out core
this starts up gdb with a.out
(gdb) run
this should run the program and show the line where the seg fault is happening.

Different run time after Segfault in Infinite Recursive main()

Just as we know,
In Linux world, infinite recusive "main()" in userspace will receive "segmentation fault" messsage, which is actually caused by stack overflow. (just as the following code)
#include <stdio.h>
void main(void)
{
main ();
}
Experiment and Question:
Change code to:
#include <stdio.h>
int cnt = 0;
void main(void) {
printf("cnt %d\n", cnt++);
main();
}
Test environment:
x86-64 ubuntu,
gcc-4.6
I need your help and thanks in advance!
Why Segmentation fault happens in different "cnt" value:
cnt: 523614
cnt: 523602
cnt: 523712
cnt: 523671
This is probably due to Address space layout randomization. If you run the slightly modified example of your program:
#include <stdio.h>
int cnt = 0;
void main(void)
{
int a;
printf("cnt %d %p\n", cnt++, (void*)&a); fflush(stdout);
main();
}
you will see that the address of a is not consistent over various runs of the program. Probably the initial size of the stack is also slightly randomized resulting in a slightly different number of stack frames fitting in this space.
P.S: I've added a fflush so the output of the program can be safely piped through for example tail and grep, otherwise buffering may blur the actual last line of output.
P.S2: I had to change print into printf and add #include <stdio.h>.
P.S3: You should not use an optimization on your program, because otherwise a tail-call optimization will remove your recursion and your program will actually loop forever. My version of the program doesn't do that, because of the aliased a.

Cant figure out why program is crashing in C

I have this code:
#include <stdio.h>
#include <math.h>
#define gridSize 400
void main() {
float grid[gridSize][gridSize];
short height[gridSize][gridSize];
short power[gridSize][gridSize];
}
I'm using visual studio 2010, the program seems to crash instantly when I run it. However this code:
#include <stdio.h>
#include <math.h>
#define gridSize 400
void main() {
float grid[gridSize][gridSize];
short height[gridSize][gridSize];
//short power[gridSize][gridSize];
}
Seems to work fine, and the program doesn't crash. What could be the problem?
Here grid height and power are auto variable and going to store in stack.
In any Os each process has some fixed default size stack.
Here you are allocating too much data on stack so process has no other memory left on stack for other operation. so it crash
you have two option
1> Increase stack size for this process
On Linux with gcc you can increase it by
–stack 16777216
adding this in gcc command
2> you can store this data on heap section by using malloc.
You're allocating too much stack. Move one or more into heap instead.
Just read the name of this website, stack overflow.
You can:
1, move those three arrays out of main function(maybe you will get a large .exe after compilation if you initialize those arrays).
or
2, use malloc().

Resources