Hi Paul, whoopsie, I remember that I inserted the check for _len > 0 in allocate(). So it was me causing the bug. Thanks that you found it. The patch looks good to me. Thanks for the work.
- Andre On Mon, 30 Oct 2017 12:20:20 +0000 Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > Dear All, > > This bug took a silly amount of effort to diagnose but once done, the > fix was obvious. > > The bug is triggered in this function from the reporter's source file > gfc_graph.F90: > > function GraphIterAppendVertex(this,vertex) result(ierr) > !Appends a new vertex to the graph. > implicit none > integer(INTD):: ierr !out: error code > class(graph_iter_t), intent(inout):: this !inout: > graph iterator > class(graph_vertex_t), intent(in), target:: vertex !in: new vertex > type(vert_link_refs_t):: vlr > > ierr=this%vert_it%append(vertex) !<===== right here! > ....snip.... > return > end function GraphIterAppendVertex > > 'vertex' is being passed to a class(*) dummy. As you will see from the > attached patch and the ChangeLog, 'vertex' was being cast as unlimited > polymorphic and assigned to the passed actual argument. This left the > _len field indeterminate since it is not present in normal (limited?) > polymorphic objects. > > Further down the way, in stsubs.F90(clone_object) an allocation is > being made using the unlimited version of 'vertex as a source. Since > the size passed to malloc for an unlimited source is, for _len > 0, > the value of the _len multiplied by the vtable _size, the amount of > memory is also indeterminate and causes the operating system to flag a > failed allocation, pretty much at random. > > The ChangeLog and the patch describe the fix sufficiently well as not > to require further explanation. I will write a testcase that tests the > tree dump for the _len field before committing the patch. > > Bootstraps and regtests on FC23/x86_64 - OK for 7- and 8-branches? > > If I do not receive any contrary comments, I will commit tonight. > > Regards > > Paul > > 2017-10-30 Paul Thomas <pa...@gcc.gnu.org> > > PR fortran/80850 > * trans_expr.c (gfc_conv_procedure_call): When passing a class > argument to an unlimited polymorphic dummy, it is wrong to cast > the passed expression as unlimited, unless it is unlimited. The > correct way is to assign to each of the fields and set the _len > field to zero. -- Andre Vehreschild * Email: vehre ad gmx dot de
