by Carl Windso » Sat, 10 Oct 1998 04:00:00
But is shouldn't limit how many swap partitions you have, just make moreQuote:> 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.
Carl
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
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.
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
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.