Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!sgiblab!swrinde!elroy.jpl.nasa.gov!usc!venice!gumby.dsd.trw.com!eel.dsd.trw.com!gottloeb From: gottloeb@eel.dsd.trw.com (Jeffrey R. Gottloeb) Subject: Re: The Compile from HELL! Message-ID: <1992Oct9.005309.13915@gumby.dsd.trw.com> Keywords: 386BSD GCC compiler Xview3 Sender: news@gumby.dsd.trw.com Organization: TRW, INC. References: <1992Oct6.074223.615@coplex.com> Date: Fri, 9 Oct 1992 00:53:09 GMT Lines: 50 In article <1992Oct6.074223.615@coplex.com> chuck@coplex.com (Chuck Sites) writes: > > > Recently when trying to port XView3 to 386BSD and XFree, I ran into a >brickwall of a performance problem. There are some files which start >compiling but they just don't stop. One file, attr_char.c, I let compile >over the weekend only to come back and find the system apparently frozen. >Frozen may be a misnomer though. While trying to telnet into the system >during the early stages of the compile, I can access the system, but slowly >the perfomace degrades to the point of printing 1 line/min for an ls, and it >gets worse to the point of not responding at all. I assumed it was swapping, >but the severity that other process are excluded from thier share of the >clock makes me think this is a kernel problem. > > Well in fairness, this may not be a kernel problem alone. GCC maybe >partially to blame. On large structure arrays I've seen it go 'all >consuming' before on OS2 and SYSV, but both resulted in an out of >memory error at the user prompt after several hours. Neither had the >multitasking performace degradation like I got with 386bsd. (I was >trying to port the fax portion of the TIFF package on uunet fyi.) I have seen this problem also. On my system, I have 16MB of swap space and set limit datasize 14m. CC aborts with virtual memory exhausted while processing g3states.h. This is a hugh file that seems to only have data initialization code in it. I have noticed using the patched version of ps that the vsz attribute of the compile process continues to climb to the 14MB value causing the abort. I am not sure if cc is working correctly and trying to keep the arrays in memory as it is compiled or not. Jeff Gottloeb gottloeb@gumby.dsd.trw.com > > So, my question is: has anybody seen this type of problem and is this >symtom fixed by the latest beta patches? Second, if the beta patches do >fix this problem, could someone direct me to a site that has the collected >binaries of the beta patchs. > > >Thanks, >Chuck Sites >chuck@coplex.com (502)-9688495 >