forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Bug with /UNDEF and global variables via COMMON in a DLL...
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
StamK



Joined: 12 Oct 2016
Posts: 56

PostPosted: Thu Mar 16, 2017 11:31 am    Post subject: Bug with /UNDEF and global variables via COMMON in a DLL... Reply with quote

If you declare a variable in a common block, and you define it in a subroutine(SET_DEFAULT), then if the subroutine is in a separate file but linked into the main.exe as an obj, then it works fine, but if the separate file is compiled and linked into a DLL, which then is loaded during compilation, then it will fail under UNDEF (reference to undefined variable).

ftn95 /windows /zero /f2k /cfpp /free /64 /undef /debug LIBRARIES.for
ftn95 /windows /zero /f2k /cfpp /free /64 /undef /debug main.f90
slink64 libraries.obj /file:libraries.dll
slink64 main.obj libraries.dll /file:main.exe

It fails also under 32bit.

Code:

SUBROUTINE SET_DEFAULT()
INTEGER*4 IVERS
INTEGER(kind=7) IADD

COMMON /EZ/ IVERS, IADD

 INTEGER*4 :: IVERS2 = 10
 INTEGER(kind=7) :: IADD2 = 30429112

 IVERS = IVERS2
 IADD  = IADD2
 
END SUBROUTINE


PROGRAM MAIN
INTEGER*4 IVERS
INTEGER(kind=7) IADD
COMMON /EZ/ IVERS, IADD
 

 CALL SET_DEFAULT()

 PRINT*,"IVERS=",IVERS
 PRINT*,"IADD=",IADD

END PROGRAM
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5043
Location: Salford, UK

PostPosted: Thu Mar 16, 2017 3:08 pm    Post subject: Reply with quote

That is what I would expect. Common blocks are linked via SLINK/SLINK64. They can't be linked dynamically at load time. In other words you can't share data between an executable and a DLL via a common block.
Back to top
View user's profile Send private message
StamK



Joined: 12 Oct 2016
Posts: 56

PostPosted: Thu Mar 16, 2017 6:02 pm    Post subject: Reply with quote

So I am guessing they would have to be in a module file if a DLL file is a used (and undef).
But in that case isn't is surprising that it works without UNDEF and the values are correct?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5043
Location: Salford, UK

PostPosted: Thu Mar 16, 2017 7:43 pm    Post subject: Reply with quote

Module data behaves in the same way as data in a COMMON block so it can't be linked at load time. Module functions are OK.

/UNDEF will reveal undefined data. If you don't use /UNDEF and you don't initialise the data then you will get garbage (hopefully zeros but maybe not). In your program the garbage must be having no visible effect.
Back to top
View user's profile Send private message
StamK



Joined: 12 Oct 2016
Posts: 56

PostPosted: Wed Mar 22, 2017 11:11 am    Post subject: Reply with quote

You are absolutely right. Actually we never had this problem before because all the files using variables defined in COMMON blocks would be linked into a single DLL, but because with the 64bit version we got an error, we had to split into multiple DLLs. I mentioned this last time, I believe you increased the buffer size and indeed we can now include more files in a DLL but still not all the ones we need - perhaps you could increase the buffer size a bit more?
Thanks
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5043
Location: Salford, UK

PostPosted: Wed Mar 22, 2017 12:36 pm    Post subject: Reply with quote

If it is the buffer that I am thinking of then it is currently set at 100 million bytes.
Back to top
View user's profile Send private message
StamK



Joined: 12 Oct 2016
Posts: 56

PostPosted: Wed Mar 22, 2017 3:01 pm    Post subject: Reply with quote

Would it be possible to increase the buffer size to, say, 200MB? This problem becomes more pronounced when we use debug files by the way, so we need to split into even more DLLs when using the debug option. Thanks
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5043
Location: Salford, UK

PostPosted: Wed Mar 22, 2017 4:10 pm    Post subject: Reply with quote

I will add this to the list.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5043
Location: Salford, UK

PostPosted: Wed Mar 22, 2017 4:49 pm    Post subject: Reply with quote

Here is a new SLINK64 for you to try...

https://www.dropbox.com/s/mhyia7e6tsa1qe9/Slink64_2.zip?dl=0
Back to top
View user's profile Send private message
StamK



Joined: 12 Oct 2016
Posts: 56

PostPosted: Wed Mar 22, 2017 5:01 pm    Post subject: Reply with quote

Thanks, I just downloaded it and replaced the older SLINK64. Unfortunately I am still getting the same error (not sure if the output below is helpful).

Runtime error from program:c:\program files (x86)\silverfrost\ftn95\slink64.exe
Access Violation
The instruction at address 0040482c attempted to write to location 13007000

00404568 load(<ptr>char) [+02c4]
00401000 main [+0a2b]

eax=06276000 ebx=06275eaa ecx=034feeaa
edx=03a306c0 esi=1da8e198 edi=13007000
ebp=0367ec8c esp=0367eba8 IOPL=1
ds=002b es=002b fs=0053
gs=002b cs=0023 ss=002b
flgs=00010246 [NC EP ZR SN DN NV]

0040482c rep
0040482d movsb
0040482e mov ebx,[edx+0x4]
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5043
Location: Salford, UK

PostPosted: Thu Mar 23, 2017 8:36 am    Post subject: Reply with quote

Here is another update for you to try...

https://www.dropbox.com/s/qs1eh3fyfq7qnjb/Slink64_3.zip?dl=0
Back to top
View user's profile Send private message
StamK



Joined: 12 Oct 2016
Posts: 56

PostPosted: Thu Mar 23, 2017 11:02 am    Post subject: Reply with quote

That seems to have fixed it! I have now included two large files in debug mode and I was able to link successfully. I will let you know if this problem pops up again. Great work!
Back to top
View user's profile Send private message
StamK



Joined: 12 Oct 2016
Posts: 56

PostPosted: Tue May 16, 2017 9:27 am    Post subject: Reply with quote

We are still having an issue with a large Fortran file (in 64bit only)- I need to split the actual Fortran file into smaller sized files, and then the linking works. We have just one DLL at the end (and not multiple like before), which is great, but for the linking to work, I need to split the Fortran file into smaller parts (via a script), recompile and link the smaller object files.
Do you think this is still a buffer size issue?
Thanks
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5043
Location: Salford, UK

PostPosted: Tue May 16, 2017 12:44 pm    Post subject: Reply with quote

If there is an internal buffer overflow when using SLINK64 then you should now get a clear error report to this effect.

How does the error present itself?
Back to top
View user's profile Send private message
StamK



Joined: 12 Oct 2016
Posts: 56

PostPosted: Wed May 17, 2017 10:09 am    Post subject: Re: Reply with quote

The only error I am getting is "***Corrupt symbol reference" and slink64 stops. Since by splitting into smaller files fixes the issue, I think it points to a buffer overflow rather than a symbol reference issue.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group