Is my Pelles C Debugger skipping lines?

[Hydronium]

I'm not sure if this has anything to do with a bug or if it's just the way Pelles C is supposed to work. Basically, I'll reach a breakpoint in my code and then use "Step Into" to continue. At a certain line, which are the source of other problems I'm trying to reproduce, my "Step Into" seems to execute "Go/Debug" instead, and all the debugger options become disabled as the program runs infinitely (there is an infinite loop, as this side project involves a Win API window). The screen i create still functions, but I can no longer Stop debugging. Additionally, moving to any other tab that is open (such as the source code) and the moving back to the Debugger tab shows me a blank page. All the views are blank (Auto, Local, Globals, etc).

The breakpoint was placed in a function that only gets called once, before reaching the while(!done) loop where window messages are handled. Is this standard Pelles C behavior? It's making it very difficult to tell what the problem is at the point where it begins running infinitely (and I know there is a problem there, but I don't know what).

I'm sorry if this sounds vague, or if there is a better place for this question. Doing a search for "debugger" only gave me 22 results, and the issue is similar to http://forum.pellesc.de/index.php?topic=2699.msg10200#msg10200 but this was unresolved.

[Bitbeisser]

It's pretty much impossible to give you a definitive answer as to what your problem is unless we could see the (whole!) source and your project settings...

The most common reason for something like you seem to be describing is either that a breakpoint is placed on a line of source code that isn't reached by the program logic or in case of a project consisting of several source files (and hence object files) with not all of them properly compiled with debug info enabled...

Ralf

[CommonTater]

Hydronium...
Ralf is right in that we're going to have to see your sourcecode to know what's going on.

Understand that the debugger is not running your source code line by line.  What's actually happening is that a series of markers are placed in the executable file and as the file runs, the debugger aligns a disiplay of your source code with the current marker in the program...  Thus if your program locks up, so does the IDE.

There are a couple of things you can try... Plase a number of breakpoints  before and after the problem code as well as in it. Now move through your code by clicking the GO button to move from break to break... observe your program's behaviour as you approach the bad spot. 

Another trick I commonly use is to place Beep(500,100); calls at different spots in the problem code... if it beeps I know it's reaching that part of the code... move the Beep along a bit, if it doesn't beep before messing up I know where the problem is.

But be warned... the debugger and various other tricks will help you find the place where it locks up...
figuring out why it locks up is your job. 

 
(Hi Ralf!)
 

[Hydronium]

I've uploaded my code on https://github.com/Hydronium/TimeSink. Also, the origin of this problem (before trying to reproduce it with the current modified code) is described in a stack overflow post, if you want a link to that as well.

[CommonTater]

I've uploaded my code on https://github.com/Hydronium/TimeSink. Also, the origin of this problem (before trying to reproduce it with the current modified code) is described in a stack overflow post, if you want a link to that as well.

In future... go into the POIDE Menu ... Project -> Zip Project Files ... post a message here explaining the problem, where it is, what happens and attach the zip ... we need the Pelles C project files to properly deduce the problem. 

I am not going to chase all over the net to find your source code and then still have to create my own projects to test it.

[Hydronium]

I wasn't aware you could do that, though in the end I needed to zip up some .bmps for the program to work, so I just did it manually. Plus it makes sense to do it, seeing as you wouldn't know my project settings etc. Sorry.

I've attached the 64bit and 32bit versions. 64bit is the one I'm actually working on, 32bit I made in case you have a 32bit system.

Basically I get to certain API calls and something seems to fail, at which point following API calls will be skipped (and they're from a separate, but similar, .dll).

The first case of this happens inside GetBitmap(), here:

Code: [Select]

      glActiveTexture(GL_TEXTURE0); <---------------------------Problem is here
      glGenTextures(1, &texture);      <---------------------------This and the following calls are skipped entirely to the end of the function
      glBindTexture(GL_TEXTURE_2D, texture);

      glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
      glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);

      glTexImage2D(GL_TEXTURE_2D,   /*Type of texture*/
                   0,               /*Level of Detail number*/
                   GL_RGB,          /*Internal format*/
                   bmWidthPx,       /*Width in texels(pixels?)*/
                   bmHeightPx,      /*Height in texels(pixels?)*/
                   0,               /*Border. Must be 0 (probably only for 2D)*/
                   GL_BGR,          /*Format, of the data the texture will be created from*/
                   GL_UNSIGNED_BYTE,/*Data type of the pixel data*/
                   bmBuffer);       /*Pointer to the image data to create the texture from*/
glActiveTexture comes from atio6axx.dll in 64bit (not sure in 32bit because the debugger lists EVERY dll as "untitled", don't know why. I assume it is the same or similar, as it would also be from AMD). The other functions i include afterwards are from OPENGL32.dll. If I comment out the glActiveTexture call, the following calls are called and executed.

This same issue happens here:

Code: [Select]

GLvoid InitGL(GLvoid)
{
      FnLdInit();
      GetBitmap();

      glClearColor(0.0f, 0.0f, 0.0f, 0.0f);           <-------OPENGL32.dll, good.
      glClearDepth(1.0f);                                  <-------OPENGL32.dll, good.
      glEnable(GL_DEPTH_TEST);                     <-------OPENGL32.dll, good.
      glDepthFunc(GL_LEQUAL);                      <-------OPENGL32.dll, good.

      glGenBuffers(1, &positionBufferObject);  <-------atio6axx.dll, BUT it works! positionBufferObject receives a value of 1! (this value is legitimate).
      errort = glGetError();                                <------this runs, and returns 0 (which means it either detected no errors, or it failed. OPENGL32.dll
      glBindBuffer(GL_ARRAY_BUFFER, positionBufferObject);   <----------atio6axx.dll. Stepping into this point causes the debugger to lose control to the window, and I cannot use any more buttons (step Into, Go/Debug, etc). I'm forced to close the tab to quit.
      errort = glGetError();
      glBufferData(GL_ARRAY_BUFFER, sizeof(thing), thing, GL_STATIC_DRAW);
      errort = glGetError();
      glBindBuffer(GL_ARRAY_BUFFER, 0);
      errort = glGetError();

      myProgram = CreateProgram();
}
All this code is a partial re-do of prior code which encountered a similar error, which I meant to debug with this (by scraping off some of the less necessary functions). That issue is outlined here: http://stackoverflow.com/questions/13433071/why-do-i-get-an-access-violation-in-atio6axx-dll-when-calling-glbindbuffer. That is part of the larger, precursor code. The problem is that this re-do does not recreate the exact same error, just a similar one dealing with the same code locations.

The reason I have come here is because I would like to know why the Pelles C debugger acts how it does upon reaching those API calls (the call-skipping and the debugger losing control after Step Into). If you can also assist me with my code issue, that would be nice as well, but not required (I can start a new post for that, and am already attempting to solve it on my own/with stackoverflow). If there's anything else you need from me, let me know. I'll get back to you ASAP, but it seems we're in different time zones (if you're local to this forum's time, as I am not).

Thank you for your assistance so far.

[CommonTater]

On my system it crashes as soon as it creates the window... If you add WS_VISIBLE to the styles it will crash right on the CreateWindowEX() or if you use your ShowWindow() it crashes there... Because... the hinstance passed into the program at WinMain is different than the one you're getting from GetModuleHandle() in your create window function.

A module's handle is NOT it's instance.  What you should do is store your global hinstance from the one passed in at WinMain() (which will be correct) and dispense with the GetModuleHandle() call, altogether. 

Another aspect of your problem is that you do exhorbitant error checking in some places where it's not really needed, and almost none in places where it is.  For example... you don't check your LoadLibrary() call or any of the GetProcAddress() calls at all but you have about 4 checks right after creating your window (which almost never fails, btw).

Best I can see, the debugger is working fine (Pelles ver 7.00.335), it led me right to the problem with the Instance handles...  The debugger locks up because your program locks up.  It skips lines because your program skips lines... It's tracing what your program does... which is what it's supposed to do.

Hope this helps...
 

[Hydronium]

I made the change you suggested regarding hInstance, but I still ran into the same error and my program's function did not change. I'm going to look into why GetModuleHandle(NULL) would return a different handle than the hInstance (and mine was different, like you said), though from what I've read they are used interchangeably and are supposed to be the same. I'll keep the change as you mentioned, since it makes more sense to use a HINSTANCE where it is required instead of using a HMODULE. Did you make the change as well, and come across the problems I mentioned? In the meantime I'm going to re-evaluate the reasons I'm using the WinAPI calls that I use. Maybe I have another mix up somewhere.

Thanks.

Edit: After looking around, it seems that HMODULE and HINSTANCE for a process are supposed to be interchangeable. I'm not disputing that the value of hInstance and the return value of GetModuleHandle(NULL) were different (14000D2D8 for hInstance, 140000000 for GMH), but could you explain why this might be the case? All the places I've looked explain that after 16bit windows, win32 and beyond were created with HINSTANCE and HMODULE pointing to the same place. Do you have any information on this? Do you also have any insight as to why (in my case, apparently not in yours) changing it had no effect on my program?

http://blogs.msdn.com/b/oldnewthing/archive/2004/06/14/155107.aspx
http://cboard.cprogramming.com/windows-programming/70479-getmodulehandle-null-vs-hinstance.html
http://stackoverflow.com/questions/2126657/how-can-i-get-hinstance-from-a-dll

Also, according to http://msdn.microsoft.com/en-us/library/windows/desktop/ms633559%28v=vs.85%29.aspx:

Code: [Select]

hInstance [in]

    Type: HINSTANCE

    A handle to the current instance of the application.
So it turns out that they're both handles.

The ridiculous error checking is the side effect of a) basing my work off a tutorial b) never going back to clean it up because it works. Not necessarily the correct way to do things, I'll admit. Right now the loadlibrary functions work. When they stop working, i'll diagnose why and act.

Also, my program does not crash with/without WS_VISIBLE, with or without fixing GetModuleHandle(NULL). Not sure why yours is crashing yet mine is not.

I'll keep tinkering. Thanks again.

[aardvajk]

Consider when you call ShowWindow
Consider what happens when that calls your WndProc with WM_SIZE
Consider glViewport
Consider when you actually give glViewport a value

Then consider this as to why the 64-bit version crashed the first time and then never again, and the 32-bit one never crashed at all.

[CommonTater]

In my experience the only occasion of HInstance that is always correct is the one passed in on WinMain.  I have no explaination why GetModuleHandle is returning different values... but it is.  What I can tell you is that even if they are both handles, there's no reason to assume that two functions using them will return the same handle.

In your place, I would place all of the gl, hdc, etc. initialization steps in a WM_CREATE handler, not in the same function.  That way you can be absolutely sure your system is registering it's class, creating the window, tossing messages and generally active before you start getting fancy.  You actually should register the class and make the main window right in WinMain (which is why the handles are passed to WinMain).  The sequence should be WinMain -> Check mutexes etc -> register your class -> Create your window -> straight into the message tosser.  Everything else should be done via messages...

Similarly, I would place all the close out functions in a WM_CLOSE handler, then call DestroyWindow() after you are sure you've got a clean shutdown.

To not error check a disk operation such as LoadLibrary() is just begging for sporadic unexplained failures.  If that disk read fails, every function address after it will be either null or incorrect, depending on what GetProcAddress() finds. This code is core to your system, it's silly not to trap it.  It might never fail... but the one time it does you will be glad of the error message.

As to why it hangs when creating a window... I dunno.  Perhaps your best bet is to take a short side trip, write a small proggy that successfully creates a window, as described... and then slowly add your stuff to it, one step at a time, testing as you go...

[CLR]

It works for me. I can set a breakpoint, and step into, etc.
However, glActiveTexture comes from ig4icd64.dll in my computer; see attachment.

[TimoVJL]

As aardvajk pointed out, there is an error in InitGL() / FnLdInit() usage.

[Hydronium]

Consider when you call ShowWindow
Consider what happens when that calls your WndProc with WM_SIZE
Consider glViewport
Consider when you actually give glViewport a value

Then consider this as to why the 64-bit version crashed the first time and then never again, and the 32-bit one never crashed at all.

As aardvajk pointed out, there is an error in InitGL() / FnLdInit() usage.

I never thought that ShowWindow would send a WM_SIZE message, and before ever encountering my crashing problem it was never a problem (the glViewport call never failed, that I recall). I've since changed the ordering so that OpenGL functions are properly set up before ShowWindow, just in case. This hasn't changed the nature or effect of my problem, though, since with InitGL happening before the first ShowWindow call it breaks on the atio6axx.dll access violation before it ever reaches ShowWindow. Did I go in the completely wrong direction with what you guys meant though?

As to your last point: my program never crashed up until recently, at which point it repeatedly does. When I tested it in 32bit it does not crash when run (like you said) but upon debugging it still encounters the Access Violation error, in the same way my 64bit one does. Maybe I'm missing the point of your statement; if so, could you clarify? I followed the links and I'll look into creating a manifest; I visited that registry key and saw the same thing from that stackoverflow post, so it is clearly happening.

Thanks.

In my experience the only occasion of HInstance that is always correct is the one passed in on WinMain.  I have no explaination why GetModuleHandle is returning different values... but it is.  What I can tell you is that even if they are both handles, there's no reason to assume that two functions using them will return the same handle.

In your place, I would place all of the gl, hdc, etc. initialization steps in a WM_CREATE handler, not in the same function.  That way you can be absolutely sure your system is registering it's class, creating the window, tossing messages and generally active before you start getting fancy.  You actually should register the class and make the main window right in WinMain (which is why the handles are passed to WinMain).  The sequence should be WinMain -> Check mutexes etc -> register your class -> Create your window -> straight into the message tosser.  Everything else should be done via messages...

Similarly, I would place all the close out functions in a WM_CLOSE handler, then call DestroyWindow() after you are sure you've got a clean shutdown.

To not error check a disk operation such as LoadLibrary() is just begging for sporadic unexplained failures.  If that disk read fails, every function address after it will be either null or incorrect, depending on what GetProcAddress() finds. This code is core to your system, it's silly not to trap it.  It might never fail... but the one time it does you will be glad of the error message.

As to why it hangs when creating a window... I dunno.  Perhaps your best bet is to take a short side trip, write a small proggy that successfully creates a window, as described... and then slowly add your stuff to it, one step at a time, testing as you go...

CreateGLWindow is the first function called, so merely moving all those lines from the function into WinMAIN wouldn't make any noticeable change except to eliminate variable passing. Nevermind, I misread.

I don't error-check GetProcAddress() because it has worked so far, and I can see the value of the PFN when debugging if I need to see if it is null (and I did this extensively while trying to implement it). I have no way of knowing what the true value of it should be, beyond it's name and an offset into the DLL.

According to this and this I couldn't see any way of verifying the exact address of any particular function. Either it returns NULL or some address, which may or may not be correct. The wgl ones in particular vary from context to context, which makes it more difficult (unless I misinterpreted what the MSDN said).

Thanks.

It works for me. I can set a breakpoint, and step into, etc.
However, glActiveTexture comes from ig4icd64.dll in my computer; see attachment.

I run Windows 7, 64bit Home edition with a Radeon HD 6850. The atio6axx.dll is AMD(or ATI)'s OpenGL driver. ig4icd64.dll is nVidia's OpenGL driver.

Did you run this without any of the modifications discussed thus far? If so, it would seem that my WinAPI code is not the (biggest) problem.

[CLR]

Did you run this without any of the modifications discussed thus far?

Yes.

[CommonTater]

I don't error-check GetProcAddress() because it has worked so far, and I can see the value of the PFN when debugging if I need to see if it is null (and I did this extensively while trying to implement it). I have no way of knowing what the true value of it should be, beyond it's name and an offset into the DLL.

Very simply ... how do you know it worked?
 
If your LoadLibrary() call fails --the library is missing, the paths are wrong, your disk is crapping out, etc.-- all those GetProcAddress() calls are going to fail, returning nulls... and your function is going to return just like everything went perfectly.  What impact do you think that would have on the rest of your program?
 
"It's always worked so far" does not cut it when the code is "mission critical"...
 

According to this and this I couldn't see any way of verifying the exact address of any particular function. Either it returns NULL or some address, which may or may not be correct. The wgl ones in particular vary from context to context, which makes it more difficult (unless I misinterpreted what the MSDN said).

You are looking for total failure...
 

Code: [Select]


if (! LoadLibrary(...))
  ReportFatalError();
 
if (! GetProcAddress(...  ))
  ReportFatalError();

When it cannot fetch the address of the function (for any reason) it returns NULL... signalling failure.  If it returns an address, it will be the correct address.
 
 
Also I am in agreement with the others who are pointing out flaws in your sequence of events... You really have to go at this incrementally... as already suggested, get the window showing up, resizing and closing, first then add the GL stuff in bits and pieces, testing as you go.