Skip to main content
gamedev.net
🔒 Locked

Release build problems

Started by Magister 5 replies 600+ views
Original Post
Magister
Magister
Hello everybody, OK so am working on my 3D engine project that is a dll file, now if i build the dll in the debug mode and use it in my application it works fine ( the app is in debug mode too its just to test my dll ), now if i switch to release mode in the dll project and build it and try it with my app it generates upheld exceptions.. I tried my app in release build as well but no success =[... than i rebuild the app with the new obj file form the release mode dll and still the same exceptions errors. than i tried to my app in debug mode and dll in release to see where it crashes and when the function is passing the struct and it enters my dll its garbage so i guess the passing is falling? i pass by pointer any suggestions ? name calling problems maybe ? i use visual 2005 c plus plus - ( heh i can't put the plus sign it does not show lol ) to export to dll i use _declspec(dllexport) before each function and the dll is part of the project as i include the lib file in the app. Thanks any help is appreciated.
kohlrak
kohlrak
Can you give me a little more detail on the error? Also, i've noticed a few times before of people having issues like this. Usually, they find out it's a timing issue that results from depending on execution being in a certain rate, but the rates change from computer to computer and/or (usually and) the retail release is much faster than the debug release.
smitty1276
smitty1276
First of all, you've made it unclear whether you are getting runtime errors, or compile-time errors (though I think you are meaning runtime errors).

If you got errors during compilation and you're using headers for the classes, etc., exported from your DLL, you should conditionally define the _declspec stuff...

#ifdef MYDLLPROJECT#define MYDLLAPI __declspec(dllexport)#else#define MYDLLAPI __declspec(dllimport)#endif
...then use MYDLLAPI instead of directly using the __declspec stuff. That way the app that includes and links to it has it defined properly as dllimport. (Just define MYDLLPROJECT in your DLL project settings).

If you're getting errors during runtime, a lot of runtime crashes are caused because the incorrect runtime is specified in the projects. Under your project settings for the app, go into C/C++-->Code Generation and make sure that "Multi-threaded" is set, and for the DLL check to see that it is set to "Multi-threaded DLL". For debug, you want "multi-threaded Debug" and "multi-threaded Debug DLL", respectively.

If those don't agree, they can cause odd behavior and crashing, particularly when calling functions in the DLL.
Magister
Magister
the problem is that if the app is in debug mode and the dll is in release mode it crashes...
the error i get is

Unhandled exception at 0x7e41ff0e (user32.dll) in 3d Engine - console.exe: 0xC0000005: Access violation reading location 0x0000000f.

when i select a debuger it shows that the function passed garbage in the struct and it <bad_ptr> on its members it only happen if app is debug and dll is release

if the DLL is in release mode and the application is in release mode it works fine, but as i will work on it the dll will be in release mode and the app in debug so i can debug it.

is this because of the dll lib being part of the application. I link the lib file from the dll in the application i don't use GetProcAddress() is there any way i can use the release dll with a debug mode app ?

sorry if i was unclear before.

thank
Crypter
Crypter
Quote:

the problem is that if the app is in debug mode and the dll is in release mode it crashes

Of course. Debug build versions contain extra routines, data and symbols
specific for debugging purposes, while release builds don't. Based on the
exception error, it seems the application expects something on the debug
DLL that would normally be there if it was not a debug build.

May I ask why you are mixing a debug build DLL with a release build application?
On normal cases, one would either use both DEBUG or RELEASE builds, not mix
them.

Also, insure any library files that use the DLLs are both in the same
build (That is, both DEBUG or RELEASE builds). Not doing so may cause
odd CRT errors of calling incorrect routines. I learned this the hard way[smile]
kohlrak
kohlrak
Quote:
Unhandled exception at 0x7e41ff0e (user32.dll) in 3d Engine - console.exe: 0xC0000005: Access violation reading location 0x0000000f.


I wonder which function you're calling... I'm assuming not message box... Whatever it is, it is likely to have something to do with your window code. I hate when i see exceptions generated from a DLL that isn't mine... Then it's a pain in the rear trying to find out which function call in particular set off that error in the DLL... I had a problem with some one beta testing earlier, he swore it wasn't his drivers. We found out there was a problem with opengl and his video card drivers. Nvidia still hasn't fixed the issue.

Quote:
is this because of the dll lib being part of the application. I link the lib file from the dll in the application i don't use GetProcAddress() is there any way i can use the release dll with a debug mode app ?


Two seperate libs are generated for both dlls i assume. Are you using the retail version lib for the retail dll when compiling the debug release exe?
Magister
Magister
thank you for your repiless...

Quote:


the problem is that if the app is in debug mode and the dll is in release mode it crashes


Of course. Debug build versions contain extra routines, data and symbols
specific for debugging purposes, while release builds don't. Based on the
exception error, it seems the application expects something on the debug
DLL that would normally be there if it was not a debug build.

May I ask why you are mixing a debug build DLL with a release build application?
On normal cases, one would either use both DEBUG or RELEASE builds, not mix
them.

Also, insure any library files that use the DLLs are both in the same
build (That is, both DEBUG or RELEASE builds). Not doing so may cause
odd CRT errors of calling incorrect routines. I learned this the hard way



ok well so its not possible to use a release dll with a project thats in debug mode ? if the dll is in release mode and i give to my frined the obj file and include file with the release dll he can't use it unless his application is in release mode ? as it crashes or i must give him both the release and debug builds of the files so he cnus debug it and than use release whne he is done ?

Quote:


Two seperate libs are generated for both dlls i assume. Are you using the retail version lib for the retail dll when compiling the debug release exe?



yes when i switch setting to release the different lib is generated, yes am using the retail lib with retail dll to compile debug exe. and whne i run it it crashes with the runtime error.

Quote:


I wonder which function you're calling... I'm assuming not message box... Whatever it is, it is likely to have something to do with your window code. I hate when i see exceptions generated from a DLL that isn't mine... Then it's a pain in the rear trying to find out which function call in particular set off that error in the DLL... I had a problem with some one beta testing earlier, he swore it wasn't his drivers. We found out there was a problem with opengl and his video card drivers. Nvidia still hasn't fixed the issue.



Am calling a function inside the dll to initialize the engine and i pass the struct 

 int Initilize(      TIX3D_INITILIZATIONSETTINGS *pdata,DWORD Flags);


the struct looks like this:

 struct TIX3D_INITILIZATIONSETTINGS //information of how to create the window and device{	UINT uiWidth;                   //width of screen in pixels	UINT uiHeight;                  //height of screen in pixels	D3DFORMAT d3dBackBufferFmt;     //format of back buffer	D3DFORMAT d3dDepthFmt;          //format of depth 	D3DCOLOR BackBufferColor;       //backBufferColor	std::string Inifile;            //Init file for creation used with (Flags TIX3D_CREATE_INIFILE )	std::string FileID;             //Id of the file for validation	std::string Title;              //Title of the window	HINSTANCE hInst;                //instnace of the window	int nCmdShow;                   //show window ?	BOOL bWindowed;                 //windowed or fullscreen	void (*SceneRenderer)(void);      //called by the engine evry frame to update the scene	TIX3D_INITILIZATIONSETTINGS(UINT Width,		           UINT Height,				   D3DFORMAT BBFmt,				   D3DFORMAT DBFmt,				   bool Windowed,				   std::string title, 				   HINSTANCE hInstance, 				   int ncmdshow,				   D3DCOLOR BackColor) {	               uiWidth = Width; uiHeight = Height; d3dBackBufferFmt = BBFmt; d3dDepthFmt = DBFmt; bWindowed = Windowed; Title = title; hInst = hInstance; nCmdShow = ncmdshow;  BackBufferColor = BackColor;};	TIX3D_INITILIZATIONSETTINGS(bool Windowed,		           std::string title, 				   HINSTANCE hInstance, 				   int ncmdshow,				   D3DCOLOR BackColor) { 				   bWindowed = Windowed; Title = title; hInst = hInstance; nCmdShow = ncmdshow;  BackBufferColor = BackColor; };	TIX3D_INITILIZATIONSETTINGS(std::string title, 		           HINSTANCE hInstance, 				   int ncmdshow,				   D3DCOLOR BackColor, 				   std::string InitFile, 				   std::string Fileid) { 				   Title = title; hInst = hInstance; nCmdShow = ncmdshow;  BackBufferColor = BackColor; Inifile = InitFile; FileID = Fileid; };   TIX3D_INITILIZATIONSETTINGS() { };}TIX3DINITILIZATIONSETTINGS;


when i pass the pointer the members are garbage. it inly happens with release dll and debug app other wise it workss.

is this struct messy ?

Quote:

First of all, you've made it unclear whether you are getting runtime errors, or compile-time errors (though I think you are meaning runtime errors).

If you got errors during compilation and you're using headers for the classes, etc., exported from your DLL, you should conditionally define the _declspec stuff...

#ifdef MYDLLPROJECT
#define MYDLLAPI __declspec(dllexport)
#else
#define MYDLLAPI __declspec(dllimport)
#endif


...then use MYDLLAPI instead of directly using the __declspec stuff. That way the app that includes and links to it has it defined properly as dllimport. (Just define MYDLLPROJECT in your DLL project settings).

If you're getting errors during runtime, a lot of runtime crashes are caused because the incorrect runtime is specified in the projects. Under your project settings for the app, go into C/C++-->Code Generation and make sure that "Multi-threaded" is set, and for the DLL check to see that it is set to "Multi-threaded DLL". For debug, you want "multi-threaded Debug" and "multi-threaded Debug DLL", respectively.

If those don't agree, they can cause odd behavior and crashing, particularly when calling functions in the DLL.


thanks i chnaged it but still same thing happens.. but it makes my coding easier ;)

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.