[Bug libgomp/104385] New: Segmentation fault when using nested dependent tasks

[Bug libgomp/104385] New: Segmentation fault when using nested dependent tasks

[wacrenier at labri dot fr]

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

            Bug ID: 104385
           Summary: Segmentation fault when using nested dependent tasks
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgomp
          Assignee: unassigned at gcc dot gnu.org
          Reporter: wacrenier at labri dot fr
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 52351
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52351&action=edit
simple openmp code that leads to a segfault

Hello,

The attached code leads to SIGSEV when executing. 

Best regards,
P.A. Wacrenier
--------

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin21/11.2.0/lto-wrapper
Target: x86_64-apple-darwin21
Configured with:
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc11/gcc11/work/gcc-11.2.0/configure
--prefix=/opt/local --build=x86_64-apple-darwin21
--enable-languages=c,c++,objc,obj-c++,lto,fortran,jit
--libdir=/opt/local/lib/gcc11 --includedir=/opt/local/include/gcc11
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-11 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-11
--with-gxx-include-dir=/opt/local/include/gcc11/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local
--enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-build-config=bootstrap-debug
--with-bugurl=https://trac.macports.org/newticket --enable-host-shared
--disable-tls --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-pkgversion='MacPorts gcc11 11.2.0_3'
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.0 (MacPorts gcc11 11.2.0_3) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-mmacosx-version-min=12.1.0'
'-asm_macosx_version_min=12.1' '-mtune=core2' '-dumpdir' 'a-'
 /opt/local/libexec/gcc/x86_64-apple-darwin21/11.2.0/cc1 -E -quiet -v
-D__DYNAMIC__ ici.c -fPIC -mmacosx-version-min=12.1.0 -mtune=core2 -fopenmp
-fpch-preprocess -o a-ici.i
ignoring nonexistent directory
"/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/opt/local/include"
ignoring nonexistent directory
"/opt/local/lib/gcc11/gcc/x86_64-apple-darwin21/11.2.0/../../../../../x86_64-apple-darwin21/include"
ignoring nonexistent directory
"/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /opt/local/lib/gcc11/gcc/x86_64-apple-darwin21/11.2.0/include
 /opt/local/lib/gcc11/gcc/x86_64-apple-darwin21/11.2.0/include-fixed
 /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include

/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-mmacosx-version-min=12.1.0'
'-asm_macosx_version_min=12.1' '-mtune=core2' '-dumpdir' 'a-'
 /opt/local/libexec/gcc/x86_64-apple-darwin21/11.2.0/cc1 -fpreprocessed a-ici.i
-fPIC -quiet -dumpdir a- -dumpbase ici.c -dumpbase-ext .c
-mmacosx-version-min=12.1.0 -mtune=core2 -version -fopenmp -o a-ici.s
GNU C17 (MacPorts gcc11 11.2.0_3) version 11.2.0 (x86_64-apple-darwin21)
        compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (MacPorts gcc11 11.2.0_3) version 11.2.0 (x86_64-apple-darwin21)
        compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: f32d7bc7d3a774eacf5c9650a419dd5f
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-mmacosx-version-min=12.1.0'
 '-mtune=core2' '-dumpdir' 'a-'
 /opt/local/bin/as -arch x86_64 -v -force_cpusubtype_ALL
-mmacosx-version-min=12.1 -o a-ici.o a-ici.s
Apple clang version 13.0.0 (clang-1300.0.29.30)
Target: x86_64-apple-darwin21.2.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
 "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1as -triple
x86_64-apple-macosx12.1.0 -filetype obj -main-file-name a-ici.s -target-cpu
penryn -fdebug-compilation-dir /tmp -dwarf-debug-producer "Apple clang version
13.0.0 (clang-1300.0.29.30)" -dwarf-version=4 -mrelocation-model pic
--mrelax-relocations -mllvm -disable-aligned-alloc-awareness=1 -mllvm
-enable-dse-memoryssa=0 -o a-ici.o a-ici.s
COMPILER_PATH=/opt/local/libexec/gcc/x86_64-apple-darwin21/11.2.0/:/opt/local/libexec/gcc/x86_64-apple-darwin21/11.2.0/:/opt/local/libexec/gcc/x86_64-apple-darwin21/:/opt/local/lib/gcc11/gcc/x86_64-apple-darwin21/11.2.0/:/opt/local/lib/gcc11/gcc/x86_64-apple-darwin21/
LIBRARY_PATH=/opt/local/lib/gcc11/gcc/x86_64-apple-darwin21/11.2.0/:/opt/local/lib/gcc11/gcc/x86_64-apple-darwin21/11.2.0/../../../
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-mmacosx-version-min=12.1.0'
 '-mtune=core2' '-dumpdir' 'a.'
 /opt/local/libexec/gcc/x86_64-apple-darwin21/11.2.0/collect2 -syslibroot
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/ -dynamic -arch x86_64
-macosx_version_min 12.1.0 -weak_reference_mismatches non-weak -o a.out
-L/opt/local/lib/gcc11/gcc/x86_64-apple-darwin21/11.2.0
-L/opt/local/lib/gcc11/gcc/x86_64-apple-darwin21/11.2.0/../../.. a-ici.o -lgomp
-lSystem -lgcc_ext.10.5 -lgcc -lSystem -no_compact_unwind -v
collect2 version 11.2.0
/opt/local/bin/ld -syslibroot
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/ -dynamic -arch x86_64
-macosx_version_min 12.1.0 -weak_reference_mismatches non-weak -o a.out
-L/opt/local/lib/gcc11/gcc/x86_64-apple-darwin21/11.2.0
-L/opt/local/lib/gcc11/gcc/x86_64-apple-darwin21/11.2.0/../../.. a-ici.o -lgomp
-lSystem -lgcc_ext.10.5 -lgcc -lSystem -no_compact_unwind -v
@(#)PROGRAM:ld  PROJECT:ld64-711
BUILD 21:57:11 Nov 17 2021
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386
x86_64 x86_64h armv6m armv7k armv7m armv7em
Library search paths:
        /opt/local/lib/gcc11/gcc/x86_64-apple-darwin21/11.2.0
        /opt/local/lib/gcc11
        /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/lib
Framework search paths:
       
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks/

[Bug libgomp/104385] Segmentation fault when using nested dependent tasks

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-apple-darwin21

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Works on x86_64-linux-gnu.  Maybe related to TLS emulation?

[Bug libgomp/104385] Segmentation fault when using nested dependent tasks

[wacrenier at labri dot fr]

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

--- Comment #2 from P.A. Wacrenier <wacrenier at labri dot fr> ---
Sorry, as a matter of fact it does not (always) work on x86_64-pc-linux-gnu.  

Utilisation des specs internes.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Cible : x86_64-pc-linux-gnu
Configuré avec: ./configure --prefix=/net/ens/gcc/gcc_10.2.0
--exec-prefix=/net/ens/gcc/gcc_10.2.0
Modèle de thread: posix
Algorithmes de compression LTO supportés: zlib zstd
gcc version 10.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-mtune=generic'
'-march=x86-64' '-pthread'

/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.2.0/cc1
-E -quiet -v -imultiarch x86_64-linux-gnu -iprefix
/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0/
-D_REENTRANT ici.c -mtune=generic -march=x86-64 -fopenmp -fpch-preprocess -o
ici.i
le répertoire «
/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/include
» est ignoré car inexistant
le répertoire «
/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/10.2.0/include
» est ignoré car présent deux fois
le répertoire « /usr/local/include/x86_64-linux-gnu » est ignoré car inexistant
le répertoire «
/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/10.2.0/include-fixed
» est ignoré car présent deux fois
le répertoire «
/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/include
» est ignoré car inexistant
la recherche pour #include "..." débute ici :
la recherche pour #include <...> débute ici:

/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0/include

/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0/include-fixed
 /usr/local/include
 /autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/../../include
 /usr/include/x86_64-linux-gnu
 /usr/include
Fin de la liste de recherche.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-mtune=generic'
'-march=x86-64' '-pthread'

/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.2.0/cc1
-fpreprocessed ici.i -quiet -dumpbase ici.c -mtune=generic -march=x86-64
-auxbase ici -version -fopenmp -o ici.s
GNU C17 (GCC) version 10.2.0 (x86_64-pc-linux-gnu)
        compilé par GNU C version 10.2.0, GMP version 6.1.2, MPFR version
4.0.2, MPC version 1.1.0, isl version isl-0.20-GMP

heuristiques GGC: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 10.2.0 (x86_64-pc-linux-gnu)
        compilé par GNU C version 10.2.0, GMP version 6.1.2, MPFR version
4.0.2, MPC version 1.1.0, isl version isl-0.20-GMP

heuristiques GGC: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 64cac5b5eb450f2b66ce9b43c80e8788
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-mtune=generic'
'-march=x86-64' '-pthread'
 as -v --64 -o ici.o ici.s
Version de l'assembleur GNU 2.31.1 (x86_64-linux-gnu) utilisant la version BFD
(GNU Binutils for Debian) 2.31.1
COMPILER_PATH=/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.2.0/:/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../libexec/gcc/
LIBRARY_PATH=/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0/:/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/:/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/:/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../:/lib/:/usr/lib/
Lecture des spécifications à partir de
/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/libgomp.spec
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-mtune=generic'
'-march=x86-64' '-pthread'

/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.2.0/collect2
-plugin
/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.2.0/liblto_plugin.so
-plugin-opt=/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
-plugin-opt=-fresolution=ici.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lpthread
-plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 /lib/x86_64-linux-gnu/crt1.o
/lib/x86_64-linux-gnu/crti.o
/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0/crtbegin.o
-L/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0
-L/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc
-L/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64
-L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
-L/usr/lib/../lib64
-L/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../..
ici.o -lgomp -lgcc --push-state --as-needed -lgcc_s --pop-state -lpthread -lc
-lgcc --push-state --as-needed -lgcc_s --pop-state
/autofs/unityaccount/ens/gcc/gcc_10.2.0/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0/crtend.o
/lib/x86_64-linux-gnu/crtn.o
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-mtune=generic'
'-march=x86-64' '-pthread'

[Bug libgomp/104385] Segmentation fault when using nested dependent tasks

[wacrenier at labri dot fr]

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

--- Comment #3 from P.A. Wacrenier <wacrenier at labri dot fr> ---
gdb output (x86_64 linux)


Thread 22 "a.out" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffedd10700 (LWP 1363311)]
priority_list_downgrade_task (child_task=0x7fffe0000cc0, list=0x7fffe00008d0,
type=PQ_CHILDREN) at ../.././libgomp/task.c:991
991     ../.././libgomp/task.c: Aucun fichier ou dossier de ce type.
(gdb) thread 22
[Switching to thread 22 (Thread 0x7fffedd10700 (LWP 1363311))]
#0  priority_list_downgrade_task (child_task=0x7fffe0000cc0,
list=0x7fffe00008d0, type=PQ_CHILDREN) at ../.././libgomp/task.c:991
991     in ../.././libgomp/task.c
(gdb) bt full
#0  priority_list_downgrade_task (child_task=0x7fffe0000cc0,
list=0x7fffe00008d0, type=PQ_CHILDREN) at ../.././libgomp/task.c:991
        next_task = 0xffffffffffffff90
        node = 0x7fffe0000d30
        node = <optimized out>
        next_task = <optimized out>
        prev_child = <optimized out>
#1  priority_queue_downgrade_task (task=0x7fffe0000cc0, head=<optimized out>,
type=PQ_CHILDREN) at ../.././libgomp/task.c:1047
        list = 0x7fffe00008d0
#2  priority_queue_downgrade_task (task=0x7fffe0000cc0, head=<optimized out>,
type=PQ_CHILDREN) at ../.././libgomp/task.c:1035
        list = <optimized out>
#3  gomp_task_run_pre (child_task=child_task@entry=0x7fffe0000cc0,
parent=<optimized out>, team=team@entry=0x405350)
    at ../.././libgomp/task.c:1077
        taskgroup = <optimized out>
#4  0x00007ffff7fa315c in gomp_barrier_handle_tasks (state=state@entry=0) at
../.././libgomp/task.c:1335
        ignored = true
        cancelled = false
        thr = <optimized out>
        team = 0x405350
        task = <optimized out>
        child_task = 0x7fffe0000cc0
        to_free = 0x7fffe0000b20
        do_wake = 0
#5  0x00007ffff7faa7f8 in gomp_team_barrier_wait_end (bar=<optimized out>,
state=0) at ../.././libgomp/config/linux/bar.c:116
        generation = 0
        gen = <optimized out>
#6  0x00007ffff7faa8da in gomp_team_barrier_wait_final (bar=bar@entry=0x4053d0)
at ../.././libgomp/config/linux/bar.c:136
        state = <optimized out>
#7  0x00007ffff7fa7e12 in gomp_thread_start (xdata=<optimized out>) at
../.././libgomp/team.c:124
        team = 0x405350
        task = 0x4069a0
        data = <optimized out>
        thr = <optimized out>
        pool = 0x405280
        local_fn = 0x401201 <main._omp_fn.0>
        local_data = 0x7fffffffdec8
--Type <RET> for more, q to quit, c to continue without paging--
#8  0x00007ffff7ef4fa3 in start_thread (arg=<optimized out>) at
pthread_create.c:486
        ret = <optimized out>
        pd = <optimized out>
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737183287040,
-8592581161367667977, 140737488341950, 140737488341951, 
                140737183287040, -120, 8592550692851776247,
8592563709294246647}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 
              0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#9  0x00007ffff7e254cf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

[Bug libgomp/104385] Segmentation fault when using nested dependent tasks

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I can't get it to fail for me on x86_64-linux-gnu.

[Bug libgomp/104385] Segmentation fault when using nested dependent tasks

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |openmp

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
With
#include <unistd.h>

int
main ()
{
  int j = 0;
#pragma omp parallel master shared(j)
  {
    #pragma omp task shared(j)
    {
      #pragma omp task depend(out: j) shared(j)
      {
        sleep (1);
        j = 1;
      }

      #pragma omp task depend(inout: j) shared(j)
      j += 1;
    }
  }
  return j - 2;
}
it segfaults fairly reliably.

[Bug libgomp/104385] Segmentation fault when using nested dependent tasks

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-02-05
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
      Known to fail|                            |9.1.0
             Target|x86_64-apple-darwin21       |

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

[Bug libgomp/104385] Segmentation fault when using nested dependent tasks

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52366
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52366&action=edit
gcc12-pr104385.patch

So far lightly tested fix.

[Bug libgomp/104385] Segmentation fault when using nested dependent tasks

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:0af7ef050aed9f678d70d79931ede38374fde863

commit r12-7091-g0af7ef050aed9f678d70d79931ede38374fde863
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Feb 8 09:30:17 2022 +0100

    libgomp: Fix segfault with posthumous orphan tasks [PR104385]

    The following patch fixes crashes with posthumous orphan tasks.
    When a parent task finishes, gomp_clear_parent clears the parent
    pointers of its children tasks present in the parent->children_queue.
    But children that are still waiting for dependencies aren't in that
    queue yet, they will be added there only when the sibling they are
    waiting for exits.  Unfortunately we were adding those tasks into
    the queues with the original task->parent which then causes crashes
    because that task is gone and freed.  The following patch fixes that
    by clearing the parent field when we schedule such task for running
    by adding it into the queues and we know that the sibling task which
    is about to finish has NULL parent.

    2022-02-08  Jakub Jelinek  <jakub@redhat.com>

            PR libgomp/104385
            * task.c (gomp_task_run_post_handle_dependers): If parent is NULL,
            clear task->parent.
            * testsuite/libgomp.c/pr104385.c: New test.

[Bug libgomp/104385] Segmentation fault when using nested dependent tasks

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:312a10bdf6ba86d0e32641f5d8f0b6df76810da0

commit r11-9599-g312a10bdf6ba86d0e32641f5d8f0b6df76810da0
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Feb 8 09:30:17 2022 +0100

    libgomp: Fix segfault with posthumous orphan tasks [PR104385]

    The following patch fixes crashes with posthumous orphan tasks.
    When a parent task finishes, gomp_clear_parent clears the parent
    pointers of its children tasks present in the parent->children_queue.
    But children that are still waiting for dependencies aren't in that
    queue yet, they will be added there only when the sibling they are
    waiting for exits.  Unfortunately we were adding those tasks into
    the queues with the original task->parent which then causes crashes
    because that task is gone and freed.  The following patch fixes that
    by clearing the parent field when we schedule such task for running
    by adding it into the queues and we know that the sibling task which
    is about to finish has NULL parent.

    2022-02-08  Jakub Jelinek  <jakub@redhat.com>

            PR libgomp/104385
            * task.c (gomp_task_run_post_handle_dependers): If parent is NULL,
            clear task->parent.
            * testsuite/libgomp.c/pr104385.c: New test.

    (cherry picked from commit 0af7ef050aed9f678d70d79931ede38374fde863)

[Bug libgomp/104385] Segmentation fault when using nested dependent tasks

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:ae536532103c0cd1116865dbca5cc02ba4ccca12

commit r10-10674-gae536532103c0cd1116865dbca5cc02ba4ccca12
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Feb 8 09:30:17 2022 +0100

    libgomp: Fix segfault with posthumous orphan tasks [PR104385]

    The following patch fixes crashes with posthumous orphan tasks.
    When a parent task finishes, gomp_clear_parent clears the parent
    pointers of its children tasks present in the parent->children_queue.
    But children that are still waiting for dependencies aren't in that
    queue yet, they will be added there only when the sibling they are
    waiting for exits.  Unfortunately we were adding those tasks into
    the queues with the original task->parent which then causes crashes
    because that task is gone and freed.  The following patch fixes that
    by clearing the parent field when we schedule such task for running
    by adding it into the queues and we know that the sibling task which
    is about to finish has NULL parent.

    2022-02-08  Jakub Jelinek  <jakub@redhat.com>

            PR libgomp/104385
            * task.c (gomp_task_run_post_handle_dependers): If parent is NULL,
            clear task->parent.
            * testsuite/libgomp.c/pr104385.c: New test.

    (cherry picked from commit 0af7ef050aed9f678d70d79931ede38374fde863)

[Bug libgomp/104385] Segmentation fault when using nested dependent tasks

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:b7e9d466fcf2f7c44ae31a2b308b0f1e406d1b9f

commit r9-10122-gb7e9d466fcf2f7c44ae31a2b308b0f1e406d1b9f
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Feb 8 09:30:17 2022 +0100

    libgomp: Fix segfault with posthumous orphan tasks [PR104385]

    The following patch fixes crashes with posthumous orphan tasks.
    When a parent task finishes, gomp_clear_parent clears the parent
    pointers of its children tasks present in the parent->children_queue.
    But children that are still waiting for dependencies aren't in that
    queue yet, they will be added there only when the sibling they are
    waiting for exits.  Unfortunately we were adding those tasks into
    the queues with the original task->parent which then causes crashes
    because that task is gone and freed.  The following patch fixes that
    by clearing the parent field when we schedule such task for running
    by adding it into the queues and we know that the sibling task which
    is about to finish has NULL parent.

    2022-02-08  Jakub Jelinek  <jakub@redhat.com>

            PR libgomp/104385
            * task.c (gomp_task_run_post_handle_dependers): If parent is NULL,
            clear task->parent.
            * testsuite/libgomp.c/pr104385.c: New test.

    (cherry picked from commit 0af7ef050aed9f678d70d79931ede38374fde863)

[Bug libgomp/104385] Segmentation fault when using nested dependent tasks

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.