Bug 53296 - Segfault on non-constant character array constructor containing kind spec
Summary: Segfault on non-constant character array constructor containing kind spec
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.6.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2012-05-09 15:38 UTC by gccbgz.lionm
Modified: 2020-10-13 02:42 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.6.1, 4.8.0
Last reconfirmed: 2013-06-16 00:00:00


Attachments
source raising the segfault (329 bytes, text/plain)
2012-05-09 15:38 UTC, gccbgz.lionm
Details

Note You need to log in before you can comment on or make changes to this bug.
Description gccbgz.lionm 2012-05-09 15:38:41 UTC
Created attachment 27360 [details]
source raising the segfault

Executing the binary compiled from attached source prints:

 size          78
 arr: ABCDEGHIJ 
 size           1
Speicherzugriffsfehler (Speicherabzug geschrieben)

Besides the segfault, the array size should not change.

This is not reproducable when replacing the character(*)-type entities by integer(INT64) nor when omitting the function call in the constructor.
Comment 1 Tobias Burnus 2012-05-09 17:22:43 UTC
It also doesn't segfault if one replaces the call by:

  call rou( [character(len=120) :: "123",uCase("abcde"),uCase("ghij")])

Namely: adding as first item in the constructor list a string literal (which by construction has a known length).

According to VALGRIND, the problem is an
   Invalid free() / delete / delete[] / realloc()
in line 10 or, if commented, in line 9. Line 9 is the "call rou" line.


With ifort 12.1, the programs seems to work while with cryftn it fails at run time with an illegal instruction. In any case, the program looks valid to me.
Comment 2 Tobias Burnus 2012-05-10 10:35:22 UTC
Simplified program.

* As is, it prints 128
* Without  "txt", it prints 5 and segfaults
* Without  character(len=128) :: "txt",   it prints 5 and works

Thus, the extension to 128 characters does not properly work in the case of having no character literal. That matches what is in the code:

          character(kind=1) A.16[2][1:5];
vs.
          character(kind=1) A.15[3][1:128];


I have not looked through the source code, but the first place, where constructors string lengths are handled is array.c's gfc_resolve_character_array_constructor. I don't quickly see whether it does so correctly or not. If it does, the failure must be later.

It might be that in that function, the "txt" is correctly extended and padded to len=128 - and that then everything is later handled correctly because the first element has the right size?


program charArrErr
  implicit none
  call rou([character(len=128) :: "txt", uCase("abcde"),uCase("ghij_")])
contains
  subroutine rou(arr)
    implicit none
    character(*),intent(in) :: arr(:)
    print *, len(arr)
  end subroutine

  function uCase(str)
    implicit none
    character(*), intent(in) :: str
    character(len(str)) :: uCase
    uCase=str
  end function uCase
end program charArrErr
Comment 3 Dominique d'Humieres 2013-06-16 22:34:26 UTC
Still present at revision 200133.
Comment 4 kargls 2018-03-09 00:03:41 UTC
This seems to have morphed into a strange off-by-1
in the array constructor.  Consider this code,

 program chararrerr

   implicit none

   character(len=128) :: str(2)
   str = [ucase("abcde"), ucase("ghij")]
 
   contains

   function ucase(str)
      character(*) :: str
      character(len(str)) :: ucase
      intent(in) :: str
      ucase = str
      print *, '>' // trim(str) // '<', len(str)
   end function ucase

end program chararrerr

Trunk gives

% gfcx -o z a.f90 -fdump-tree-original && ./z
 >abcde<           5
 >abcde<           5
 >ghij<           4

For some reason, the first element is evaluated twice.