This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/46408] [OOP] Segfault when running gfortran.dg/class_allocate_6.f03


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

--- Comment #7 from janus at gcc dot gnu.org 2011-01-02 19:02:31 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > x%a should get default-initialized to NULL via the memcpy call from
> > x._vptr->_def_init. The memcpy itself is done alright, but apparently the
> > _def_init variable is not properly initialized (is it?):
> > 
> >   static struct t2 __def_init_MAIN___t2 = {};
> 
> 
> No, it's not. The problem is:  __def_init_MAIN___t2 is declared as SAVE in
> gfc_find_derived_vtab. Therefore it's allocatable components do not get
> default-initialized to NULL.

However, if I add a static initializer for this guy, i.e.

  static struct t2 __def_init_MAIN___t2 = {.a=0B};

I still get the same valgrind error. What the hell?


Conclusion: The error must come from the second part of the copying routine's
dump:

        if (D.1545.a != 0B)
          {
            __builtin_free ((void *) D.1545.a);
          }
        D.1545.a = 0B;

Here D.1545 is the old value of the destination. Since this was just freshly
allocated before calling the copy routine, it's technically undefined (unless
the malloc zeroes it). Now, that really is it!

Two possible solutions:

1) Initialize with _def_init, before calling _copy (which means extra work
since we initialize twice).

2) Forget about freeing the old value of 'dst' (which is fine as long as we
only call _copy on allocation, where dst is undefined; this is currently the
case).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]