From: mikea@ruby.aruba.UUCP (Mike Arsenault)
Subject: overloaded 'new' called twice ??
Date: Wed, 7 Oct 1992 12:05:04 GMT
Organization: Project Zed

I'm using the HP-UX native C++ compiler


In Short:
	
	I'm overloading new globally to try to do some memory leak 
	investigations with our library. Does it make sense for the 
	overloaded new operator to be called twice for a single call
	to new? The first time corresponds to the actual call intended
	and it APPEARS that the second call is coming from some internal
	allocation ???
	
In Detail:


enum oElementType {oExact,
   		oOpposite,
   		oCalculated,
   		oUnspecified};
   

///////////////////////////////////////////////////////////////////
// This is a class that represents a single element in a table that
// is going to be dynamically allocated
///////////////////////////////////////////////////////////////////

struct oTableElementStr {
   oTableElementStr() : num(0), type(oUnspecified) {}
   
   float num;
   oElementType type;
};


//----------------------------------------------------------------
class oUOMCategory
{
public:

	...	// other stuff

private:

   oTableElementStr ** tableData;
   long tableSize;
   
   void buildTable(long size);
   void destroyTable();

};



typedef oTableElementStr * tPtr;
   
///////////////////////////////////////////////////////////////////
// I found I had to have this typedef in order to allocate the
// initial array of pointers, each of which will point to an array
// of oTableElementStr's (see buildTable below)
// 
// tableData -+
// 			  |       0    1    2         size
// 			  V
// 			 +-+   +----+----+----+	     +----+
// 		0	 | |-->|    |    |    | .... |    |
// 			 +-+   +----+----+----+	     +----+
// 		1	 | |-->|    |    |    | .... |    |
// 			 +-+   +----+----+----+	     +----+
// 		.
// 		.
// 		.
// 			 +-+   +----+----+----+      +----+
//             size      | |-->|    |    |    | .... |    |
// 			 +-+   +----+----+----+	     +----+
// 
///////////////////////////////////////////////////////////////////

//-----------------------------------------------------------------
void oUOMCategory :: buildTable(INTMAG size)
{
   int x;
   
   destroyTable();				// in case table already exists
   
   if (size) {     				// account for size == 0
		tableData = new tPtr[size];	// allocates array of pointers
		
		for (x = 0; x < size; x++)
			tableData[x] = new oTableElementStr[size];
		
		tableSize = size;
   }
}

//-----------------------------------------------------------------
void oUOMCategory :: destroyTable()
{
   
   if (tableSize) {
      
      for (int x = 0; x < tableSize; x++)
			delete tableData[x];
      
      delete tableData;
      tableData = 0;
   }
   
}
	
The call to new that I was tracing is the one inside the for
loop in oUOMCategory :: buildTable(INTMAG size). The corresponding
size argument to the new operator is 48 which corresponds to 6
elements each of size 8. When I debug the executable under 
HP Softbench, I set a breakpoint in the overloaded new, at which 
point I dump the stack and it looks like this, which I understand.

 0 ::operator new (size = 48)    [memmgmt.cc: 62]
 1 __nw__FUi + 0x00000008 (hp-ux export stub)
 2 __vec_new@libC + 0x00000048 (0x18, 0x68fad009, 0, 0)
 3 __vec_new@libC + 0x00000008 (hp-ux export stub)
 4 oUOMCategory::buildTable (size = 6)    [uomctg.cc: 512]
 5 oUOM::initTable ()    [uom.cc: 837]
 6 oUOM::load (aFileName = 0x29000001)    [uom.cc: 508]
 7 oUOM::loadFrom (aFileName = 0x29000001)    [uom.cc: 534]
 8 oUOM::loadFrom ()    [uom.cc: 526]
 9 ::initKernel ()    [init.cc: 136]
10 ::main (argc = 687865857, argv = 0x29000001)    [main.cc: 68]

When I try to step through the 'new', as I step off the last brace 
(expecting to return back to oUOMCategory::buildTable), the program
counter is placed back at the top of new again, this time with a size 
of 2600. The stack at this point is listed below. Where is this call
coming from and what are the supposed functions in steps 1-11 below??
What is 2600 ?? What is going on??? argh! 

 0 ::operator new (size = 2600)    [memmgmt.cc: 62]
 1 __nw__FUi + 0x00000008 (hp-ux export stub)
 2 __ct__11__Node_PoolFv@libC + 0x0000001c (0, 0x6dfa50ec, ...
 3 __ct__11__Node_PoolFv@libC + 0x00000008 (hp-ux export stub)
 4 __ct__19__pnd_internal_nodeFv@ + 0x00000028 (0x2e203, 0x68fae5e8, ...
 5 __ct__19__pnd_internal_nodeFv@ + 0x00000008 (hp-ux export stub)
 6 insert__5__pndFPvi@libC + 0x0000010c (0x40112e30, 0x303131, ...
 7 insert__5__pndFPvi@libC + 0x00000008 (hp-ux export stub)
 8 __insert_new_array__FPvi@libC + 0x0000004c (0x40112db8, 0x6, ...
 9 __insert_new_array__FPvi@libC + 0x00000008 (hp-ux export stub)
10 __vec_new@libC + 0x0000006c (0x18, 0x68fad009, 0, 0)
11 __vec_new@libC + 0x00000008 (hp-ux export stub)
12 oUOMCategory::buildTable (size = 6)    [uomctg.cc: 512]
13 oUOM::initTable ()    [uom.cc: 837]
14 oUOM::load (aFileName = 0x29000001)    [uom.cc: 508]
15 oUOM::loadFrom (aFileName = 0x29000001)    [uom.cc: 534]
16 oUOM::loadFrom ()    [uom.cc: 526]
17 ::initKernel ()    [init.cc: 136]
18 ::main (argc = 687865857, argv = 0x29000001)    [main.cc: 68]

Any help would be much appreciated. Either post an answer or e-mail
me and I'll post a response if there is enough interest.

Thanks in advance for any input.




-- 
*******************************************************************************
* Mike Arsenault                |Internet Style: aruba!mikea@uu2.psi.com      *
* Systems Programming           |UUCP     : ...!uunet!uu2.psi.com!aruba!mikea *
*******************************************************************************