[omniORB] Getting segmentation fault when I delete an array of
	structs
    W T Meyer 
    meyer at iastate.edu
       
    Mon Jun  4 15:17:56 BST 2007
    
    
  
I'm trying to pass an array of fixed-length structs via CORBA. It 
almost works, but I get a seqmentation fault at the very end.
Here is the relevant IDL code:
module CoRCC {
    enum vmeType {SBC, ROD, TIM, EMPTY, OTHER, UNKNOWNTYPE};
    enum vmeModStatus {OK, WARNING, ERROR, UNKNOWNSTATUS};
    struct slotInfo {
       vmeType contents;
       long serNo;
       vmeModStatus status;
       long revision;
    };
    typedef slotInfo crateInfo[22];
    interface RCC {
       long scanCrate(inout crateInfo modList);
    };
}
The implementation (server) code seems to work OK; it even returns 
the correct information. The problem is on the client side. Here is 
the relevant code:
int pyScanCrate(int rccHandle, struct mySlotInfo slotList[]) {
   int status = 0;
   unsigned int;
   int si;
   CoRCC::slotInfo* tempList = new CoRCC::slotInfo[24];
   status = rccref[rccHandle]->scanCrate((CoRCC::crateInfo_var)tempList);
   for (unsigned int i=2; i<NSLOTS+1; i++) {
     slotList[i].contents = vmeType((int)tempList[ui].contents);
     slotList[i].serNo = tempList[ui].serNo;
     slotList[i].status = vmeModStatus((int)tempList[ui].status);
     slotList[i].revision = tempList[ui].revision;
   }
   delete [] tempList;
   return status;
}
For technical reasons I need to copy the information into another 
array of structs, called slotList, but this should not affect the 
CORBA side. I am creating a temporary array of structs, which the 
client application owns, and filling it via the call to 
rccref[rccHandle]->scanCrate. The information comes back from the 
server just fine.  I can print it out and everything looks good.  The 
problem comes on the "delete [] tempList" statement, where I get a 
segmentation fault.
If I just create tempList and the delete it without doing anything to 
it, there is no problem. It is only after filling tempList from CORBA 
that I have a problem.
For the record, I'm running an Intel processor under Linux (Kernel 
version 2.4), using g++ 3.2.2, and omniORB 4.0.6.
    
    
More information about the omniORB-list
mailing list