• Advertisement
Sign in to follow this  

[win32] the most bizarr error ever..

This topic is 2672 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Im creating this TimerLog class, that calculates frame durations and outputs to file, Im just using the win32 api..

Until now it was working just fine, it do everything ok, I was testing it before the message loop, it was "donne".
Now I just tryied to create one at the windows procedure, and my application first started to "get dead"(it stills was doing stuff cause I have hard coded it to display fps, and it was indeed being displayed)), it didnt receive any inputs..

I got those debug outputs saying stack overflow( O.o how can that be, it didnt do anything), and 4 other saying writing acces violation...I cant get it anymore cause all of sudden it changed behavior o.O

Now I get an error creating the main window..guess what is the error? errorcode == 0( ERROR_SUCCESS )..very informative..

Trying to isolate the problem, the only thing I could figure out is that the CreateWindowEx function is not getting at the windowprocedure(it should)..

The problem is for sure with that class at the window procedure, since if I comment it at the wndproc it backs to normal...but I cant see any connection(this class just appears at a very specific WM_COMMAND, it just get theres if user press a specific menu button..)

I dont know what piece of code I could post here..Notting is making sense to me..any ideas?

Share this post


Link to post
Share on other sites
Advertisement
When CreateWindow() or CreateWindowEx() is called, it sends a few messages to the window that it creates. If it doesn't like the responses it gets back, it cancels the window creation and ERROR_SUCCESS will be the result. Example: if the window procedure returns FALSE when processing WM_NCCREATE.

Share this post


Link to post
Share on other sites
It never gets at the window procedure, the break point isnt reached..
When it works, createwindow jump execution to windproc, since Im not handling wm_create it gets at the DefWindowProc..

I found out what causes the problem, but I still dont know why, it still doesnt make sense to me..

If I call the constructor without parameters it works fine..

I have just one constructor, that takes 3 parameters, all 3 parameters have default values( it makes it my default constructor?):

TimerLog( const CHAR* szFilename_p = NULL, DOUBLE TimeInterval_MSec = 1000.0,
TIMING_DESIGN eDateOrder = eDAY_MONTH_YEAR_HMS );



So..it just works if I call the constructor with its default parameters values( means without parameters)..
I tried removing default values from the prototype and:
--calling with my own parameters - SAME ERROR
--calling default constructor - WORKS(but I dont have a default constructor..I cant use the class like this)

Still weird, I have other classes at windproc that works fine with its explicits constructors(and they dont have a default constructor defined also), why it doesnt accept my constructor?



Share this post


Link to post
Share on other sites
Any ideas?I still dont have a clue..
I started to think it could be the size of windproc, but commenting out lots of stuff there still doesnt solve..

The behavior changed again, it doesnt crash, its like not receiving input again, with a minor difference that now I can see the menu buttons highlighted when the mouse is over(but they highlighted with a one color blue..not the windows default way..

Thats freaking weird.

Share this post


Link to post
Share on other sites
1: You need to debug your code and find out why this is happening.
Calling a normal C++ class constructor has nothing to do with a window procedure or CreateWindow - there must be some interaction there, what is it?

2: This is an advertisement for source control, if you can compare your changes against the last version that worked, you know where the problem is.

Share this post


Link to post
Share on other sites

As I said, if I cut out the class from windowsproc, it works man, I KNOW it doesnt make any sense, but jeezes, it works fine outside the windows proc..Thats the most important track of changes..it have to be something with that class..But how can that generates problem..just at the windows creation..without the code reaching the class...

Just think on that, removing that from windproc make it backs to normal..

The constructor is just called(inside the windows proc) if the user clicks the rigging button at the menubar, and if a file is succefully opened..this never happens cause the insane behavior starts as soon as the window is created.

I hope its a stupid error, but this behavior is tottaly nuts..its like some compile error just being detected after runtime..

I tried having a default constructor and a init function, same problem..

Share this post


Link to post
Share on other sites
My window procedure :

line 569

line 4079

-__-..my app is like a multifunctional based on its menu buttons..

I will resume it here:


static LRESULT CALLBACK WndProc( HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam ){

static BOOL bHullSetPointsFromInput = 0;
static Vector3 *pPoints = NULL;

switch( Msg ){

case WM_COMMAND:

switch( LOWORD( wParam ) ){
case 2000:{}break;
...
}
return 0;
default:
return DefWindowProc( hWnd, Msg, wParam, lParam );

}
}


I dont think it helps, here a screenshot:
http://i16.photobucket.com/albums/b29/0o--Karnage--o0/wndproc1.png

at case 4000 I have the class object:
case 4000:{//Rigging/Open

case 4000:{//Rigging/Open

//NOTEs:
//-for using the fbx sdk, the include directorie at the sdk path is setted
//on the project properties(C++ additional include diretories)
//-the lib directories also(linker additional lib dir)

//NOTE:files supported:
//autocad .dxf/Collada .dae/3D studio .3ds/alias .obj

//Open Dialog Stuff:
OPENFILENAME openFile = {0};

openFile.lStructSize = sizeof(OPENFILENAME);
openFile.hwndOwner = hWnd;

TCHAR szFilters[] = { TEXT("Autodesk FBX file\0*.FBX\0COLLADA\0*.DAE\0Obj\0*.OBJ\0\0") };
openFile.lpstrFilter = szFilters;

TCHAR szFileName[256] = { TEXT("\0") };
openFile.lpstrFile = szFileName;
openFile.nMaxFile = 256;

TCHAR szFileTitle[256] = { TEXT("\0") };
openFile.lpstrFileTitle = szFileTitle;
openFile.nMaxFileTitle = 256;

openFile.lpstrInitialDir = szRiggDir;

DWORD dwOpenFlags = OFN_DONTADDTORECENT|OFN_FILEMUSTEXIST|OFN_HIDEREADONLY|OFN_NONETWORKBUTTON;
openFile.Flags = dwOpenFlags;

TCHAR szExt[] = { TEXT("fbx") };
openFile.lpstrDefExt = szExt;


if( GetOpenFileName( &openFile ) ){
...

//timing data:-----------------------
timerlogger::TimerLog my( "myfile", 1000.0, timerlogger::eDAY_MONTH_YEAR_HMS );
FLOAT sec = 0.0f;//msec = 0.0f;
//----------------------------------



Simply commenting out the line timerlogger::... everything is ok..

If u have windows 7 you know that menus should look like this:
http://i16.photobucket.com/albums/b29/0o--Karnage--o0/particleNormalBlend.png

See the highlighted button? When my app go nuts, it looks like this:
http://i16.photobucket.com/albums/b29/0o--Karnage--o0/goingcrazy.png

None of the buttons works..with means it never reaches case 4000...
If I put a breakpoint in the windowsproc, it doesnt break, but the message loop stills loops..

I uploaded the .h and .cpp of the timerlog class on google docs, first time Im using it, dont know if everything is fine:
https://docs.google.com/leaf?id=0B_iN9pcbyoiKNDk2ZjhhZjAtOTFjYS00Yzg0LWE1MDItN2Y5YzQ2YzMxNzI2&hl=en&authkey=CKjzkaYB


https://docs.google.com/leaf?id=0B_iN9pcbyoiKYjUyZTVmMTItYTY1My00NDE1LTgwYTYtZDc4ZWY1N2I0YzVk&hl=en&authkey=CLnCw6gF

>_< I bet its a stupid thing..

Share this post


Link to post
Share on other sites
It have to be a crazy bug..I created a function that the only thing it do is calling the timerlog constructor:
void Foo(){
timerlogger::TimerLog myLog( "myfiletest", 1000.0, timerlogger::eDAY_MONTH_YEAR_HMS );
}

I replaced it on the windows procedure, it compiles and runs fine, so I put a breakpoint in the function call, when the code get there, I press f11 to enter the function..nothing happens..absolute notting happens, the yellow arrow disappear, it doesnt get at the function, so I press f10 and it continues like nothing happens..My vs is on crack..why things like this happens with me.. T_T Im depressive

Share this post


Link to post
Share on other sites
Is it possible your TimerLog function is throwing an exception? There's actually bug in Windows 7 where exceptions thrown inside a message loop are automatically caught.

http://support.microsoft.com/kb/976038

Try putting try/catch blocks around the function call and see if they catch anything

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
I never did exception handling before..shame on me, is this right:


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]

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
>___<

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?..

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement