Performer Memory problem

New Message Reply Date view Thread view Subject view Author view

From: Marco O. Lanzagorta (lnzgrt++at++volt.nrl.navy.mil)
Date: 05/23/2001 13:30:28


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
===========================================================================


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Wed May 23 2001 - 13:34:03 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.