[Bug libfortran/109454] New: Possible memory leak after using random_number

[Bug libfortran/109454] New: Possible memory leak after using random_number

[stephen at soliday dot com]

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

            Bug ID: 109454
           Summary: Possible memory leak after using random_number
           Product: gcc
           Version: 11.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: stephen at soliday dot com
  Target Milestone: ---

Simple call to RANDOM_NUMBER leaves 168 bytes still reachable after the process
exits, as indicated by valgrind.

GNU Fortran:   11.3.0
valgrind:      3.18.1
Ubuntu:        22.04.2 LTS
Linux Kernel:  5.15.0-69-generic


v----- cut here --------v (rtest.f90)
program main
  use iso_fortran_env
  implicit none

  real(REAL64) :: x

  call random_number(x)

  print *, x

end program main
^----- cut here --------^

gfortran -o rtest rtest.f90

valgrind --leak-check=full --show-leak-kinds=all regulus/bin/ftest_fuzzy
./rtest

v----- cut here ---------v
==44961== Memcheck, a memory error detector
==44961== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==44961== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==44961== Command: regulus/bin/ftest_fuzzy ./rtest
==44961== 
  0.26639924712129115     
==44961== 
==44961== HEAP SUMMARY:
==44961==     in use at exit: 168 bytes in 2 blocks
==44961==   total heap usage: 133 allocs, 131 frees, 112,809 bytes allocated
==44961== 
==44961== 40 bytes in 1 blocks are still reachable in loss record 1 of 2
==44961==    at 0x484DA83: calloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==44961==    by 0x6CF8F86: ??? (in
/usr/lib/x86_64-linux-gnu/libgfortran.so.5.0.0)
==44961==    by 0x6F63F46: _gfortran_random_r8 (in
/usr/lib/x86_64-linux-gnu/libgfortran.so.5.0.0)
==44961==    by 0x1136DC: __ftest_fuzzy_test_MOD_test03 (ftest_fuzzy.f90:221)
==44961==    by 0x116FD1: MAIN__ (ftest_fuzzy.f90:238)
==44961==    by 0x11702D: main (ftest_fuzzy.f90:234)
==44961== 
==44961== 128 bytes in 1 blocks are still reachable in loss record 2 of 2
==44961==    at 0x484DCD3: realloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==44961==    by 0x70A58AC: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==44961==    by 0x70B8114: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==44961==    by 0x70A3FE1: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==44961==    by 0x400647D: call_init.part.0 (dl-init.c:70)
==44961==    by 0x4006567: call_init (dl-init.c:33)
==44961==    by 0x4006567: _dl_init (dl-init.c:117)
==44961==    by 0x40202E9: ??? (in
/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2)
==44961==    by 0x1: ???
==44961==    by 0x1FFF00015A: ???
==44961==    by 0x1FFF000172: ???
==44961== 
==44961== LEAK SUMMARY:
==44961==    definitely lost: 0 bytes in 0 blocks
==44961==    indirectly lost: 0 bytes in 0 blocks
==44961==      possibly lost: 0 bytes in 0 blocks
==44961==    still reachable: 168 bytes in 2 blocks
==44961==         suppressed: 0 bytes in 0 blocks
==44961== 
==44961== For lists of detected and suppressed errors, rerun with: -s
==44961== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
^----- cut here ---------^

[Bug libfortran/109454] Possible memory leak after using random_number

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think this is a bogus leak from valgrind. Specifically not supporting
pthread_getspecific, pthread_setspecific .

[Bug libfortran/109454] Possible memory leak after using random_number

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is obviously a valgrind bug not tracking
pthread_getspecific/pthread_setspecific .