Errrors while debugging in Compaq Visual Fortran 6.6
in [Fortran]
|
Prev: gate II
Next: best way to pass arguments inside dlls
From: Allamarein on 18 Jul 2010 05:28 I've just installed CVF 6.6 on my windows xp. Now I don't have problems that I found by Vista. Now it compiles, builds and runs as it should. Anyway I tried to debug a my code and I get this error: Loaded 'ntdll.dll', no matching symbolic information found. Loaded 'C:\WINDOWS\system32\kernel32.dll', no matching symbolic information found. Besides a pop-up window writes 'One o more breakpoints are not positioned on valid lines. These break points have been moved to the next valid line' I understand the pop-up windows, but the previous errors? I premise I didn't install Microsoft Visual Studio on my machine.
From: dpb on 18 Jul 2010 09:52 Allamarein wrote: > I've just installed CVF 6.6 on my windows xp. > Now I don't have problems that I found by Vista. > Now it compiles, builds and runs as it should. > Anyway I tried to debug a my code and I get this error: > > Loaded 'ntdll.dll', no matching symbolic information found. > Loaded 'C:\WINDOWS\system32\kernel32.dll', no matching symbolic > information found. > > Besides a pop-up window writes 'One o more breakpoints are not > positioned on valid lines. These break points have been moved to the > next valid line' > > I understand the pop-up windows, but the previous errors? > I premise I didn't install Microsoft Visual Studio on my machine. Sounds like you broke in the OS dll which isn't compiled w/ debug information. CVF is simply telling you that. W/ no user code one can only presume and what comes to me is one of two things -- either you're trying to use a Win API or one of the compatibility routines and there's a problem in the call sequence or there is still an issue w/ the installation. Oh, I don't know if it's likely could be the cause of the symptom but I wonder if one tried linking a combination of built for console and windowed object files or similar if the startup code might be confused and end up in debugging mode that way... Undoubtedly there are other things that could be causes but those are what strike me at the moment. If it's a console app, I'd first simply start it w/o the debugger and see what symptoms are shown; that might be quite informative. If not, I'd do a careful check for consistency within the project settings, etc. as noted above. Since it seems that you have been successful in building at least some sample code/executable I'd tend to presume there's a fault in this one over the installation but there's a case that w/o anything at all to look at there's nothing to say but "Houston, we have a problem..." --
From: Allamarein on 18 Jul 2010 10:48 On 18 Lug, 15:52, dpb <n...(a)non.net> wrote: > Allamarein wrote: > > I've just installed CVF 6.6 on my windows xp. > > Now I don't have problems that I found by Vista. > > Now it compiles, builds and runs as it should. > > Anyway I tried to debug a my code and I get this error: > > > Loaded 'ntdll.dll', no matching symbolic information found. > > Loaded 'C:\WINDOWS\system32\kernel32.dll', no matching symbolic > > information found. > > > Besides a pop-up window writes 'One o more breakpoints are not > > positioned on valid lines. These break points have been moved to the > > next valid line' > > > I understand the pop-up windows, but the previous errors? > > I premise I didn't install Microsoft Visual Studio on my machine. > > Sounds like you broke in the OS dll which isn't compiled w/ debug > information. CVF is simply telling you that. > > W/ no user code one can only presume and what comes to me is one of two > things -- either you're trying to use a Win API or one of the > compatibility routines and there's a problem in the call sequence or > there is still an issue w/ the installation. > > Oh, I don't know if it's likely could be the cause of the symptom but I > wonder if one tried linking a combination of built for console and > windowed object files or similar if the startup code might be confused > and end up in debugging mode that way... > > Undoubtedly there are other things that could be causes but those are > what strike me at the moment. > > If it's a console app, I'd first simply start it w/o the debugger and > see what symptoms are shown; that might be quite informative. > > If not, I'd do a careful check for consistency within the project > settings, etc. as noted above. > > Since it seems that you have been successful in building at least some > sample code/executable I'd tend to presume there's a fault in this one > over the installation but there's a case that w/o anything at all to > look at there's nothing to say but "Houston, we have a problem..." > > -- Yeah, I think the problem it is the debugger, because my code work greatly in release mode. Installing Visual Studio can help?
From: dpb on 18 Jul 2010 11:13 Allamarein wrote: .... > Yeah, I think the problem it is the debugger, because my code work > greatly in release mode. > Installing Visual Studio can help? If the code doesn't fail w/o the debugger but is stopping when built w/ debugging I'd guess you have a breakpoint set or are starting w/ "step" or "step into" instead of "run" that's causing the debug window to open. I have CVF 6.6 but use the interactive debugger so little I can't otomh tell you where or how specifically to clear all breakpoints w/o searching myself, but I'm quite confident it can be done. I don't suspect there's anything about VS you need to do; only figure out how to use the debugger itself in the IDE. --
From: dpb on 18 Jul 2010 15:05
dpb wrote: > Allamarein wrote: > ... > >> Yeah, I think the problem it is the debugger, because my code work >> greatly in release mode. >> Installing Visual Studio can help? > > If the code doesn't fail w/o the debugger but is stopping when built w/ > debugging I'd guess you have a breakpoint set or are starting w/ "step" > or "step into" instead of "run" that's causing the debug window to open. .... As a followup to the above, note the following in the Debugger Help... > Step Into Single-steps through instructions in the program, and > enters each function (or subroutine) call that is encountered. With > Visual Fortran programs, avoid using this menu command for initial > program execution. Instead, set a breakpoint or insertion point at > the first executable line of Fortran source code and either use Go or > Run to Cursor. This avoids entering the Visual Fortran run-time > initialization code that is executed before your main Fortran routine I'm virtually certain it's this you're seeing given the symptom description. -- |