Some notes on this change are at https://urldefense.us/v3/__https://gitlab.com/petsc/petsc/-/merge_requests/7517__;!!G_uCfscf7eWS!aQQ-TMsusc4QHRyMCbC8OwFN-znAEEo80ngP1kAlhvQJ_3zegcumVUvSqcBuE6lTbRZ0LWeAKXEXHEBXPmWRk-6NNBs$
Satish On Fri, 21 Mar 2025, Barry Smith wrote: > > I have just pushed a major update to the Fortran interface to the main > PETSc git branch. Could you please try to work with main (to become release > in a couple of weeks) with your Fortran code as we debug the problem? This > will save you a lot of work and hopefully make the debugging more > straightforward. > > You can send the same output with the debugger if it crashes in the main > branch and I can try to track down what is going wrong. > > Barry > > > > > > On Mar 21, 2025, at 12:37 AM, Sanjay Govindjee via petsc-users > > <petsc-users@mcs.anl.gov> wrote: > > > > I am trying to upgrade my code to PETSc 3.22.4 (the code was last updated > > to 3.19.4 or perhaps 3.18.1, I've lost track). I've been using this code > > with PETSc for over 20 years. > > > > To get my code to compile and link during this update, I only need to make > > two changes; one was to use PetscViewerPushFormat instead of > > PetscViewerSetFormat and the other was to use PETSC_NULL_INTEGER_ARRAY in a > > spot or two. > > > > When I run the code however, I am getting an error very early on during a > > call to MatCreate near the beginning of the code. The screen output says: > > [3]PETSC ERROR: matcreate_() at > > /Users/sg/petsc-3.22.4/gnug/src/mat/utils/ftn-auto/gcreatef.c:101 Cannot > > create PETSC_NULL_XXX object > > [0]PETSC ERROR: matcreate_() at > > /Users/sg/petsc-3.22.4/gnug/src/mat/utils/ftn-auto/gcreatef.c:101 Cannot > > create PETSC_NULL_XXX object > > [1]PETSC ERROR: matcreate_() at > > /Users/sg/petsc-3.22.4/gnug/src/mat/utils/ftn-auto/gcreatef.c:101 Cannot > > create PETSC_NULL_XXX object > > [2]PETSC ERROR: matcreate_() at > > /Users/sg/petsc-3.22.4/gnug/src/mat/utils/ftn-auto/gcreatef.c:101 Cannot > > create PETSC_NULL_XXX object > > I have a 4 processor run going. I am running with > > -on_error_attach_debugger but the debugger is giving me cryptic (at least > > to me) output (the same for all 4 processes modulo the PID). Stack traces > > seem to be unavailable :( > > lldb -p 71963 > > (lldb) process attach --pid 71963 > > Process 71963 stopped > > * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP > > frame #0: 0x00007fff69d92746 libsystem_kernel.dylib`__semwait_signal + > > 10 > > libsystem_kernel.dylib`__semwait_signal: > > -> 0x7fff69d92746 <+10>: jae 0x7fff69d92750 ; <+20> > > 0x7fff69d92748 <+12>: movq %rax, %rdi > > 0x7fff69d9274b <+15>: jmp 0x7fff69d9121d ; cerror > > 0x7fff69d92750 <+20>: retq > > Target 0: (feap) stopped. > > > > Executable module set to "/Users/sg/Feap/ver87/parfeap/feap". > > Architecture set to: x86_64h-apple-macosx-. > > Does anyone have any hints as to what may be going on? Note the program > > starts normally and i can do stuff with the interactive interface for the > > code -- even plotting the mesh etc. so I believe the input data has been > > read in correctly. The crash only occurs when I initiate the formation of > > the matrix. > > > > I am attaching the > > /Users/sg/petsc-3.22.4/gnug/src/mat/utils/ftn-auto/gcreatef.c file in case > > that offers some insight. > > > > Note, I have been > > -sanjay > > -- > > <gcreatef.c> > >
