[Bug fortran/66640] New: Symbolic (addr2line) backtrace handler sometimes does not terminate when using OpenMP

[Bug fortran/66640] New: Symbolic (addr2line) backtrace handler sometimes does not terminate when using OpenMP

[bugs at stellardeath dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66640

            Bug ID: 66640
           Summary: Symbolic (addr2line) backtrace handler sometimes does
                    not terminate when using OpenMP
           Product: gcc
           Version: 5.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bugs at stellardeath dot org
  Target Milestone: ---

Symbolic backtraces seem to be implemented by a fork()/execve() to addr2line.
when this is done from within an OpenMP parallel region, the fork()ed
addr2line somehow never terminates and the program hangs forever in the
backtrace.


Small example program that triggers a divide-by-zero:

#######################################################
program test
  use, intrinsic :: iso_c_binding
  real(kind=C_DOUBLE) :: a
  integer i

  !$omp parallel private(a)
  a = 2.0_C_DOUBLE
  do i = 2, 0, -1
    a = a / i
  end do

  write(*,*) a
  !$omp end parallel

end program
#######################################################

Compile with

  gfortran -g -fopenmp test.F90 -ffpe-trap=zero


With one thread it produces a backtrace and terminates, as expected:

#######################################################
$> OMP_NUM_THREADS=1 ./test

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic
operation.

Backtrace for this error:
#0  0x7F76637514B7
#1  0x7F76637506B0
#2  0x7F766282D43F
#3  0x400A6D in MAIN__._omp_fn.0 at test.F90:9
#4  0x400985 in test at test.F90:6
[1]    17635 floating point exception  OMP_NUM_THREADS=1 ./test
$>
#######################################################


While with more than one thread it _sometimes_ does not terminate
(here enforced by calling it as often as it takes in the "while true" loop):

#######################################################
$> while true; do clear; OMP_NUM_THREADS=2 ./test; done
^L

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic
operation.

Backtrace for this error:

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic
operation.

Backtrace for this error:
#0  0x7F7B3D2834B7
#1  0x7F7B3D2826B0
#2  0x7F7B3C35F43F
#0  0x7F7B3D2834B7
#1  0x7F7B3D2826B0
#3  0x400A6D in MAIN__._omp_fn.0 at test.F90:9
#2  0x7F7B3C35F43F
#4  0x7F7B3CD4FFAD
#5  0x7F7B3C6D4483
#6  0x7F7B3C412A4C
#3  0x400A6D in MAIN__._omp_fn.0 at test.F90:9
#7  0xFFFFFFFFFFFFFFFF
#4  0x400985 in test at test.F90:6
[Hangs here]
#######################################################


This might also be interesting:

#######################################################
$> ps uf | grep -n "addr2line\|test"
12:lorenz   18346  0.0  0.0  29532  1392 pts/4    Sl+  15:10   0:00  \_ ./test
13:lorenz   18348  0.0  0.0  13832  2000 pts/4    S+   15:10   0:00      \_
/usr/bin/addr2line -e /home/lorenz/dev/addr2line_bug/test -f -s -C
14:lorenz   18349  0.0  0.0  13832  2048 pts/4    S+   15:10   0:00      \_
/usr/bin/addr2line -e /home/lorenz/dev/addr2line_bug/test -f -s -C
$>
$> gdb -p 18348 -ex bt -ex detach -ex q 2>/dev/null | tail -n 13 
#0  0x00007f04bb171580 in __read_nocancel () at
../sysdeps/unix/syscall-template.S:81
#1  0x00007f04bb109f00 in _IO_new_file_underflow (fp=0x7f04bb4324c0
<_IO_2_1_stdin_>) at fileops.c:580
#2  0x00007f04bb10ad6e in __GI__IO_default_uflow (fp=0x7f04bb4324c0
<_IO_2_1_stdin_>) at genops.c:426
#3  0x00007f04bb0ffc94 in __GI__IO_getline_info (fp=fp@entry=0x7f04bb4324c0
<_IO_2_1_stdin_>, buf=buf@entry=0x7ffdd8139e60 'F' <repeats 16 times>, "\n",
n=99, delim=delim@entry=10, 
    extract_delim=extract_delim@entry=1, eof=eof@entry=0x0) at iogetline.c:69
#4  0x00007f04bb0ffd88 in __GI__IO_getline (fp=fp@entry=0x7f04bb4324c0
<_IO_2_1_stdin_>, buf=buf@entry=0x7ffdd8139e60 'F' <repeats 16 times>, "\n",
n=<optimized out>, 
    delim=delim@entry=10, extract_delim=extract_delim@entry=1) at
iogetline.c:38
#5  0x00007f04bb0fec34 in _IO_fgets (buf=0x7ffdd8139e60 'F' <repeats 16 times>,
"\n", n=<optimized out>, fp=0x7f04bb4324c0 <_IO_2_1_stdin_>) at iofgets.c:56
#6  0x000000000040230b in ?? ()
#7  0x00007f04bb0b78c5 in __libc_start_main (main=0x401fc0, argc=6,
argv=0x7ffdd8139fe8, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, 
    stack_end=0x7ffdd8139fd8) at libc-start.c:289
#8  0x0000000000402855 in ?? ()
Detaching from program: /usr/bin/addr2line, process 18348
$>
$> gdb -p 18346 -ex bt -ex "info threads" -ex detach -ex q 2>/dev/null | tail
-n 15
0x00007fda31d43f44 in __libc_wait (stat_loc=0x0) at
../sysdeps/unix/sysv/linux/wait.c:35
#0  0x00007fda31d43f44 in __libc_wait (stat_loc=0x0) at
../sysdeps/unix/sysv/linux/wait.c:35
#1  0x00007fda328eb4e9 in _gfortrani_backtrace () at
../../../libgfortran/runtime/backtrace.c:263
#2  0x00007fda328ea6b1 in _gfortrani_backtrace_handler (signum=8) at
../../../libgfortran/runtime/compile_options.c:129
#3  <signal handler called>
#4  0x0000000000400a6d in MAIN__._omp_fn.0 () at test.F90:9
#5  0x0000000000400986 in test () at test.F90:6
#6  0x00000000004009cb in main (argc=1, argv=0x7ffc70796e8f) at test.F90:15
#7  0x00007fda319b48c5 in __libc_start_main (main=0x40098d <main>, argc=1,
argv=0x7ffc707969c8, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, 
    stack_end=0x7ffc707969b8) at libc-start.c:289
#8  0x0000000000400899 in _start () at ../sysdeps/x86_64/start.S:118
  Id   Target Id         Frame 
  2    Thread 0x7fda3178f700 (LWP 18347) "test" 0x00007fda31d43f44 in
__libc_wait (stat_loc=0x0) at ../sysdeps/unix/sysv/linux/wait.c:35
* 1    Thread 0x7fda32dd8780 (LWP 18346) "test" 0x00007fda31d43f44 in
__libc_wait (stat_loc=0x0) at ../sysdeps/unix/sysv/linux/wait.c:35
Detaching from program: /home/lorenz/dev/addr2line_bug/test, process 18346
$>
#######################################################


I would guess there is some thread-unsafety in libgfortran/runtime/backtrace.c?

Kind regards,
  Lorenz

[Bug fortran/66640] Symbolic (addr2line) backtrace handler sometimes does not terminate when using OpenMP

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66640

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2015-09-07
     Ever confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
I cannot reproduce this PR on darwin (no addr2line).

Could you check that this has not been fixed on a recent version of trunk
(6.0): post r227503?

[Bug fortran/66640] Symbolic (addr2line) backtrace handler sometimes does not terminate when using OpenMP

[bugs at stellardeath dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66640

--- Comment #2 from Lorenz Hüdepohl <bugs at stellardeath dot org> ---
(In reply to Dominique d'Humieres from comment #1)
> I cannot reproduce this PR on darwin (no addr2line).
> 
> Could you check that this has not been fixed on a recent version of trunk
> (6.0): post r227503?

Indeed, it does seem fixed. The example always terminates now.
>From gcc-bugs-return-497013-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Sep 11 21:33:16 2015
Return-Path: <gcc-bugs-return-497013-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 115244 invoked by alias); 11 Sep 2015 21:33:16 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 115147 invoked by uid 55); 11 Sep 2015 21:33:13 -0000
From: "law at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/47679] [4.9/5/6 Regression] Strange uninitialized warning after SRA
Date: Fri, 11 Sep 2015 21:33:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.6.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: law at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-47679-4-EQQU6JrmEy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-47679-4@http.gcc.gnu.org/bugzilla/>
References: <bug-47679-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-09/txt/msg00991.txt.bz2
Content-length: 891

https://gcc.gnu.org/bugzilla/show_bug.cgi?idG679

--- Comment #22 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Author: law
Date: Fri Sep 11 21:32:38 2015
New Revision: 227697

URL: https://gcc.gnu.org/viewcvs?rev"7697&root=gcc&view=rev
Log:
[PATCH] Another small cleanup to the const_and_copies stack

2015-09-11  Jeff Law  <law@redhat.com>

        PR tree-optimization/47679
        * tree-ssa-dom.c (struct cond_equivalence): Update comment.
        * tree-ssa-scopedtables.h (class const_and_copies): Prefix data
        member with m_.  Update inline member functions as necessary.  Add
        toplevel comment.
        * tree-ssa-scopedtables.c: Update const_and_copies's member
        functions to use m_ prefix to access the stack.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-ssa-dom.c
    trunk/gcc/tree-ssa-scopedtables.c
    trunk/gcc/tree-ssa-scopedtables.h

[Bug fortran/66640] Symbolic (addr2line) backtrace handler sometimes does not terminate when using OpenMP

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66640

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
                 CC|                            |fxcoudert at gcc dot gnu.org
         Resolution|---                         |FIXED
   Target Milestone|---                         |6.0

--- Comment #3 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
We've completely changed the backtrace mechanism in trunk (6.0). The new
mechanism is more robust. Closing as FIXED, please open new PR (and CC me) if
you experience more trouble in this area.