sfilippone/psblas3

segmenation fault with ifort 2018 routine psb_spasb

Opened this issue · 4 comments

I am using psblas3-development on the AMU mesocentre, with ifort 2018. I obtained segmetation fault errors on executing my application (either in debug mode or optimized). The error appeared in different parts of the code whether or not I was doing different stuffs in my application (such as, for example, saving my unknown vector). I realized the fault was caused by the routine psb_spasb (commenting this routine the code used to run without problem).

The problem was solved by modifying the file: base/modules/serial/psb_d_mat_mod.F90

replacing the following line (~line 248)

class(psb_d_base_sparse_mat), allocatable, target, &                                                                                                                                                                                                                                   
      & save, private :: psb_d_base_mat_default 

with

  class(psb_d_base_sparse_mat), allocatable, target, &
       & save :: psb_d_base_mat_default

and also the file: base/serial/impl/psb_d_mat_impl.F90

replacing the following line (~line 1265)

allocate(altmp, mold=psb_get_mat_default(a),stat=info)

with

if (.not.allocated(psb_d_base_mat_default)) then
allocate(psb_d_csr_sparse_mat :: psb_d_base_mat_default)
end if
allocate(altmp, mold=psb_d_base_mat_default,stat=info)

Thanks for the bug report and for testing the workaround. I will check what happens with other versions of IFORT, and will investigate a general solution.

The need for the POINTER assignment can be worked around in a better way when we introduce SUBMODULES in the library. Because SUBMODULES would be a choice purely on the implementation side, with no changes to the user/visible interface, they could be introduced in version 3.6.1/3.6.2. However, they would require a bump of the GCC minimum version to 6, so maybe it's best to do it in version 3.7.0.

@sfilippone You will of course also need to do some testing. After submodule support was added, there were some important bug fixes in later releases. I don't recall many details, but there is at least some chance the version might need to be higher than the 6.1 for what you need. GFortran developer Jerry DeLisle add sumdodule support under contract for Sourcery Institute so he'll know the most detail, but of course you'll figure out what version you need once you test.

@rouson a quick test with 6.4.0, which is the current release, seems to give positive results.
This particular issue has to take a backseat for the time being, unless it surfaces for other users, in which case I can always put in the workaround I have now, especially considering it would leave the user interface essentially unchanged.