Memory allocation problem in Solaris 5.8

The address 0x345fa0 in disassembled code like this

0x000e9e1c: SetInstrument+0x00d4: call operator new [PLT] ! 0x345fa0

indicates the address of operator new, not the value returned by operator new.

The value returned by operator new is in register %o0

If the code crashes on one system but not on another, the most likely cause is invalid code that by accident does not cause a problem on one system but does on the other.

For example, suppose you store a value through an uninitialized pointer, or one that points to an object that no longer exists. The store modifies some location in memory. By chance, that location might still be in the program's address space, but not used. No harm done. But on another system, the location might not be in the address space, or might be in use as a variable, as part of the stack frame, or as bookkeeping information for the heap. At some point probably far removed from this error, the program crashes.

Run your program under dbx will all Run-Time Checking enabled:

% dbx myprog

...

(dbx) check=all

(dbx) run

RTC will find many common types of programming errors. You can read more about it in the dbx manual.

clamage45 at 2007-7-7 12:00:53 >

I did realtime checking .. I enabled check -access and ran the code.

Just before crashing, it is giving out of memory exceptions.. And that too because of calls to malloc with blocksize 4GB, which I dont have in my code..See the output from DBX below..

Out of memory (oom):

Attempting to allocate a block of size 4294967096 bytes

stopped in operator new at 0xecd103d8

0xecd103d8: operator new+0x0024:callmalloc [PLT]! 0xecd5dc68

(dbx) cont

Out of memory (oom):

Attempting to allocate a block of size 4294967096 bytes

stopped in operator new at 0xecd1040c

0xecd1040c: operator new+0x0058:callmalloc [PLT]! 0xecd5dc68

(dbx) cont

Write to unallocated (wua):

Attempting to write 4 bytes through NULL pointer

stopped in FC_DStaticSpreadCalculator::SetInstrument at 0x000e9e44

0x000e9e44: SetInstrument+0x00fc:ba,a0x00571e50! 0x571e50

And the regs command is showing the same output as I've pasted in my initial post.. Now, I assume the trouble is either with 1) memory running out

2) Some erroneous values creeping into some registers. , consequently resulting in the call 'malloc' to request 4GB memory space..

Could anyone tell which register(s) hold the information about how much memory is to be issued by the call to malloc / new ? ..

In the c++ code at this point, I'm calling a function 'SetInstrument', which is a member of one class having two double values and one pointer to a structure having 5 doubles...The array in the callee program is of size 16000

.And it is initialized by the call to new before passing to the SetInstrument procedure.. So, the total size of the memory for this array thats being used is 16000* 8 * 5 = 640 KB , which is nowhere near the 4GB memory requested..

In Solaris( SunOs 5.8 ) C++, is there any limit to the heap memory that a process can own ?

showmemleaks is also showing that there is memory leak ..

Possible leaks report (possible leaks:3029 total size:2556685 bytes)

TotalNum of LeakedAllocation call stack

SizeBlocks Block

Address

========== ====== =========== =======================================

2043200600-operator new < 0xd57e4

1840007-operator new <

8747691-operator new < _vector_new_

43296984-operator new < 0x14abb4

Error limit reached. Disabling RTC until next run.

Is there anything wrong in Solaris over passing a base pointer ( which is initialized using a call to 'new' )into another class so that the base value of this address can be stored in that variable ?

And, what does 'PLT' mean in that call to malloc ?

Ajith

Message was edited by:

ajith_prasad

ajith_prasad at 2007-7-7 12:00:53 >