public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/99711] New: Crash when reading an allocated character array in namelist
@ 2021-03-22 14:02 phil1691 at gmail dot com
2021-03-23 1:11 ` [Bug fortran/99711] " jvdelisle at gcc dot gnu.org
` (19 more replies)
0 siblings, 20 replies; 21+ messages in thread
From: phil1691 at gmail dot com @ 2021-03-22 14:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
Bug ID: 99711
Summary: Crash when reading an allocated character array in
namelist
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: phil1691 at gmail dot com
Target Milestone: ---
The following code crashes with a segmentation fault (gcc 10.2.0):
> cat alloc_nml.f90
program allocnml
implicit none
character(len=:), dimension(:), allocatable :: cbulist_ru
integer :: iluseg
namelist /nam_bu_ru/ cbulist_ru
allocate( character(len=10) :: cbulist_ru(5) )
open(newunit=iluseg, file='list.nml', status='old', &
action='read', form='formatted', access='sequential')
read(unit=iluseg, nml=nam_bu_ru)
print *, cbulist_ru
close(unit=iluseg)
end program allocnml
With the following namelist file:
> cat list.nml
&NAM_BU_RU
CBULIST_RU(1) = 'PRES'
CBULIST_RU(2) = 'NEST'
CBULIST_RU(3) = 'HTURB'
CBULIST_RU(4) = 'VTURB'
/
Compilation:
> gfortran -g alloc_nml.f90
Execution:
> ./a.out
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x146bdba3349f in ???
#1 0x146bdbb57d7a in ???
#2 0x146bdc79df4b in nml_read_obj
at ../../../gcc-10.2.0-srcdir/libgfortran/io/list_read.c:3142
#3 0x146bdc79ee8a in nml_get_obj_data
at ../../../gcc-10.2.0-srcdir/libgfortran/io/list_read.c:3512
#4 0x146bdc7a78b7 in finalize_transfer
at ../../../gcc-10.2.0-srcdir/libgfortran/io/transfer.c:4128
#5 0x400d48 in allocnml
at
/home/waup/F90/bug_gcc/character_allocatable_namelist/alloc_nml.f90:14
#6 0x400e20 in main
at
/home/waup/F90/bug_gcc/character_allocatable_namelist/alloc_nml.f90:19
Erreur de segmentation (core dumped)
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/99711] Crash when reading an allocated character array in namelist
2021-03-22 14:02 [Bug fortran/99711] New: Crash when reading an allocated character array in namelist phil1691 at gmail dot com
@ 2021-03-23 1:11 ` jvdelisle at gcc dot gnu.org
2021-03-23 2:11 ` kargl at gcc dot gnu.org
` (18 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2021-03-23 1:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jvdelisle at gcc dot gnu.org
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
F2018 standard section 13.10.3 List-directed Input
There is a note NOTE 13.29 at the end of the first sub-section 13.10.3.1"
"An allocatable, deferred-length character effective item does not have its
allocation status or allocated length changed as a result of list-directed
input."
This implies that if the strings of the array are not already allocated to a
resonable length, for example a string of blanks, then the read will attempt to
transfer the file contents into unallocated strings.
If the status is unallocated the list READ cannot do any allocation to change
its status to ALLOCATED.
Thus all bets are off if it crashes. The read routines have no idea of the size
to allocate the length to until the read is completed. There may be other
places in the standard to clarify this, but looks like invalid fortran.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/99711] Crash when reading an allocated character array in namelist
2021-03-22 14:02 [Bug fortran/99711] New: Crash when reading an allocated character array in namelist phil1691 at gmail dot com
2021-03-23 1:11 ` [Bug fortran/99711] " jvdelisle at gcc dot gnu.org
@ 2021-03-23 2:11 ` kargl at gcc dot gnu.org
2021-03-23 2:29 ` jvdelisle at gcc dot gnu.org
` (17 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: kargl at gcc dot gnu.org @ 2021-03-23 2:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #1)
> F2018 standard section 13.10.3 List-directed Input
>
> There is a note NOTE 13.29 at the end of the first sub-section 13.10.3.1"
>
> "An allocatable, deferred-length character effective item does not have its
> allocation status or allocated length changed as a result of list-directed
> input."
>
> This implies that if the strings of the array are not already allocated to a
> resonable length, for example a string of blanks, then the read will attempt
> to transfer the file contents into unallocated strings.
Doesn't the line
allocate( character(len=10) :: cbulist_ru(5) )
that is the first executable statement in the program
allocate an array of 5 strings with length 10?
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/99711] Crash when reading an allocated character array in namelist
2021-03-22 14:02 [Bug fortran/99711] New: Crash when reading an allocated character array in namelist phil1691 at gmail dot com
2021-03-23 1:11 ` [Bug fortran/99711] " jvdelisle at gcc dot gnu.org
2021-03-23 2:11 ` kargl at gcc dot gnu.org
@ 2021-03-23 2:29 ` jvdelisle at gcc dot gnu.org
2021-03-23 2:41 ` jvdelisle at gcc dot gnu.org
` (16 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2021-03-23 2:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |---
Last reconfirmed| |2021-03-23
Status|RESOLVED |NEW
Ever confirmed|0 |1
--- Comment #3 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to kargl from comment #2)
> (In reply to Jerry DeLisle from comment #1)
> > F2018 standard section 13.10.3 List-directed Input
> >
> > There is a note NOTE 13.29 at the end of the first sub-section 13.10.3.1"
> >
> > "An allocatable, deferred-length character effective item does not have its
> > allocation status or allocated length changed as a result of list-directed
> > input."
> >
> > This implies that if the strings of the array are not already allocated to a
> > resonable length, for example a string of blanks, then the read will attempt
> > to transfer the file contents into unallocated strings.
>
> Doesn't the line
>
> allocate( character(len=10) :: cbulist_ru(5) )
>
> that is the first executable statement in the program
> allocate an array of 5 strings with length 10?
You are right Steve, tired eyes were "seeing" only the declaration. In that
case this should be OK and I do see the segfault. It is likely a front end
issue.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/99711] Crash when reading an allocated character array in namelist
2021-03-22 14:02 [Bug fortran/99711] New: Crash when reading an allocated character array in namelist phil1691 at gmail dot com
` (2 preceding siblings ...)
2021-03-23 2:29 ` jvdelisle at gcc dot gnu.org
@ 2021-03-23 2:41 ` jvdelisle at gcc dot gnu.org
2021-03-23 6:16 ` sgk at troutmask dot apl.washington.edu
` (15 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2021-03-23 2:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
--- Comment #4 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Setting the character length in the type spec enables this to run correctly, so
the string length is not getting set correctly in the allocate statement.
program allocnml
implicit none
character(len=10), dimension(:), allocatable :: cbulist_ru ! set here
integer :: iluseg
namelist /nam_bu_ru/ cbulist_ru
allocate( character(len=10) :: cbulist_ru(5) )
open(newunit=iluseg, file='list.nml', status='old', &
action='read', form='formatted', access='sequential')
read(unit=iluseg, nml=nam_bu_ru)
print *, cbulist_ru
close(unit=iluseg)
end program allocnml
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/99711] Crash when reading an allocated character array in namelist
2021-03-22 14:02 [Bug fortran/99711] New: Crash when reading an allocated character array in namelist phil1691 at gmail dot com
` (3 preceding siblings ...)
2021-03-23 2:41 ` jvdelisle at gcc dot gnu.org
@ 2021-03-23 6:16 ` sgk at troutmask dot apl.washington.edu
2021-03-23 7:37 ` philippe.wautelet at aero dot obs-mip.fr
` (14 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2021-03-23 6:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Tue, Mar 23, 2021 at 02:41:27AM +0000, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
>
> --- Comment #4 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
> Setting the character length in the type spec enables this to run correctly, so
> the string length is not getting set correctly in the allocate statement.
>
> program allocnml
> implicit none
>
> character(len=10), dimension(:), allocatable :: cbulist_ru ! set here
> integer :: iluseg
>
> namelist /nam_bu_ru/ cbulist_ru
>
> allocate( character(len=10) :: cbulist_ru(5) )
>
> open(newunit=iluseg, file='list.nml', status='old', &
> action='read', form='formatted', access='sequential')
>
> read(unit=iluseg, nml=nam_bu_ru)
>
> print *, cbulist_ru
>
I don't use namelist, so will defer to you on the details.
I input file only defines cbulist_ru(1) through cbulist_ru(4),
so the namelist initializes only an array section. If that
is conforming, then technically the print statement is invalid,
because cbulist_ru(5) is uninitialized.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/99711] Crash when reading an allocated character array in namelist
2021-03-22 14:02 [Bug fortran/99711] New: Crash when reading an allocated character array in namelist phil1691 at gmail dot com
` (4 preceding siblings ...)
2021-03-23 6:16 ` sgk at troutmask dot apl.washington.edu
@ 2021-03-23 7:37 ` philippe.wautelet at aero dot obs-mip.fr
2021-03-24 2:41 ` jvdelisle at gcc dot gnu.org
` (13 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: philippe.wautelet at aero dot obs-mip.fr @ 2021-03-23 7:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
--- Comment #6 from philippe.wautelet at aero dot obs-mip.fr ---
Hello,
The segfault occurs on the read line.
If I allocate the array with the right number of lines (allocate(
character(len=10) :: cbulist_ru(4)), I get exactly the same behavior
(segfault).
However, if I initialize the array just after its allocation:
cbulist_ru(:)=''
and runs the application, it prints:
> ./a.out
VTURB
which is the last line of the variable in the namelist.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/99711] Crash when reading an allocated character array in namelist
2021-03-22 14:02 [Bug fortran/99711] New: Crash when reading an allocated character array in namelist phil1691 at gmail dot com
` (5 preceding siblings ...)
2021-03-23 7:37 ` philippe.wautelet at aero dot obs-mip.fr
@ 2021-03-24 2:41 ` jvdelisle at gcc dot gnu.org
2021-03-24 3:15 ` jvdelisle at gcc dot gnu.org
` (12 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2021-03-24 2:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
--- Comment #7 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Digging further within gfc_resolve_dt which is resolving the READ statement,
one can find:
(gdb) p *e->symtree.n.sym.ts.u.cl
$31 = {length = 0x0, next = 0x0, length_from_typespec = false, backend_decl =
0x0,
passed_length = 0x0, resolved = 1}
e is the gfc_expr for cbulist_ru in the test case
I have checked both the gfc_expr itself and it's symtree and in all cases the
character length is NULL, not being intialized. I suspect it is getting missed
in the resolution of the allocate statement. At this point in gfc_resolve_dt
it is marked as having been resolved.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/99711] Crash when reading an allocated character array in namelist
2021-03-22 14:02 [Bug fortran/99711] New: Crash when reading an allocated character array in namelist phil1691 at gmail dot com
` (6 preceding siblings ...)
2021-03-24 2:41 ` jvdelisle at gcc dot gnu.org
@ 2021-03-24 3:15 ` jvdelisle at gcc dot gnu.org
2021-03-24 5:35 ` sgk at troutmask dot apl.washington.edu
` (11 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2021-03-24 3:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
--- Comment #8 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
I see nowhere in resolve.c (resolve_allocate_expr) any attempt to resolve the
chraracter length. I think it has been missed. I have cc'ed Paul to see if he
has any thoughts.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/99711] Crash when reading an allocated character array in namelist
2021-03-22 14:02 [Bug fortran/99711] New: Crash when reading an allocated character array in namelist phil1691 at gmail dot com
` (7 preceding siblings ...)
2021-03-24 3:15 ` jvdelisle at gcc dot gnu.org
@ 2021-03-24 5:35 ` sgk at troutmask dot apl.washington.edu
2021-03-24 5:45 ` sgk at troutmask dot apl.washington.edu
` (10 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2021-03-24 5:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
--- Comment #9 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Mar 24, 2021 at 02:41:08AM +0000, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
>
> --- Comment #7 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
> Digging further within gfc_resolve_dt which is resolving the READ statement,
> one can find:
>
> (gdb) p *e->symtree.n.sym.ts.u.cl
> $31 = {length = 0x0, next = 0x0, length_from_typespec = false, backend_decl =
> 0x0,
> passed_length = 0x0, resolved = 1}
>
> e is the gfc_expr for cbulist_ru in the test case
>
> I have checked both the gfc_expr itself and it's symtree and in all cases the
> character length is NULL, not being intialized. I suspect it is getting missed
> in the resolution of the allocate statement. At this point in gfc_resolve_dt
> it is marked as having been resolved.
>
What does -ftree-dump-original show? I wonder if gfortran is doing a
re-allocation on assignment when it shouldn't.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/99711] Crash when reading an allocated character array in namelist
2021-03-22 14:02 [Bug fortran/99711] New: Crash when reading an allocated character array in namelist phil1691 at gmail dot com
` (8 preceding siblings ...)
2021-03-24 5:35 ` sgk at troutmask dot apl.washington.edu
@ 2021-03-24 5:45 ` sgk at troutmask dot apl.washington.edu
2021-03-25 3:32 ` jvdelisle at gcc dot gnu.org
` (9 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2021-03-24 5:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
--- Comment #10 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Mar 24, 2021 at 05:35:31AM +0000, sgk at troutmask dot
apl.washington.edu wrote:
>
> What does -ftree-dump-original show? I wonder if gfortran is doing a
> re-allocation on assignment when it shouldn't.
>
Nope. It looks like a counting problem. Here's a modified
testcase.
program allocnml
implicit none
character(len=:), dimension(:), allocatable :: cbulist_ru
integer :: iluseg
namelist /nam_bu_ru/ cbulist_ru
allocate( character(len=10) :: cbulist_ru(4) )
cbulist_ru = 'abc'
print *, size(cbulist_ru), len(cbulist_ru(1))
open(newunit=iluseg, file='list.nml', status='old')
read(unit=iluseg, nml=nam_bu_ru)
print *, size(cbulist_ru), len(cbulist_ru(1))
print *, cbulist_ru
print *, '>'//cbulist_ru(1)//'<'
print *, '>'//cbulist_ru(2)//'<'
print *, '>'//cbulist_ru(3)//'<'
print *, '>'//cbulist_ru(4)//'<'
close(unit=iluseg)
end program allocnml
I get
% gfcx -o z -O a.f90 && ./z
4 10
4 10
VTURB abc abc abc
>VTURB <
>abc <
>abc <
>abc <
which suggests that during the READ, the individual array
elements aren't assigned. That is, the array index is
never incremented from 1 to 4.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/99711] Crash when reading an allocated character array in namelist
2021-03-22 14:02 [Bug fortran/99711] New: Crash when reading an allocated character array in namelist phil1691 at gmail dot com
` (9 preceding siblings ...)
2021-03-24 5:45 ` sgk at troutmask dot apl.washington.edu
@ 2021-03-25 3:32 ` jvdelisle at gcc dot gnu.org
2021-03-26 1:47 ` jvdelisle at gcc dot gnu.org
` (8 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2021-03-25 3:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
--- Comment #11 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Steve, I agree with your comment. Now in the READ at runtime there is a loop
specification that is initialized to allow the read process to loop through
these elements of an array. This works fine elsewhere, so I suspect, based on
what you see here, that this loopspec is not getting initialized correctly
meaning the array descriptor is uninitialized or otherwize corrupted. It is a
bit late for me to look at this tonight, but as I get time I will examine where
we set the loop spec and where it comes from.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/99711] Crash when reading an allocated character array in namelist
2021-03-22 14:02 [Bug fortran/99711] New: Crash when reading an allocated character array in namelist phil1691 at gmail dot com
` (10 preceding siblings ...)
2021-03-25 3:32 ` jvdelisle at gcc dot gnu.org
@ 2021-03-26 1:47 ` jvdelisle at gcc dot gnu.org
2021-03-26 2:25 ` jvdelisle at gcc dot gnu.org
` (7 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2021-03-26 1:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
--- Comment #12 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
This is interesting, compiling with the -g option for debugging.
Running a test case that is working with:
character(len=10), dimension(:), allocatable :: cbulist_ru ! explicit char
len
Breakpoint 1, nml_read_obj (dtp=dtp@entry=0x7fffffffd260,
nl=nl@entry=0x5184c0, offset=offset@entry=0,
pprev_nl=pprev_nl@entry=0x7fffffffd068,
nml_err_msg=nml_err_msg@entry=0x7fffffffd100 "Internal namelist read
error", clow=1, chigh=0, nml_err_msg_size=200)
at ../../../trunk/libgfortran/io/list_read.c:2886
2886 if (dtp->u.p.nml_read_error || !nl->touched)
(gdb) p nl
$1 = (namelist_info *) 0x5184c0
(gdb) p *nl
$2 = {type = BT_CHARACTER, var_name = 0x518530 "cbulist_ru",
mem_pos = 0x515e80, dtio_sub = 0x0, vtable = 0x0, touched = 1, len = 1,
var_rank = 1, size = 10, string_length = 10, dim = 0x518550, ls = 0x518570,
next = 0x0}
string_length as expected.
Running the failing test case with:
character(len=:), dimension(:), allocatable :: cbulist_ru ! deferred len
Breakpoint 1, nml_read_obj (dtp=dtp@entry=0x7fffffffd240,
nl=nl@entry=0x5184c0, offset=offset@entry=0,
pprev_nl=pprev_nl@entry=0x7fffffffd048,
nml_err_msg=nml_err_msg@entry=0x7fffffffd0e0 "Internal namelist read
error", clow=1, chigh=0, nml_err_msg_size=200)
at ../../../trunk/libgfortran/io/list_read.c:2886
2886 if (dtp->u.p.nml_read_error || !nl->touched)
(gdb) p nl->string_length
$13 = 10
(gdb) p *nl
$14 = {type = BT_CHARACTER, var_name = 0x518530 "cbulist_ru",
mem_pos = 0x515e80, dtio_sub = 0x0, vtable = 0x0, touched = 1, len = 1,
var_rank = 1, size = 967676983855022080, string_length = 10, dim = 0x518550,
ls = 0x518570, next = 0x0}
(gdb) p *nl->dim
$15 = {_stride = 1, lower_bound = 1, _ubound = 5}
size is messed up badly.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/99711] Crash when reading an allocated character array in namelist
2021-03-22 14:02 [Bug fortran/99711] New: Crash when reading an allocated character array in namelist phil1691 at gmail dot com
` (11 preceding siblings ...)
2021-03-26 1:47 ` jvdelisle at gcc dot gnu.org
@ 2021-03-26 2:25 ` jvdelisle at gcc dot gnu.org
2021-03-26 2:38 ` jvdelisle at gcc dot gnu.org
` (6 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2021-03-26 2:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
--- Comment #13 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Looking at the -fdump-tree-originals in the two cases:
The working case:
{.elem_len=10, .rank=1, .type=6});
The failing case:
D.3962 = (sizetype) NON_LVALUE_EXPR <.cbulist_ru>;
.....
{.elem_len=(unsigned long) SAVE_EXPR <D.3962>, .rank=1, .type=6});
Also one sees this:
Breakpoint 1, _gfortran_st_set_nml_var (dtp=0x7fffffffd2a0, var_addr=0x408910,
var_name=0x402053 "cbulist_ru", len=1, string_length=10, dtype=...)
at ../../../trunk/libgfortran/io/transfer.c:4597
4597 {
(gdb) p *dtype
Structure has no component named operator*.
(gdb) p dtype
$1 = {elem_len = 14971996835529359360, version = 0, rank = 1 '\001',
type = 6 '\006', attribute = 0}
The call to _gfortran_st_set_nml_var is created by the frontend as shown in the
dump, the elem_len is bogus.
As far as I can tell then, the front-end is failing in the allocation
initializing the size correctly.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/99711] Crash when reading an allocated character array in namelist
2021-03-22 14:02 [Bug fortran/99711] New: Crash when reading an allocated character array in namelist phil1691 at gmail dot com
` (12 preceding siblings ...)
2021-03-26 2:25 ` jvdelisle at gcc dot gnu.org
@ 2021-03-26 2:38 ` jvdelisle at gcc dot gnu.org
2021-03-26 6:04 ` sgk at troutmask dot apl.washington.edu
` (5 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2021-03-26 2:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
--- Comment #14 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Created attachment 50473
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50473&action=edit
-fdump-tree-original for failing case
Attached the dump file of the failing case.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/99711] Crash when reading an allocated character array in namelist
2021-03-22 14:02 [Bug fortran/99711] New: Crash when reading an allocated character array in namelist phil1691 at gmail dot com
` (13 preceding siblings ...)
2021-03-26 2:38 ` jvdelisle at gcc dot gnu.org
@ 2021-03-26 6:04 ` sgk at troutmask dot apl.washington.edu
2021-03-26 23:38 ` jvdelisle at gcc dot gnu.org
` (4 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2021-03-26 6:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
--- Comment #15 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Fri, Mar 26, 2021 at 01:47:28AM +0000, jvdelisle at gcc dot gnu.org wrote:
> --- Comment #12 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
> This is interesting, compiling with the -g option for debugging.
>
> Running a test case that is working with:
>
> character(len=10), dimension(:), allocatable :: cbulist_ru ! explicit char
> len
>
> Breakpoint 1, nml_read_obj (dtp=dtp@entry=0x7fffffffd260,
> nl=nl@entry=0x5184c0, offset=offset@entry=0,
> pprev_nl=pprev_nl@entry=0x7fffffffd068,
> nml_err_msg=nml_err_msg@entry=0x7fffffffd100 "Internal namelist read
> error", clow=1, chigh=0, nml_err_msg_size=200)
> at ../../../trunk/libgfortran/io/list_read.c:2886
> 2886 if (dtp->u.p.nml_read_error || !nl->touched)
> (gdb) p nl
> $1 = (namelist_info *) 0x5184c0
> (gdb) p *nl
> $2 = {type = BT_CHARACTER, var_name = 0x518530 "cbulist_ru",
> mem_pos = 0x515e80, dtio_sub = 0x0, vtable = 0x0, touched = 1, len = 1,
> var_rank = 1, size = 10, string_length = 10, dim = 0x518550, ls = 0x518570,
> next = 0x0}
>
> string_length as expected.
>
Hmmm. Another place that string length info is held? gfortran
has ts->u.cl.length, expr->value->character->length, and now
nl->string_length. Yep, I would say that the deferred length
isn't being propagated into the nl struct. Probably need to
check for expr->ts.type == BT_CHARACTER and expr->ts.deferred
to grab the string length from the type spec.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/99711] Crash when reading an allocated character array in namelist
2021-03-22 14:02 [Bug fortran/99711] New: Crash when reading an allocated character array in namelist phil1691 at gmail dot com
` (14 preceding siblings ...)
2021-03-26 6:04 ` sgk at troutmask dot apl.washington.edu
@ 2021-03-26 23:38 ` jvdelisle at gcc dot gnu.org
2021-03-27 3:14 ` jvdelisle at gcc dot gnu.org
` (3 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2021-03-26 23:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
--- Comment #16 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
FWIW it also segfaults on:
write(unit=6, nml=nam_bu_ru)
I have been digging around with gdb in trans-io.c and I can see the cl is 0x0
in the sym->ts.u.cl and I can find nothing else accessible at this point. I
think I am going to have to go back to the "trans" for the allocate which
should have the length resolved and stuff it into the sym.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/99711] Crash when reading an allocated character array in namelist
2021-03-22 14:02 [Bug fortran/99711] New: Crash when reading an allocated character array in namelist phil1691 at gmail dot com
` (15 preceding siblings ...)
2021-03-26 23:38 ` jvdelisle at gcc dot gnu.org
@ 2021-03-27 3:14 ` jvdelisle at gcc dot gnu.org
2023-08-31 12:58 ` philippe.wautelet at aero dot obs-mip.fr
` (2 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2021-03-27 3:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
--- Comment #17 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to Jerry DeLisle from comment #16)
> FWIW it also segfaults on:
>
> write(unit=6, nml=nam_bu_ru)
>
> I have been digging around with gdb in trans-io.c and I can see the cl is
> 0x0 in the sym->ts.u.cl and I can find nothing else accessible at this
> point. I think I am going to have to go back to the "trans" for the allocate
> which should have the length resolved and stuff it into the sym.
In trans-stmt.c (gfc_trans_allocate (gfc_code * code))
I find:
(gdb) p *code->ext->alloc.ts.u.cl.length.value.integer._mp_d
$41 = 10
So it is there and there is code to handle it in that function. However, I do
not yet understand the inner workings of frontend to see what the problem is.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/99711] Crash when reading an allocated character array in namelist
2021-03-22 14:02 [Bug fortran/99711] New: Crash when reading an allocated character array in namelist phil1691 at gmail dot com
` (16 preceding siblings ...)
2021-03-27 3:14 ` jvdelisle at gcc dot gnu.org
@ 2023-08-31 12:58 ` philippe.wautelet at aero dot obs-mip.fr
2023-08-31 17:20 ` sgk at troutmask dot apl.washington.edu
2023-08-31 17:22 ` kargl at gcc dot gnu.org
19 siblings, 0 replies; 21+ messages in thread
From: philippe.wautelet at aero dot obs-mip.fr @ 2023-08-31 12:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
--- Comment #18 from philippe.wautelet at aero dot obs-mip.fr ---
Hello,
What is the status of this bug?
It seems that it is not present any more in the 12.x and 13.x GCC versions.
11.4 does not crash but gives incorrect results.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/99711] Crash when reading an allocated character array in namelist
2021-03-22 14:02 [Bug fortran/99711] New: Crash when reading an allocated character array in namelist phil1691 at gmail dot com
` (17 preceding siblings ...)
2023-08-31 12:58 ` philippe.wautelet at aero dot obs-mip.fr
@ 2023-08-31 17:20 ` sgk at troutmask dot apl.washington.edu
2023-08-31 17:22 ` kargl at gcc dot gnu.org
19 siblings, 0 replies; 21+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2023-08-31 17:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
--- Comment #19 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Aug 31, 2023 at 12:58:15PM +0000, philippe.wautelet at aero dot
obs-mip.fr wrote:
>
> What is the status of this bug?
>
> It seems that it is not present any more in the 12.x and 13.x GCC versions.
>
Looks like it is fixed by the patch for some other bug report.
A scan of gcc/fortran/ChangeLog shows a number patches that
tinker with the character length for deferred length strings.
I don't which one is the responsiblei, and since I don't use
git (other than for trivial 'git diff' and 'git pull') doing a
bisection is beyond my skillset.
Someone should likely convert your testcase into something
that the testsuite can digest, and commit it.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [Bug fortran/99711] Crash when reading an allocated character array in namelist
2021-03-22 14:02 [Bug fortran/99711] New: Crash when reading an allocated character array in namelist phil1691 at gmail dot com
` (18 preceding siblings ...)
2023-08-31 17:20 ` sgk at troutmask dot apl.washington.edu
@ 2023-08-31 17:22 ` kargl at gcc dot gnu.org
19 siblings, 0 replies; 21+ messages in thread
From: kargl at gcc dot gnu.org @ 2023-08-31 17:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to work| |12.2.0, 14.0
Priority|P3 |P4
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2023-08-31 17:22 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-22 14:02 [Bug fortran/99711] New: Crash when reading an allocated character array in namelist phil1691 at gmail dot com
2021-03-23 1:11 ` [Bug fortran/99711] " jvdelisle at gcc dot gnu.org
2021-03-23 2:11 ` kargl at gcc dot gnu.org
2021-03-23 2:29 ` jvdelisle at gcc dot gnu.org
2021-03-23 2:41 ` jvdelisle at gcc dot gnu.org
2021-03-23 6:16 ` sgk at troutmask dot apl.washington.edu
2021-03-23 7:37 ` philippe.wautelet at aero dot obs-mip.fr
2021-03-24 2:41 ` jvdelisle at gcc dot gnu.org
2021-03-24 3:15 ` jvdelisle at gcc dot gnu.org
2021-03-24 5:35 ` sgk at troutmask dot apl.washington.edu
2021-03-24 5:45 ` sgk at troutmask dot apl.washington.edu
2021-03-25 3:32 ` jvdelisle at gcc dot gnu.org
2021-03-26 1:47 ` jvdelisle at gcc dot gnu.org
2021-03-26 2:25 ` jvdelisle at gcc dot gnu.org
2021-03-26 2:38 ` jvdelisle at gcc dot gnu.org
2021-03-26 6:04 ` sgk at troutmask dot apl.washington.edu
2021-03-26 23:38 ` jvdelisle at gcc dot gnu.org
2021-03-27 3:14 ` jvdelisle at gcc dot gnu.org
2023-08-31 12:58 ` philippe.wautelet at aero dot obs-mip.fr
2023-08-31 17:20 ` sgk at troutmask dot apl.washington.edu
2023-08-31 17:22 ` kargl 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).