[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::fortran

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

1275.0. "DFA410 f90, internal error, long time??" by KERNEL::PULLEY (Come! while living waters flow) Tue Apr 29 1997 11:17

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.RTitleUserPersonal
Name
DateLines
1275.1QUARK::LIONELFree advice is worth every centTue Apr 29 1997 12:474
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.2It's there ...KERNEL::PULLEYCome! while living waters flowWed Apr 30 1997 06:1016
    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.3QUARK::LIONELFree advice is worth every centWed Apr 30 1997 12:315
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.4KERNEL::PULLEYCome! while living waters flowTue May 20 1997 06:518
    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.5TLE::EKLUNDAlways smiling on the inside!Tue May 20 1997 15:256
    	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.6KERNEL::PULLEYCome! while living waters flowWed Jun 04 1997 11:2048
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.