Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

No Source Code Available from DLL

blackre3
Beginner
1,143 Views
I am trying to debug a FORTRAN DLL that is being called from Visual Basic. The FORTRAN Subroutine looks like this:

-----
subroutine SFA(STRING_IN)

!DEC$ ATTRIBUTES DLLEXPORT,STDCALL,REFERENCE,ALIAS:"SFA" :: SFA
!DEC$ ATTRIBUTES REFERENCE :: STRING_IN
CHARACTER(10), INTENT(IN) :: STRING_IN

etc


Return
End
------


When I step into the subroutine it lands on the "Subroutine" line, when I click "Step Into" again it says that there is no source code available for the current location.

After reading some other posts here, I tried to click "Step Over" when I got into the subroutine but it quickly exits the DLL and returns me to Visual Basic then shows me a message saying "No symbols are loaded for any call stack frame. The source code cannot be displayed."

If I take the code out of the DLL and compile it as it's own project, it runs fine.

In the Visual Basic Debug properties, I have "Enable unmanaged code debugging" checked if that matters.

Is there some compiler setting or debugging setting that I need to set to be able to debug the code once I step into the DLL subroutine?

Thank you.
Rob
0 Kudos
6 Replies
netphilou31
New Contributor III
1,143 Views
Hi bob,
Have you tried to debug the dll directly using the Visual studio environment ?
You have just to declare the main program to debug in your project settings.
Are you sure that the DLL has been build using the Debug configuration ?
Regards,
0 Kudos
blackre3
Beginner
1,143 Views
Thank you for your reply.

If I go into Configuration Manager it says that both the Visual Basic and FORTRAN projects are in Debug.

I am not sure what you meant by your first suggestion.

I tried the following
1. In MVS2008, went to the solution properties and told it that the Startup Project should be the Fortran DLL. When I run it it says "Visual Studio cannot debug because a debug target has not been specified".

2. Not knowing what that error meant, I then added the following code to my Fortran so that it looks like this:

Program STATRH_FORTRAN
Call SFA("C:\VB\testcase_slotted tube.INP")
End



subroutine SFA(STRING_IN)

!DEC$ ATTRIBUTES DLLEXPORT,STDCALL,REFERENCE,ALIAS:"SFA" :: SFA
!DEC$ ATTRIBUTES REFERENCE :: STRING_IN
CHARACTER(10), INTENT(IN) :: STRING_IN

etc

Return
End


I get the same error.

Sorry as I am new at this but I am just wanting to debug the FORTRAN DLL when it is called from Visual Basic. If I can't get this to work I will have to just have the Visual Basic call a standalone FORTRAN executable and use an intermediate text file to pass information between the two, but that is kind of unprofessional.

Thanks again for your help.
Rob
0 Kudos
IanH
Honored Contributor III
1,143 Views
The problem may lie elsewhere, but in the meantime check that you don't have multiple copies of the DLL on your system.

To solve the error message associated with your step one, in addition to marking the DLL project as the startup project, in the Visual Studio project properties for the DLL on the "Debugging" page set the "Command" property to be your VB executable. Then set a break point inside your DLL, and run the program via "Start debugging". The command can be any program that loads and calls your DLL.
0 Kudos
netphilou31
New Contributor III
1,143 Views
Rob (not bob sorry for the mispelling)

My question was based on the assumption that you have a Visual Basic program on one side, trying to call a Fortran dll belonging to a different solution. In this case you can define in the fortran project properties window the executable to debug (indicating the location of the Visual Basic program built separately, sorry to not include a screenshot as I use only VS2005 and in French !). Anyway, with these setting, VS should start the VB executable and when the fortran dll should be called when needed so you should be able to stop in the fortran code. However, if both projects belong to the same solution I don't understand why the debugger is unable to enter the fortran dll !
Regards,
Phil.
0 Kudos
blackre3
Beginner
1,143 Views
Here is where I am now. They are in the same project.

To help diagnose this, I stripped away most of my code in the DLL. This is now the complete DLL:

subroutine SFA(STRING_IN)

!DEC$ ATTRIBUTES DLLEXPORT,STDCALL,REFERENCE,ALIAS:"SFA" :: SFA
!DEC$ ATTRIBUTES REFERENCE :: STRING_IN
CHARACTER(10), INTENT(IN) :: STRING_IN

CHARACTER*80 TITLE
CHARACTER*260 FNAME,FNAMEI,FIRFILE

NAMELIST/INPUT/TIME,PC,F

open (1,File='C:\sfainput.dat',STATUS='OLD')
read (1,'(A)') FNAME
FNAMEI=FNAME
read (1,'(A)') FIRFILE
close (1)
Return
End

Below is the Visual Basic code that is getting executed.

Option Strict On
Option Explicit On
Imports VB = Microsoft.VisualBasic
Imports System.Threading
Imports System.Math
Imports System.Runtime.InteropServices


Public Class Form1
Inherits System.Windows.Forms.Form
Public Declare Sub SFA Lib "..\..\..\SFA\debug\sfa.DLL" (ByVal STR_IN As String)


...some other subroutines that aren't relevant...


Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Call SFA("hi")
End Sub
End Class


When I run in debug and step into the DLL (breakpoint at "Call SFA("hi")" line), it goes into the DLL, opens the file (open (1,File='C:\sfainput.dat',STATUS='OLD')), reads the line and everything is fine. When I take the next step "FNAMEI=FNAME" then I get the "There is no source code available for the current location" message again.

If I say "Step Over" the offending (FNAMEI=FNAME) line it continues on without further incident.



This is really puzzling me, but maybe the above diagnostics will spark some thought that would help?

Thanks,
Rob
0 Kudos
IanH
Honored Contributor III
1,143 Views
So breakpoints in the fortran subroutine work (you can step over lines without problems) and it is just a step-in on the assignment statement that's troubling you? If so - looks like the debugger wants the source code for the underlying C or fortran runtime library call. I think this is an environment (VS IDE settings) problem - not a source code problem. Have a look under Tools > Options for possible culprits. Under my VS2005 environment here everything works as expected with VB to fortran.

0 Kudos
Reply