[Bug fortran/11354] error in evaluating variable length fortran strings causes stalls

[Bug fortran/11354] error in evaluating variable length fortran strings causes stalls

[jan.kratochvil at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11354

Jan Kratochvil <jan.kratochvil at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jan.kratochvil at redhat
                   |                            |dot com

--- Comment #2 from Jan Kratochvil <jan.kratochvil at redhat dot com> 2011-04-29 13:47:07 UTC ---
The random reading of memory is a problem but it should be interruptible by
CTRL-C back to the GDB prompt.  I do not have it reproducible with FSF GDB.

It is rather a problem FSF GDB does not support properly the Fortran data
types.
This works with archer-jankratochvil-vla from:
  http://sourceware.org/gdb/wiki/ArcherBranchManagement

Breakpoint 1, print_string (string='hello world', _string=11) at kramer.f90:11

And present also in Fedora (and AFAIK SUSE) GNU/Linux GDBs.

Why it is not in FSF GDB is a longterm issue, it still needs a lot of work:
Re: fortran multidimensional arrays and pointers
http://sourceware.org/ml/gdb/2011-03/msg00021.html

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug fortran/11354] error in evaluating variable length fortran strings causes stalls

[stephan.kramer at imperial dot ac.uk]

http://sourceware.org/bugzilla/show_bug.cgi?id=11354

--- Comment #3 from Stephan Kramer <stephan.kramer at imperial dot ac.uk> 2011-04-29 16:26:39 UTC ---
Thanks for your response. I know proper modern fortran support is a more
longterm issue - really appreciate the effort that needs to go into that.
Hitting ctrl-c doesn't solve the issue as that breaks off printing the frame
info before even printing the line number, which rather limits the
functionality of gdb: no backtraces, no line numbers when stepping through the
code.

When you say I don't see this issue with fsf gdb, do you mean it doesn't stall?
Or, do you not see "Cannot access memory at address <random-address>". It's the
latter that is the real issue, because that causes the stalls in executables
with a large memory layout (not the example program of course); basically goes
through the lot of it before giving up. I still see this behaviour with gdb
version 7.2 on Ubuntu Natty.

Once again, the issue is not the faulty printing. We know we can work around
this with some pointer voodoo, it's the stalling that's causing us some real
headaches trying to debug things on a large executable.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug fortran/11354] error in evaluating variable length fortran strings causes stalls

[jan.kratochvil at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11354

--- Comment #4 from Jan Kratochvil <jan.kratochvil at redhat dot com> 2011-04-29 16:34:25 UTC ---
(In reply to comment #3)
> When you say I don't see this issue with fsf gdb, do you mean it doesn't stall?

It does not stall.  But that depends on various random memory layouts so I
understand it may happen.


> Or, do you not see "Cannot access memory at address <random-address>".

I see this message with FSF GDB:
Breakpoint 1, print_string (string=Cannot access memory at address 0x4008eb
) at kramer.f90:11


> I still see this behaviour with gdb version 7.2 on Ubuntu Natty.

Therefore Ubuntu does not include the Fortran support.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug fortran/11354] error in evaluating variable length fortran strings causes stalls

[stephan.kramer at imperial dot ac.uk]

http://sourceware.org/bugzilla/show_bug.cgi?id=11354

--- Comment #5 from Stephan Kramer <stephan.kramer at imperial dot ac.uk> 2011-04-29 16:58:38 UTC ---
The below example actually reproduces the stalling behaviour by creating some
artificial memory contents. (compiled with gfortran 4.5.2, using gdb 4.2). Put
a breakpoint on line 14: print *, string

program main
implicit none
integer, parameter::n=10*1000*1000
character(len=11):: hello_world="hello_world"
! some filler for memory
character(len=3*n):: str

call print_string(hello_world)

! make sure the strings don't get optimized out:
hello_world(1:3)='bar'
str(1:3)='bar'


contains

subroutine print_string(string)
character(len=*):: string

print *, string

end subroutine print_string
end program main

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug fortran/11354] error in evaluating variable length fortran strings causes stalls

[jan.kratochvil at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11354

--- Comment #6 from Jan Kratochvil <jan.kratochvil at redhat dot com> 2011-04-29 17:03:10 UTC ---
(In reply to comment #5)
> The below example actually reproduces the stalling behaviour

The problem is people sometimes print huge arrays for example into file and it
takes a lot of time.  There was discussed some way to read data while it is
being printed instead of reading it all in advance.  No limit is going to fit
all the cases.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug fortran/11354] New: error in evaluating variable length fortran strings causes stalls

[stephan dot kramer at imperial dot ac dot uk]

The below simple test program was compiled with gfortran 4.4.1, -g. After
putting a breakpoint on the print line, the displayed frame looks as follows:

Breakpoint 1, print_string (string=Cannot access memory at address 0x80487eb
) at string.f90:11

I don't mind so much the string not being printed correctly (lots of things in
fortran aren't), but in particular for big executables this seems to cause huge
waiting times for the frame to be printed out (several minutes). This makes gdb
7.0 and 7.1 currently unusable for our project.

After a digging a little deeper, the cause seems to be the length of the string
not being picked up correctly from stack. Putting a breakpoint on valops.c (cvs
1.237 of the gdb_7_1-branch) on line 942 value_fetch_lazy(), the length of the
value it tries to read is some random big number. It then tries to read this
from the debugged process memory, and fails reaching the end which takes quite a
while for a large process.

The sample program:

program main
  implicit none
  
  call print_string("hello world")
    
  contains
  
  subroutine print_string(string)
    character(len=*):: string
    
    print *, string
    
  end subroutine print_string
end program main

-- 
           Summary: error in evaluating variable length fortran strings
                    causes stalls
           Product: gdb
           Version: 7.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: fortran
        AssignedTo: unassigned at sourceware dot org
        ReportedBy: stephan dot kramer at imperial dot ac dot uk
                CC: gdb-prs at sourceware dot org


http://sourceware.org/bugzilla/show_bug.cgi?id=11354

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug fortran/11354] error in evaluating variable length fortran strings causes stalls

[stephan dot kramer at imperial dot ac dot uk]

------- Additional Comments From stephan dot kramer at imperial dot ac dot uk  2010-09-14 19:21 -------
Hello. Has anyone had a chance to look at this? This really makes gdb quite
frustrating to work with on any fortran code.

Could we have a safety cap (till one day "modern" fortran data structures are
supported) - something like:

if length>1024 {length=1024;}

Just made up the number 1024 here of course!

Please let me know if anything is unclear in my bug-report.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11354

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.