home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / gnu / gcc / help / 2772 < prev    next >
Encoding:
Text File  |  1992-12-21  |  1.6 KB  |  46 lines
  1. Newsgroups: gnu.gcc.help
  2. Path: sparky!uunet!clsi!mitch
  3. From: mitch@clsi.COM (Mitchell N. Perilstein)
  4. Subject: Need advice debugging 2.1
  5. Message-ID: <MITCH.92Dec18160719@pollux.clsi>
  6. Sender: usenet@clsi.COM
  7. Organization: CAD Language Systems, Inc.
  8. Distribution: gnu
  9. Date: 18 Dec 92 16:07:19
  10. Lines: 34
  11.  
  12. I'm giving all the following information not as a bug report but as a
  13. request in hopes that someone can suggest a debugging technique that
  14. will result in understanding the cause of the crash.  Once understood, I
  15. will submit a report.
  16.  
  17. I'm trying to debug gcc2.1 on a Sun 4/110 running SunOS 4.1.2. The error is
  18.  
  19.   gcc: Internal compiler error: program cc1 got fatal signal 4
  20.  
  21. while compiling an 11meg C file.  (It's automatically generated C for
  22. simulation which needs to be that big. Anyway, it's a good torture test
  23. for gcc.)
  24.  
  25. cc1 runs for a long time. Watching the sizes of the /tmp/cca files, the
  26. .i appears very quickly, then the .s grows steadily in size, then stops
  27. growing.  Things sit for about fifteen minutes in this state, with cc1
  28. in `D' state and and gcc in `IW'. Finally, the message appears and it
  29. leaves a 45 meg core. gdb4.6 is confused and prints only one stack frame
  30. when examining the core.
  31.  
  32.   (gdb) i st
  33.   #0  0xf76e3e54 in bzero ()
  34.  
  35. It works the same way when run under gdb4.6 by attach'ing to cc1.
  36. Resourcewise, there is 50m of swap free at the lowest point, and 80m
  37. /tmp.
  38.  
  39. If anyone thinks upgrading to more recent gcc would change anything, I
  40. will do so.
  41.  
  42. TIA,
  43. ---
  44.  Mitchell N. Perilstein   CAD Language Systems, Inc.   410-992-5700 x225 
  45.  Member, League for Programming Freedom.  Mail lpf@uunet.uu.net for info.
  46.