Segfault when prune_modes= .true.

Bug/problem reports for any of the GYRE executables (gyre_ad, gyre_nad, etc)
Post Reply
wvrossem
Posts: 1
Joined: Fri Feb 01, 2019 12:56 pm

Segfault when prune_modes= .true.

Post by wvrossem » Tue Feb 05, 2019 8:54 am

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
Attachments
segfaults.tgz
profile and inlist for gyre
(294.02 KiB) Downloaded 13 times

warrick
Posts: 51
Joined: Wed Aug 28, 2013 2:47 am

Re: Segfault when prune_modes= .true.

Post by warrick » Tue Feb 05, 2019 10:25 am

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

User avatar
rhtownsend
Site Admin
Posts: 305
Joined: Sun Mar 31, 2013 4:22 pm

Re: Segfault when prune_modes= .true.

Post by rhtownsend » Tue Feb 05, 2019 10:36 am

warrick wrote:
Tue Feb 05, 2019 10:25 am
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
Posts: 51
Joined: Wed Aug 28, 2013 2:47 am

Re: Segfault when prune_modes= .true.

Post by warrick » Tue Feb 05, 2019 11:00 am

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

User avatar
rhtownsend
Site Admin
Posts: 305
Joined: Sun Mar 31, 2013 4:22 pm

Re: Segfault when prune_modes= .true.

Post by rhtownsend » Tue Feb 05, 2019 11:36 am

warrick wrote:
Tue Feb 05, 2019 11:00 am
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
Posts: 51
Joined: Wed Aug 28, 2013 2:47 am

Re: Segfault when prune_modes= .true.

Post by warrick » Wed Feb 06, 2019 6:27 am

rhtownsend wrote:
Tue Feb 05, 2019 11:36 am
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...

User avatar
rhtownsend
Site Admin
Posts: 305
Joined: Sun Mar 31, 2013 4:22 pm

Re: Segfault when prune_modes= .true.

Post by rhtownsend » Wed Feb 06, 2019 9:30 am

warrick wrote:
Wed Feb 06, 2019 6:27 am
rhtownsend wrote:
Tue Feb 05, 2019 11:36 am
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!

User avatar
rhtownsend
Site Admin
Posts: 305
Joined: Sun Mar 31, 2013 4:22 pm

Re: Segfault when prune_modes= .true.

Post by rhtownsend » Wed Feb 06, 2019 9:32 am

rhtownsend wrote:
Wed Feb 06, 2019 9:30 am
warrick wrote:
Wed Feb 06, 2019 6:27 am
rhtownsend wrote:
Tue Feb 05, 2019 11:36 am
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!

Post Reply