View previous topic :: View next topic |
Author |
Message |
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Thu Mar 16, 2017 11:31 am Post subject: Bug with /UNDEF and global variables via COMMON in a DLL... |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Thu Mar 16, 2017 3:08 pm Post subject: |
|
|
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 |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Thu Mar 16, 2017 6:02 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Thu Mar 16, 2017 7:43 pm Post subject: |
|
|
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 |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Wed Mar 22, 2017 11:11 am Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Wed Mar 22, 2017 12:36 pm Post subject: |
|
|
If it is the buffer that I am thinking of then it is currently set at 100 million bytes. |
|
Back to top |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Wed Mar 22, 2017 3:01 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Wed Mar 22, 2017 4:10 pm Post subject: |
|
|
I will add this to the list. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
|
Back to top |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Wed Mar 22, 2017 5:01 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
|
Back to top |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Thu Mar 23, 2017 11:02 am Post subject: |
|
|
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 |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Tue May 16, 2017 9:27 am Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Tue May 16, 2017 12:44 pm Post subject: |
|
|
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 |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Wed May 17, 2017 10:09 am Post subject: Re: |
|
|
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 |
|
|
|