segfaults in libgfortran

Tobias Burnus burnus@net-b.de
Wed Jan 24 13:52:00 GMT 2007


Hi,

Daniel Franke wrote:
> are segfaults in libgfortran which are triggered by "bad" user code
> considered noteworthy bugs?
If e.g. the format is wrong, libgfortran (at least with checking
options, -Wall etc.) should report this and not crash. (Note that
expensive tests might/should not be enabled by default; I think there
are not that many optional tests currently.)

> For example
>   WRITE(*, FMT="(' #elements:', I2)") p%data%graph%nused
>
> segfaults  if one of the pointer components of p%data%graph%nused is
> not associated, graph in this case (libgfortran/io/write.c:158,
> extract_int).
What do you mean by not associated?
(a) unassociated (i.e. using null() or nullify)?
or
(b) undefined (e.g. deallocated, but not nullified; never assigned
pointer, etc.)

The first can be comparably easily checked and in fact there is a PR to
add a check-pointer option to gfortran, which checks for the invalid use
of unassociated pointers: PR 29616.

The second is much harder and actually not supported by many compilers.
One needs to track for every pointer whether it has been ever been
associated. Furthermore, one has also to make sure that the target has
not been deallocated inbetween, e.g. by yet another pointer. As this can
also involve procedure calls with unknown interface, it is in general
only possible if you compile the whole program including all
non-intrinsic procedures with an option (i.e. the association status is
passed on to the procedures, which take therefore additional parameters
just for checking purpose).

I don't think the latter will be implemented any time soon.

Tobias



More information about the Fortran mailing list