Re:

Re:

[Ron Michael Khu]

did u try allocating it the dynamic way??
via a call to malloc or in a similar fashion?

Ankit Jain wrote:

>hi
>
>well i am fixed up in a new problem
>
>i am using a array of size 1024*1024
>
>it gives segmentation fault
>
>it works with 512*512
>
>my menory size is 128 mb and 512 swap
>
>i have enough memory space and using gcc 3.2 v
>
>may be i need to increase the memory size
>
>how to do that?
>
>ankit
>
>________________________________________________________________________
>Yahoo! Messenger - Communicate instantly..."Ping" 
>your friends today! Download Messenger Now 
>http://uk.messenger.yahoo.com/download/index.html
>-
>To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>  
>

re: memory problem

[Ron Michael Khu]

what method did u use to allocate memory??

static:
 char array[1024*1024] ;

dynamic
 char *array = (char*)calloc(  1024*1024, sizeof(char) );

and why r u allocating such huge chunks for an array?



Ankit Jain wrote:

>hi
>
>well i am fixed up in a new problem
>
>i am using a array of size 1024*1024
>
>it gives segmentation fault
>
>it works with 512*512
>
>my menory size is 128 mb and 512 swap
>
>i have enough memory space and using gcc 3.2 v
>
>may be i need to increase the memory size
>
>how to do that?
>
>ankit
>
>________________________________________________________________________
>Yahoo! Messenger - Communicate instantly..."Ping" 
>your friends today! Download Messenger Now 
>http://uk.messenger.yahoo.com/download/index.html
>-
>To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>  
>

Re:

[zippo]

try 1024x768...

On Mon, 13 Sep 2004 19:20:58 +0800
Ron Michael Khu <ronkhu@ntsp.nec.co.jp> wrote:

> did u try allocating it the dynamic way??
> via a call to malloc or in a similar fashion?
> 
> Ankit Jain wrote:
> 
> >hi
> >
> >well i am fixed up in a new problem
> >
> >i am using a array of size 1024*1024
> >
> >it gives segmentation fault
> >
> >it works with 512*512
> >
> >my menory size is 128 mb and 512 swap
> >
> >i have enough memory space and using gcc 3.2 v
> >
> >may be i need to increase the memory size
> >
> >how to do that?
> >
> >ankit
> >
> >________________________________________________________________________
> >Yahoo! Messenger - Communicate instantly..."Ping" 
> >your friends today! Download Messenger Now 
> >http://uk.messenger.yahoo.com/download/index.html
> >-
> >To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> >
> >  
> >
> 

Re:

[Ron Michael Khu]

here 's an example of static and dynamic allocation...
(my prev example was only about single dimensional arrays...)

a 2dimensional array of  4450 x 4450
(change the dimension to 1450 x 1450 if  u find the
first size to be too big)

TEST.C
#include <stdio.h>
int main()
{
  double a[4450][4450];

  a[4449][0] = 999;
  printf( "%lf\n", a[4449][0] );
  return 1;
}


TEST2.c
#include <stdio.h>
int main()
{
  double **a;
  int i;

  a = (double**) calloc( 4450, sizeof(double*) );
  for ( i=0; i <1450; i++ )
  {
    a[i] = (double*) calloc( 4450, sizeof(double) );
  }

  a[4449][0]=999;
  printf( "%lf\n", a[4449][0] );
  return 1;
}




Ankit Jain wrote:

>hi
>
>well i am fixed up in a new problem
>
>i am using a array of size 1024*1024
>
>it gives segmentation fault
>
>it works with 512*512
>
>my menory size is 128 mb and 512 swap
>
>i have enough memory space and using gcc 3.2 v
>
>may be i need to increase the memory size
>
>how to do that?
>
>ankit
>
>________________________________________________________________________
>Yahoo! Messenger - Communicate instantly..."Ping" 
>your friends today! Download Messenger Now 
>http://uk.messenger.yahoo.com/download/index.html
>-
>To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>  
>

Re: memory problem

[Tim Prince]

Deepan wrote:
> Hi,
>   My fortran code compiles fine if i use arrays of size less that 4 GB.
> When i increase the array size to more that 4 GB, the compilation fails
> with the following error. I am running this on 32GB RAM machine.
> 
> $  g77 -O3 MAIN.o write_output.o read_population.o write_population.o
> collide.o initial_conditions.o stream.o communicate.o -o lbm.x
> -I/usr/local/include -L/usr/local/lib -lmpich -lpthread -lrt
> MAIN.o(.text+0x7a): In function `MAIN__':
> : relocation truncated to fit: R_X86_64_PC32 directions_
> read_population.o(.text+0x252): In function `read_population__':

> I guess there must me some option to g77, that will let the program
> use more than 4 GB of memory. 
x86_64 binutils don't support larger static objects. You should have no 
trouble using more memory, just not in a single static object. As g77 
doesn't support allocatable arrays nor Cray pointers, you would have to 
change compilers (e.g. to gfortran) to use either of those methods. 
Remember that g77 support had dwindled before x86_64 was released.

memory problem

[Deepan]

Hi,
  My fortran code compiles fine if i use arrays of size less that 4 GB.
When i increase the array size to more that 4 GB, the compilation fails
with the following error. I am running this on 32GB RAM machine.

$  g77 -O3 MAIN.o write_output.o read_population.o write_population.o
collide.o initial_conditions.o stream.o communicate.o -o lbm.x
-I/usr/local/include -L/usr/local/lib -lmpich -lpthread -lrt
MAIN.o(.text+0x7a): In function `MAIN__':
: relocation truncated to fit: R_X86_64_PC32 directions_
read_population.o(.text+0x252): In function `read_population__':
: relocation truncated to fit: R_X86_64_PC32 directions_
read_population.o(.text+0x273): In function `read_population__':
: relocation truncated to fit: R_X86_64_PC32 directions_
read_population.o(.text+0x294): In function `read_population__':
: relocation truncated to fit: R_X86_64_PC32 directions_
read_population.o(.text+0x2b5): In function `read_population__':
: relocation truncated to fit: R_X86_64_PC32 directions_
read_population.o(.text+0x2d6): In function `read_population__':
: relocation truncated to fit: R_X86_64_PC32 directions_
read_population.o(.text+0x2f7): In function `read_population__':
: relocation truncated to fit: R_X86_64_PC32 directions_
read_population.o(.text+0x318): In function `read_population__':
: relocation truncated to fit: R_X86_64_PC32 directions_
read_population.o(.text+0x339): In function `read_population__':
: relocation truncated to fit: R_X86_64_PC32 directions_
read_population.o(.text+0x35a): In function `read_population__':
: relocation truncated to fit: R_X86_64_PC32 directions_
read_population.o(.text+0x37b): In function `read_population__':
: additional relocation overflows omitted from the output
collect2: ld returned 1 exit status





I guess there must me some option to g77, that will let the program
use more than 4 GB of memory. 
If someone knows how to resolve this issue, please tell me,
Thanks
Deepan Chakravarthy N 
www.codeshepherd.com 

Re: memory problem

[Eljay Love-Jensen]

Hi xuejun gu,

Are you allocating the extremely large array on the heap, or on the stack?

If you are allocating the array on the stack, make sure you have enough 
stack space for your large array.  For Red Hat Linux, I believe that's via 
the ulimit command, use "ulimit -a" to see your current settings.

HTH,
--Eljay

RE: memory problem

[lrtaylor]

If you're allocating this array on the stack, then you're just running
into stack size problems.  The maximum stack size is limited by the OS,
and if your stack frame ends up larger than that, your program will
segfault like this.  Basically, you just need to increase your maximum
stack size, or allocate the array dynamically, which would probably be
preferable.

Run 'ulimit -s' to see what your stack size limit is set to (probably
something like 8 MB).  You can also use that command to change it
temporarily.

Thanks,
Lyle


-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
Behalf Of xuejun gu
Sent: Thursday, January 13, 2005 10:31 AM
To: gcc-help@gcc.gnu.org
Subject: memory problem

HI,

The machine I used have 6GB physical memory. However, when I run the c++

program I found the biggest array I can assign like

double A[10000][100]

I complied as:

$ gcc test1.cpp -o test1
$ ./test1'

When I increased the array size to double A[10000][120], it gave the 
message:
'Segmentation fault'


Is there any way to solve the problem?

Thanks!


here is the detail information of my machine:

1) cat /proc/meminfo

        total:    used:    free:  shared: buffers:  cached:
Mem:  6349705216 1669341184 4680364032        0 161710080 1048535040
Swap: 6547218432        0 6547218432
MemTotal:      6200884 kB
MemFree:       4570668 kB
MemShared:           0 kB
Buffers:        157920 kB
Cached:        1023960 kB
SwapCached:          0 kB
Active:         970660 kB
Inactive:       425152 kB
HighTotal:     5373376 kB
HighFree:      4126628 kB
LowTotal:       827508 kB
LowFree:        444040 kB
SwapTotal:     6393768 kB
SwapFree:      6393768 kB

2) cat /etc/redhat-release

Red Hat Linux release 9 (Shrike)

3) gcc  -v

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

4) cat /proc/mtrr
reg00: base=0x100000000 (4096MB), size=2048MB: write-back, count=1
reg01: base=0x180000000 (6144MB), size=1024MB: write-back, count=1
reg02: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg03: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg04: base=0xbff80000 (3071MB), size= 512KB: uncachable, count=1
reg05: base=0xbff80000 (3071MB), size= 512KB: uncachable, count=1
reg06: base=0xc8000000 (3200MB), size= 128MB: write-combining,
count=1
reg07: base=0xe0000000 (3584MB), size= 256MB: write-combining,
count=1

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!

http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

memory problem

[xuejun gu]

HI,

The machine I used have 6GB physical memory. However, when I run the c++ 
program I found the biggest array I can assign like

double A[10000][100]

I complied as:

$ gcc test1.cpp -o test1
$ ./test1'

When I increased the array size to double A[10000][120], it gave the 
message:
'Segmentation fault'


Is there any way to solve the problem?

Thanks!


here is the detail information of my machine:

1) cat /proc/meminfo

        total:    used:    free:  shared: buffers:  cached:
Mem:  6349705216 1669341184 4680364032        0 161710080 1048535040
Swap: 6547218432        0 6547218432
MemTotal:      6200884 kB
MemFree:       4570668 kB
MemShared:           0 kB
Buffers:        157920 kB
Cached:        1023960 kB
SwapCached:          0 kB
Active:         970660 kB
Inactive:       425152 kB
HighTotal:     5373376 kB
HighFree:      4126628 kB
LowTotal:       827508 kB
LowFree:        444040 kB
SwapTotal:     6393768 kB
SwapFree:      6393768 kB

2) cat /etc/redhat-release

Red Hat Linux release 9 (Shrike)

3) gcc  -v

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

4) cat /proc/mtrr
reg00: base=0x100000000 (4096MB), size=2048MB: write-back, count=1
reg01: base=0x180000000 (6144MB), size=1024MB: write-back, count=1
reg02: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg03: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg04: base=0xbff80000 (3071MB), size= 512KB: uncachable, count=1
reg05: base=0xbff80000 (3071MB), size= 512KB: uncachable, count=1
reg06: base=0xc8000000 (3200MB), size= 128MB: write-combining,
count=1
reg07: base=0xe0000000 (3584MB), size= 256MB: write-combining,
count=1

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/