printf() causes core dump

Discussion in 'C Programming' started by Sheldon, Feb 27, 2008.

  1. Sheldon

    Sheldon Guest

    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....
     
    Sheldon, Feb 27, 2008
    #1
    1. Advertising

  2. Sheldon

    jacob navia Guest

    Sheldon wrote:
    > 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


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Feb 27, 2008
    #2
    1. Advertising

  3. On Feb 27, 3:18 pm, Sheldon <> wrote:
    > 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
     
    David Resnick, Feb 27, 2008
    #3
  4. Sheldon

    Sheldon Guest

    On 27 Feb, 21:26, David Resnick <> wrote:
    > On Feb 27, 3:18 pm, Sheldon <> wrote:
    >
    >
    >
    >
    >
    > > 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, Feb 27, 2008
    #4
  5. Sheldon

    Sheldon Guest

    On 27 Feb, 21:18, Sheldon <> wrote:
    > 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
     
    Sheldon, Feb 27, 2008
    #5
  6. Sheldon wrote:

    > 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.

    > }
     
    Martin Ambuhl, Feb 27, 2008
    #6
  7. In article <>,
    Sheldon <> wrote:

    >> 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.


    >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


    --
    :wq
     
    Richard Tobin, Feb 27, 2008
    #7
  8. Sheldon

    Ben Pfaff Guest

    (Richard Tobin) writes:

    > 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.
    --
    Peter Seebach on C99:
    "[F]or the most part, features were added, not removed. This sounds
    great until you try to carry a full-sized printout of the standard
    around for a day."
     
    Ben Pfaff, Feb 27, 2008
    #8
  9. In article <>,
    Ben Pfaff <> wrote:

    >> 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.


    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
    --
    :wq
     
    Richard Tobin, Feb 27, 2008
    #9
  10. Sheldon

    CBFalconer Guest

    Sheldon wrote:
    >
    > 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.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Feb 27, 2008
    #10
  11. Sheldon

    Sheldon Guest

    On 27 Feb, 21:36, Martin Ambuhl <> wrote:
    > Sheldon wrote:
    > > 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, Feb 28, 2008
    #11
  12. Sheldon

    Sheldon Guest

    On 27 Feb, 23:42, CBFalconer <> wrote:
    > Sheldon wrote:
    >
    > > 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.
    >
    > --
    >  [mail]: Chuck F (cbfalconer at maineline dot net)
    >  [page]: <http://cbfalconer.home.att.net>
    >             Try the download section.
    >
    > --
    > Posted via a free Usenet account fromhttp://www.teranews.com


    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
     
    Sheldon, Feb 28, 2008
    #12
  13. Sheldon

    Doug Miller Guest

    In article <>, Sheldon <> wrote:
    >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?
     
    Doug Miller, Feb 28, 2008
    #13
  14. Sheldon

    Wade Ward Guest

    On Feb 27, 3:42 pm, CBFalconer <> wrote:
    > Sheldon wrote:
    >
    > > 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.

    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.
    --
     
    Wade Ward, Feb 29, 2008
    #14
  15. Sheldon

    Micah Cowan Guest

    Wade Ward <> writes:

    > On Feb 27, 3:42 pm, CBFalconer <> wrote:
    >> Sheldon wrote:
    >>
    >> > 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.

    > 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.

    --
    Micah J. Cowan
    Programmer, musician, typesetting enthusiast, gamer...
    http://micah.cowan.name/
     
    Micah Cowan, Feb 29, 2008
    #15
  16. In article <fq4k4u$fg7$>,
    Richard Tobin <> wrote:
    >In article <>,
    >Sheldon <> wrote:
    >
    >>> 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.

    >
    >>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.


    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.
     
    Kenny McCormack, Feb 29, 2008
    #16
  17. In article <fq9vfb$efj$>,
    Kenny McCormack <> wrote:

    >In article <fq4k4u$fg7$>,
    >Richard Tobin <> wrote:

    [...]
    >>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?

    -- Richard
    --
    :wq
     
    Richard Tobin, Feb 29, 2008
    #17
  18. In article <fqa0cm$25jj$>,
    Richard Tobin <> wrote:
    >In article <fq9vfb$efj$>,
    >Kenny McCormack <> wrote:
    >
    >>In article <fq4k4u$fg7$>,
    >>Richard Tobin <> wrote:

    >[...]
    >>>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?


    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.
     
    Kenny McCormack, Feb 29, 2008
    #18
  19. Sheldon

    CBFalconer Guest

    Richard Tobin wrote:
    > Kenny McCormack <> wrote:
    >> Richard Tobin <> wrote:

    >
    > [...]
    >
    >>> 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.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Feb 29, 2008
    #19
  20. Richard Tobin said:

    > In article <fq9vfb$efj$>,
    > Kenny McCormack <> wrote:
    >
    >>In article <fq4k4u$fg7$>,
    >>Richard Tobin <> wrote:

    > [...]
    >>>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?


    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.)

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Mar 1, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. BlueDoze
    Replies:
    2
    Views:
    1,199
    Gordon Beaton
    May 4, 2004
  2. Replies:
    2
    Views:
    1,834
  3. halfdog
    Replies:
    12
    Views:
    12,557
  4. Jake
    Replies:
    1
    Views:
    324
    mlimber
    Nov 11, 2005
  5. loudking

    free causes core-dump

    loudking, Jan 9, 2008, in forum: C Programming
    Replies:
    4
    Views:
    916
    Keith Thompson
    Jan 11, 2008
Loading...

Share This Page