Conference turris::fortran

We'll wait for the detailed information.  There's nothing in Fortran that
should be able to crash a system.  This suggests an operating system
problem.

				Steve

This has nothing to do with Fortran.

There is a known problem where trying to use a debugger on a V4.0B system
with the kdebug kernel option turned on will crash the system.   I believe
that there are or will be soon kernel patches for this.   In the meantime, you 
can use one of the following workarounds:

    1. Comment out options KDEBUG in /usr/sys/conf/SYSTEM-NAME:

       #options KDEBUG

       Rebuild the kernel and reboot with the new kernel

    2. As root:

       Fix the running kernel:

       . # dbx -k /vmunix
       . (dbx) a db_enable = 0
       . (dbx) q

       Fix the on-disk kernel image, in case of reboots:

       . # dbx /vmunix
       . (dbx) patch db_enable = 0
       . (dbx) q

   3.   Add the following to the /etc/sysconfigtab and then reboot:

	kdebug:
        	kdebug_saveterm = 0

    Actually we can compress step 2 down to:
    
    dbx -k /vmunix
    patch db_enable = 0
    q	
    
    You figure I've been working dbx so long, I should know this offhand,
    but then I've never worked the patch command.  It takes care of both
    the running and disk kernels.
    
    And the patch is, or will be:
    
    patch OSF410-046 (New id 26-00) to V4.0B
    
    PeterT
    

    I have tried to send the mail to zk02-3/N30, but it failed saying the 
    address could not be found on HGOM22. How to write your mail address in
    All-IN-1 or Teamlink. Pls advice.
    
    Anyway, thank you all a lot. I'll try to use the steps to solve the
    problem.
    If any suggestion, please let me know.
    Thanks again.

>>    I have tried to send the mail to zk02-3/N30, but it failed saying the 
>>    address could not be found on HGOM22. How to write your mail address in
>>    All-IN-1 or Teamlink. Pls advice.
    
To whom are you trying to send electronic mail?  "ZKO2-3/N30" is the location
code for Spit Brook Road in New Hampshire, building 2, floor 3, mailstop N30.
It's for interoffice hardcopy mail.

The previous replies tell you how to fix the problem so there's no need to send
us information on how to reproduce the problem.

If you want to send me email, I am

	TLE::WHITLOCK
	[email protected]
	[email protected]

The various note replies here display the email address of the writer, as in
QUARK::LIONEL for Steve L.

/Stan

    Stan Whitlock, thank you.
    What I have Write is one of the problem. There still some other
    problem.
    1.  On alphaserver 1000a 5/300 with
    	UNIX:	v4.0b
    	FORTRAN:	v3.5 or v3.8
    	Program compiler:	OK!
    	Running the program in debug mode, the  subroutine could not be
    entered, error message is like "end of file"    (1)
    	Running in normal mode, the program could give out the right
    result.
    
    2.  On alphaserver 1000a 5/300 with
    	UNIX:	v3.2g
    	FORTRAN:	v3.8
    	Running the program in debug mode, there different situation occur:
    n some of the subroutines could be debugged successfully.
    n some of the subroutine could be entered into by the following two
    steps:
    		first, stop at aaa
    		second, stop in aaa
    n for some of  the subroutines, the result is the same as (1).
    
    	When running some programs in normal mode, there will be error
    message like "core error" sometimes.
    
    The other FORTRAN problem is about the debug:
    	When debugging  a large program(more than 10000 lines of source),
    if youd like to list the last few lines, you have to list them step by
    step as:
    	l 999
    	l 1999
    	l 2999   .....
    Thats all.
    
    Please help me.

   You may want to try debugging using decladebug, rather than dbx,
   to see if this fixes your problems. A lot of work has been done
   in decladebug to support f77 and f90 programs. The decladebug group suggest
   using at least V3.8 or higher of the Fortran compiler.

   -- John Faricelli

    	I know that there were improvements in debugging information
    which happened after V3.8 of the compiler.  In order to really
    give you any help, we will need the full program(s), the exact
    method you used to compile and link the image (all compiler
    switches, etc.), and a script of what you see.  Otherwise,
    we can only speculate on what might be wrong, and make no
    progress whatsoever.
    
    	However, before sending us that kind of information, I would
    strongly encourage you to pick up the latest compiler and try
    ladebug.
    
    Cheers!
    Dave Eklund
    

    I can see two possibilites here.  One is that the compiler is giving
    incorrect source line information and the debugger is reporting
    that line xxx is "beyond the end of file", a message that dbx
    will certainly give you if you try to view lines out of range of
    the current source, and I think ladebug comes up with something
    similar.  By all means try ladebug, but if the line number information
    is incorrect, you're not likely to have much better luck.
    
    The other possibility is that the debugger is not looking at
    the same source that you think it is.  If you use the 'file'
    command in either debugger, it will tell you which source file 
    it is working with currently.  The 'use' command will tell you 
    which directories it is searching.  If you have, say, a previous
    version of the same file which does not have the same number of
    lines, you could run into this or a similar problem.
    
    Or it could be something else entirely.
    
    PeterT
    

    Does there any patches for the DBX problem I mentioned in 1260.6? If
    no, is there any plans for doing the patch?

Since no specific problem has been identified, we can't offer a patch.  Please
respond to the requests for more information in replies 7-9.

				Steve

    I just mean that for the same program and the same compiler switch, if
    you use dbx, the program could not enter into subroutine, if using the
    ladebug, the program could enter into subroutine. So, it seams that dbx
    has some problems in debugging the subroutines.

    	If you want help, we still need an example program.
    
    Cheers!
    Dave Eklund
    

And as the dbx person here in DIGITAL, I'd would also like to see an 
example.  I've had a lot of experience debugging FORTRAN programs, and
have never seen a problem where dbx was unable to debug inside a subroutine.
I'm not saying that you aren't seeing a problem, but it must be
a problem with this particular source.  The only way I can fix a problem
is to see a test case that shows the problem so I can reproduce it
and test dbx with it.   If the customer does not want to release the source
perhaps we can work out something (we are willing to sign non-disclosure
statements if it comes to that).  While we are trying to encourage the use
of ladebug, I would hate to see dbx fail in an apparently simple manner
like this.  You can send email directly to me if you want to take
this out of the conference:

[email protected]


Thanks,
PeterT