Code crash in vista not in XP

[ShashiKantSuman]

Hi,

I write a dll that is called by a java application. For some set of input the code is crash in vista but for same input its working in XP.
Can any one plz tell me what is the possible reason and why it's happening.

Thanks in advance,

Shashi Kant Suman

[Fordy]

Could be gremlins, but without some code it will be difficult to know for sure...

[grumpy]

You're presumably the sort of person who calls a mechanic and asks why your car won't go, without providing any further information.

Without useful information (such as a small but complete sample of code that exhibits the symptom) it is not even possible to guess. There are many possible explanations.

While you have probably decided it must be a problem with vista, a programming error on your part is the most likely explanation.

[AndrewHunter]

OP: "Doc, my body hurts all over and I don't know what's wrong"
Doc: "What do you mean?"
OP: "It doesn't matter where I touch, it hurts like he**. I think I might be dying."
Doc: "Your finger is broken..."

[vee]

Please provide a code Shashi..

[iMalc]

Attach the debugger to the java app on the vista machine and see what line of code was running when it breaks into the debugger.
Make sure you load the symbols and have the source files handy.

[ShashiKantSuman]

All;

I am sorry for not uploading any code, thought it might a standard problem with a standard solution !!

The code is quite large and this in turn calls another dll. I built a separate C exe to call my code. When I ran this via the de-bugger, I noticed that the code crashed in the line

	fnpUnLoad = (fn_NP_Router_OSPF_UnLoadingDLL)GetProcAddress(hOSPFDLL,"fn_NP_Router_OSPF_UnLoadingDLL");
	fnpUnLoad();
	fn_NP_MPLS_UnLoadingDll();
	free(NETWORK);              ----> CRASHES HERE
	//NETWORK = NULL;
	free(pszProcessingTime);
	//FreeLibrary(hRouterDLL);      //free the primitive dll(RIP or OSPF)

The NETWORK Sturcture is as follows

typedef struct stru_NC_Network
{
	int n_NC_NumberOfNodes;
	int n_NC_NumberOfSwitches;
	int n_NC_NumberOfHubs;
	int n_NC_NumberOfRouters;
	int n_NC_NumberOfAccessPoints;
	int n_NC_NumberOfPhysicalMediums;	//Included by Sangeetha for tha device which has only physical layer
	DEVICE *pstruNodelist[MAXNODES];//list of nodes
	DEVICE *pstruSwitchList[MAXSWITCHES];//list of switches
	DEVICE *pstruHubList[20];//list of hubs
	DEVICE *pstruRouterList[MAXROUTERS];//list of routers
	DEVICE *pstruAccessPointList[MAXACCESSPOINTS];//list of access points
	DEVICE *pstruPhysicalMediumsList;	//list of physical mediums
	int n_NC_SourceNode;		// used to form the lookup table for ATM/TCP included by sangeetha
	int n_NC_DestinationNode;	// used to form the lookup table for ATM/TCP included by sangeetha
	char *sz_NC_Path[100][100];	// used to form the lookup table for ATM/TCP included by sangeetha
	double d_NC_SimulationEndTime; // time at which simulation ends
	char *sz_NC_TraceDetails;		// used to store the fields which are going to write in a file
	char *sz_NC_TraceName;	        // Name of the trace file
	int n_NC_TraceFlag;
	int sz_NC_WriteField[13];// used to set the variable which the user wants to set
	int sz_NC_ASDeviceCount[MAXAUTONOMOUS];      // added on 6/1/2011 by swetha
	int sz_NC_ASRouterCount[MAXAUTONOMOUS];      // added on 7/1/2011 by swetha

};

Hope this helps.

Thanks

[grumpy]

A crash on free() - assuming this is the standard C function named free() and not something else - most usually results from an error in preceding code.

The most common cause of problems when calling free() is some form of pointer molestation in code BEFORE the call of free(). For example, dereferencing a NULL pointer, falling off the end of an array, etc. If one of those invalid operations interferes with data structures used internally by malloc() and free() to keep track of things, then the free() call may fail.

So you are going to have to search through all of your code that is executed BEFORE the offending free() call.

[Shakti]

Also make sure you don't free any memory allocated within a dll outside the dll that allocated it (if dll A calls malloc then dll A should also be the one that calls free).

[Salem]

I'm guessing (from the scattering of "added by..." comments) that this is your work code.

In which case, get your employer to purchase a few licences for one or more of these tools.
Debugging tools - DevPartner - Micro Focus
Insure++®: C/C++ Testing Tool, Detect elusive Runtime Memory Errors - Parasoft
MicroQuill Software Publishing
IBM Software - Rational Purify

If the code has made several 1000's of malloc calls to that point, there is no practical way for you to examine each one of them in detail to make sure you're not doing something dumb. In a large program, you could do only a handful a day; it would take you years to finish the task, and your employer simply won't regard that as value for money (not to mention lost business for your product being at least 1 year late).

What is an almost certain guarantee is that this will NOT be the only memory problem in that large code base. It's only the first one which has had a serious consequence when ported to a new platform. Others will be still hidden from view, waiting for the next small change (new OS, new compiler, random code addition or bug fix).

The tools above will help you find them all, quickly and directly.

[adeyblue]

Looks like somebody needs to give 'swetha' a refersher on hungarian notation.

[rags_to_riches]

pointer molestation

Love it! Now I'm picturing pair programming with Chris Hansen.

[Salem]

Mmm, I thought a molestation was where these critters changed from one tunnel to another

[_Mike]

What compiler are you using? If Microsoft; Compile in debug mode and see what the exception/assertion text says.

[ShashiKantSuman]

All;

Thanks for your suggestions. After debugging through the weekend, I found out that, we are passing 20 fields for this array, which could hold only 13.

int sz_NC_WriteField[13];

And resolved that this cause the crash. (Though I am not able to understand why the crash happens in the free() !!)

However, further testing has thrown up new type error. The code crashes while running in release mode, but doesn't during de-bugging. Would welcome any ideas on what can be done ? Or let me know if I should attach any section of code?

Also thanks for those links on the memory leak identification tools. I have begun evaluation and am currently exploring Rational Purify.

Thanks
Shashikant