[Bug fortran/81241] write end of file

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81241

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from Dominique d'Humieres  ---


*** This bug has been marked as a duplicate of bug 81195 ***

[Bug fortran/81241] write end of file

[townsend at astro dot wisc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81241

--- Comment #6 from Rich Townsend  ---
Jim's patch for pr81195 fixes all the issues we've been experiencing -- so yes,
this counts as a duplicate. Thanks to all for the quick response.

[Bug fortran/81241] write end of file

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81241

--- Comment #5 from Dominique d'Humieres  ---
AFAICT this seems fixed on trunk (8.0) and gcc-7 by the patch for pr81195.
Duplicate?

[Bug fortran/81241] write end of file

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81241

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-06-29
 Ever confirmed|0   |1

[Bug fortran/81241] write end of file

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81241

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #4 from Jerry DeLisle  ---
We had to do significant changes to support DTIO and internal units. A stack is
used to hold unit information as execution passes between parent and child I/O
statements. That bug was discovered and fixed by Jim. So I hope you can try 7.2
or latest trunk, 8.0 and confirm.

[Bug fortran/81241] write end of file

[wilson at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81241

Jim Wilson  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #3 from Jim Wilson  ---
It might be related to
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81195
which is already fixed on mainline and for gcc-7.2.  This failure was triggered
by multithreaded write statements.

[Bug fortran/81241] write end of file

[townsend at astro dot wisc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81241

--- Comment #2 from Rich Townsend  ---
Aha, given that MESA is multithreaded, this may well be linked to this issue:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78387

Certainly, running with just 1 thread seems to make things behave.

[Bug fortran/81241] write end of file

[townsend at astro dot wisc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81241

--- Comment #1 from Rich Townsend  ---
(Apologies for the initial blank description, my web-browser submitted before I
was ready).

I've recently upgraded to gfortran 7.1 from 5.3, and am seeing a large number
of breakages in a significant piece of software that I help maintain (the
"Modules for Experiments in Stellar Astrophysics" project -- MESA).

The breakages are unfortunately intermittent -- sometimes they occur, and
sometimes not. But they all share the similarity of being triggered by internal
write statements. Sometimes the code crashes with a segfault on the internal
write; and sometimes it stops with the error message:

Fortran runtime error: End of fileERROR STOP 1

The breakage occurs on both Linux and OSX 10.12.

As an example backtrace from a segfault:

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

Backtrace for this error:
#0  0x2b7af459555f in ???
#1  0x2b7af381f7d6 in write_decimal
at /root/mesasdk-src/gcc/libgfortran/io/write.c:852
#2  0x2b7af3816c9c in formatted_transfer_scalar_write
at /root/mesasdk-src/gcc/libgfortran/io/transfer.c:2043
#3  0x2b7af38170fc in formatted_transfer
at /root/mesasdk-src/gcc/libgfortran/io/transfer.c:2272
#4  0x859bca in setstr
at ../private/eosdt_load_tables.f90:220
#5  0x85b624 in __eosdt_load_tables_MOD_get_eosdt_table_filenames
at ../private/eosdt_load_tables.f90:192
#6  0x85e132 in read_one
at ../private/eosdt_load_tables.f90:172
#7  0x85e2bd in do_read
at ../private/eosdt_load_tables.f90:156
#8  0x85e2bd in __eosdt_load_tables_MOD_load_single_eosdt_table_by_id
at ../private/eosdt_load_tables.f90:149
#9  0x8242cf in __eosdt_eval_MOD_get_eosdt_xtable_results
at ../private/eosdt_eval.f90:1079
#10  0x825cc9 in do_interp2
at ../private/eosdt_eval.f90:797
#11  0x825cc9 in __eosdt_eval_MOD_get_opal_scvh_results
at ../private/eosdt_eval.f90:758
#12  0x826c51 in __eosdt_eval_MOD_get_eosdt_results
at ../private/eosdt_eval.f90:387
#13  0x828800 in f
at ../private/eosdt_eval.f90:2340
#14  0x9362d2 in __mod_root_MOD_do_safe_root_with_guess
at ../private/mod_root.f:102
#15  0x81ff7b in __eosdt_eval_MOD_do_safe_get_rho_t
at ../private/eosdt_eval.f90:2297
#16  0x820508 in __eosdt_eval_MOD_get_rho
at ../private/eosdt_eval.f90:2178
#17  0x829199 in __eospt_eval_MOD_get_pt_results_using_dt
at ../private/eospt_eval.f90:1127
#18  0x82c783 in __eospt_eval_MOD_get_eospt_results
at ../private/eospt_eval.f90:213
#19  0x8171c1 in __eos_lib_MOD_eospt_get
at ../public/eos_lib.f90:805
#20  0x4ae874 in eval_eospt
at ../private/micro.f90:678
#21  0x4ae874 in __micro_MOD_do_eos_for_cell
at ../private/micro.f90:381
#22  0x4293d4 in __star_utils_MOD_foreach_cell._omp_fn.1
at ../private/star_utils.f90:68
#23  0x2b7af3cd48cd in gomp_thread_start
at /root/mesasdk-src/gcc/libgomp/team.c:120
#24  0x2b7af434c65c in ???
#25  0x2b7af4633ecc in ???
./rn: line 8:  5111 Segmentation fault  (core dumped) ./star

The offending line of code which triggered the segfault was this:

write(str, '(a,i1)') '0', floor(100d0 * v + 0.5)

I realize that this is an unconventional bug report -- I'm unable to provide a
test case which demonstrates the problem, since it comes and goes. However, I'm
hoping the backtrace above may be helpful, and I'd appreciate any suggestions
on how to proceed in tracking this down.

cheers,

Rich