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 

corrupt object module when compiling huge program with debug
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
ljfarrugia



Joined: 06 Jun 2016
Posts: 35

PostPosted: Mon Dec 06, 2021 7:24 pm    Post subject: corrupt object module when compiling huge program with debug Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Dec 06, 2021 7:47 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
ljfarrugia



Joined: 06 Jun 2016
Posts: 35

PostPosted: Mon Dec 06, 2021 7:52 pm    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Dec 06, 2021 7:56 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
ljfarrugia



Joined: 06 Jun 2016
Posts: 35

PostPosted: Mon Dec 06, 2021 9:59 pm    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Dec 07, 2021 8:56 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Tue Dec 07, 2021 10:31 am    Post subject: Re: Reply with quote

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
View user's profile Send private message
ljfarrugia



Joined: 06 Jun 2016
Posts: 35

PostPosted: Thu Dec 09, 2021 6:41 pm    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu Dec 09, 2021 7:35 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Thu Dec 09, 2021 8:20 pm    Post subject: Reply with quote

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
View user's profile Send private message
ljfarrugia



Joined: 06 Jun 2016
Posts: 35

PostPosted: Thu Dec 09, 2021 9:16 pm    Post subject: Reply with quote

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
View user's profile Send private message
ljfarrugia



Joined: 06 Jun 2016
Posts: 35

PostPosted: Thu Dec 09, 2021 9:20 pm    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Fri Dec 10, 2021 12:24 am    Post subject: Re: Reply with quote

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
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Fri Dec 10, 2021 3:31 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Dec 10, 2021 8:19 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support 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