Title: | Digital Fortran |
Notice: | Read notes 1.* for important information |
Moderator: | QUARK::LIONEL |
Created: | Thu Jun 01 1995 |
Last Modified: | Fri Jun 06 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 1333 |
Total number of notes: | 6734 |
Hi, I've a customer with Digital UNIX v4.0b (564), fortran v4.1. He has an application of about 60 files all compile fine. The final file includes all others as modules, and is about 5000 lines. He let the compile of that program go for three hours but it didn't complete. He has been able to compile it on other non DEC compilers. He can compile other larger programs, (6000ish lines), that don't include so many routines in seconds. He tryed cutting out some code, so the program that broke, didn't use so many routines, and got it to compile in twelve seconds. If he adds just one routine, takes about 40 seconds. If he adds one more takes about 3 minutes. I think his machine has about 300Mb and during his compile, the process went up to about 128M. I tryed it here on OSF v3.2 148, Fortran 90 v4.1-270. After >twelve hours I got:- f90 -i8 -free -g -O0 -c main.f f90: Severe: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error. *** Exit 1 Stop. Ran it again without using make and got:- RSS VSZ PID S STARTED TIME USER SYSTEM COMMAND 2.1M 89.6M 598 R + 12:21:58 2:53.65 2:04.96 0:48.69 /usr/lib/cmp 65M 90.0M 598 R + 12:21:58 2:57.84 2:06.47 0:51.37 /usr/lib/cmp 37M 96.3M 598 S + 12:21:58 4:48.22 2:33.11 2:15.11 /usr/lib/cmp 67M 97.5M 598 S + 12:21:58 5:11.32 2:38.64 2:32.68 /usr/lib/cmp 64M 99.2M 598 S + 12:21:58 5:46.71 2:46.35 3:00.36 /usr/lib/cmp The code plus files is a fair size, but it seems to depend a bit on how much is in there, so I don't know if I can cut it down a lot. Can I put the code somewhere for someone to have a go with? Thanks, Steve.
T.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
1275.1 | QUARK::LIONEL | Free advice is worth every cent | Tue Apr 29 1997 12:47 | 4 | |
Yes, if you provide us a pointer, we'll look at it. I think I've exchanged mail with your customer before - and each time I asked for sources. Steve | |||||
1275.2 | It's there ... | KERNEL::PULLEY | Come! while living waters flow | Wed Apr 30 1997 06:10 | 16 |
I've put a tar file in the ftp of alexei.uvo.dec.com. It's in the pub directory called vasp.4.2.tar. Having copied the file if you:- > tar -xf vasp.4.2.tar > cd vasp.4.2 > cp makefile.dec makefile > make you should see the problem. Last attempt to compile the main.f ended up with the porcess taking up >90% of the cpu in system. It had got to 136 meg of memory. That was from f90 -syntax_only -i8 -free -g0 -O0 -c main.f Thanks, Steve. | |||||
1275.3 | QUARK::LIONEL | Free advice is worth every cent | Wed Apr 30 1997 12:31 | 5 | |
Ok, thanks. The "internal error" is due to the compiler running out of memory. It may be that a "limit datasize unlimited" command will help. We'll look at this more closely. Steve | |||||
1275.4 | KERNEL::PULLEY | Come! while living waters flow | Tue May 20 1997 06:51 | 8 | |
Hi, I've not tryed that datasize unlimited here yet, but on his machine, though he had a limit, it was equal to the total memory on the machine. Thanks, Steve. | |||||
1275.5 | TLE::EKLUND | Always smiling on the inside! | Tue May 20 1997 15:25 | 6 | |
It's not hard to need more memory than you have physical memory. I have an entire disk devoted to swapping... Cheers! Dave Eklund | |||||
1275.6 | KERNEL::PULLEY | Come! while living waters flow | Wed Jun 04 1997 11:20 | 48 | |
I tryed the following and monitored it from another process:- > limit cputime unlimited filesize unlimited datasize 131072 kbytes stacksize 2048 kbytes coredumpsize unlimited memoryuse 117496 kbytes vmemoryuse 1048576 kbytes descriptors 4096 > limit datasize unlimited > limit cputime unlimited filesize unlimited datasize 1048576 kbytes stacksize 2048 kbytes coredumpsize unlimited memoryuse 117496 kbytes vmemoryuse 1048576 kbytes descriptors 4096 > f90 -i8 -free -g -O0 -c main.f When trying to monitor it the last time or two I got:- > ps -p4498 -o rssize,vsize,pid,state,start,cputime,usertime,systime,command RSS VSZ PID S STARTED TIME USER SYSTEM COMMAND 86M 124M 4498 U + 10:14:24 2:55.50 1:56.54 0:58.96 /usr/lib/cmplrs/fort90/decfort90 -platinum -integer_size 64 -fre > ps -p4498 -o rssize,vsize,pid,state,start,cputime,usertime,systime,command swap space below 10 percent free RSS VSZ PID S STARTED TIME USER SYSTEM COMMAND 87M 199M 4498 U + 10:14:24 14:32.59 5:51.65 8:40.94 /usr/lib/cmplrs/fort90/decfort90 -platinum -integer_size 64 -fre > ps -p4498 -o rssize,vsize,pid,state,start,cputime,usertime,systime,command swap space below 10 percent free Unable to obtain requested swap space tcsh: Cannot allocate space for bss. Killed The running process is also continually giving me swap messages. It's now been going about 20 hours. I'm not sure this is going to be a viable workaround. I'll check with the customer, but I don't think they can build their application. Have you any updates at all on your investigations. Thanks muchly, Steve. |