Show us your TimerLog class declaration.
Does it have TimerLog object (not pointer to it) as it's member?
You are debugging Debug configuration of project (not Release), right? Optimizations disabled and debugging information present, right?
[win32] the most bizarr error ever..
Author
I never did exception handling before..shame on me, is this right:
It doesnt display the message box..
I have posted the links to google docs, you can download the ,h and .cpp of the timer log class, but no, it dont have any references to itself..
Debug mode, no optimizations, x64..At now I cant compile x32 cause Im using some xna math stuff that I would have to handle lots of stuff.. Now I just tryed release mode, the same problem happen, and I noticed something that wasnt happening till all that started, my release builds doesnt detect uptodate anymore, it always build, and always says my project is out of date..( god is trying to screw me by all means )
I got those outputs when I stop execution after the app behavior(unresponsible window with crazy menu)
[Edited by - Icebone1000 on October 26, 2010 7:18:12 PM]
try{ Foo(); }catch(...){ MB( "EXCEPTION", "fatal error", MB_E ); }It doesnt display the message box..
I have posted the links to google docs, you can download the ,h and .cpp of the timer log class, but no, it dont have any references to itself..
Debug mode, no optimizations, x64..At now I cant compile x32 cause Im using some xna math stuff that I would have to handle lots of stuff.. Now I just tryed release mode, the same problem happen, and I noticed something that wasnt happening till all that started, my release builds doesnt detect uptodate anymore, it always build, and always says my project is out of date..( god is trying to screw me by all means )
I got those outputs when I stop execution after the app behavior(unresponsible window with crazy menu)
Quote:
First-chance exception at 0x000000013f3bbeb7 in Physics_plus_DX11_practicing.exe: 0xC0000005: Access violation writing location 0x00000000001e0000.
First-chance exception at 0x000000013f3bbeb7 in Physics_plus_DX11_practicing.exe: 0xC0000005: Access violation writing location 0x00000000001e0000.
First-chance exception at 0x000000013f3bbeb7 in Physics_plus_DX11_practicing.exe: 0xC0000005: Access violation writing location 0x00000000001e0000.
First-chance exception at 0x000000013f3bbeb7 in Physics_plus_DX11_practicing.exe: 0xC0000005: Access violation writing location 0x00000000001e0000.
First-chance exception at 0x000000013f3bbeb7 in Physics_plus_DX11_practicing.exe: 0xC0000005: Access violation writing location 0x00000000001e0000.
First-chance exception at 0x000000013f3bbeb7 in Physics_plus_DX11_practicing.exe: 0xC0000005: Access violation writing location 0x00000000001e0000.
[Edited by - Icebone1000 on October 26, 2010 7:18:12 PM]
Author
I have a very informative news..
Well the problem continues, after repairing VS with the installation cd, notting changes(that up to date thing at least stoped)
I just tested my class in another app, and the exaclty same thing happens, just when I add a damn timerlog class object in the windproc those things happens...so can someone please, download the files I have posted on google docs, and test it yourselfs, just create an instance of the class at your windows procedure, and see what happens?
Well the problem continues, after repairing VS with the installation cd, notting changes(that up to date thing at least stoped)
I just tested my class in another app, and the exaclty same thing happens, just when I add a damn timerlog class object in the windproc those things happens...so can someone please, download the files I have posted on google docs, and test it yourselfs, just create an instance of the class at your windows procedure, and see what happens?
Hi,
I'd like to point out a few things:
1. In your ctor implementation you don't actually create the file. The call to CreateFile is commented for some reason. This may be a problem for your assert there as the variable hLogFile (HANDLE) is never initialized to INVALID_HANDLE_VALUE. That's just something small.
2. A more interesting problem is the size of your object. The TimerLog class defines an array of CHARs that is 0.5 MB in size. Do you realize that normally in Win32 each thread is initialized with 1MB of stack space by default ? Allocating an object that has a size of ~0.5MB on the stack is a VERY BAD practice.
Technically you should receive a stack overflow exception but who knows what happens if you do overflow the stack in a brutal way. I'd check if that happens.
Also, is your CHAR type defined to be actual C++ char ? Because if Unicode is defined maybe CHAR is really a wide char (2 bytes per char) ? That may lead to an object size of more than 1 MB, allocated on the stack.
Just print sizeof(TimerLog) to verify its size. Try allocating the buffer a different way and see if it helps.
3. Using assert within a window procedure is permitted but you have to be aware. In debug mode it will raise a dialog. That dialog has its own dialog window procedure so a nested window proc is created. This means the stack becomes roughly:
..
..
<code leading to your wnd proc>
MyWndProc(..)
foo()
TimerLog::TimerLog()
assert()
..
..
DialogWndProc() (not sure what the signature is)
..
What this basically means is that until that wnd proc is done, your wnd proc is stuck in place, so your app won't even respond while the assertion dialog is up.
Just FYI.
I'd like to point out a few things:
1. In your ctor implementation you don't actually create the file. The call to CreateFile is commented for some reason. This may be a problem for your assert there as the variable hLogFile (HANDLE) is never initialized to INVALID_HANDLE_VALUE. That's just something small.
2. A more interesting problem is the size of your object. The TimerLog class defines an array of CHARs that is 0.5 MB in size. Do you realize that normally in Win32 each thread is initialized with 1MB of stack space by default ? Allocating an object that has a size of ~0.5MB on the stack is a VERY BAD practice.
Technically you should receive a stack overflow exception but who knows what happens if you do overflow the stack in a brutal way. I'd check if that happens.
Also, is your CHAR type defined to be actual C++ char ? Because if Unicode is defined maybe CHAR is really a wide char (2 bytes per char) ? That may lead to an object size of more than 1 MB, allocated on the stack.
Just print sizeof(TimerLog) to verify its size. Try allocating the buffer a different way and see if it helps.
3. Using assert within a window procedure is permitted but you have to be aware. In debug mode it will raise a dialog. That dialog has its own dialog window procedure so a nested window proc is created. This means the stack becomes roughly:
..
..
<code leading to your wnd proc>
MyWndProc(..)
foo()
TimerLog::TimerLog()
assert()
..
..
DialogWndProc() (not sure what the signature is)
..
What this basically means is that until that wnd proc is done, your wnd proc is stuck in place, so your app won't even respond while the assertion dialog is up.
Just FYI.
Author
>___<
The size...why I didnt thinked on that? Thats the problem, thanks a lot man..
The commented thing is my bad, I was trying to modify everything a bit at a time to see if I find the problem( the only thing I didnt modify was the size of the buffer, damn)..so I uploaded like that..by mistake
I didnt was thinking on size issues until read your post..the thing is..how windows know(how it checks) how much the windows procedure will use of memory..If the code was not even reached you know..to me this is still magic..First the error was at creating the window, and later the windows procedure was just dead..( it doesnt make sense, so createwindow check the windows procedure and see that theres a class who needs huge memory and so the wndproc explodes the memory? Shouldnt the memory just exploades when the code is reached, since it is local..)
Remember sometimes I got writting access violation(after execution), would that explain why no stack overflow?)
Windows CHAR is always char, at least is what I understand(on my apps it is for sure a char), you would use TCHAR for having it choosed at compile time(unicode /ansi)..
Thanks \o/
-edit-
The fact that I have 4GB of ram is usefull?..
The size...why I didnt thinked on that? Thats the problem, thanks a lot man..
The commented thing is my bad, I was trying to modify everything a bit at a time to see if I find the problem( the only thing I didnt modify was the size of the buffer, damn)..so I uploaded like that..by mistake
Quote:
Do you realize that normally in Win32 each thread is initialized with 1MB of stack space by default ? Allocating an object that has a size of ~0.5MB on the stack is a VERY BAD practice.
I didnt was thinking on size issues until read your post..the thing is..how windows know(how it checks) how much the windows procedure will use of memory..If the code was not even reached you know..to me this is still magic..First the error was at creating the window, and later the windows procedure was just dead..( it doesnt make sense, so createwindow check the windows procedure and see that theres a class who needs huge memory and so the wndproc explodes the memory? Shouldnt the memory just exploades when the code is reached, since it is local..)
Remember sometimes I got writting access violation(after execution), would that explain why no stack overflow?)
Windows CHAR is always char, at least is what I understand(on my apps it is for sure a char), you would use TCHAR for having it choosed at compile time(unicode /ansi)..
Thanks \o/
-edit-
The fact that I have 4GB of ram is usefull?..
No, 4 GB of RAM doesn't help in this case. The 4 GB of RAM is handed out to processes in the system. A process can allocate a lot of memory but that's not the issue.
The issue is stack space. When you call a function or allocate a variable on the stack, the stack reduces in size (technically, ESP becomes smaller, gets substracted). Since Windows, by default, allocates 1 MB of stack thread for a given *THREAD*, you may very well overflow the stack.
There's a way to override that value but it should suffice under almost all circumstances.
The issue is stack space. When you call a function or allocate a variable on the stack, the stack reduces in size (technically, ESP becomes smaller, gets substracted). Since Windows, by default, allocates 1 MB of stack thread for a given *THREAD*, you may very well overflow the stack.
There's a way to override that value but it should suffice under almost all circumstances.
Well you can easily increase the stack size to see if that was the problem.
On Visual Studio:
Project > YourProject properties > Linker > System > Stack reserve size. (sizes are in bytes)
Normally you're allerted when a stack overflow occurs though. Still, can't hurt to try
On Visual Studio:
Project > YourProject properties > Linker > System > Stack reserve size. (sizes are in bytes)
Normally you're allerted when a stack overflow occurs though. Still, can't hurt to try
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
