printf() causes core dump

[Sheldon]

Hi,

Can anyone tell me why this script file.c and file.h causes a core
dump when it is compiled and run?

Any help is appreciated.
Sheldon

snip....

file.h:

#include <string.h>
#include <math.h>
#include <stdlib.h>
#include <stdio.h>
#include <dirent.h>
#include <errno.h>
#include <ctype.h>
#include <stdarg.h>
#include <sys/types.h>
#include "fort2c.h"

#define KELEM 500
#define KVALS 200000
#define IBFLEN 50000

char MODER[] = "r";
char FILNM[] = "string_path";

file.c:

#include "file.h"

int main() {

int IRET, ILEN, IUNIT1, IUNIT2, ILOOP, KERR;
int KTDLEN, KTDEXL;

/* 1D arrays */
int IBUFF[IBFLEN];

char CNAMES[64][KELEM];
char CUNITS[24][KELEM];
char CVALS[80][KVALS];
float VALUES[KVALS];
int KTDLST[KELEM];
int KTDEXP[KELEM];

int KSEC0[8];
int KSEC1[40];
int KSEC2[64];
int KEY[46];
int KSUP[9];
int KSEC3[4];
int KSEC4[2];

char ID[8];

int i, ii;

printf("Testing\n");

return 1;
}
snip....

 

[jacob navia]

Hi,

Can anyone tell me why this script file.c and file.h causes a core
dump when it is compiled and run?

Any help is appreciated.
Sheldon

Try to use less stack. Probably you are going beyond what
you are allowed.

Look at

ulimit -a

 

[David Resnick]

Hi,

Can anyone tell me why this script file.c and file.h causes a core
dump when it is compiled and run? .... snip ...

#define KELEM 500
#define KVALS 200000
#define IBFLEN 50000
.... snip ...

/* 1D arrays */
int IBUFF[IBFLEN];

char CNAMES[64][KELEM];
char CUNITS[24][KELEM];
char CVALS[80][KVALS];
float VALUES[KVALS];
int KTDLST[KELEM];
int KTDEXP[KELEM];

Try with IBFLEN, KELEM, and KVALS set to small numbers. Assuming that
fixes your problem, the issue is that you are creating automatic
("stack") variables that are just too big for your system for whatever
reason. Try allocating them with malloc in that case.

-David

 

[Sheldon]

Hi,

Can anyone tell me why this script file.c and file.h causes a core
dump when it is compiled and run?

... snip ...

#define KELEM 500
#define KVALS 200000
#define IBFLEN 50000

... snip ...

  /* 1D arrays */
  int IBUFF[IBFLEN];

  char  CNAMES[64][KELEM];
  char  CUNITS[24][KELEM];
  char  CVALS[80][KVALS];
  float VALUES[KVALS];
  int   KTDLST[KELEM];
  int   KTDEXP[KELEM];

Try with IBFLEN, KELEM, and KVALS set to small numbers.  Assuming that
fixes your problem, the issue is that you are creating automatic
("stack") variables that are just too big for your system for whatever
reason.  Try allocating them with malloc in that case.

-David- Dölj citerad text -

- Visa citerad text -

Thanks! I will try this.

/S

 

[Sheldon]

Hi,

Can anyone tell me why this script file.c and file.h causes a core
dump when it is compiled and run?

Any help is appreciated.
Sheldon

snip....

file.h:

#include <string.h>
#include <math.h>
#include <stdlib.h>
#include <stdio.h>
#include <dirent.h>
#include <errno.h>
#include <ctype.h>
#include <stdarg.h>
#include <sys/types.h>
#include "fort2c.h"

#define KELEM 500
#define KVALS 200000
#define IBFLEN 50000

char MODER[] = "r";
char FILNM[] = "string_path";

file.c:

#include "file.h"

int main() {

  int IRET, ILEN, IUNIT1, IUNIT2, ILOOP, KERR;
  int KTDLEN, KTDEXL;

  /* 1D arrays */
  int IBUFF[IBFLEN];

  char  CNAMES[64][KELEM];
  char  CUNITS[24][KELEM];
  char  CVALS[80][KVALS];
  float VALUES[KVALS];
  int   KTDLST[KELEM];
  int   KTDEXP[KELEM];

  int KSEC0[8];
  int KSEC1[40];
  int KSEC2[64];
  int KEY[46];
  int KSUP[9];
  int KSEC3[4];
  int KSEC4[2];

  char ID[8];

  int i, ii;

  printf("Testing\n");

  return 1;}

snip....

Thnaks, I will try it.

/S

 

[Martin Ambuhl]

Can anyone tell me why this script file.c and file.h causes a core
dump when it is compiled and run?

BTW, C is not a scripting language. Using 'script' in this context is
likely to earn you sneers, so you might not want to do that. In any case

#define KELEM 500
#define KVALS 200000
#define IBFLEN 50000 [...]
int main() { [...]
int IBUFF[IBFLEN];
char CNAMES[64][KELEM];
char CUNITS[24][KELEM];
char CVALS[80][KVALS];
float VALUES[KVALS];
int KTDLST[KELEM];
int KTDEXP[KELEM];
int KSEC0[8];
int KSEC1[40];
int KSEC2[64];
int KEY[46];
int KSUP[9];
int KSEC3[4];
int KSEC4[2];
char ID[8];

The limits on arrays guaranteed to be supported is much smaller than you
are attempting. Even worse, you are trying to allocate them as auto
variables. Learn to use dynamic allocation or, possibly, static arrays.
Your subject line is completely off base: printf() has nothing to do
with your problem. And splitting the content of your post between
subject line and body of the message is silly. If it's worth saying,
it's worth saying in the body of the message.

return 1;

1 is not a portable value for return. Worse, you are using this for
successful completion. We know that 0 is one of the defined values for
successful completion, the other being EXIT_SUCCESS.

 

[Richard Tobin]

Try with IBFLEN, KELEM, and KVALS set to small numbers.  Assuming that
fixes your problem, the issue is that you are creating automatic
("stack") variables that are just too big for your system for whatever
reason.  Try allocating them with malloc in that case.

[/QUOTE]

Thanks! I will try this.

As Jacob indicated, there's probably a way to increase the stack
available on your system. There's nothing wrong in principle with
having large stack-allocated arrays.

-- Richard

 

[Ben Pfaff]

There's nothing wrong in principle with having large
stack-allocated arrays.

I am not sure that I agree. Exhaustion of automatic storage is
not an event that a C program can detect and recover from.
Exhaustion of dynamically allocated storage, on the other hand,
is.

 

[Richard Tobin]

There's nothing wrong in principle with having large
stack-allocated arrays.

[/QUOTE]

I am not sure that I agree. Exhaustion of automatic storage is
not an event that a C program can detect and recover from.

That's true. If you're writing the kind of program where dealing
cleanly with that is important, it would certainly make sense to
prefer malloc().

-- Richard

 

[CBFalconer]

Can anyone tell me why this script file.c and file.h causes a core
dump when it is compiled and run?

You have a serious stack overflow occurring.

 

[Sheldon]

Can anyone tell me why this script file.c and file.h causes a core
dump when it is compiled and run?

BTW, C is not a scripting language.  Using 'script' in this context is
likely to earn you sneers, so you might not want to do that.  In any case

#define KELEM 500
#define KVALS 200000
#define IBFLEN 50000 [...]
int main() { [...]
  int IBUFF[IBFLEN];
  char  CNAMES[64][KELEM];
  char  CUNITS[24][KELEM];
  char  CVALS[80][KVALS];
  float VALUES[KVALS];
  int   KTDLST[KELEM];
  int   KTDEXP[KELEM];
  int KSEC0[8];
  int KSEC1[40];
  int KSEC2[64];
  int KEY[46];
  int KSUP[9];
  int KSEC3[4];
  int KSEC4[2];
  char ID[8];

The limits on arrays guaranteed to be supported is much smaller than you
are attempting.  Even worse, you are trying to allocate them as auto
variables.  Learn to use dynamic allocation or, possibly, static arrays.
Your subject line is completely off base: printf() has nothing to do
with your problem.  And splitting the content of your post between
subject line and body of the message is silly.  If it's worth saying,
it's worth saying in the body of the message.

  return 1;

1 is not a portable value for return.  Worse, you are using this for
successful completion.  We know that 0 is one of the defined values for
successful completion, the other being EXIT_SUCCESS.

}- Dölj citerad text -

- Visa citerad text -- Dölj citerad text -

- Visa citerad text -

Thanks for the tips!

 

[Sheldon]

You have a serious stack overflow occurring.

Thanks everyone for your comments, critiques, and advice.
I am not a programmer so I don't do this very often and hence the
rookie mistakes.
Dynamic allocating of memory works. I am grateful

/Sheldon

 

[Doug Miller]

Hi,

Can anyone tell me why this script file.c and file.h causes a core
dump when it is compiled and run? [...]

#define KVALS 200000
[...]

char CVALS[80][KVALS];

80 * 200000 = 16MB

Ya think you might be running out of stack space?

 

[Wade Ward]

You have a serious stack overflow occurring.

Gosh. Core dump. Stack trouble. Any pipes broken?

Oh I know ...linux.

Please comment further for those who aren't acquainted with whatever
strange reason you prefer it to windows. You're the definition of
topicality, Chuck.
--

 

[Micah Cowan]

Gosh. Core dump. Stack trouble. Any pipes broken?

Oh I know ...linux.

Please comment further for those who aren't acquainted with whatever
strange reason you prefer it to windows. You're the definition of
topicality, Chuck.

What in the world makes you think that stack overflows aren't a
problem on Windows?

And yes, stacks are not topical here. However, it was a helpful,
succint, and accurate response. Which also was not particularly
platform-specific.

The mention of core dumps, of course, is more platform-specific
(though hardly specific to Linux). But that wasn't Chuck, that was the
OP.

 

[Kenny McCormack]

Thanks! I will try this.

As Jacob indicated, there's probably a way to increase the stack
available on your system. There's nothing wrong in principle with
having large stack-allocated arrays.[/QUOTE]

Note how a Clique member can say "the s-word" here and no one complains.

Needless to say, should anyone else utter it, massive flamage would ensue.

It is good to be in the in-crowd.

 

[Richard Tobin]

Note how a Clique member can say "the s-word" here and no one complains.

Am I a clique member? I never knew! Where do I get my badge?

-- Richard

 

[Kenny McCormack]

Am I a clique member? I never knew! Where do I get my badge?

Dunno about the badges, but, more or less by definition, if you can say
the "s-word" and not get stomped on, you must be in.

 

[CBFalconer]

[...]

As Jacob indicated, there's probably a way to increase the stack
available on your system. There's nothing wrong in principle
with having large stack-allocated arrays.

Note how a Clique member can say "the s-word" here and no one
complains.

Am I a clique member? I never knew! Where do I get my badge?

Hold out your hand, palm down, and we will stamp it.

 

[Richard Heathfield]

Richard Tobin said:

Am I a clique member? I never knew! Where do I get my badge?

Presumably from any of the resident trolls, since this so-called "clique"
is a fiction of their imagination. A clique is exclusive. The comp.lang.c
newsgroup is inclusive - anyone who wants to talk about C is welcome. The
trolls (Riley, McCormack and Twink) don't want to talk about C; they are
only here for the jeer. The only people who ever agree with them are...
each other.

(Having said that, the trolls don't constitute a clique either.)

What the trolls (and some of the non-trolls) fail to realise is that it is
sometimes inevitable that discussions about C will drift into
platform-specific areas without /quite/ getting so far away from C that
it's worth moving the discussion to another group. Many subscribers see
this as a bad thing, but many don't. (Of course, there's a difference
between getting there accidentally via platform drift and starting off
there deliberately in the first place.)