From: Marcin Romaszewicz (marcin++at++asmodean.engr.sgi.com)
Date: 05/23/2001 13:43:18
Your example program is allocating about 800MB of memory. Performer
allocates its memory from a shared arena which consumes a fair bit of
address space itself. What may work is for you to make a large arena and
allocate your data with pfMalloc vs malloc. With a 32bit application, you
have about 2GB of user space addressable memory which has to hold the
arena, all dso's and their memory, the stack, the heap, etc. It just may
not be possible to keep 800MB of data in memory, so you may have to page
data or move to 64 bit for good.
-- Marcin
On Wed, 23 May 2001, Marco O. Lanzagorta wrote:
>
> Hello,
>
> I have the following memory allocation problem that I do not understand. I
> am doing some terrain visualization, and when I increase the size of my
> terrain, the performer application reports a segmentation fault. The
> problem gets reduced to the following very simple example:
>
> Let us suppose we have the following very simple c code which only
> allocates memory for an array and does not make any single performer
> call:
>
> /***/
>
> #include <stdio.h>
>
> main()
> {
> int num = 14400;
> float *value;
>
> value = (float *) malloc (num*num* sizeof(float));
>
> if(value == NULL) perror("ERROR ALLOCATING MEMORY\n");
> else printf("NO ERROR ALLOCATING MEMORY\n");
> }
>
> /****/
>
> If I compile it just like "cc test1 test.c" I have no problems and I
> am able to allocate the memory in the array.
>
> But if I compile linking it to the performer libraries:
>
> cc -c test.c
> cc -I./ -I/usr/include -I/usr/include/X11 -n32 -mips4 -c test.c
> cc -o test2 -n32 -mips4 -L./ -L/usr/lib32 -L/usr/lib32/libpfdb
> -L/afs/depot.nrl.navy.mil/++at++sys/lib test.o -no_unresolved -lpfdu_ogl -lpfui
> -lpfutil_ogl -lpf_ogl -lGLU -lGL -lXext -lXmu -lX11 -limage -lm -lC
>
> It can not allocate the memory for the array!
>
> Any idea of what is going on? Does this means that performer allocates
> stuff in memory even if it is never declared nor used anywhere? is there a
> way to control this? is this an efficient memory management system?
>
> A quick fix has been to recompile using 64 bits instead of 32, but I would
> like to understand what is Performer doing to the memory.
>
> Thanks in advance,
>
> Marco
>
> ===========================================================================
> Dr. Marco Lanzagorta email: lnzgrt++at++volt.nrl.navy.mil
> Code 5594 phone: (202) 767-8427
> Visualization Laboratory fax : (202) 404-7402
> Naval Research Laboratory
> 4555 Overlook Ave, S.W.
> Washington, DC 20375 http://ohm.nrl.navy.mil/staff/lnzgrt
> ===========================================================================
>
>
>
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Open Development Project: http://oss.sgi.com/projects/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>
This archive was generated by hypermail 2b29 : Wed May 23 2001 - 13:43:21 PDT