View previous topic :: View next topic |
Author |
Message |
ljfarrugia
Joined: 06 Jun 2016 Posts: 35
|
Posted: Mon Dec 06, 2021 7:24 pm Post subject: corrupt object module when compiling huge program with debug |
|
|
Hello
When trying to compile a very large program (source code primarily in one large file) in debug mode with the /debug compiler option, it fails with a message that the object module is corrupt. Is there anything I can try?
Louis |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Mon Dec 06, 2021 7:47 pm Post subject: |
|
|
First delete the object file. This is the file with the extension .obj.
Then try to compile the source file by running the compiler FTN95. Try without any compiler options first and see if any compilation errors are reported.
In the worst case, split the large file into small parts taking (say) a few hundred lines at a time. You must put the whole of the main program in one file. Each module and subprogram could have a file each.
Compile each small file one at a time. |
|
Back to top |
|
|
ljfarrugia
Joined: 06 Jun 2016 Posts: 35
|
Posted: Mon Dec 06, 2021 7:52 pm Post subject: |
|
|
Thanks Paul
The source file compiles without any problems if I do not use the debug flag. Is the size of the source file the issue here? Its just under 165,000 lines of code. Would splitting it up into smaller files solve this problem?
Louis |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Mon Dec 06, 2021 7:56 pm Post subject: |
|
|
The size of the file will not be a problem for the compiler but smaller files will help you to locate what is going wrong.
Are you using Plato or compiling from a command prompt? |
|
Back to top |
|
|
ljfarrugia
Joined: 06 Jun 2016 Posts: 35
|
Posted: Mon Dec 06, 2021 9:59 pm Post subject: |
|
|
Thanks
I use the command line. Are you suggesting that using smaller files will get round the corrupt object file problem? I'm not really clear why this is happening.
Louis |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Tue Dec 07, 2021 8:56 am Post subject: |
|
|
No. Smaller files just help you to locate the bug that is causing the problem.
If your program fails to compile (has compilation errors) then the object file is created but is marked as corrupt. So you need to find the bug or bugs in your code.
Under normal circumstances the compiler will report the compilation errors quite clearly. So either there is some wrong with how you are running FTN95 or you have very strange code.
Does FTN95 report simple errors such as a missing bracket? |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Tue Dec 07, 2021 10:31 am Post subject: Re: |
|
|
ljfarrugia wrote: | Thanks Paul
The source file compiles without any problems if I do not use the debug flag. Is the size of the source file the issue here? Its just under 165,000 lines of code. Would splitting it up into smaller files solve this problem? |
Object files are larger when compiled with the debug flag.
Louis, are you aware that there are available utility programs, usually named fsplit or f90split, that can take your large source file as input and place each subprogram in it into a separate file?
See for example, https://people.math.sc.edu/Burkardt/f_src/f90split/f90split.html . |
|
Back to top |
|
|
ljfarrugia
Joined: 06 Jun 2016 Posts: 35
|
Posted: Thu Dec 09, 2021 6:41 pm Post subject: |
|
|
Hello
Still trying to track source of the problem. One thing I don't understand is why some .MOD files for modules do not seem to be created and which may be the cause
The code below is taken from this huge program (incidentally not written by myself). When it is compiled and linked (on command line) the .EXE file is created but not a .MOD file for the module. This is the same when the large code sources is compiled. All the other .MOD files seem to be there. Is this the expected behaviour?
MODULE com3
INTEGER :: ITOP
INTEGER :: NGRID
REAL :: STHM
END MODULE com3
PROGRAM MAIN
call pla351
end program main
SUBROUTINE PLA351
C * THIS ROUTINE IMPLEMENTS THE CHARGE FLIPPING CONCEPT - Oszlanyi et al.
USE com3
end |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Thu Dec 09, 2021 7:35 pm Post subject: |
|
|
There must be a mod file somewhere otherwise the compiler would report it as missing.
com3 does not have object code in a .obj file because it does not contain any executable code. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Thu Dec 09, 2021 8:20 pm Post subject: |
|
|
I think that the module/file name that Louis chose is clashing with one of the predefined device names in MSDOS/Windows. COM1, COM2, COM3, COM4 used to be serial communications ports (for RS232 devices such as modems, terminals, mice and printers).
Even on today's PCs, one can plug in a GPS receiver into a USB port and the receiver can send GPS data to the PC as if the USB port were a 4800 baud serial port.
Here is an example.
Code: | s:\lang\ftn95>type fcom.f90
MODULE com3
INTEGER :: ITOP
INTEGER :: NGRID
REAL :: STHM
END MODULE com3
s:\lang\ftn95>copy fcom.f90 com3.f90
The system cannot find the file specified.
0 file(s) copied.
s:\lang\ftn95> |
Note that the file copy failed because the destination file name began with "com3".
A slightly different example, this time using the device name CON:
Code: | s:\lang\ftn95>copy fcom.f90 con.f90
MODULE com3
INTEGER :: ITOP
INTEGER :: NGRID
REAL :: STHM
END MODULE com3
1 file(s) copied.
s:\lang\ftn95>dir con.*
Directory of \\.
File Not Found |
This time, the name "con.f90" got interpreted as the console device CON:, and that is why we see the lines copied to the console rather than to a disk file, and after the copying was completed there is no file on disk with the name of the copy destination. |
|
Back to top |
|
|
ljfarrugia
Joined: 06 Jun 2016 Posts: 35
|
Posted: Thu Dec 09, 2021 9:16 pm Post subject: |
|
|
Hello
I wasn't complaining that there was no object file for module COM3, but that there was no .MOD file after compilation. If you are compiling code which spreads over many files, I suppose these mod files are needed for subsequent source file being compiled which use module COM3, which has been defined in another source file.
In any case the comment about the name COM3 seems to be correct. I changed the module name COM3 to COMTHREE and the file COMTHREE.mod now appears after compilation. I wonder if there are other forbidden names for modules?
Louis |
|
Back to top |
|
|
ljfarrugia
Joined: 06 Jun 2016 Posts: 35
|
Posted: Thu Dec 09, 2021 9:20 pm Post subject: |
|
|
Dear Paul
The compiler did not report that the .MOD file was missing, it just hung up.
This was when I created a debug version using the /debug command line flag.
If I created a standard executable without /debug compiler flag, then the compilation ran to completion without reporting any errors.
Louis |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Fri Dec 10, 2021 12:24 am Post subject: Re: |
|
|
ljfarrugia wrote: | I wonder if there are other forbidden names for modules? |
The limitation on allowable file names is attributable to the operating system, not the Fortran language or the Silverfrost compiler. See https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file , where it says:
"Do not use the following reserved names for the name of a file:
CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Also avoid these names followed immediately by an extension; for example, NUL.txt is not recommended. "
I combined your sources in logical order into a single source file:
Code: | module com3
implicit none
integer :: itop, ngrid
real :: sthm
end module com3
subroutine pla351()
use com3
implicit none
print *,itop,ngrid,sthm
end
program main
implicit none
call pla351
end program main
|
The FTN95 compiler crashed when I attempted to compile this file, with the message:
Code: | Access Violation
The instruction at address 0045e0f6 attempted to read from location 00000000 |
|
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Fri Dec 10, 2021 3:31 am Post subject: |
|
|
My impression always was that compilation may have some limits on source size though it was long ago with 32bit version. So i traditionally have ~10 files with 20-30 k lines max
Try at least to split your file into 3-4. Create batch file where you compile each individual file as usual and LINK as usual. Example
Code: | ftn95 A.for /64 /err /no_truncate /free /undef /debug /statistics /binary A.obj >ErrorsForA
ftn95 B.for /64 /err /no_truncate /free /undef /debug /statistics /binary B.obj >ErrorsForB
slink64 A.obj B.obj /file:A.exe >ErrorsForLink
|
This will make your debugging much more easier since you may not need /undef for all files, only just for few for example graphics part, or any other specific part (though mecej4 warns with /undef or /checkmate this might not be good idea but i never had any problems).
Then you can make batch more complex where there will be commands for compiling with or without debug. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Fri Dec 10, 2021 8:19 am Post subject: |
|
|
It is quite possible that com3.mod exists but is hidden from view.
Rather than use /debug, put OPTIONS(debug) half way through the file (before a subprogram). If it fails to compile then the problem is in the second half of the file etc. |
|
Back to top |
|
|
|