toivanen@tukki.jyu.fi (Jari Toivanen) (10/21/90)
I am doing calculations in HP 9000/835 and in those calculations I need a lot memory (sometimes more than 30 MB). I am having problems with fortran (f77). If I compile program, which have bigger data segment than 2 MB, normally and run it, I get segmentation fault in fortran's initialization code. Everything works right if I use -K option with f77 so that variables are allocated statically. Problem with -K option is that executables are at least as big as data segment and therefore they take a lot of disk space and they start very slowly. Without -K option variables are allocated dynamically from the stack. I am quite sure that stack size limit is more than 2 MB, so that the problem shouldn't be stack size limit. I would like to know what is causing this 2 MB limit and how I can make big programs work without -K option or statical variable allocation. -- Jari Toivanen (toivanen@jyu.fi) Memories are lost in time University of Jyvaskyla, Finland like tears in rain.
mike@hpfcso.HP.COM (Mike McNelly) (10/23/90)
> I am doing calculations in HP 9000/835 and in those calculations > I need a lot memory (sometimes more than 30 MB). I am having > problems with fortran (f77). If I compile program, which have bigger > data segment than 2 MB, normally and run it, I get segmentation > fault in fortran's initialization code. Everything works right if > I use -K option with f77 so that variables are allocated statically. > Problem with -K option is that executables are at least as big as > data segment and therefore they take a lot of disk space and they > start very slowly. > > Without -K option variables are allocated dynamically from the stack. > I am quite sure that stack size limit is more than 2 MB, so that the > problem shouldn't be stack size limit. I would like to know what is > causing this 2 MB limit and how I can make big programs work without > -K option or statical variable allocation. > -- > Jari Toivanen (toivanen@jyu.fi) Memories are lost in time > University of Jyvaskyla, Finland like tears in rain. I suspect that you are exceeding a default kernel parameter that is unrelated to FORTRAN per se. Check with your system administrator to see what maxssize is set to. On series 300 it is set to 2 MB by default but your system administrator can reconfigure it for much larger values. I'm not sufficiently familiar with the Series 800 to tell you how exactly but the procedure is documented in the Series 800 System Administration manuals for sure. maxssize is max user stack size. Mike McNelly mike@fc.hp.com
cary@hpclcac.HP.COM (Cary Coutant) (10/25/90)
> Without -K option variables are allocated dynamically from the stack. > I am quite sure that stack size limit is more than 2 MB, so that the > problem shouldn't be stack size limit. I would like to know what is > causing this 2 MB limit and how I can make big programs work without > -K option or statical variable allocation. The default stack size limit is probably around 4 MB -- I'm not sure exactly (it's 8 MB on my 800 here at work). You can check by running adb on your kernel: echo "maxssiz?D" | adb /hpux The number will be in 2K pages, so 4096 pages is 8 MB. When you use -K with the Fortran compiler, locals are allocated statically, but they are allocated in BSS, so your .o and a.out files should not be any larger. If you're running on an old version of HP-UX, it's possible that an older version of Fortran allocated locals in the initialized data area, but it doesn't on my 7.0 system. You can easily check to see if this is the case -- try compiling the following file with "f77 -c -K big.f": subroutine big real x(4000000) x(1) = 0 x(4000000) = 1 return end Then run "nm big.o". Here's the output that I get: Symbols from big.o: Name Value Scope Type Subspace $global$ | |undef |data | big | 0|extern|entry |$CODE$ M$2$big | 16000000|undef |common |$DATA$ S$2$big | 32|static|data |$LIT$ The third symbol indicates that the local array is a "common" symbol, which the linker will allocate from BSS. This won't make your executable big. Cary Coutant, HP Language Lab, Cupertino, CA