public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/56594] New: Invalid read of size 1 for gfortran.dg/realloc_on_assign_5.f03
@ 2013-03-11 13:28 dominiq at lps dot ens.fr
  2013-03-17 19:56 ` [Bug fortran/56594] " tilo@tilo-schwarz.de
  2013-04-08 20:25 ` tkoenig at gcc dot gnu.org
  0 siblings, 2 replies; 3+ messages in thread
From: dominiq at lps dot ens.fr @ 2013-03-11 13:28 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56594

             Bug #: 56594
           Summary: Invalid read of size 1 for
                    gfortran.dg/realloc_on_assign_5.f03
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dominiq@lps.ens.fr


Running gfortran.dg/realloc_on_assign_5.f03 under valgrind gives

==32678== Invalid read of size 1
==32678==    at 0x7FFFFFE007D4: ???
==32678==    by 0x100000DA6: MAIN__ (realloc_on_assign_5.f03:15)
==32678==    by 0x100000E60: main (realloc_on_assign_5.f03:18)
==32678==  Address 0x100449541 is 0 bytes after a block of size 1 alloc'd
==32678==    at 0x100012891: realloc (vg_replace_malloc.c:635)
==32678==    by 0x100000D71: MAIN__ (realloc_on_assign_5.f03:15)
==32678==    by 0x100000E60: main (realloc_on_assign_5.f03:18)
==32678== 

Program aborted. Backtrace:
#0  0x10001fe42
#1  0x1000201b2
#2  0x1000f1618
#3  0x100000dfc
#4  0x100000e60
==32678== 
==32678== Process terminating with default action of signal 6 (SIGABRT)
==32678==    at 0x1001DA0B6: __kill (in /usr/lib/libSystem.B.dylib)
==32678==    by 0x100020198: _gfortrani_sys_abort (in
/opt/gcc/gcc4.8w/lib/libgfortran.3.dylib)
==32678==    by 0x100000E60: main (realloc_on_assign_5.f03:18)
==32678== 
==32678== HEAP SUMMARY:
==32678==     in use at exit: 3,822 bytes in 18 blocks
==32678==   total heap usage: 21 allocs, 3 frees, 3,953 bytes allocated
==32678== 
==32678== LEAK SUMMARY:
==32678==    definitely lost: 0 bytes in 0 blocks
==32678==    indirectly lost: 0 bytes in 0 blocks
==32678==      possibly lost: 0 bytes in 0 blocks
==32678==    still reachable: 3,734 bytes in 17 blocks
==32678==         suppressed: 88 bytes in 1 blocks
==32678== Rerun with --leak-check=full to see details of leaked memory
==32678== 
==32678== For counts of detected and suppressed errors, rerun with: -v
==32678== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Abort

The test also aborts at run time when compiled with -fsanitize=address.

Reduced test

program main
  implicit none
  character(:), allocatable :: a, b
  a = 'ax'
  a = a(2:2)
end program main

There is no error if "a = a(2:2)" is replaced with "a = 'x'".


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

* [Bug fortran/56594] Invalid read of size 1 for gfortran.dg/realloc_on_assign_5.f03
  2013-03-11 13:28 [Bug fortran/56594] New: Invalid read of size 1 for gfortran.dg/realloc_on_assign_5.f03 dominiq at lps dot ens.fr
@ 2013-03-17 19:56 ` tilo@tilo-schwarz.de
  2013-04-08 20:25 ` tkoenig at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: tilo@tilo-schwarz.de @ 2013-03-17 19:56 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56594

Tilo Schwarz <tilo@tilo-schwarz.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tilo@tilo-schwarz.de

--- Comment #1 from Tilo Schwarz <tilo@tilo-schwarz.de> 2013-03-17 19:56:11 UTC ---
I think the problem is, that for the line 

a = a(2:2)

1st, a is realloced to length one and
2nd, a(2) is memmoved to a(1), but at that time a(2) is already invalid.

Using -fdump-tree-original:

On line 42 the realloc happens to length 1.
On line 50 the memmove happens from &(*a)[2], which is not valid anymore
because of the realloc on line 42.

 42         a = (character(kind=1)[1:.a] *) __builtin_realloc ((void *) a, 1);
 43         L.4:;
 44         .a = 1;
 45         D.1827 = .a;
 46         if (D.1827 != 0)
 47           {
 48             if ((character(kind=4)) D.1827 <= 1)
 49               {
 50                 __builtin_memmove ((void *) a, (void *) &(*a)[2]{lb: 1 sz:
1}, (character(kind=4)) D.1827);
 51               }


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

* [Bug fortran/56594] Invalid read of size 1 for gfortran.dg/realloc_on_assign_5.f03
  2013-03-11 13:28 [Bug fortran/56594] New: Invalid read of size 1 for gfortran.dg/realloc_on_assign_5.f03 dominiq at lps dot ens.fr
  2013-03-17 19:56 ` [Bug fortran/56594] " tilo@tilo-schwarz.de
@ 2013-04-08 20:25 ` tkoenig at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2013-04-08 20:25 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56594

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

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

--- Comment #2 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2013-04-08 20:25:49 UTC ---
Dup of PR 47674.

*** This bug has been marked as a duplicate of bug 47674 ***


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

end of thread, other threads:[~2013-04-08 20:25 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-11 13:28 [Bug fortran/56594] New: Invalid read of size 1 for gfortran.dg/realloc_on_assign_5.f03 dominiq at lps dot ens.fr
2013-03-17 19:56 ` [Bug fortran/56594] " tilo@tilo-schwarz.de
2013-04-08 20:25 ` tkoenig at gcc dot gnu.org

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).