A seg fault

[Albert]

Why does this seg fault?

#include <stdio.h>

#define MAX 1000

int positions[MAX];
int nleaflets;

void storeinput () {
FILE *fin = fopen ("dropin.txt", "r");
int i;
fscanf (fin, "%d", &nleaflets);
for (i = 0; i < nleaflets; i++) fscanf (fin, "%d", &positions);
}

int main () {
FILE *fout = fopen ("dropout.txt", "w");
int i, j, d, l, a, b, val, best, done[MAX][MAX];

return 0;
}

 

[Ben Bacarisse]

Why does this seg fault?

#include <stdio.h>

#define MAX 1000

int positions[MAX];
int nleaflets;

void storeinput () {
FILE *fin = fopen ("dropin.txt", "r");
int i;
fscanf (fin, "%d", &nleaflets);
for (i = 0; i < nleaflets; i++) fscanf (fin, "%d", &positions);
}

int main () {
FILE *fout = fopen ("dropout.txt", "w");
int i, j, d, l, a, b, val, best, done[MAX][MAX];

return 0;
}

There's not much to go on but my first guess would be that you'd don't
have room to allocate 1,000,000 ints of automatic storage. It's odd
that the small array is static and the bug one is automatic.

 

[Paul N]

There's not much to go on but my first guess would be that you'd don't
have room to allocate 1,000,000 ints of automatic storage.  It's odd
that the small array is static and the bug one is automatic.

Does that get some sort of award for "most appropriate typo"?

 

[Ben Bacarisse]

Does that get some sort of award for "most appropriate typo"?

I think I've done better, you know. Since I have at least one per
line on average, the odds are better than you'd think!

 

[Keith Thompson]

Why does this seg fault?

#include <stdio.h>

#define MAX 1000

int positions[MAX];
int nleaflets;

void storeinput () {
FILE *fin = fopen ("dropin.txt", "r");
int i;
fscanf (fin, "%d", &nleaflets);
for (i = 0; i < nleaflets; i++) fscanf (fin, "%d", &positions);
}

int main () {
FILE *fout = fopen ("dropout.txt", "w");
int i, j, d, l, a, b, val, best, done[MAX][MAX];

return 0;
}

It doesn't on my system.

Ben Bacarisse already pointed out that the "done" array may be too
big. Depending on your implementation, declaring it static might
help.

I also note that you never call storeinput(). You probably removed
the call while trying to reduce the program to a minimal example that
exhibits the problem. But if the "done" array is really the problem,
you could probably have removed the storeinput() function and most of
the rest of the code, eventualy giving you just:

#define MAX 1000

int main() {
int done[MAX][MAX];
return 0;
}

I think you just gave up too soon.

 

[BGB / cr88192]

Why does this seg fault?

#include <stdio.h>

#define MAX 1000

int positions[MAX];
int nleaflets;

void storeinput () {
FILE *fin = fopen ("dropin.txt", "r");
int i;
fscanf (fin, "%d", &nleaflets);
for (i = 0; i < nleaflets; i++) fscanf (fin, "%d", &positions);
}

int main () {
FILE *fout = fopen ("dropout.txt", "w");
int i, j, d, l, a, b, val, best, done[MAX][MAX];

return 0;
}

It doesn't on my system.

Ben Bacarisse already pointed out that the "done" array may be too
big. Depending on your implementation, declaring it static might
help.

<snip>

yep.

actually, this example is more likely to crash on Windows, and not crash on
Linux, since Linux tends to default to a bigger stack than Windows.

however, the mystery is:
this still should not crash right-off on Windows, as there should still be
around 194kB of stack left over, which does (presumably, it would crash
after a few more functions were called...).

then again, considering Windows memory default layout:
0x00000000-0x0000FFFF //unused, NULL page (Windows likes 64kB "pages").
0x00010000-0x0001FFFF //unused, trap page
0x00020000-0x003FFFFF //main stack

this leaves 63232 bytes free (61.75kB).

if I remember correctly, the TEB and TLS go on the stack in Windows 4kB or
8kB for TLS (Win32 or Win64), + ~4kB for the TEB (rough estimate).

this leaves ~49.75 kB.
- whatever is used in crtMainEntry (or whatever this is called, I forget).
- whatever is needed by 'fopen'.
....

so, yeah, it is very close to the edge here...

something likely happens somewhere to push it over the limit...


well, that, or Windows is just like OMG WTF?... when a function just goes
and tries to grab such a huge chunk of stack space all at once...

 

[Albert]

Why does this seg fault?

#include <stdio.h>

#define MAX 1000

int positions[MAX];
int nleaflets;

void storeinput () {
FILE *fin = fopen ("dropin.txt", "r");
int i;
fscanf (fin, "%d", &nleaflets);
for (i = 0; i < nleaflets; i++) fscanf (fin, "%d", &positions);
}

int main () {
FILE *fout = fopen ("dropout.txt", "w");
int i, j, d, l, a, b, val, best, done[MAX][MAX];

return 0;
}

<snip>
...f the "done" array is really the problem,
you could probably have removed the storeinput() function and most of
the rest of the code, eventualy giving you just:

#define MAX 1000

int main() {
int done[MAX][MAX];
return 0;
}

I think you just gave up too soon.

The "done" array was really the problem.

I've been told to assume 8MB static memory for coding contests.

 

[BGB / cr88192]

Why does this seg fault?

#include <stdio.h>

#define MAX 1000

int positions[MAX];
int nleaflets;

void storeinput () {
FILE *fin = fopen ("dropin.txt", "r");
int i;
fscanf (fin, "%d", &nleaflets);
for (i = 0; i < nleaflets; i++) fscanf (fin, "%d", &positions);
}

int main () {
FILE *fout = fopen ("dropout.txt", "w");
int i, j, d, l, a, b, val, best, done[MAX][MAX];

return 0;
}

<snip>
...f the "done" array is really the problem,
you could probably have removed the storeinput() function and most of
the rest of the code, eventualy giving you just:

#define MAX 1000

int main() {
int done[MAX][MAX];
return 0;
}

I think you just gave up too soon.

The "done" array was really the problem.

I've been told to assume 8MB static memory for coding contests.

8MB stack is for Linux, but not for Windows, which uses 4MB...

it is also not uncommon to create additional threads with smaller stacks
(such as 256kB or 1MB), although this would normally be specified manually
by the app.


also, stack!=static...

 

[James Dow Allen]

Why does this seg fault?

It doesn't on my system.
[snip discussion of "optimizing" program to force seg fault]
I think you just gave up too soon.

I've noticed a lot of callous, deliberate seg faulting
in this ng lately.

Perhaps some of you should read this:
http://xkcd.com/371/

James

 

[Nick Keighley]

Why does this seg fault?

besides what everyone else has said there's a woeful lack of error
checking in this program

#include <stdio.h>

#define MAX 1000

int positions[MAX];
int nleaflets;

void storeinput () {
        FILE *fin = fopen ("dropin.txt", "r");

check fopen()

        int i;
        fscanf (fin, "%d", &nleaflets);

check fscanf() (error recovery with fscanf() is a bit 'icky but that's
another issue)

        for (i = 0; i < nleaflets; i++) fscanf (fin, "%d", &positions);

check fscanf(). Also check nleaflets is smaller than MAX

}

int main () {
        FILE *fout = fopen ("dropout.txt", "w");

check fopen()

        int i, j, d, l, a, b, val, best, done[MAX][MAX];

that's a lot of stuff to declare in main(). I pretty much think all
main() should do is parse the command line arguments and call one
function.

 

[jaysome]

On Sun, 17 Jan 2010 18:56:08 -0700, "BGB / cr88192"


[SNIP]

8MB stack is for Linux, but not for Windows, which uses 4MB...

Note that the term "stack" is not even mentioned in the C Standard.

On platforms that use a "stack", its size typically depends on the
compiler, not the OS. For example, the Visual C++ compiler for Windows
uses a default stack size of 1 MB. It's been that way since at least
Visual V++ 6.0 and as far as I know even up to and including the
latest version. See this link:

http://msdn.microsoft.com/en-us/library/tdkhxaks(VS.71).aspx

When I run the OP's program under Windows compiled with Visual C++ 6.0
SP5, I get a "0xC00000FD: Stack Overflow" exception, because the stack
size exceeds 1 MB. If I add the "/stack:0x989680" linker option, the
program executes without an exception.

 

[Seebs]

Note that the term "stack" is not even mentioned in the C Standard.

Yes. And for good reason...

On platforms that use a "stack", its size typically depends on the
compiler, not the OS. For example, the Visual C++ compiler for Windows
uses a default stack size of 1 MB. It's been that way since at least
Visual V++ 6.0 and as far as I know even up to and including the
latest version. See this link:

See, here you surprise me. Of the two systems where I know off the top
of my head how stack space is allocated, in both cases, the limit is defined
by the OS, not by the compiler. (UNIX and AmigaDOS)

-s