Segmentation fault when finalizing an inherited type with custom constructor

I’m trying to troubleshoot some code that was working in earlier gfortran versions (5-12), but when compiled with gfortran 13.2.1 it produces a segmentation fault. The following appears to be the minimum that reproduces the problem:

module finalization_with_inheritance

     character(:), allocatable::name
  end type parent

  type, extends(parent)::child
  end type child

  interface child
     module procedure new_child
  end interface child


  type(child) function new_child(name)



  end function new_child

  subroutine child_finalize(this)

    type(child), intent(in)::this

  end subroutine child_finalize

end module finalization_with_inheritance

program main

  use finalization_with_inheritance, only: child

  implicit none

  kid = child("Name")

end program main

Note that in the example the type child has the following properties:

  • It inherits from another type (parent)
  • It is instantiated by a call to a custom constructor that modifies a member of the ancestor type (child%name)
  • It has a finalization routine

It appears that all of the above are required to duplicate the problem.

So my questions for the community are:

  • Is there a problem with how I wrote my program? Or is this a compiler bug?
  • If this is a compiler bug, is there any way to simplify the code and still reproduce the problem, and are there any workarounds I can try?
1 Like

I confirm it crashes most of the time with GFortran 13.2.0 under Ubuntu 23.10. Most of the time, because sometimes (15-20% of the time) it does not.

It runs with GFortran 11.4.0.

In FreeBSD 14.0 with GFortran 13.2.0:

$ gfortran -g bug.f90 && ./a.out

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x825420379 in ???
#1  0x82541f4a5 in ???
#2  0x8216632d2 in ???
#3  0x823b01fa4 in atomic_load_p
	at /usr/src/contrib/jemalloc/include/jemalloc/internal/atomic.h:62
#4  0x823b01fa4 in rtree_leaf_elm_bits_read
	at /usr/src/contrib/jemalloc/include/jemalloc/internal/rtree.h:175
#5  0x823b01fa4 in rtree_szind_slab_read
	at /usr/src/contrib/jemalloc/include/jemalloc/internal/rtree.h:500
#6  0x823b01fa4 in ifree
	at /usr/obj/usr/src/amd64.amd64/lib/libc/jemalloc_jemalloc.c:2574
#7  0x823b01fa4 in __je_free_default
	at /usr/obj/usr/src/amd64.amd64/lib/libc/jemalloc_jemalloc.c:2775
#8  0x400f2e in __finalization_with_inheritance_MOD___final_finalization_with_inheritance_Parent
	at /home/vmagnin/bug.f90:32
#9  0x400ac1 in __finalization_with_inheritance_MOD___final_finalization_with_inheritance_Child
	at /home/vmagnin/bug.f90:32
#10  0x401214 in MAIN__
	at /home/vmagnin/bug.f90:41
#11  0x401253 in main
	at /home/vmagnin/bug.f90:36
Segmentation fault (core dumped)

It runs with GFortran 12.2.0.

Mac OS Arm same
crash.txt (758 Bytes)

Since the bug has been confirmed, please consider filing a bug report through GCC Bugzilla. Or you can can send an email to

fortran at gcc dot gnu dot org


Welcome to Discourse @jhaiduce!

I would suggest to file a bug to GCC Bugzilla.

In case it helps, please also include the following: the crash is caused by the inherited type not containing further variables. If you add even just one, then everything works again.

Try again with this version:

  type, extends(parent)::child
     integer :: do_not_crash = 0
  end type child

If this also works for you, please do submit this additional info to the gfortran team.

1 Like

According to @JerryD it may be related to:

As suggested by @Beliavsky and @FedericoPerini you could contact the GFortran team and post your minimalist code.

Concerning GFortran bug reporting / development / testing, I remind you that you can find up to date information here:

Thanks @FedericoPerini, that works for me too. I’ve also added variables to inherited types in my production code and that fixes the segmentation fault I encountered there.

This looks to me like a duplicate of . With that being the case, I’m wondering if it’s better not to file a bug report. I’ll send a message to the gfortran mailing list and see what people there think about filing.

1 Like

Yes, if you think it is that bug don’t fill a new report. But you can send a message on the mailing list or add a post to the bug 110987, with the shortest code that crashes and precise versions of your compilers and OS.

I posted to the mailing list and the feedback there was also a suggestion to post a comment to bug 110987. I’ve added my code along with a summary of this thread to the bug report (see comments 5 and 6 on that bug). Thanks all for confirming this bug and helping me with reporting and troubleshooting!


Fix on March 29 on gcc 14.