From: Allamarein on
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
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
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
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
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.

--
 |  Next  |  Last
Pages: 1 2 3
Prev: gate II
Next: best way to pass arguments inside dlls