[petsc-users] Segfaults when calling some PETSc functions in Fortran with variables initialized to PETSC_NULL_XX

Barry Smith bsmith at petsc.dev
Mon Jul 21 08:10:36 CDT 2025


   One passes PETSC_NULL_XXX  as an argument that one does not want to get filled up, an optional argument. Similarly in PETSc C one passes NULL as an optional argument. 

   You should not be setting variables to PETSC_NULL_XXX. When they are declared in your code they are automatically correctly initialized to an appropriate default value (which is not PETSC_NULL_XXX). 

   You can use code such as

   if (PetscObjectIsNull(vec)) then 

   to check if a PetscObject is currently validly set. Do not use

   if (vec == PETSC_NULL_VEC) then

   So, for example,

   VecCreate(..., vec,ierr)
   ....
   VecDestroy(vec,ierr)
   if (PetscObjectIsNull(vec)) then 
      print*, 'vector was appropriately freed')
    endif
   VecCreate(..., vec,ierr)
   ....

   Any further questions, please ask on petsc-maint or petsc-users

   Barry 

  

> On Jul 21, 2025, at 8:49 AM, Matthew Knepley <knepley at gmail.com> wrote:
> 
> On Mon, Jul 21, 2025 at 7:49 AM Mark Adams <mfadams at lbl.gov <mailto:mfadams at lbl.gov>> wrote:
>> Hi Robert, [I don't see this message to PETSc users in my email so cc'ing manually]
>> 
>> This is odd, something is messed up. 
>> These NULL things are certainly 0 and the initial value of these objects is not defined by the compiler, and they could be 0 in some cases.
> 
> Hi Robert,
> 
> I am not the Fortran expert, but I believe that passing PETSC_NULL_XXX to a creation routine is not correct. Here is my logic.
> 
> In the wrapper, PETSC_NULL_XXX is converted to a NULL pointer (_not_ a pointer whose value is NULL). Thus KSPCreate would try to set a NULL pointer and you get the SEGV. I think it may have worked before because this was not automated, so these routines did not check for PETSC_NULL_XXX since it is not a case handled by the C function.
> 
> Could you try without initializing? Barry would have to tell you what they should be initialized to.
> 
>   Thanks,
> 
>      Matt
>  
>> Others are more up on the new Fortran stuff, but I would do a clean build of PETSc (rm -fr arch...), and turn debugging on. 
>> You will get a stack trace and it might find something and give a useful error message, or "fix" the problem mysteriously.
>> 
>> You could put a print statement in before these are initialized to see what *was* in it that you are clobbering.
>> 
>> Mark
>> 
>> 
>> On Sun, Jul 20, 2025 at 10:33 AM Robert Hager <rhager at pppl.gov <mailto:rhager at pppl.gov>> wrote:
>>> FYI
>>> 
>>> ---------- Forwarded message ---------
>>> From: Robert Hager <rhager at pppl.gov <mailto:rhager at pppl.gov>>
>>> Date: Sun, Jul 20, 2025 at 10:32 AM
>>> Subject: Segfaults when calling some PETSc functions in Fortran with variables initialized to PETSC_NULL_XX
>>> To: <petsc-users at mcs.anl.gov <mailto:petsc-users at mcs.anl.gov>>
>>> 
>>> 
>>> Hello,
>>> 
>>> I am in the process of updating my code to use PETSc versions >=3.22. (I am using v3.22.3 compiled with GCC on Perlmutter-CPU at NERSC for debugging at this time.) After updating all the Fortran function calls that have changed from v3.21 to v3.22 I am now getting segfaults in some PETSc routines. In the two instances I was able to identify, the problem seems to be calling the PETSc function with a PETSc variable that has been initialized to PETSC_NULL_XX:
>>> 
>>> solver%rhs2_mat = PETSC_NULL_MAT
>>> [...]
>>> call MatDuplicate(solver%Amat,MAT_DO_NOT_COPY_VALUES,solver%rhs2_mat,ierr)
>>> --> Segfault
>>> 
>>> solver%ksp      = PETSC_NULL_KSP
>>> [...]
>>> call KSPCreate(solver%comm,solver%ksp,ierr)
>>> --> Segfault
>>> 
>>> When I comment out the assignments to PETSC_NULL_XX in the above examples, the code works just fine.
>>> 
>>> Is this the intended behavior or a bug that you might have fixed by now?
>>> 
>>> Best,
>>> 
>>> Robert
> 
> 
> 
> --
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
> -- Norbert Wiener
> 
> https://urldefense.us/v3/__https://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!egzw7ALU5FsbUczu5y2X9FXQ7OQkGlERHVGi34DRcifCs4AIpGl4eCMgo5jZtd3OCkBB4NFbMiXA8gyS7yRnYjA$  <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfscf7eWS!Ylz6mzmFkBJe1SAiy6sraNQ79TbZP3WWJtJY0kJSoeydhbohH8fH8uPd-f_ig_mjlKa2S7MME6rnPWQlLV-_$>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20250721/4747b542/attachment.html>


More information about the petsc-users mailing list