Memory Issue 2

[jamez05]

I'm using Visual Studio 2005 to write a C/C++ program.

I declare the following struct that contains an array:

typedef struct DataElement {
	char Fragment[45];
	double FragVal;
	int   NumFound;
	int FragID;
	char FragDisplay[45];
} MetaFrag, ParaFrag, PhenOFrag,PhenPFrag;

I call a function that creates a struct for MetaFrag,
ParaFrag etc..(showing the MetaFrag Example):

MetaFrag *MF = NULL;
MF = CreateMetaFile();
//CreateMetaFile()
MetaFrag *CreateMetaFile( void )
{ 

	MetaFrag *MF;

	MF = new DataElement [ 351 ];
	int n = 0;
	//0 - 10   
	strcpy(MF[n].Fragment,"R{A}CCCCCCC");
	strcpy(MF[n].FragDisplay,"CCCCCCC");
    MF[n].FragVal = -0.19; 
	MF[n].NumFound = 0; 
	MF[n].FragID = -1; n++;
    //etc..
    return( MF );
}

The program compiles fine, but it only works if I call 3 or
less of the data elements.
For example, I can call createmetafile, createparafile and
create phenofile and it works fine. However, if I add the 4th call, create phenopfile, it blows up when I try to run it. I've switched the calls around to make sure it wasn't specific to the function being called.

Does anyone see what I'm doing wrong? Any help is greatly appreciated

 

[xwb]

Try this for starters

MetaFrag* metaf = new MetaFrag[351];
ParaFrag* paraf = new ParaFrag[351];
PhenOFrag* penof = new PhenoFrag[351];
PhenPFrag* penpf = new PhenpFrag[351];

Does that run out of memory? If it doesn't then check your procedures. Check that none of your strcpy to Fragment and FragDisplay are over 44 chars.

That's all I can think of for now.

 

[ArkM]

I think it's impossible to exhaust all heap memory resources with near 140 Kb request (on 32-bit C++ implementation.
IMHO, better use more clear (and efficient) initialization code, for example:

namespace {
  DataElement d0 = // or static w/o anonymous namespace...
  { 
    "R{A}CCCCCCC",
    -0.19,
     0,
    -1,
    "CCCCCCC" 
  };
  DataElement d1 = 
  {
    // ....
  };
  // etc
}

DataElement* CreateD() // Names for example only...
{
  DataElement* pe = new DataElement[351];

  pe[0] = d0;
  pe[1] = d1;
  // etc
  return pe;
}
// and so on...

There are some alignment gaps in your structure (for example, between Fragment and FragVal members). Are you sure it's OK?..

 

[jamez05]

Thanks,

I will try your advice today and let you know what happens.

 

[jamez05]

Found out a little more...

When I try and run the program using three of the four
data elements, I get the Run-Time Check Failure #2 - Stack around variable 'CF_PKA was corrupted.

I run the debugger and get the following message:
Unhandled exception at 07c911430 in jrun.exe:0xC0000005: Access violation reading location 0x2a432a47.

The error is happening in Malloc.c:

#ifdef _WIN64
    return HeapAlloc(_crtheap, 0, size ? size : 1);
#else  /* _WIN64 */
    if (__active_heap == __SYSTEM_HEAP) {
        return HeapAlloc(_crtheap, 0, size ? size : 1);
    } else
    if ( __active_heap == __V6_HEAP ) {
        if (pvReturn = V6_HeapAlloc(size)) {
            return pvReturn;
        }
    }

The stack shows its error at:
ntdll.dll!7c911430

Does anyone know how to go about trouble-shooting this?

Thanks

 

[Salem]

> Access violation reading location 0x2a432a47
Which, if you take those hex values, is a string "*C*G"
Do you have anything which writes this string, or it's reversed version "G*C*" ?
If you do have, then following exactly where that goes can be pretty useful.

> Stack around variable 'CF_PKA was corrupted.
Sounds like you may have passed [tt] &myPtr [/tt] rather than [tt] myPtr [/tt] to some other function, and that's written all over the pointer itself rather than where it was pointing.

I take it you don't have any compiler warnings.
If you're running with a .net compiler, then change the warning level to /W4.

Microsoft have made a pretty good job of cleaning up all their header files for max warning level. VC6 was useless at W4 level due to too much crud in their own header files.

> The error is happening in Malloc.c:
The memory allocators are just very good at noticing that there is "a problem". It rarely tells you immediately where the problem is.


--