Question

正如标题所示，我遇到了与使用派生类型组件有关的段错误。这是Segmentation fault for array, but only if a component of a derived type的后续工作，但代表了更实际的用例。与先前的问题相比，不存在缺少显式接口的问题（下面的示例是一个没有子例程的程序，如果在更实际的用例中对程序进行模块化，结果是相同的。）

! gfortran 4.8.5 on Red Hat linux
! default compile with no extra flags:  "gfortran source.f90"
! default stack size = 8mb (ulimit -s)

program main

    type table
        real :: col(2100000) = 0.0         ! but OK if no initial value
    end type table

    type(table) :: table1(2)               ! but OK if not an array

    table1(1)%col = 1.0                    ! segfault here

end program main

在更现实的用例中（在我的实际用例中），类型table将在模块中定义，为了简洁起见，我将它们全部合并在同一位置。（我确实以这种方式进行了测试（在模块中使用类型定义），并且发生了完全相同的段错误。）

这里至少有3个更改可以消除段错误（只有最后一个对我而言效果很好）

不初始化类型
不要将table1声明为数组
使组件col可分配

关键（对我来说，最令人惊讶的是）似乎是在table1声明为数组，似乎在某种程度上欺骗了编译器。另外，成为派生类型的组件是一个重要方面。

要获得答案，我只是在寻找此处发生的情况的一般说明（包括是否存在某种错误）以及避免该问题的一般建议-特别是此处遵循的最佳实践是什么希望可以帮助我避免这个问题。

请注意，此问题部分与堆栈大小（例如ulimit -s）和外壳程序交互有关，但在上述问题的答案中已很好地解决了这一问题，我希望研究该问题的其他方面此处的问题–并不是要最小化该问题，而是要包括其他方面。

编辑以添加： @Steve评论说：“这与Fortran完全无关，更不用说gfortran了”。这也许是我的问题的症结所在。我希望fortran编译器能够像在此使用的那样处理纯静态声明，但也许我期望太多。根本问题可能是环境（即ulimit -s（8mb））和编译器标志之间的不匹配吗？编译器（gfortran或其他工具）是否无法查询环境或无法自动解决此问题？

在@ripero对前任问题的回答中，我很欣赏增加堆栈大小可能会有所帮助，尽管从某种意义上说问题似乎不一定是堆栈大小，而是某种错误，但对我而言这并不完整-堆栈大小（操作系统或环境级别问题）和编译器选项（例如-fmax-stack-var-size ？

之间是否匹配？

与派生类型的组件有关的分段错误

0 个答案: