[Bug testsuite/100071] New: Test case libgomp.fortran/alloc-2.F90 fails with invalid memory reference

[Bug testsuite/100071] New: Test case libgomp.fortran/alloc-2.F90 fails with invalid memory reference

[seurer at gcc dot gnu.org]

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

            Bug ID: 100071
           Summary: Test case libgomp.fortran/alloc-2.F90 fails with
                    invalid memory reference
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: testsuite
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:fff15bad1ab571906c37b88380431768d917dcb0, r11-2101

The commit above is where this test case was introduced and it fails both there
and with current trunk.  The following runs were on a power 8 BE machine.  I
did not see failures on LE.

This is kind of odd.  If I run the test case like this the 64 bit run fails:

make  -k check-target-libgomp RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
fortran.exp=libgomp.fortran/alloc-2.F90"
                === libgomp tests ===
Running target unix/-m32
                === libgomp Summary for unix/-m32 ===
# of expected passes            2
Running target unix/-m64
FAIL: libgomp.fortran/alloc-2.F90   -O  execution test
                === libgomp Summary for unix/-m64 ===
# of expected passes            1
# of unexpected failures        1
                === libgomp Summary ===
# of expected passes            3
# of unexpected failures        1

The error is:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x3fffb7f80477 in ???
#1  0x3fffb799af24 in __GI___libc_free
        at /usr/src/debug/glibc-2.17-c758a686/malloc/malloc.c:2941
#2  0x3fffb7b9940f in omp_free
        at /home/seurer/gcc/git/gcc-test2/libgomp/allocator.c:391
#3  0x100015bb in ???
#4  0x10001793 in ???
#5  0x3fffb7927ceb in generic_start_main
        at ../csu/libc-start.c:266
FAIL: libgomp.fortran/alloc-2.F90   -O  execution test


If I run just the 32 or the 64 bit ones individually they work:

make  -k check-target-libgomp RUNTESTFLAGS="--target_board=unix'{-m32}'
fortran.exp=libgomp.fortran/alloc-2.F90"
                === libgomp tests ===
Running target unix/-m32
                === libgomp Summary ===
# of expected passes            2

make  -k check-target-libgomp RUNTESTFLAGS="--target_board=unix'{-m64}'
fortran.exp=libgomp.fortran/alloc-2.F90"
                === libgomp tests ===
Running target unix/-m64
                === libgomp Summary ===
# of expected passes            2


If I run the 64 bit one before the 32 bit one they both work.  If I do the 64
bit one twice the second run fails.  If I do the 32 bit one twice they both
work.

So, it looks like something is not being cleaned up between the runs that
causes the second run to fail if it is a 64 bit run.

[Bug testsuite/100071] Test case libgomp.fortran/alloc-2.F90 fails with invalid memory reference

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
did you try running the executable within valgrind?  maybe it's simply a heap
corruption issue that's hard to trigger.

[Bug testsuite/100071] Test case libgomp.fortran/alloc-2.F90 fails with invalid memory reference

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I have and see
==3196657== Invalid write of size 8
==3196657==    at 0x401DAF: MAIN__ (in
/home/jakub/src/gcc/obj02/x86_64-pc-linux-gnu/libgomp/testsuite/alloc-2.exe)
==3196657==    by 0x40204A: main (in
/home/jakub/src/gcc/obj02/x86_64-pc-linux-gnu/libgomp/testsuite/alloc-2.exe)
==3196657==  Address 0x4f2a560 is 48 bytes inside a block of size 896 free'd
==3196657==    at 0x483A9F5: free (vg_replace_malloc.c:538)
==3196657==    by 0x401C20: MAIN__ (in
/home/jakub/src/gcc/obj02/x86_64-pc-linux-gnu/libgomp/testsuite/alloc-2.exe)
==3196657==    by 0x40204A: main (in
/home/jakub/src/gcc/obj02/x86_64-pc-linux-gnu/libgomp/testsuite/alloc-2.exe)
==3196657==  Block was alloc'd at
==3196657==    at 0x4839809: malloc (vg_replace_malloc.c:307)
==3196657==    by 0x4CF6CCC: omp_aligned_alloc.part.0 (in
/home/jakub/src/gcc/obj02/x86_64-pc-linux-gnu/libgomp/.libs/libgomp.so.1.0.0)
==3196657==    by 0x4018E1: MAIN__ (in
/home/jakub/src/gcc/obj02/x86_64-pc-linux-gnu/libgomp/testsuite/alloc-2.exe)
==3196657==    by 0x40204A: main (in
/home/jakub/src/gcc/obj02/x86_64-pc-linux-gnu/libgomp/testsuite/alloc-2.exe)

2021-04-14  Jakub Jelinek  <jakub@redhat.com>

        PR testsuite/100071
        * testsuite/libgomp.fortran/alloc-1.F90: Call c_f_pointer after last
        cp = omp_alloc with cp, p arguments instead of cq, q and call
        c_f_pointer after last cq = omp_alloc with cq, q.

--- libgomp/testsuite/libgomp.fortran/alloc-1.F90.jj    2020-07-18
00:05:57.245601544 +0200
+++ libgomp/testsuite/libgomp.fortran/alloc-1.F90       2021-04-14
10:35:19.425186364 +0200
@@ -155,12 +155,13 @@
         cp = omp_alloc (ONEoFIVE,                                       &
      &                  omp_null_allocator)
         if (mod (transfer (cp, intptr), 32_c_intptr_t) /= 0) stop 17
-        call c_f_pointer (cq, q, [ONEoFIVE                              &
+        call c_f_pointer (cp, p, [ONEoFIVE                              &
      &                            / c_sizeof (i)])
         p(1) = 5
         p(ONEoFIVE / c_sizeof (i)) = 6
         cq = omp_alloc (768_c_size_t, omp_null_allocator)
         if (mod (transfer (cq, intptr), 128_c_intptr_t) /= 0) stop 18
+        call c_f_pointer (cq, q, [768 / c_sizeof (i)])
         q(1) = 7
         q(768 / c_sizeof (i)) = 8
         if (c_associated (omp_alloc (768_c_size_t, omp_null_allocator))) &

seems to fix it.

[Bug testsuite/100071] Test case libgomp.fortran/alloc-2.F90 fails with invalid memory reference

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 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:287be7f7a587cb08eb88ecee39ff5556a22976d2

commit r11-8167-g287be7f7a587cb08eb88ecee39ff5556a22976d2
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Apr 14 10:48:56 2021 +0200

    testsuite: Fix up libgomp.fortran/alloc-1.F90 testcase [PR100071]

    As can be seen under valgrind, the testcase didn't bind in the last part
    the fortran pointers properly to the c pointers.

    2021-04-14  Jakub Jelinek  <jakub@redhat.com>

            PR testsuite/100071
            * testsuite/libgomp.fortran/alloc-1.F90: Call c_f_pointer after
last
            cp = omp_alloc with cp, p arguments instead of cq, q and call
            c_f_pointer after last cq = omp_alloc with cq, q.

[Bug testsuite/100071] Test case libgomp.fortran/alloc-2.F90 fails with invalid memory reference

[seurer at gcc dot gnu.org]

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

--- Comment #4 from seurer at gcc dot gnu.org ---
Thanks for the fix.  Any idea why it failed in the weird way it did?  I ran it
dozens of times and it only failed and then every time when the 64 bit test run
was done a second time?

[Bug testsuite/100071] Test case libgomp.fortran/alloc-2.F90 fails with invalid memory reference

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It was writing into malloced memory after free, anything could happen.