FreeBSD 4.9 on i386, using Generic Mapping Tools, calloc

Howard G Bundock bundock at usgs.gov
Thu Feb 5 16:39:32 PST 2004


I think I'm on the right track with trying to increase the "dat seg size" 
with ulimit. But even as root, I cannot increase the size of the data 
segment above 262144 kbytes.

$ ulimit -a
cpu time               (seconds, -t)  unlimited
file size           (512-blocks, -f)  unlimited
data seg size           (kbytes, -d)  262144
stack size              (kbytes, -s)  65536
core file size      (512-blocks, -c)  unlimited
max memory size         (kbytes, -m)  unlimited
locked memory           (kbytes, -l)  unlimited
max user processes              (-u)  5547
open files                      (-n)  11095
virtual mem size        (kbytes, -v)  unlimited
sbsize                   (bytes, -b)  unlimited
$ ulimit -d  524288
$ulimit -a
cpu time               (seconds, -t)  unlimited
file size           (512-blocks, -f)  unlimited
data seg size           (kbytes, -d)  262144
stack size              (kbytes, -s)  65536
core file size      (512-blocks, -c)  unlimited
max memory size         (kbytes, -m)  unlimited
locked memory           (kbytes, -l)  unlimited
max user processes              (-u)  5547
open files                      (-n)  11095
virtual mem size        (kbytes, -v)  unlimited
sbsize                   (bytes, -b)  unlimited


Is some sysctl parameter sitting on this?


Previous question --------------

I am running GMT on a FreeBSD i386 with 2GB physical memory and 6GB total 
swap space. Queries to the system show that I am truly running with that 
amount of memory (sysctl hw.physmem and top to see swap space.) My GMT 
script bombs when the grdproject program tries to allocate less than 100MB 
of memory (23049601 x 4bytes)! Even if I am forgetting about something in 
this calculation, it is 20 times less memory than what exists on the 
system, NOT INCLUDING SWAP!

Is there a sysctl variable that I need to adjust, like a vm.??? or vfs.??? 
Is "calloc" the problem? I'm stumped. 


 
GMT code that is running when Fatal Error occurs -

This is a routine, gmt_support.c, that is used by many  of the GMT 
programs.


void *GMT_memory (void *prev_addr, size_t nelem, size_t size, char 
*progname)
{
        void *tmp;

        if (nelem == 0) return(VNULL); /* Take care of n = 0 */

        if (prev_addr) {
                if ((tmp = realloc ((void *) prev_addr, (size_t)(nelem * 
size))) == VNULL) {
                        fprintf (stderr, "GMT Fatal Error: %s could not 
reallocate more memory, n = %d\n", progname, nel
em);
                        exit (EXIT_FAILURE);
                }
        }
        else {

                if ((tmp = calloc ((size_t) nelem, (unsigned) size)) == VNULL) {
           fprintf (stderr, "GMT Fatal Error: %s could not allocate 
memory, n = %d, %d\n", progname, nelem, size);

                        exit (EXIT_FAILURE);
                }
        }
        return (tmp);
}


Fatal Error -

$cal_neva.script
grdimage: Allocates memory and read data file
grdimage: Allocates memory and read intensity file
grdimage: project grdfiles
grdimage: New grid size (nx,ny) 4801 by 4801
GMT Fatal Error: grdproject could not allocate memory, n = 23049601, 4

man page for calloc -

The calloc() function allocates space for number objects, each size bytes
     in length.  The result is identical to calling malloc() with an 
argument
     of ``number * size'', with the exception that the allocated memory is
     explicitly initialized to zero bytes.



Howard Bundock
U. S. Geological Survey
Earthquake Hazards Team
345 Middlefield Road, MS977
Menlo Park, CA  94025
phone (650) 329-5621
FAX (650) 329-4732
bundock at usgs.gov


More information about the freebsd-questions mailing list