Buffer Overrrun when calling ADP_Initialize

Buffer Overrrun when calling ADP_Initialize

When running a Release build of our program, the following message occurs when calling ADP_Initialize. Any ideas? A buffer overrun has occurred in Fashion Salon.exe which has corrupted the program's internal state. Press Break to debug the program or Continue to terminate the program. John Jones-Steele Broadsword Games
15 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

John,

Please post your initialize code so we can review in context. Thank you.

Crash occurs in ADP_Initialize - wroks fine if linked with the debug library.

Salon::Salon() : NiApplication("YooStar Fashion Salon, v.1.00", 640, 480),
m_fTime(0.0f)
{

#if defined (_ATOM_)
ADP_RET_CODE ret_code;
const ADP_APPLICATIONID myApplicationID = ADP_DEBUG_APPLICATIONID;

if ((ret_code = ADP_Initialize()) != ADP_SUCCESS )
{
switch( ret_code )
{
case ADP_INCOMPATIBLE_VERSION:
MessageBox(NULL, "ERROR: Incompatible version" , "ERROR", MB_ICONERROR | MB_OK);
break;
case ADP_NOT_AVAILABLE:
MessageBox(NULL, "Client Agent not running", "ERROR", MB_ICONERROR | MB_OK);
break;
case ADP_FAILURE:
default:
MessageBox(NULL, "Unknown error" , "ERROR", MB_ICONERROR | MB_OK);
break;
} // switch
ADP_Close();
exit( -1 );
} // if-then

John,

A few things come to mind:

1.) Are you using the 0.91 (Beta 2) release of the SDK and ATDS?
2.) Are there libraries other than the ATOM SDK?

1)Yes, we are using the latest.
2)Gamebryo Game Engine, ogg, vorbis.

Are any of your other libraries or Dll's still linked to Debug CRT, MFC, ATL?

All the other libraries are built with 2010 and MultiThread DLL - no debug libraries used.

Are you using VS 2008 to compile your application?

That is correct.

Any further ideas?

Just did a full clean and re-build - all working fine now - don't you love VC:-)

Only one idea - you have buffer overrun in your aplication. I have not same but identical problem in my application then i try to copy text in to the text buffer. Text buffer length was 64, text length was 94. Copy operation complited successfully, all works fine in Debug version but Release version always fails. Take a look to your NiApplication constructor code, for example

I started seeing this problem in my app about the time I linked in a static LIB. I stubbed out the intel code and kept going. When I re-enabled it was still there.

To debug, I made a totally empty console program - not even a "Hello, world!", just a totally empty app - compiled, ran, and saw the same problem. It was a debug build.

Does anyone know what is happening???

Eric

PS Here is my app in toto, I also link to the libs Intel recommends:
// AM0.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include "adpcppf.h"
#include
const ApplicationId myApplicationID(ADP_DEBUG_APPLICATIONID);
int _tmain(int argc, _TCHAR* argv[])
{
Application * pApp = 0;
try
{
pApp = new Application(ApplicationId(ADP_DEBUG_APPLICATIONID));
} catch (AdpException& e)
{
cout << "The attempt to authorize the application failed: " << e.what() << endl;
if (pApp != NULL)
delete pApp;
}
return 0;
}

I solved the problem, so I am going to answer my own question here for the benefit of others.

Back in the Good Ole Days, if you wanted a static library like MYSTUFF.LIB, you would specify it under that name, and the linker would know whether you really meant MYSTUFF.LIB or MYSTUFFD.LIB for a debug build. Or maybe it just always worked that way for default libraries.

Anyway, I noticed Intel had explicitly specified two different names for some of their static libraries. I got cute and in my build settings used the bare, release form name for all builds, both release and debug.

Well, the debug version crashed. So I squawked, and then started work :-)

The release build did not crash. Hmmm.

I explicitly and carefully specified the FOO.LIB version for release, and FOOD.LIB for debug, rebuilt, presto, it works.

Bottom line: make sure you know what you are linking against.

Eric

Good to hear. When in doubt, reboot :)

Login to leave a comment.