Original Post
Hi! Every time, I want to start my Engine in the Release mode (instead of debug), it crashes! Does anyone had a similar problem?
🔒 Locked
My Engine isn't working in Release-mode
Advertisement
Yeah, I had a bug in my code where it crashed in release mode once too. I fixed it though.
I think it's happened to everyone at some point or another.
Here are a couple common things to check for (though this is not a complete list)
- Uninitialized variables. In debug variables initialize to 0, typically, and at least on Microsoft compilers I think memory on the heap initializes to 0xCD repeatedly (or was that unused heap memory?). This means your variable which is normally valid, has any possible value in it. This goes for enums as well!
- ASSERT statements. If asserts do more than check a condition, ie they actually DO something like "ASSERT((result = Func()) == NULL);", it will NOT be executed in release builds. Both "result" will not be assigned, and "Func()" will not be called.
I'd say start there.
Here are a couple common things to check for (though this is not a complete list)
- Uninitialized variables. In debug variables initialize to 0, typically, and at least on Microsoft compilers I think memory on the heap initializes to 0xCD repeatedly (or was that unused heap memory?). This means your variable which is normally valid, has any possible value in it. This goes for enums as well!
- ASSERT statements. If asserts do more than check a condition, ie they actually DO something like "ASSERT((result = Func()) == NULL);", it will NOT be executed in release builds. Both "result" will not be assigned, and "Func()" will not be called.
I'd say start there.
Ya, we had that one often.
Look into your constructors. You have uninitialized variables. In debug it will often initialize them to garbage, and bool to true. But in Release, I think depending on your compiler configs, will automatically initialize them to zero, and bools to false. Don't rely on this anyway, always initialize them.
You probably just forgot a variable or two :). That was our case, every time!
Look into your constructors. You have uninitialized variables. In debug it will often initialize them to garbage, and bool to true. But in Release, I think depending on your compiler configs, will automatically initialize them to zero, and bools to false. Don't rely on this anyway, always initialize them.
You probably just forgot a variable or two :). That was our case, every time!
Well, ok... What was it? What do I have to look for? :(
EDIT: Wow! so many answers, and I was still typing ;) Gotta read them first...
EDIT: Wow! so many answers, and I was still typing ;) Gotta read them first...
Quote:That depends what "Crash" means. If it's an access violation, what address? What line of code causes it? Are you sure all pointers are valid on that line?
Original post by WuTz
Well, ok... What was it? What do I have to look for? :(
If it won't even start up, it's probably manifest related
If it's a bluescreen, it's probably driver or hardware related.
Quote:The compiler won't initialise them to anything - their value depends on whatever happened to be in memory before it and is essentially random.
Original post by Daivuk
But in Release, I think depending on your compiler configs, will automatically initialize them to zero, and bools to false.
In Debug mode, certain things are done for you to make it easier to detect bugs. However, these have the flip side of behaving in a deterministic manner, which means that your code can end up depending on behaviour that the debug runtimes give you. An example is when you allocate or free memory, the runtime will fill it with special patterns which make it easier to discover uninitialised or release memory being used.
You also need to understand that you can attach a debugger in release mode. You can modify the default Release configuration which might make it easier to make sense of what is happening, as otherwise it will be very confusing.
You also need to understand that you can attach a debugger in release mode. You can modify the default Release configuration which might make it easier to make sense of what is happening, as otherwise it will be very confusing.
I've had it happen too! I think you need to inspect your computer for forks and see if your code has any bugs in them. Because it's most likely that those cause the crash to happen.
Without posting more details it might be hard to find help. What language are you using? What output (if any) do you get?
Taking a stab in the dark: If you're coding in C or C++, the first thing you'll want to check for is uninitialized variables. The compiler usually sets all new variables to a default value like 0 in debug mode, but in release the same variables could be anything. An uninitialized bool could be equal to 23. Uninitialized pointers would incorrectly pass null checks. Dogs and cats living together, etc.
If all else fails, drop in a printf at every other line, see which is the last one that outputs. The crash will be after that line.
edit: Wow, in the time it took me to type that, five other people beat me to it with good answers. LOL
Taking a stab in the dark: If you're coding in C or C++, the first thing you'll want to check for is uninitialized variables. The compiler usually sets all new variables to a default value like 0 in debug mode, but in release the same variables could be anything. An uninitialized bool could be equal to 23. Uninitialized pointers would incorrectly pass null checks. Dogs and cats living together, etc.
If all else fails, drop in a printf at every other line, see which is the last one that outputs. The crash will be after that line.
edit: Wow, in the time it took me to type that, five other people beat me to it with good answers. LOL
Ok. It crashes in mvcrt.dll or msvcrt.dll, something like that. I only see Assembler code, but I will take a look, what happens before that crash. And I found some uninitialized variables. Maybe it works, when I init them all. Thanks for that fast help! :)
Make sure you have your warnings set to as high as is manageable, and ideally you would have your codebase compile with no warnings.
Quote:If you turn on debug information for your release build you should be able to get a full call stack. Failing that, you can add some OutputDebugString() calls to see where it gets to before it crashes, and then work out what's wrong from there.
Original post by WuTz
Ok. It crashes in mvcrt.dll or msvcrt.dll, something like that. I only see Assembler code, but I will take a look, what happens before that crash. And I found some uninitialized variables. Maybe it works, when I init them all. Thanks for that fast help! :)
Ok. I've found the location where it crashes:
with that output:
(Sorry, I had to translate it from German)
I already checked the Variables in that piece of code. "ViewportHW" is strange.
The debugger says "No symbols found for ViewportHW" or so. But it IS initialized! Very strange..
case WM_SIZE: GetClientRect(hDlg,&MainWnd); ViewportHW=NULL; ViewportHW=GetDlgItem(hDlg,IDC_Viewport); GetClientRect(ViewportHW,&ViewportWnd); if(MainWnd.right-50>5 && MainWnd.bottom-50>5 && ViewportHW) { SetWindowPos(ViewportHW,NULL,40,40,MainWnd.right-50,MainWnd.bottom-50,0); ///<------------------ HERE! } TheScene.UpdateWindowSize(); if(wParam==SIZE_MAXIMIZED)with that output:
(Sorry, I had to translate it from German)
One exception (first Chance) at 0x00000000 in WTech DX10.exe: 0xC0000005: Access violation.One exception (first Chance) at 0x7787cdc9 in WTech DX10.exe: 0xC0000005: Access violation when reading at position 0x00000010.Unhanded exception 0x7787cdc9 in WTech DX10.exe: 0xC000041D: Unhanded exception while user-recall.I already checked the Variables in that piece of code. "ViewportHW" is strange.
The debugger says "No symbols found for ViewportHW" or so. But it IS initialized! Very strange..
One exception (first Chance) at 0x7787cdc9 in WTech DX10.exe: 0xC0000005: Access violation when reading at position 0x00000010.
That means you have a null pointer, and you're accessing something 16 bytes from the start of the object. The line you mention doesn't have any pointers in it, so that can't be the line causing the crash. If you add an OutputDebugString() before and after that line, do you see the first but not the second?
What's more likely is that on the next line, TheScene.UpdateWindowSize();, TheScene is a null reference (Or is it a global?), or causes a null pointer access.
That means you have a null pointer, and you're accessing something 16 bytes from the start of the object. The line you mention doesn't have any pointers in it, so that can't be the line causing the crash. If you add an OutputDebugString() before and after that line, do you see the first but not the second?
What's more likely is that on the next line, TheScene.UpdateWindowSize();, TheScene is a null reference (Or is it a global?), or causes a null pointer access.
I tried the DebugOutput. This is what I get:
with this code:
Before SetWindowPos()Eine Ausnahme (erste Chance) bei 0x00000000 in WTech DX10.exe: 0xC0000005: Access violation.Eine Ausnahme (erste Chance) bei 0x7787cdc9 in WTech DX10.exe: 0xC0000005: Zugriffsverletzung beim Lesen an Position 0x00000010.Unbehandelte Ausnahme bei 0x7787cdc9 in WTech DX10.exe: 0xC000041D: Unbehandelte Ausnahme während eines Benutzerrückrufs.Das Programm "[3916] WTech DX10.exe: Systemeigen" wurde mit Code 0 (0x0) beendet.with this code:
if(MainWnd.right-50>5 && MainWnd.bottom-50>5 && ViewportHW) { OutputDebugString(L"Before SetWindowPos()\n"); SetWindowPos(ViewportHW,NULL,40,40,MainWnd.right-50,MainWnd.bottom-50,0); OutputDebugString(L"After SetWindowPos()\n"); } OutputDebugString(L"Before UpdateWindowSize()\n"); TheScene.UpdateWindowSize(); OutputDebugString(L"After UpdateWindowSize()\n");
Are MainWnd or ViewportHW member variables? If so, is the this pointer null?
They are local variables of the function:
Here are (or should be) the local variables:
The ViewportHW-Var is not there!? ???
LRESULT CALLBACK MainMsgProc( HWND hDlg, UINT uMsg, WPARAM wParam, LPARAM lParam){ RECT MainWnd,ViewportWnd; HWND ViewportHW; D3DXVECTOR3 HitLoc; OPENFILENAME ofn; WCHAR szFile[MAX_PATH]; WCHAR p[MAX_PATH]; switch(uMsg) {//...Here are (or should be) the local variables:
The ViewportHW-Var is not there!? ???
Where do you initialize your ViewportHW ?
EDIT: Nevermind, I was blind: ViewportHW=NULL;
ViewportHW=GetDlgItem(hDlg,IDC_Viewport);
EDIT: Nevermind, I was blind: ViewportHW=NULL;
ViewportHW=GetDlgItem(hDlg,IDC_Viewport);
Can we see the generated disassembly for the bit of code that causes the crash (Including the two OutputDebugString()s)?
Here:
I don't understand those assembly stuff. :) Is this the right code?
if(MainWnd.right-50>5 && MainWnd.bottom-50>5 && ViewportHW)00B6FC73 mov eax,dword ptr [esp+2Ch] 00B6FC77 mov ebp,dword ptr [__imp__SetWindowPos@28 (0B99448h)] 00B6FC7D add eax,0FFFFFFCEh 00B6FC80 cmp eax,5 00B6FC83 jle $LN41+7Eh (0B6FCCAh) 00B6FC85 mov ecx,dword ptr [esp+30h] 00B6FC89 add ecx,0FFFFFFCEh 00B6FC8C cmp ecx,5 00B6FC8F jle $LN41+7Eh (0B6FCCAh) 00B6FC91 test edi,edi 00B6FC93 je $LN41+7Eh (0B6FCCAh) { OutputDebugString(L"Before SetWindowPos()\n");00B6FC95 push offset string L"Before SetWindowPos("... (0B9FD3Ch) 00B6FC9A call dword ptr [__imp__OutputDebugStringW@4 (0B99064h)] SetWindowPos(ViewportHW,NULL,40,40,MainWnd.right-50,MainWnd.bottom-50,0);00B6FCA0 mov edx,dword ptr [esp+30h] 00B6FCA4 mov eax,dword ptr [esp+2Ch] 00B6FCA8 push 0 00B6FCAA add edx,0FFFFFFCEh 00B6FCAD push edx 00B6FCAE add eax,0FFFFFFCEh 00B6FCB1 push eax 00B6FCB2 push 28h 00B6FCB4 push 28h 00B6FCB6 push 0 00B6FCB8 push edi 00B6FCB9 call ebp OutputDebugString(L"After SetWindowPos()\n");00B6FCBB mov edi,dword ptr [__imp__OutputDebugStringW@4 (0B99064h)] //MSVC++ Marks this line with a green arrow...00B6FCC1 push offset string L"After SetWindowPos()"... (0B9FD10h) 00B6FCC6 call edi 00B6FCC8 jmp $LN41+84h (0B6FCD0h) 00B6FCCA mov edi,dword ptr [__imp__OutputDebugStringW@4 (0B99064h)] } OutputDebugString(L"Before UpdateWindowSize()\n");00B6FCD0 push offset string L"Before UpdateWindowS"... (0B9FCD8h) 00B6FCD5 call edi TheScene.UpdateWindowSize();00B6FCD7 mov ecx,offset TheScene (0BA9BD8h) 00B6FCDC call DX10Scene::UpdateWindowSize (0B71170h) OutputDebugString(L"After UpdateWindowSize()\n");I don't understand those assembly stuff. :) Is this the right code?
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement