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 <bsm...@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 <knep...@gmail.com> wrote: > > On Mon, Jul 21, 2025 at 7:49 AM Mark Adams <mfad...@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 <rha...@pppl.gov> wrote: >> >>> FYI >>> >>> ---------- Forwarded message --------- >>> From: Robert Hager <rha...@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@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-_$> > > >
