g77 / large array : seg faults

g77 / large array : seg faults

Post by Carl Windso » Sat, 10 Oct 1998 04:00:00



Quote:> My solution is to create a swap file. The larger the swap file,
> the larger the array size. However, my Slackware 2.0.30 limits
> my swap file to 130 Mbytes.

But is shouldn't limit how many swap partitions you have, just make more
than one (if you really have to).

Carl

 
 
 

g77 / large array : seg faults

Post by Roger Hill-Cottingha » Wed, 14 Oct 1998 04:00:00



> I'm running Slackware 3.4 kernel 2.0.30, and I use g77/gcc2.8.1 to run
> a large fortran program; when I use an 4 dim array (30,31,30,31) in
> double precision, I get the "usual" segmentation fault. I try to correct
> this setting as "root" higher limits for the stack size:

>     ulimit -s 33000

> but this doesn't seem to work. I also tried to edit
> /usr/src/include/linux/sched.h to show an _STK_LIM of (32*1024*1024)
> but it seems that I would have to recompile the kernel, in order
> for this to work.

> Any advice on how can I overcome this limit ? Calculating in double
> precision, the array should take 30*31*30*31*8 = 6,919,200 bytes
> and my stack size is set to 8 Mb !
> (well, it might go over 8 Mb with all other variables)
> Yet, I would expect it to work for a stack of 32 MB

> Any help much appreciated

> Larry Tobos

Run size on your executable: it will report the required resources to
run:

tesla:~ $ size ./a.out
text    data    bss     dec     hex     filename
1709546 64408   287582920       289356874       113f3c4a        ./a.out

Then run free, to see what you have got:

tesla:~ $ free
             total       used       free     shared    buffers    
cached
Mem:        256160     228884      27276      47760     141368    
34300
-/+ buffers:            53216     202944
Swap:       706584       1284     705300

In this case, a.out requires about 289MB to run: and there is 705MB swap
and 27MB ram free, and 202MB ram that might be freed up from buffers. So
a.out will run. The kernel does some simple checking of process size and
free space, and if there is not enough, it will seg. fault the job. See
/usr/src/linux/mm/mmap.c

The standard kernel allows up to 8 swapfiles/partitions, of 128MB (less
a few bytes), or 1GB of swap. If you need more, and larger processes,
use 64-bit hardware, e.g. Alpha. :)

Regards,
Roger.

 
 
 

g77 / large array : seg faults

Post by Brian McIlwra » Thu, 15 Oct 1998 04:00:00


: In this case, a.out requires about 289MB to run: and there is 705MB swap
: and 27MB ram free, and 202MB ram that might be freed up from buffers. So
: a.out will run. The kernel does some simple checking of process size and
: free space, and if there is not enough, it will seg. fault the job. See
: /usr/src/linux/mm/mmap.c

I did some debugging on a large Fortran code which worked on some Linux
boxes but not others a few months back. In that case I traced the segment
fault signal to be when the C initialisation code (in main.o) tried to
store argc and argv in xargc and xargv for Fortran to use. From the link
manp xargc and xargv had been assigned virtual addresses at the end of the
image.

I did not persue this much further but it looked to me then that the kernel
was behaving incorrectly in partially loading and then trying run an image
for which there was insufficient address space.

 
 
 

1. g77 and large arrays and segmentation faults

This is a followup to my previous inquiry about segmentation faults with
large arrays and f2c/gcc. I obtained g77 and it does compile my program with
large arrays and the executable usually runs without segmentation faults.
A couple of times (when other large programs were running) it loaded and
immediately gave seg-fault. OK, now for the weirdness. When I ran top after
this happened, it cleared the screen and then the prompt reappeared.
Additionally, the echo was turned off. Switching to a different xterm or
virtual terminal brings the echo back, but top then gives the same result.
Rebooting Linux does not correct the problem and the top binary is not
corrupted. Does anyone know what the problem might be?

******************************************************************************
 Jeff Forbes                                    What we have to learn to do    
 Department of Chemistry and Biochemistry         we learn by doing.    
 University of Maryland - College Park                  -Aristotle (c. 325 BC)  
 College Park, MD 20742-2021
******************************************************************************

2. firewall

3. Seg.faults on PPRO kernel /w g77 bins

4. Wabi and MS office

5. g77 large arrays core dump under Linux

6. final test

7. Large programs + 1.3.xx --> seg faults

8. Should mount autodetect vfat file systems (Was: Long filenames on DOS partitions)

9. segmentation faults with large static arrays using gcc under RedHat 5.1

10. Segmentation Faults when using very large arrays in C++

11. Compiling *** VIM 5.3 *** Segmentation Fault..what is Seg-Fault..MEM Bounds?

12. g77 application - segmentation fault

13. G77 and F2C problems with large fortran code.