A seg fault
Albert
#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[i]);
}
int main () {
FILE *fout = fopen ("dropout.txt", "w");
int i, j, d, l, a, b, val, best, done[MAX][MAX];
return 0;
}
Ben Bacarisse
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.
--
Ben.
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
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!
--
Ben.
Keith Thompson
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.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
BGB / cr88192
"Keith Thompson" <ks...@mib.org> wrote in message
news:lnd418b...@nuthaus.mib.org...
> Albert <albert.xt...@gmail.com> writes:
>> 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[i]);
>> }
>>
>> 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
> Albert <albert.xt...@gmail.com> writes:
>> 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[i]);
>> }
>>
>> int main () {
>> FILE *fout = fopen ("dropout.txt", "w");
>> int i, j, d, l, a, b, val, best, done[MAX][MAX];
>>
>> return 0;
>> }
> ...[I]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
"Albert" <albert.xt...@gmail.com> wrote in message
news:KnO4n.1913$pv....@news-server.bigpond.net.au...
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
> 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[i]);
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.
> return 0;
jaysome
<cr8...@hotmail.com> wrote:
[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.
--
jay
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
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!