Segfault when prune_modes= .true.

[wvrossem]

Hi,

When running gyre 5.2 I ran into the following problem. Setting prune_modes to True and using the attached inlist and model resulted in the following error:

Code: Select all

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

Backtrace for this error:
#0  0x7fd836965f1f in ???
#1  0x485897 in ???
#2  0x42281d in ???
#3  0x406728 in ???
#4  0x404d16 in ???
#5  0x7fd836948b96 in ???
#6  0x404d49 in ???
#7  0xffffffffffffffff in ???
Segmentation fault (core dumped)

A similar error occurs when using the test cases in gyre, setting prune_modes to True, and including one of the following summary items:

Code: Select all

omega_int
freq
Delta_p
Delta_g
eta
f_T
f_g
psi_T
E
E_p
E_g
E_norm
E_ratio
H
W
W_eps
tau_ss
tau_tr
beta
x_ref
xi_r_ref
xi_h_ref
eul_phi_ref
deul_phi_ref
lag_S_ref
lag_L_ref

Kind regards,
Walter

[warrick]

Hi Rich,

Walter already shared this with me. I can reproduce the segfault by going to the adiabatic solar test case and setting `prune_modes = .TRUE.`.

My suspicion is that the culprits are any variables that are calculated from discarded data when the summary is written. So, e.g. the code for `freq` uses the grid object (`gr`) but that was already discarded when the mode was pruned.

W

[rhtownsend]

Hi Rich,

Walter already shared this with me. I can reproduce the segfault by going to the adiabatic solar test case and setting `prune_modes = .TRUE.`.

My suspicion is that the culprits are any variables that are calculated from discarded data when the summary is written. So, e.g. the code for `freq` uses the grid object (`gr`) but that was already discarded when the mode was pruned.

W

Yes, that's the problem. The work-around is to not prune the modes, and/or remove the output items that are trying to access the discarded data. Longer term, I'll fix GYRE so it prints out a useful error message rather than just crashing.

cheers,

Rich

[warrick]

Would another potential solution be to write the summary data at the same time as the mode data? Or is this for some reason undesirable?

I'm not expecting you to do this! Rather, I thought I might tinker around to see if I can manage to do it myself, but I'll pass if there's some reason you aren't already doing it this way.

Edit: I think I've found the right place to hack the frontend to spew the desired output to the terminal.

W

[rhtownsend]

Would another potential solution be to write the summary data at the same time as the mode data? Or is this for some reason undesirable?

I'm not expecting you to do this! Rather, I thought I might tinker around to see if I can manage to do it myself, but I'll pass if there's some reason you aren't already doing it this way.

Edit: I think I've found the right place to hack the frontend to spew the desired output to the terminal.

W

The problem with this is that not all the summary data is available at that point (since we haven't yet calculated all the modes). This is less of a problem for TXT output (because we write that file line-by-line), but for HDF5 output we would have to continually re-write the file as new modes are found.

However, how about we cache the summary data in memory (adding to these data as new modes are found), and then write it all out in a single step at the end? We already do something similar with TXT files (although we store string representations of the data, rather than the data themselves).

cheers,

Rich

[warrick]

The problem with this is that not all the summary data is available at that point (since we haven't yet calculated all the modes). This is less of a problem for TXT output (because we write that file line-by-line), but for HDF5 output we would have to continually re-write the file as new modes are found.

However, how about we cache the summary data in memory (adding to these data as new modes are found), and then write it all out in a single step at the end? We already do something similar with TXT files (although we store string representations of the data, rather than the data themselves).

cheers,

Rich

Caching sounds like the smart thing to do. Is there an example of how this is done somewhere in the source already? I honestly wouldn't know how to set it up, especially without ruining your beautiful object-oriented Fortran 2008...

[rhtownsend]

The problem with this is that not all the summary data is available at that point (since we haven't yet calculated all the modes). This is less of a problem for TXT output (because we write that file line-by-line), but for HDF5 output we would have to continually re-write the file as new modes are found.

However, how about we cache the summary data in memory (adding to these data as new modes are found), and then write it all out in a single step at the end? We already do something similar with TXT files (although we store string representations of the data, rather than the data themselves).

cheers,

Rich

Caching sounds like the smart thing to do. Is there an example of how this is done somewhere in the source already? I honestly wouldn't know how to set it up, especially without ruining your beautiful object-oriented Fortran 2008...

Probably best that I take care of this, so it can be done in an OO manner. Keep bugging me about it!

[rhtownsend]

The problem with this is that not all the summary data is available at that point (since we haven't yet calculated all the modes). This is less of a problem for TXT output (because we write that file line-by-line), but for HDF5 output we would have to continually re-write the file as new modes are found.

However, how about we cache the summary data in memory (adding to these data as new modes are found), and then write it all out in a single step at the end? We already do something similar with TXT files (although we store string representations of the data, rather than the data themselves).

cheers,

Rich

Caching sounds like the smart thing to do. Is there an example of how this is done somewhere in the source already? I honestly wouldn't know how to set it up, especially without ruining your beautiful object-oriented Fortran 2008...

Probably best that I take care of this, so it can be done in an OO manner. Keep bugging me about it!

That said, have a look at src/output/gyre_txt_writer.fpp for an example of how I do caching for TXT files. Basically, I store arrays of strings that contain the current summary output for each column. To do this for HDF5 files, we would have to have separate arrays for real, integer, complex etc data, since we don't want to convert to strings. And, we would have to keep track of which arrays contain which columns. Doable, but a little more complicated. Feel free to give it a shot, however!