public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/17989] New: gdb hangs on some Fortran stack frames
@ 2015-02-17  5:46 tom.k.cook at gmail dot com
  2015-02-17  6:25 ` [Bug fortran/17989] " tom.k.cook at gmail dot com
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: tom.k.cook at gmail dot com @ 2015-02-17  5:46 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=17989

            Bug ID: 17989
           Summary: gdb hangs on some Fortran stack frames
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: fortran
          Assignee: unassigned at sourceware dot org
          Reporter: tom.k.cook at gmail dot com

Overview:  GDB hangs when trying to display some Fortran stack frames.

Platform: Linux 3.13.0 x86_64 SMP (Ubuntu Trusty)

Steps to reproduce:  Unknown.  Sorry!  I'll give as much information as I can.

The software being debugged is mixed Fortran/C++.  The main method is in
Fortran but the executable is linked using G++.  The compiler is GCC 4.8 (for
both Fortran and C++) but I have confirmed the bug when compiling with GCC 4.9.
 I have a fairly recent GCC HEAD (early January) build around and could try
that if it might be useful.

GDB hangs when attempting to display certain stack frames (eg. when a
breakpoint is hit, or when 'finish' is used to move up a frame, or when 'bt' is
used).  'info line' and 'list' still work in these situations.

The problem always happens with Fortran stack frames, including when there are
no C++ frames on the stack.

The Fortran code is compiled with '-g -cpp -ffixed-line-length-none
-ffree-line-length-none -fcoarray=single -fno-underscoring -fPIC'.

The executable is linked with '-g', objects and libraries.

When gdb hangs, it is consuming 100% CPU (ie one CPU core).

The hang can be interrupted with Ctrl-C and the debugging session continued
normally (so long as you don't want to display the call stack etc).

I have checked that both GDB 7.7 (Ubuntu Trusty) and a fresh build from git
latest today, using GCC-5.0 latest-as-of-early-January, display this problem.

I have tried to reproduce the bug on a very simple Fortran/C++ project but have
not been able to.

Any suggestions on how to fix this, or on steps I might take to reliably
reproduce it, will be gratefully received.  I have a build of gdb
latest-of-today and could debug gdb itself if this will be useful. 
Unfortunately the Fortran/C++ code being debugged when the problem occurs is
commercial and can't be shared.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug fortran/17989] gdb hangs on some Fortran stack frames
  2015-02-17  5:46 [Bug fortran/17989] New: gdb hangs on some Fortran stack frames tom.k.cook at gmail dot com
@ 2015-02-17  6:25 ` tom.k.cook at gmail dot com
  2015-02-17  9:45 ` tom.k.cook at gmail dot com
  2015-02-20 12:08 ` tom.k.cook at gmail dot com
  2 siblings, 0 replies; 4+ messages in thread
From: tom.k.cook at gmail dot com @ 2015-02-17  6:25 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=17989

--- Comment #1 from Tom Cook <tom.k.cook at gmail dot com> ---
Here is a stack trace from interrupting GDB while it is hung:

#0  0x00007ffff705cca3 in __pread_nocancel () from
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00000000004a2532 in linux_proc_xfer_partial (ops=0xc9f4b0, annex=0x0,
writebuf=0x0, 
    xfered_len=0x7fffffffd568, len=109888164, offset=31738864, 
    readbuf=0x7fffe45439ec "ies/GHMathUtilities/ghtypes.hpp",
object=TARGET_OBJECT_MEMORY)
    at ../../gdb/linux-nat.c:3890
#2  linux_xfer_partial (ops=0xc9f4b0, object=TARGET_OBJECT_MEMORY, annex=0x0, 
    readbuf=0x7fffe45439ec "ies/GHMathUtilities/ghtypes.hpp", writebuf=0x0,
offset=31738864, 
    len=109888164, xfered_len=0x7fffffffd568) at ../../gdb/linux-nat.c:4157
#3  0x00000000004a3a23 in linux_nat_xfer_partial (ops=0xc9f4b0,
object=TARGET_OBJECT_MEMORY, 
    annex=0x0, readbuf=0x7fffe45439ec "ies/GHMathUtilities/ghtypes.hpp",
writebuf=<optimised out>, 
    offset=31738864, len=109888164, xfered_len=0x7fffffffd568) at
../../gdb/linux-nat.c:3748
#4  0x00000000005df192 in raw_memory_xfer_partial (ops=ops@entry=0xc10080
<thread_db_ops>, 
    readbuf=readbuf@entry=0x7fffe45439ec "ies/GHMathUtilities/ghtypes.hpp", 
    writebuf=writebuf@entry=0x0, memaddr=memaddr@entry=31738864, len=109888164, 
    xfered_len=xfered_len@entry=0x7fffffffd568) at ../../gdb/target.c:1075
#5  0x00000000005e0e76 in memory_xfer_partial_1 (ops=ops@entry=0xc10080
<thread_db_ops>, 
    object=object@entry=TARGET_OBJECT_MEMORY, 
    readbuf=readbuf@entry=0x7fffe45439ec "ies/GHMathUtilities/ghtypes.hpp", 
    writebuf=writebuf@entry=0x0, memaddr=memaddr@entry=31738864, len=<optimised
out>, 
    xfered_len=0x7fffffffd568) at ../../gdb/target.c:1206
#6  0x00000000005e1139 in memory_xfer_partial (xfered_len=0x7fffffffd568,
len=<optimised out>, 
    memaddr=31738864, writebuf=0x0, readbuf=0x7fffe45439ec
"ies/GHMathUtilities/ghtypes.hpp", 
    object=TARGET_OBJECT_MEMORY, ops=0xc10080 <thread_db_ops>) at
../../gdb/target.c:1233
#7  target_xfer_partial (ops=0xc10080 <thread_db_ops>,
object=object@entry=TARGET_OBJECT_MEMORY, 
    annex=annex@entry=0x0, readbuf=readbuf@entry=0x7fffe45439ec
"ies/GHMathUtilities/ghtypes.hpp", 
    writebuf=writebuf@entry=0x0, offset=offset@entry=31738864, len=109888164, 
    xfered_len=0x7fffffffd568) at ../../gdb/target.c:1309
#8  0x000000000056827f in read_value_memory (val=val@entry=0x2765080, 
    embedded_offset=embedded_offset@entry=0, stack=<optimised out>,
memaddr=memaddr@entry=31695380, 
    buffer=0x7fffe4539010 "DTBLADED.IN", length=109931648) at
../../gdb/valops.c:968
#9  0x000000000055f175 in value_fetch_lazy (val=0x2765080) at
../../gdb/value.c:3793
#10 0x000000000055f6ba in value_entirely_covered_by_range_vector
(value=0x2765080, ranges=0x2765100)
    at ../../gdb/value.c:391
#11 0x00000000005711b1 in value_check_printable (val=val@entry=0x2765080, 
    stream=stream@entry=0x14b6320, options=0x7fffffffd710) at
../../gdb/valprint.c:809
#12 0x0000000000571596 in common_val_print (val=0x2765080,
stream=stream@entry=0x14b6320, 
    recurse=recurse@entry=2, options=options@entry=0x7fffffffd710, 
    language=language@entry=0x829040 <f_language_defn>) at
../../gdb/valprint.c:848
#13 0x00000000005a8252 in print_frame_arg (arg=arg@entry=0x7fffffffd790) at
../../gdb/stack.c:285
#14 0x00000000005a902a in print_frame_args (func=<optimised out>,
frame=frame@entry=0x672f020, 
    num=num@entry=-1, stream=0xdc7360) at ../../gdb/stack.c:673
#15 0x00000000005a9a37 in print_frame (frame=frame@entry=0x672f020,
print_level=print_level@entry=1, 
    print_what=print_what@entry=LOCATION, print_args=print_args@entry=1,
sal=...)
    at ../../gdb/stack.c:1204
#16 0x00000000005a9f9f in print_frame_info (frame=frame@entry=0x672f020, 
    print_level=print_level@entry=1, print_what=print_what@entry=LOCATION, 
    print_args=print_args@entry=1, set_current_sal=set_current_sal@entry=0) at
../../gdb/stack.c:856
#17 0x00000000005aa284 in backtrace_command_1 (count_exp=count_exp@entry=0x0,
show_locals=0, 
    no_filters=0, from_tty=from_tty@entry=1) at ../../gdb/stack.c:1816
#18 0x00000000005aa79d in backtrace_command (arg=0x0, from_tty=1) at
../../gdb/stack.c:1913
#19 0x000000000067ab76 in execute_command (p=<optimised out>, p@entry=0xc30190
"bt", from_tty=1)
    at ../../gdb/top.c:476
#20 0x00000000005b9505 in command_handler (command=0xc30190 "bt") at
../../gdb/event-top.c:494
#21 0x00000000005b9c07 in command_line_handler (rl=<optimised out>) at
../../gdb/event-top.c:692
#22 0x00000000006ca893 in rl_callback_read_char () at
../../readline/callback.c:220
#23 0x00000000005b9569 in rl_callback_read_char_wrapper (client_data=<optimised
out>)
#24 0x00000000005b95b3 in stdin_event_handler (error=<optimised out>,
client_data=0x0)
    at ../../gdb/event-top.c:432
#25 0x00000000005b84e2 in gdb_wait_for_event (block=block@entry=1) at
../../gdb/event-loop.c:772
#26 0x00000000005b8699 in gdb_do_one_event () at ../../gdb/event-loop.c:309
#27 0x00000000005b87de in start_event_loop () at ../../gdb/event-loop.c:334
#28 0x00000000005b26b3 in captured_command_loop (data=data@entry=0x0) at
../../gdb/main.c:321
#29 0x00000000005afc35 in catch_errors (func=func@entry=0x5b26a0
<captured_command_loop>, 
    func_args=func_args@entry=0x0, errstring=errstring@entry=0x7948d2 "", 
    mask=mask@entry=RETURN_MASK_ALL) at ../../gdb/exceptions.c:237
#30 0x00000000005b3196 in captured_main (data=data@entry=0x7fffffffde60) at
../../gdb/main.c:1149
#31 0x00000000005afc35 in catch_errors (func=func@entry=0x5b2b00
<captured_main>, 
    func_args=func_args@entry=0x7fffffffde60,
errstring=errstring@entry=0x7948d2 "", 
    mask=mask@entry=RETURN_MASK_ALL) at ../../gdb/exceptions.c:237
#32 0x00000000005b3a8b in gdb_main (args=args@entry=0x7fffffffde60) at
../../gdb/main.c:1157
#33 0x000000000045f205 in main (argc=<optimised out>, argv=<optimised out>) at
../../gdb/gdb.c:32

This is from gdb latest as of a few hours ago.  After a little exploration, the
problem seems to be at frame #9 above, in value_fetch_lazy.  'val' has the
following value:

    (gdb) print *val
    $13 = {lval = lval_memory, modifiable = 1, lazy = 1, initialized = 1, stack
= 0, released = 0, 
      regnum = -1, location = {address = 31695380, internalvar = 0x1e3a214,
xm_worker = 0x1e3a214, 
        computed = {funcs = 0x1e3a214, closure = 0x0}}, offset = 0, bitsize =
0, bitpos = 0, 
      reference_count = 1, parent = 0x0, frame_id = {stack_addr = 0, code_addr
= 0, special_addr = 0, 
        stack_status = FID_STACK_INVALID, code_addr_p = 0, special_addr_p = 0,
artificial_depth = 0}, 
      type = 0x68b7c40, enclosing_type = 0x68b7c40, embedded_offset = 0,
pointed_to_offset = 0, 
      next = 0x2764fd0, contents = 0x7fffe4539010 "DTBLADED.IN", unavailable =
0x0, optimized_out = 0x0}

Line 3790 gets a type for val:

    struct type *type = check_typedef (value_enclosing_type (val));

and line 3793 calls read_value_memory:

    read_value_memory (val, 0, value_stack (val),
        addr, value_contents_all_raw (val),
        TYPE_LENGTH (type));

Stepping down into read_value_memory, the value of 'length', obtained using
TYPE_LENGTH(type), is:

    (gdb) print length
    $14 = 109931648

which seems... unlikely.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug fortran/17989] gdb hangs on some Fortran stack frames
  2015-02-17  5:46 [Bug fortran/17989] New: gdb hangs on some Fortran stack frames tom.k.cook at gmail dot com
  2015-02-17  6:25 ` [Bug fortran/17989] " tom.k.cook at gmail dot com
@ 2015-02-17  9:45 ` tom.k.cook at gmail dot com
  2015-02-20 12:08 ` tom.k.cook at gmail dot com
  2 siblings, 0 replies; 4+ messages in thread
From: tom.k.cook at gmail dot com @ 2015-02-17  9:45 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=17989

Tom Cook <tom.k.cook at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tom.k.cook at gmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug fortran/17989] gdb hangs on some Fortran stack frames
  2015-02-17  5:46 [Bug fortran/17989] New: gdb hangs on some Fortran stack frames tom.k.cook at gmail dot com
  2015-02-17  6:25 ` [Bug fortran/17989] " tom.k.cook at gmail dot com
  2015-02-17  9:45 ` tom.k.cook at gmail dot com
@ 2015-02-20 12:08 ` tom.k.cook at gmail dot com
  2 siblings, 0 replies; 4+ messages in thread
From: tom.k.cook at gmail dot com @ 2015-02-20 12:08 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=17989

--- Comment #2 from Tom Cook <tom.k.cook at gmail dot com> ---
Here is a reproducible case, probably related to this bug.  Put the following
in test.f90:

    program test
    implicit none
    integer :: aviFail

    type TestData
       INTEGER :: i
       INTEGER, ALLOCATABLE :: j(:)
       INTEGER :: k
       INTEGER, ALLOCATABLE :: l(:)
    end type TestData

    type(TestData), allocatable :: s(:)

    allocate(s(1), STAT = aviFail)
    allocate(s(1)%j(2), STAT = aviFail)
    allocate(s(1)%l(4), STAT = aviFail)

    s(1)%k = 0

    if(s(1)%k.EQ.0) write(*, '(A)') "Hello, world."
    end program test

Build it like this:

    gfortran -o test.o -c -g -cpp -ffixed-line-length-none
-ffree-line-length-none -fcoarray=single -fno-underscoring -fPIC test.f90
    gfortran -o test -g test.o

Load the resulting executable in gdb.  Execute the 'start' command, followed by
the 'next' command four times to step through to test.f90:18.  Execute 'print
s' to show the content of the structure 's'; gdb crashes.  The stack trace from
the resulting core is pasted in below:

#0  __memcpy_sse2_unaligned () at
../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:36
#1  0x000000000055ecf1 in value_from_decfloat (type=type@entry=0x2d96180, 
    dec=dec@entry=0x2d1fb00 "\377\377\377\377\377\377\377\377\t\001") at
../../gdb/value.c:3545
#2  0x000000000055ed56 in value_from_contents_and_address
(type=type@entry=0x2c6d0e0, 
    valaddr=valaddr@entry=0x2d1fb00 "\377\377\377\377\377\377\377\377\t\001", 
    address=address@entry=6315920) at ../../gdb/value.c:3501
#3  0x00000000005062e7 in gdbpy_apply_val_pretty_printer (extlang=<optimised
out>, type=0x2c6d0e0, 
    valaddr=0x2d1fb00 "\377\377\377\377\377\377\377\377\t\001",
embedded_offset=<optimised out>, 
    address=<optimised out>, stream=0x2c116a0, recurse=1, val=0x2d41540,
options=0x7ffff7d9d0d0, 
    language=0x829040 <f_language_defn>) at
../../gdb/python/py-prettyprint.c:716
#4  0x00000000005b039e in apply_ext_lang_val_pretty_printer
(type=type@entry=0x2c6d0e0, 
    valaddr=valaddr@entry=0x2d1faf0 "@\300\374\367\377\177", 
    embedded_offset=embedded_offset@entry=16, address=address@entry=6315904, 
    stream=stream@entry=0x2c116a0, recurse=recurse@entry=1, val=0x2d41540,
options=0x7ffff7d9d0d0, 
    language=0x829040 <f_language_defn>) at ../../gdb/extension.c:514
#5  0x000000000057152c in val_print (type=0x2c6d0e0, 
    valaddr=valaddr@entry=0x2d1faf0 "@\300\374\367\377\177",
embedded_offset=16, 
    address=address@entry=6315904, stream=stream@entry=0x2c116a0,
recurse=recurse@entry=1, 
    val=0x2d41540, options=0x7ffff7d9d0d0, language=0x829040 <f_language_defn>)
    at ../../gdb/valprint.c:770
#6  0x0000000000670b68 in f_val_print (type=0x2c6c390, valaddr=0x2d1faf0
"@\300\374\367\377\177", 
    embedded_offset=8, address=6315904, stream=0x2c116a0, recurse=0,
original_value=0x2d41540, 
    options=0x7ffff7d9d0d0) at ../../gdb/f-valprint.c:380
#7  0x00000000005714b9 in val_print (type=0x2c6c390, 
    valaddr=valaddr@entry=0x2d1faf0 "@\300\374\367\377\177", embedded_offset=8, 
    address=address@entry=6315904, stream=stream@entry=0x2c116a0,
recurse=recurse@entry=0, 
    val=0x2d41540, options=0x7ffff7d9d300, language=0x829040 <f_language_defn>)
    at ../../gdb/valprint.c:787
#8  0x000000000067074f in f77_print_array_1 (nss=nss@entry=1,
ndimensions=ndimensions@entry=1, 
    valaddr=valaddr@entry=0x2d1faf0 "@\300\374\367\377\177", 
    embedded_offset=embedded_offset@entry=0, address=address@entry=6315904,
stream=0x2c116a0, 
    recurse=0, val=0x2d41540, options=0x7ffff7d9d300, elts=0x7ffff7d9d220,
type=0x2d92ed0)
    at ../../gdb/f-valprint.c:191
#9  0x0000000000670ad6 in f77_print_array (options=0x7ffff7d9d300,
val=0x2d41540, recurse=0, 
    stream=0x2c116a0, address=6315904, embedded_offset=0, valaddr=0x2d1faf0
"@\300\374\367\377\177", 
    type=0x2d92ed0) at ../../gdb/f-valprint.c:234
#10 f_val_print (type=0x2d92ed0, valaddr=0x2d1faf0 "@\300\374\367\377\177",
embedded_offset=0, 
    address=6315904, stream=0x2c116a0, recurse=0, original_value=0x2d41540,
options=0x7ffff7d9d300)
    at ../../gdb/f-valprint.c:281
#11 0x00000000005714b9 in val_print (type=type@entry=0x2d92ed0, 
    valaddr=0x2d1faf0 "@\300\374\367\377\177",
embedded_offset=embedded_offset@entry=0, 
    address=address@entry=6315904, stream=stream@entry=0x2c116a0,
recurse=recurse@entry=0, 
    val=0x2d41540, options=0x7ffff7d9d3a0, language=0x829040 <f_language_defn>)
    at ../../gdb/valprint.c:787
#12 0x000000000066e38c in c_value_print (val=0x2d41540, stream=0x2c116a0,
options=<optimised out>)
    at ../../gdb/c-valprint.c:584
#13 0x00000000005771d9 in print_command_1 (exp=0x2a7a192 "s",
voidprint=<optimised out>)
    at ../../gdb/printcmd.c:994
#14 0x000000000067ab76 in execute_command (p=<optimised out>, p@entry=0x2a7a190
"p s", from_tty=1)
    at ../../gdb/top.c:476
#15 0x00000000005b9505 in command_handler (command=0x2a7a190 "p s") at
../../gdb/event-top.c:494
#16 0x00000000005b9c07 in command_line_handler (rl=<optimised out>) at
../../gdb/event-top.c:692
#17 0x00000000006ca893 in rl_callback_read_char () at
../../readline/callback.c:220
#18 0x00000000005b9569 in rl_callback_read_char_wrapper (client_data=<optimised
out>)
    at ../../gdb/event-top.c:171
#19 0x00000000005b95b3 in stdin_event_handler (error=<optimised out>,
client_data=0x0)
#20 0x00000000005b84e2 in gdb_wait_for_event (block=block@entry=1) at
../../gdb/event-loop.c:772
#21 0x00000000005b8699 in gdb_do_one_event () at ../../gdb/event-loop.c:309
#22 0x00000000005b87de in start_event_loop () at ../../gdb/event-loop.c:334
#23 0x00000000005b26b3 in captured_command_loop (data=data@entry=0x0) at
../../gdb/main.c:321
#24 0x00000000005afc35 in catch_errors (func=func@entry=0x5b26a0
<captured_command_loop>, 
    func_args=func_args@entry=0x0, errstring=errstring@entry=0x7948d2 "", 
    mask=mask@entry=RETURN_MASK_ALL) at ../../gdb/exceptions.c:237
#25 0x00000000005b3196 in captured_main (data=data@entry=0x7ffff7d9d820) at
../../gdb/main.c:1149
#26 0x00000000005afc35 in catch_errors (func=func@entry=0x5b2b00
<captured_main>, 
    func_args=func_args@entry=0x7ffff7d9d820,
errstring=errstring@entry=0x7948d2 "", 
    mask=mask@entry=RETURN_MASK_ALL) at ../../gdb/exceptions.c:237
#27 0x00000000005b3a8b in gdb_main (args=args@entry=0x7ffff7d9d820) at
../../gdb/main.c:1157
#28 0x000000000045f205 in main (argc=<optimised out>, argv=<optimised out>) at
../../gdb/gdb.c:32

-- 
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-02-20  3:18 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-17  5:46 [Bug fortran/17989] New: gdb hangs on some Fortran stack frames tom.k.cook at gmail dot com
2015-02-17  6:25 ` [Bug fortran/17989] " tom.k.cook at gmail dot com
2015-02-17  9:45 ` tom.k.cook at gmail dot com
2015-02-20 12:08 ` tom.k.cook at gmail dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).