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

[Robert Hager]

Thanks, all! That makes sense (and the code worked without the
initializations in question).

BTW, my original email to the PETSc mailing list was held up for review by
a moderator yesterday. So that's probably why you haven't seen it there yet.

Best,

Robert

On Mon, Jul 21, 2025 at 9:10 AM Barry Smith <bsmith at petsc.dev> wrote:

>
>    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> 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> wrote:
>>
>>> FYI
>>>
>>> ---------- Forwarded message ---------
>>> From: Robert Hager <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>
>>>
>>>
>>> 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!ff1QrxkF_3zJXayYxscsHslgcC5yaFfwPYqgEvYwhn9Zc_NC9pomafs9Ry0gaVyQwhFIk2ddjV3fAIFTeqS2zg$ 
> <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/cd232c63/attachment.html>