fourati@suvax0.shizuoka.JUNET (Fourati Mourad) (06/23/88)
May some body tell me about the most common cases when a core dumping occurs
in a C program execution. i'm still don't have much experience in this
langage. Sorry for disturbing with such questions.
THANKS in advance.
Mourad Fouratibrister@td2cad.intel.com (James Brister) (06/26/88)
In article <623@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: >From article <835@suvax0.shizuoka.JUNET>, by fourati@suvax0.shizuoka.JUNET (Fourati Mourad): >> >> May some body tell me about the most common cases when a core dumping occurs >> in a C program execution. i'm still don't have much experience in this >> langage. Sorry for disturbing with such questions. >> >> THANKS in advance. >> Mourad Fourati Well, it's my experience (which is *not* years and years) that bad pointers are the most common cause; and these can show up in a couple of places: i) A standard pointer operation goes off into an area of memory that hasn't been requested by MALLOC and isn't part of any static data areas. ii) A bad pointer corrupts the lists MALLOC uses and then when you do a FREE or a MALLOC, the function itself goes off into illegal areas. I'm sure there must be more, but I'm kinda new to this too. James Brister brister@td2cad.intel.com
beckenba@cit-vax.Caltech.Edu (Joe Beckenbach) (06/26/88)
Pointers are a good place to start looking. My horror story in this regard: I was in the middle of writing a routine (in C) to interface with a graphics package (in Fortran). When I had debug comments in, the first debug statement would have some garbage appended; the program worked like a charm. I take out all the debug statements, and it hangs dead. After about three hours I woke up, stopped thinking Pascal and Basic and brought myself back to C: I took that pointer which I was copying a string into, and malloc'ed it some area of its own. This kept it from overwriting into fixed string areas (such as for printf text strings) and into area which seems to have been necessary for the program to tell itself where it was in the code.... I swear, one of these days I'll get all these subtle misconceptions of mine about C out of the way. And then I'll be told to start learning Fortran 66. :-) -- Joe Beckenbach beckenba@csvax.caltech.edu Caltech 1-58, Pasadena CA 91125 ! ! you're dead.
koala@ddsw1.UUCP (Karl Meiser) (06/28/88)
Usually its errors that cant be checked by the compiler, such as missing
or incorrect arguments, examples:
main()
{
long x;
printf("%s"); /* Missing argument */
printf("%d",x); /* Should be descriptor for long, %d is for ints */
}
Usually i find myself doing fprintf's without the file descriptor;
main()
{
FILE *fp;
fp = fopen("foo","r");
fprintf("Hello file named foo\n");
/* Should be
fprintf(fp,"Hello file named foo\n");
*/
fclose(fp);
}
Hope this helps.
--
Karl Meiser koala@_d_d_s_w_1
koala@m-net
koala@chinet
koala@igloowalter@garth.UUCP (Walter Bays) (06/28/88)
There are two main causes of core dumps:
1) Calling someone else's routine (a buggy routine)
2) Someone else calling your routine (improper calling sequence :-)
--
------------------------------------------------------------------------------
My opinions are my own. Objects in mirror are closer than they appear.
E-Mail route: ...!pyramid!garth!walter (415) 852-2384
USPS: Intergraph APD, 2400 Geng Road, Palo Alto, California 94303
------------------------------------------------------------------------------smryan@garth.UUCP (Steven Ryan) (06/28/88)
Some other causes programmers learn are POM (1) faults and, after it's been deliverred, OIABM (2) problems. ----------------------------- (1) Phase Of Moon (2) Once In A Blue Moon
chris@mimsy.UUCP (Chris Torek) (06/29/88)
In article <1285@ddsw1.UUCP> koala@ddsw1.UUCP (Karl Meiser) writes: >Usually its errors that cant be checked by the compiler, such as missing >or incorrect arguments, examples: > >main() >{ >long x; > >printf("%s"); /* Missing argument */ >printf("%d",x); /* Should be descriptor for long, %d is for ints */ >} Hm. `Cannot be checked'? % lint -h tt.c tt.c: tt.c(5): warning: possible format/argument count mismatch tt.c(6): warning: printf: (int) format, (long) arg (arg 2) tt.c(6): warning: x may be used before set printf returns value which is always ignored % (Somehow this reminds me of arguments about `volatile' detection :-) ) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris