jet@karazm.math.uh.edu ("J. Eric Townsend") (01/24/91)
I've got a rather simple little C program that dumps core at
the first "{" of main() (according to gdb and saber).
Any hints as to what could be causing this? I'm about to run it
interpreted under saber-c, we'll see what that shows (and how long
it takes).
--
J. Eric Townsend Internet: jet@uh.edu Bitnet: jet@UHOU
Systems Mangler - UH Dept. of Mathematics - (713) 749-2120
Motorola skates on Intel's head!diamond@jit345.swstokyo.dec.com (Norman Diamond) (01/24/91)
In article <1991Jan23.232300.3698@lavaca.uh.edu> jet@karazm.math.uh.edu ("J. Eric Townsend") writes: >I've got a rather simple little C program that dumps core at >the first "{" of main() (according to gdb and saber). >Any hints as to what could be causing this? Probably incorrect initializations of automatic variables in main(). Possibly an insufficient stack limit or other similar problem. >I'm about to run it >interpreted under saber-c, we'll see what that shows (and how long >it takes). Good idea. Why didn't you try it before posting? -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it.
derge@paris.crd.ge.com (Gillmer J. Derge) (01/25/91)
In article <1991Jan23.232300.3698@lavaca.uh.edu> jet@karazm.math.uh.edu ("J. Eric Townsend") writes: >I've got a rather simple little C program that dumps core at >the first "{" of main() (according to gdb and saber). >Any hints as to what could be causing this? I've seen this happen as a result of declaring a large, global array. In my case it was a 30 by 30 by 100 by 40 array of char, and I fixed it by allocating the memory at run time. An explanation, I can not give, but this may work as a solution. Gill Derge derge@crd.ge.com
abed@saturn.wustl.edu (Abed M. Hammoud) (01/25/91)
In article <1991Jan24.061653.22785@tkou02.enet.dec.com> diamond@jit345.enet@tkou02.enet.dec.com (Norman Diamond) writes: >In article <1991Jan23.232300.3698@lavaca.uh.edu> jet@karazm.math.uh.edu ("J. Eric Townsend") writes: > >>I've got a rather simple little C program that dumps core at >>the first "{" of main() (according to gdb and saber). >>Any hints as to what could be causing this? > >Probably incorrect initializations of automatic variables in main(). >Possibly an insufficient stack limit or other similar problem. > >>I'm about to run it >>interpreted under saber-c, we'll see what that shows (and how long >>it takes). > >Good idea. Why didn't you try it before posting? >-- >Norman Diamond diamond@tkov50.enet.dec.com >If this were the company's opinion, I wouldn't be allowed to post it. I had the same problem a couple of weeks ago. (also on a sparc 1+ station). I was using a number of large arrays. by keeping the same array sizes and changing their type from double to float the problem disappear. So for some reason it seems it has something to do with big arrays. I will be interested to know what really causes this problem. -------------------------------------------------------------- | Abed M. Hammoud abed@saturn.wustl.edu| | Washington University. office:(314)726-7547 | | Electronic Systems & Signals Research Laboratory. | | Dept. of Electrical/Biomedical Engineering. | | St.Louis Mo U.S.A | --------------------------------------------------------------
jet@karazm.math.uh.edu ("J. Eric Townsend") (01/25/91)
In article <1991Jan24.214110.1478@cec1.wustl.edu> abed@saturn.wustl.edu (Abed M. Hammoud) writes: >>Good idea. Why didn't you try it before posting? I did, several different ways. I was going to try it some *more*... >In article <1991Jan24.061653.22785@tkou02.enet.dec.com> diamond@jit345.enet@tkou02.enet.dec.com (Norman Diamond) writes: > I had the same problem a couple of weeks ago. (also on a sparc > 1+ station). I was using a number of large arrays. by keeping > the same array sizes and changing their type from double to > float the problem disappear. So for some reason it seems it has > something to do with big arrays. Aha! I'm using big arrays of doubles as well. A quick :%s/double/float/g produced a source, that when compiled, did *not* dump core. For the file that uses doubles, I've also discovered that cc -o foo foo.c produces a file that *doesn't* dump core, while cc -c foo.c ld -o foo foo.o produces a file that *does* dump core. Looks like a 4.0.3c compiler bug. We go to 4.1.1 in a couple of weeks, so maybe I'll just wait and see if that "fixes" the problem. -- J. Eric Townsend Internet: jet@uh.edu Bitnet: jet@UHOU Systems Mangler - UH Dept. of Mathematics - (713) 749-2120 Motorola skates on Intel's head!
diamond@jit345.swstokyo.dec.com (Norman Diamond) (01/25/91)
In article <1991Jan24.234658.27689@lavaca.uh.edu> jet@karazm.math.uh.edu ("J. Eric Townsend") writes: >In article <1991Jan24.214110.1478@cec1.wustl.edu> abed@saturn.wustl.edu (Abed M. Hammoud) writes: >>>Good idea. Why didn't you try it before posting? > >I did, several different ways. I was going to try it some *more*... > >>In article <1991Jan24.061653.22785@tkou02.enet.dec.com> diamond@jit345.enet@tkou02.enet.dec.com (Norman Diamond) writes: >> I had the same problem a couple of weeks ago. (also on a sparc >> 1+ station). I was using a number of large arrays. by keeping >> the same array sizes and changing their type from double to >> float the problem disappear. So for some reason it seems it has >> something to do with big arrays. I am Norman Diamond. I wrote "Good idea..." and am glad to hear that you did try it before posting, but not so glad to see you mix up the attributions. >Aha! I'm using big arrays of doubles as well. A quick >:%s/double/float/g >produced a source, that when compiled, did *not* dump core. So, the second possibility that I mentioned, the stack limit or similar restriction, seems to be correct. If you have csh, try: % limit stacksize unlimited and/or % limit datasize unlimited I don't know what these commands would be under other shells. These don't actually give you unlimited space; they only raise the soft limits to match the hard limits that were set when your kernel was compiled. If these aren't enough, then see about recompiling your kernel with higher hard limits. (Also a superuser's shell should be able to raise its hard limits for the duration of its session.) >ld -o foo foo.o >produces a file that *does* dump core. Of course. You need the C run-time start-up routine. >Looks like a 4.0.3c compiler bug. Not yet. -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it.
asd@cbnewsj.att.com (Adam S. Denton) (01/26/91)
>>I've got a rather simple little C program that dumps core at >>the first "{" of main() (according to gdb and saber). >>Any hints as to what could be causing this? This can happen when you leave out a semicolon before main(): /* type definition section */ ... struct foo { int glorp; NERD *bar; } /* NOTE -- missing semicolon after `}' */ /* function definition section */ main() {...} Note that main() has now (inadvertantly) been declared to return a struct -- a Very Nasty Thing. The calling sequence may attempt to reserve space for the return value (a struct) but the startup code only expects to need space for an int which can cause trouble. Adam Denton asd@mtqua.att.com
gwyn@smoke.brl.mil (Doug Gwyn) (01/26/91)
In article <1991Jan24.234658.27689@lavaca.uh.edu> jet@karazm.math.uh.edu ("J. Eric Townsend") writes: >:%s/double/float/g >produced a source, that when compiled, did *not* dump core. There are several common errors made in use of floating types in C programs, for example invoking scanf() with the wrong format or passing the wrong type to a function. Since SPARC tends to be less tolerant of such errors than some other C environments, it is possible that your code has such a problem. Is "lint" happy with the code?
bill@platypus.uofs.edu (Bill Gunshannon) (01/29/91)
In article <14976@smoke.brl.mil>, gwyn@smoke.brl.mil (Doug Gwyn) writes: > to a function. Since SPARC tends to be less tolerant of such errors than > some other C environments, it is possible that your code has such a problem. Actually, I wouldn't lay the blame at the feet of SPARC. I have a MIPS that suffers the same problems. And I have seen it in the past on 68K systems with un-satisfactory memory management hardware. It is a rather wide spread problem. I have reached the point where the first thing I look for is an uninitialized string/char[] variable. > Is "lint" happy with the code? Unfortunately, passing "lint" doesn't guarantee that the hardware will do what the compiler (or language) thinks is proper. bill -- Bill Gunshannon | If this statement wasn't here, bill@platypus.uofs.edu | This space would be left intentionally blank
gwyn@smoke.brl.mil (Doug Gwyn) (01/30/91)
In article <246@platypus.uofs.edu> bill@platypus.uofs.edu (Bill Gunshannon) writes: >In article <14976@smoke.brl.mil>, gwyn@smoke.brl.mil (Doug Gwyn) writes: >> to a function. Since SPARC tends to be less tolerant of such errors than >> some other C environments, it is possible that your code has such a problem. >Actually, I wouldn't lay the blame at the feet of SPARC. I have a MIPS >that suffers the same problems. I wasn't "blaming" SPARC. The point is that RISC architectures differ sufficiently from VAX-like CICS architectures that bugs in C code may not turn up on VAX-like architectures but are likely to show up when porting to a RISC machine. For example, AT&T's Documenter's WorkBench Release 2.0 failed miserably on Pyramid processors, due to the programmer having made certain assumptions about how arguments were passed to functions (rather than using the varargs mechanism).
rob@ireta.cynic.wimsey.bc.ca (Rob Prior) (02/06/91)
abed@saturn.wustl.edu (Abed M. Hammoud) writes: > By the way..Its kind of weird that you misspled weird. ?^^^^^^^^? It's kind of weird that you misspelled misspelled. +------------ | rob@ireta.cynic.wimsey.bc.ca | Rob Prior, President, Still Animation Logo Design +------------------------------------------------------------
abed@saturn.wustl.edu (Abed M. Hammoud) (02/13/91)
In article <1991Jan23.232300.3698@lavaca.uh.edu> jet@karazm.math.uh.edu ("J. Eric Townsend") writes: > >I've got a rather simple little C program that dumps core at >the first "{" of main() (according to gdb and saber). > >Any hints as to what could be causing this? I'm about to run it >interpreted under saber-c, we'll see what that shows (and how long >it takes). > >-- >J. Eric Townsend Internet: jet@uh.edu Bitnet: jet@UHOU >Systems Mangler - UH Dept. of Mathematics - (713) 749-2120 >Motorola skates on Intel's head! I had the same problem, couple of month ago.... The problem seemed to be correlated with the sizes of the arrays I was using...after I reduced the sizes of the arrays the problem disappeared. By the way..Its kind of weird that you misspled weird. -------------------------------------------------------------- | Abed M. Hammoud abed@saturn.wustl.edu| | Washington University. office:(314)726-7547 | | Electronic Systems & Signals Research Laboratory. | | Dept. of Electrical/Biomedical Engineering. | | St.Louis Mo U.S.A | --------------------------------------------------------------
gwyn@smoke.brl.mil (Doug Gwyn) (02/14/91)
In article <1991Feb13.042942.20015@cec1.wustl.edu> abed@saturn.wustl.edu (Abed M. Hammoud) writes: >In article <1991Jan23.232300.3698@lavaca.uh.edu> jet@karazm.math.uh.edu ("J. Eric Townsend") writes: >>I've got a rather simple little C program that dumps core at >>the first "{" of main() (according to gdb and saber). Often symptoms like this is caused by a missing semicolon in a preceding structure declaration, often in a header. > By the way..Its kind of weird that you misspled weird. Misspled??
sarroyo@govtdev-11w9.shearson.com (Suzanne Arroyo) (02/20/91)
rob@ireta.cynic.wimsey.bc.ca writes: > abed@saturn.wustl.edu (Abed M. Hammoud) writes: >> By the way..Its kind of weird that you misspled weird. > ?^^^^^^^^? > It's kind of weird that you misspelled misspelled. Could you guys please take the spelling bee out of comp.lang.c? -- Suzanne Arroyo Wusses Are Fun People!!!! Internet: sarroyo@govtdev-11w9.shearson.com UUCP: ...!uunet!slcpi!sarroyo