Using debug under Vista - Vista stops prog.
Open Source C & C++ IDE for Windows
Brought to you by:
claplace
Menu
▾
▴
Version 4.9.9.2
Cannot offer a piece of code that demonstrates the problem as you will see.
Likewise a compile log cannot be available given the nature of the problem.
I have just got Dev-Cpp up and running on my new system.
HP system
OS=Vista Home Premium 32bit.
CPU=Q6600 - quad 2.4 GHz core.
When I try to run under debug to stop at cursor Vista produces the message that the programme under test has stop running and will be closed. At the same time is is paled out in the usual way. Note: the programme under test is reported as stopped; not Dev-Cpp or the debugger.
Anyone had this experience? Are others finding their system debugs normally under Vista? Does anyone have a solution to this?
Blue Meanie.
We could perhaps help you if you give information about your problem. Once again you have failed to provide the build log. You typed a lot of words talking abuot the log, but that was wasted effort - what are we supposed to do with that!?
If you did not include the appropriate header for the functions you use how did it ever compile?
The Win32 API documentation on MSDN specifies header file for all calls (usually at the bottom of the page, along with teh library that must be linked - although not using the GNU naming convention) . What calls specifically are you having trouble with?
You know you could always do a text search on the header files to locate the headers related to specific functions.
> Then having switched on -Wall and -Werror as advised it spewed a ton of errors for the include file!
That was rather the point. Don't count them, read them! Quantity is irrelevant. The chances are that the majority of them have a single root cause.
> come back when I have made some progress with this.
You seem to be just 'chatting', you could make progress with it far quicker if you post the information requested, but you seem reluctant to do so at every turn. If that continues to be the case we will not be able to assist. Why are you here if you don;t want or need assistance?
> Cannot offer a piece of code that demonstrates
> the problem as you will see.
Nothing in your post justifies that statement. Why can you not post the code?
> Likewise a compile log cannot be available
> given the nature of the problem.
That does not follow either. If it built, there is a build log.
> When I try to run under debug to stop at cursor [...]
Is it possible that your program is crashing before the break-point?
Does the program also crash if you simply execute it in teh normal way (i.e. not under the debugger)?
To be honest, you are lucky to get the Dev-C++ GDB integration working at all, if even if you do, it sucks. It is the primary reason I no longer use Dev-C++.
> At the same time is is paled out in the usual way.
I have no ideal what you mean. What is 'paled out', and how is it 'usual'?
Since VC++ 2008 Express is both free, and has an excellent debugger (probably the best available), I suggest that you try it under that. Even if you have a good reason for using Dev-C++, using an alternative tool for debugging is still a good idea. I often use more than one compiler to find more bugs. VC++ also has better Vista compatibility, so is a no-brainer IMO.
Clifford
The reason I don't post the code is because the code is not the problem.
Nor the compilation. To address the salient questions.
>Is it possible that your program is crashing before the break-point?
No. When the prog is run without the debugger it gets to that point satisfactorily.
The programme is an icon builder; it fails during the open and load function. It generates the coded error 'This is not an ICON file' because it fails to find a 1 in the idType word of the icon (ICONDIR) header. I wanted to stop at that point a check the contents of the structure that accepts the (ICONDIR) info.
When I run the programme using debug it crashes; it does not crash when executed normally. Under normal execution it displays the error message window and then returns to the main part of the code as it should.
The breakpoint is set at the first line of the test for idType != 1 and execute the error function if this is true. According to MSDN the idType should be 1 for an ICON.
Therefore the code should get to the breakpoint without crashing. This is not a compilation problem; and it is not a code problem; it very much looks like a debugger problem. It only stopped by Vista when the debugger is running.
As for VC++ the current Dev-C++ is referred to as 5 beta which I take to indicate that it is in development.
I may take a look at VC++ later. For the present I want to sort out why I can't debug normally with everything as it was on my previous system but for the new hardware and OS.
Blue.
> The reason I don't post the code is because the
> code is not the problem.
But it crashes. What makes you so certain?
> Nor the compilation.
Your choice, but if when it comes down to it, it turns out to be a problem with your installation or project options that could have been spotted from the compile log you will have wasted other peoples time and your own. Whereas simply copying & pasting it will have cost you nothing, even if it turns out to be clean and can be ignored. It would have been quicker to have just done that than it would have to have given bogus excuses for not doing so!
Make sure you compile with -Wall -Werror and fix any warnings that are emitted.
> No. When the prog is run without the debugger
> it gets to that point satisfactorily.
That is not the same thing at all. It is entirely possible (in fact common) for bugs to cause failure in the debugger but not without - or vice versa. A bug that corrupts memory or makes an invalid access may or may not cause an OS trap exception depending on what it corrupts and when, and the different execution environment may affect this. A more appropriate test, would be to place the break point on the first executable statement in main() and see if it gets that far. As I said the debugger sucks, and I can believe that it fails before your code even runs, but if you want remote assistance, you have to provide good information and evidence.
> When I run the programme using debug it crashes;
> it does not crash when executed normally.
Sounds like a bug in your code to me - one that exhibits different symptoms under different execution environments. That said, I would still not trust this debugger in any case.
> The programme is an icon builder; it fails
> during the open and load function. [...]
I am not sure that simply describing your code helps! ;-)
> [...]and it is not a code problem; it very much
> looks like a debugger problem.
You may be right, but Occam's Razor suggests otherwise. The behaviour you describe is not uncommon, and does not suggest a debugger failure.
> the current Dev-C++ is referred to as 5 beta
> which I take to indicate that it is in development.
The nature of open source software is to never be complete! However Dev-C++ has not been developed for several years now. However 4.9.9.2 is the latest and most reliable version. Be aware however that Dev-C++ is neither a compiler or debugger, just an IDE fro GCC and GDB. That said most of the debugger problems are related to the Dev-C++ integration rather than GDB itself (which still sucks as it happens).
> For the present I want to sort out why I can't debug
> normally with everything as it was on my previous
> system but for the new hardware and OS.
Almost certainly (twenty years of C programming tells me so) the bug was always there, but merely manifests itself differently in a different execution environment. I would make the move to VC++ immediately. When the program causes an exception, the debugger will show you the precise instruction that caused the failure, and you can unwind the call stack to determine where in your code this occurred and what the variable state was at that time. All of that is either impossible or very difficult in Dev-C++. You may save yourself a lot of time.
Clifford
A couple of notes here:
One important point in posting code is that it provides a means for the person helping you to try and duplicate the problem that you are seeing.
Posting the log shows how the code is being compiled. Compile options are important in how your code works in the debugger, no?
And please avoid the "It works on platform X, so the code is correct" pitfall. We all have done it at some point or other, but it is still logically flawed.
Wayne
Re Wayne.
I took Clifford's advice and started at the first instruction inside winmain.
I was able to step through instructions normally.
I advanced on the piece that was broken and I seem to have a problem with an include.
One of the problems is that neither the Win32 help module nor MSDN provide the required includes for each function call.
Then having switched on -Wall and -Werror as advised it spewed a ton of errors for the include file!
I haven't had a lot of time in the last few days which is why I have not made much progress and have not got back.
I think I had better wrap this thread and come back when I have made some progress with this.
Blue.