Bug report: using a custom ksp convergence function
Hello PETSc Community, I think I've found a bug - Go to $PETSC_DIR/src/ksp/ksp/tutorials/ open ex5f.F90, and add the following line in MyKSPConverged(), say around line 336: call KSPConvergedDefault(ksp,n,rnorm,flag,dummy,ierr) It should make sense why someone would want to do this - within a definition of custom convergence behaviour, get the default convergence flags, and, based on certain conditions, overwrite it. Now, building and running the exercise, making sure to include the flag to use the custom convergence: boston@boston-SYS-540A-TR:~/DATA_DRIVE/PETSC_DIRS/petsc_3.22/src/ksp/ksp/tutorials$ ./ex2f -my_ksp_convergence [0]PETSC ERROR: ------------------------------------------------------------------------ [0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably memory access out of range[...]
From my debugging, the issue is at line 1520 of iterativ.c:
KSPConvergedDefaultCtx *cctx = (KSPConvergedDefaultCtx *)ctx; Because a dummy is used for the context object, this cast fails (my debugger says "cannot access memory..." for cctx). Then the crash happens when trying to access members of cctx: if (cctx->convmaxits && n >= ksp->max_it) { I'm not sure how to fix it. Crucially, we must note that that this did work in older versions of PETSc - I can repeat this test in 3.19.1, for example, and it works fine - a debugger shows the cast succeeding and producing some defaulted version of the ctx object, the subsequent crash does not happen, etc. Does anybody have any advice for working around this for the time being? A piece of software I work with uses a custom ksp convergence test in the manner described above, and is only functional with older versions of petsc because of this. Like in ex2f, I have no need of the ctx object, and just as in ex2f, I use 0 instead. Things I'll try next: defining a proper ctx object (I use 0, like in ex2f), or looking for some PETSC_NULL_CTX definition somewhere. Many Thanks, Daniel
David, KSPConvergedDefault() now takes a non-NULL context that must be provided. I have attached a modified version of ex5f.F90 that demonstrates how it is constructured before being passed to KSPSetConvergenceTest(). Barry
On Jan 20, 2025, at 8:54 AM, Daniel Stone <[email protected]> wrote:
Hello PETSc Community,
I think I've found a bug -
Go to $PETSC_DIR/src/ksp/ksp/tutorials/
open ex5f.F90, and add the following line in MyKSPConverged(), say around line 336:
call KSPConvergedDefault(ksp,n,rnorm,flag,dummy,ierr)
It should make sense why someone would want to do this - within a definition of custom convergence behaviour, get the default convergence flags, and, based on certain conditions, overwrite it.
Now, building and running the exercise, making sure to include the flag to use the custom convergence:
boston@boston-SYS-540A-TR:~/DATA_DRIVE/PETSC_DIRS/petsc_3.22/src/ksp/ksp/tutorials$ ./ex2f -my_ksp_convergence [0]PETSC ERROR: ------------------------------------------------------------------------ [0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably memory access out of range[...]
From my debugging, the issue is at line 1520 of iterativ.c:
KSPConvergedDefaultCtx *cctx = (KSPConvergedDefaultCtx *)ctx;
Because a dummy is used for the context object, this cast fails (my debugger says "cannot access memory..." for cctx). Then the crash happens when trying to access members of cctx:
if (cctx->convmaxits && n >= ksp->max_it) {
I'm not sure how to fix it. Crucially, we must note that that this did work in older versions of PETSc - I can repeat this test in 3.19.1, for example, and it works fine - a debugger shows the cast succeeding and producing some defaulted version of the ctx object, the subsequent crash does not happen, etc.
Does anybody have any advice for working around this for the time being? A piece of software I work with uses a custom ksp convergence test in the manner described above, and is only functional with older versions of petsc because of this. Like in ex2f, I have no need of the ctx object, and just as in ex2f, I use 0 instead.
Things I'll try next: defining a proper ctx object (I use 0, like in ex2f), or looking for some PETSC_NULL_CTX definition somewhere.
Many Thanks,
Daniel
That works wonderfully, thanks! Should be paired with call KSPConvergedDefaultDestroy(ctx,ierr) I think. Best Regards, Daniel On Mon, Jan 20, 2025 at 3:20 PM Barry Smith <[email protected]> wrote:
David,
KSPConvergedDefault() now takes a non-NULL context that must be provided. I have attached a modified version of ex5f.F90 that demonstrates how it is constructured before being passed to KSPSetConvergenceTest().
Barry
On Jan 20, 2025, at 8:54 AM, Daniel Stone <[email protected]> wrote:
Hello PETSc Community,
I think I've found a bug -
Go to $PETSC_DIR/src/ksp/ksp/tutorials/
open ex5f.F90, and add the following line in MyKSPConverged(), say around line 336:
call KSPConvergedDefault(ksp,n,rnorm,flag,dummy,ierr)
It should make sense why someone would want to do this - within a definition of custom convergence behaviour, get the default convergence flags, and, based on certain conditions, overwrite it.
Now, building and running the exercise, making sure to include the flag to use the custom convergence:
boston@boston-SYS-540A-TR:~/DATA_DRIVE/PETSC_DIRS/petsc_3.22/src/ksp/ksp/tutorials$ ./ex2f -my_ksp_convergence [0]PETSC ERROR:
[0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably memory access out of range[...]
From my debugging, the issue is at line 1520 of iterativ.c:
KSPConvergedDefaultCtx *cctx = (KSPConvergedDefaultCtx *)ctx;
Because a dummy is used for the context object, this cast fails (my debugger says "cannot access memory..." for cctx). Then the crash happens when trying to access members of cctx:
if (cctx->convmaxits && n >= ksp->max_it) {
I'm not sure how to fix it. Crucially, we must note that that this did work in older versions of PETSc - I can repeat this test in 3.19.1, for example, and it works fine - a debugger shows the cast succeeding and producing some defaulted version of the ctx object, the subsequent crash does not happen, etc.
Does anybody have any advice for working around this for the time being? A piece of software I work with uses a custom ksp convergence test in the manner described above, and is only functional with older versions of petsc because of this. Like in ex2f, I have no need of the ctx object, and just as in ex2f, I use 0 instead.
Things I'll try next: defining a proper ctx object (I use 0, like in ex2f), or looking for some PETSC_NULL_CTX definition somewhere.
Many Thanks,
Daniel
Yes, that can be passed in also with KSPSetConvergenceTest()
On Jan 21, 2025, at 4:25 AM, Daniel Stone <[email protected]> wrote:
That works wonderfully, thanks! Should be paired with
call KSPConvergedDefaultDestroy(ctx,ierr)
I think.
Best Regards,
Daniel
On Mon, Jan 20, 2025 at 3:20 PM Barry Smith <[email protected] <mailto:[email protected]>> wrote:
David,
KSPConvergedDefault() now takes a non-NULL context that must be provided. I have attached a modified version of ex5f.F90 that demonstrates how it is constructured before being passed to KSPSetConvergenceTest().
Barry
On Jan 20, 2025, at 8:54 AM, Daniel Stone <[email protected] <mailto:[email protected]>> wrote:
Hello PETSc Community,
I think I've found a bug -
Go to $PETSC_DIR/src/ksp/ksp/tutorials/
open ex5f.F90, and add the following line in MyKSPConverged(), say around line 336:
call KSPConvergedDefault(ksp,n,rnorm,flag,dummy,ierr)
It should make sense why someone would want to do this - within a definition of custom convergence behaviour, get the default convergence flags, and, based on certain conditions, overwrite it.
Now, building and running the exercise, making sure to include the flag to use the custom convergence:
boston@boston-SYS-540A-TR:~/DATA_DRIVE/PETSC_DIRS/petsc_3.22/src/ksp/ksp/tutorials$ ./ex2f -my_ksp_convergence [0]PETSC ERROR: ------------------------------------------------------------------------ [0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably memory access out of range[...]
From my debugging, the issue is at line 1520 of iterativ.c:
KSPConvergedDefaultCtx *cctx = (KSPConvergedDefaultCtx *)ctx;
Because a dummy is used for the context object, this cast fails (my debugger says "cannot access memory..." for cctx). Then the crash happens when trying to access members of cctx:
if (cctx->convmaxits && n >= ksp->max_it) {
I'm not sure how to fix it. Crucially, we must note that that this did work in older versions of PETSc - I can repeat this test in 3.19.1, for example, and it works fine - a debugger shows the cast succeeding and producing some defaulted version of the ctx object, the subsequent crash does not happen, etc.
Does anybody have any advice for working around this for the time being? A piece of software I work with uses a custom ksp convergence test in the manner described above, and is only functional with older versions of petsc because of this. Like in ex2f, I have no need of the ctx object, and just as in ex2f, I use 0 instead.
Things I'll try next: defining a proper ctx object (I use 0, like in ex2f), or looking for some PETSC_NULL_CTX definition somewhere.
Many Thanks,
Daniel
Is there a quick way for me to find out which version of PETSc KSPConvergedDefaultCreate() was introduced with? I'll likely need to conditionally pragma-out these calls for back compatibility. Thanks, Daniel On Tue, Jan 21, 2025 at 1:16 PM Barry Smith <[email protected]> wrote:
Yes, that can be passed in also with KSPSetConvergenceTest()
On Jan 21, 2025, at 4:25 AM, Daniel Stone <[email protected]> wrote:
That works wonderfully, thanks! Should be paired with
call KSPConvergedDefaultDestroy(ctx,ierr)
I think.
Best Regards,
Daniel
On Mon, Jan 20, 2025 at 3:20 PM Barry Smith <[email protected]> wrote:
David,
KSPConvergedDefault() now takes a non-NULL context that must be provided. I have attached a modified version of ex5f.F90 that demonstrates how it is constructured before being passed to KSPSetConvergenceTest().
Barry
On Jan 20, 2025, at 8:54 AM, Daniel Stone <[email protected]> wrote:
Hello PETSc Community,
I think I've found a bug -
Go to $PETSC_DIR/src/ksp/ksp/tutorials/
open ex5f.F90, and add the following line in MyKSPConverged(), say around line 336:
call KSPConvergedDefault(ksp,n,rnorm,flag,dummy,ierr)
It should make sense why someone would want to do this - within a definition of custom convergence behaviour, get the default convergence flags, and, based on certain conditions, overwrite it.
Now, building and running the exercise, making sure to include the flag to use the custom convergence:
boston@boston-SYS-540A-TR:~/DATA_DRIVE/PETSC_DIRS/petsc_3.22/src/ksp/ksp/tutorials$ ./ex2f -my_ksp_convergence [0]PETSC ERROR:
[0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably memory access out of range[...]
From my debugging, the issue is at line 1520 of iterativ.c:
KSPConvergedDefaultCtx *cctx = (KSPConvergedDefaultCtx *)ctx;
Because a dummy is used for the context object, this cast fails (my debugger says "cannot access memory..." for cctx). Then the crash happens when trying to access members of cctx:
if (cctx->convmaxits && n >= ksp->max_it) {
I'm not sure how to fix it. Crucially, we must note that that this did work in older versions of PETSc - I can repeat this test in 3.19.1, for example, and it works fine - a debugger shows the cast succeeding and producing some defaulted version of the ctx object, the subsequent crash does not happen, etc.
Does anybody have any advice for working around this for the time being? A piece of software I work with uses a custom ksp convergence test in the manner described above, and is only functional with older versions of petsc because of this. Like in ex2f, I have no need of the ctx object, and just as in ex2f, I use 0 instead.
Things I'll try next: defining a proper ctx object (I use 0, like in ex2f), or looking for some PETSC_NULL_CTX definition somewhere.
Many Thanks,
Daniel
On Tue, Jan 21, 2025 at 9:46 AM Daniel Stone <[email protected]> wrote:
Is there a quick way for me to find out which version of PETSc KSPConvergedDefaultCreate() was introduced with? I'll likely need to conditionally pragma-out these calls for back compatibility.
We have changes docs: https://urldefense.us/v3/__https://petsc.org/main/changes/__;!!G_uCfscf7eWS!... main *$:~/PETSc4/petsc/petsc-pylith$ find doc/changes/ | xargs grep KSPConvergedDefaultCreate doc/changes//35.rst: ``KSPConvergedDefaultCreate()``, Thanks, Matt Thanks,
Daniel
On Tue, Jan 21, 2025 at 1:16 PM Barry Smith <[email protected]> wrote:
Yes, that can be passed in also with KSPSetConvergenceTest()
On Jan 21, 2025, at 4:25 AM, Daniel Stone <[email protected]> wrote:
That works wonderfully, thanks! Should be paired with
call KSPConvergedDefaultDestroy(ctx,ierr)
I think.
Best Regards,
Daniel
On Mon, Jan 20, 2025 at 3:20 PM Barry Smith <[email protected]> wrote:
David,
KSPConvergedDefault() now takes a non-NULL context that must be provided. I have attached a modified version of ex5f.F90 that demonstrates how it is constructured before being passed to KSPSetConvergenceTest().
Barry
On Jan 20, 2025, at 8:54 AM, Daniel Stone <[email protected]> wrote:
Hello PETSc Community,
I think I've found a bug -
Go to $PETSC_DIR/src/ksp/ksp/tutorials/
open ex5f.F90, and add the following line in MyKSPConverged(), say around line 336:
call KSPConvergedDefault(ksp,n,rnorm,flag,dummy,ierr)
It should make sense why someone would want to do this - within a definition of custom convergence behaviour, get the default convergence flags, and, based on certain conditions, overwrite it.
Now, building and running the exercise, making sure to include the flag to use the custom convergence:
boston@boston-SYS-540A-TR:~/DATA_DRIVE/PETSC_DIRS/petsc_3.22/src/ksp/ksp/tutorials$ ./ex2f -my_ksp_convergence [0]PETSC ERROR:
[0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably memory access out of range[...]
From my debugging, the issue is at line 1520 of iterativ.c:
KSPConvergedDefaultCtx *cctx = (KSPConvergedDefaultCtx *)ctx;
Because a dummy is used for the context object, this cast fails (my debugger says "cannot access memory..." for cctx). Then the crash happens when trying to access members of cctx:
if (cctx->convmaxits && n >= ksp->max_it) {
I'm not sure how to fix it. Crucially, we must note that that this did work in older versions of PETSc - I can repeat this test in 3.19.1, for example, and it works fine - a debugger shows the cast succeeding and producing some defaulted version of the ctx object, the subsequent crash does not happen, etc.
Does anybody have any advice for working around this for the time being? A piece of software I work with uses a custom ksp convergence test in the manner described above, and is only functional with older versions of petsc because of this. Like in ex2f, I have no need of the ctx object, and just as in ex2f, I use 0 instead.
Things I'll try next: defining a proper ctx object (I use 0, like in ex2f), or looking for some PETSC_NULL_CTX definition somewhere.
Many Thanks,
Daniel
-- 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_uCf... <https://urldefense.us/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!G_uCfs... >
Yes, that can be passed in also with KSPSetConvergenceTest()
On Jan 21, 2025, at 4:25 AM, Daniel Stone <[email protected]> wrote:
That works wonderfully, thanks! Should be paired with
call KSPConvergedDefaultDestroy(ctx,ierr)
I think.
Best Regards,
Daniel
On Mon, Jan 20, 2025 at 3:20 PM Barry Smith <[email protected] <mailto:[email protected]>> wrote:
David,
KSPConvergedDefault() now takes a non-NULL context that must be provided. I have attached a modified version of ex5f.F90 that demonstrates how it is constructured before being passed to KSPSetConvergenceTest().
Barry
On Jan 20, 2025, at 8:54 AM, Daniel Stone <[email protected] <mailto:[email protected]>> wrote:
Hello PETSc Community,
I think I've found a bug -
Go to $PETSC_DIR/src/ksp/ksp/tutorials/
open ex5f.F90, and add the following line in MyKSPConverged(), say around line 336:
call KSPConvergedDefault(ksp,n,rnorm,flag,dummy,ierr)
It should make sense why someone would want to do this - within a definition of custom convergence behaviour, get the default convergence flags, and, based on certain conditions, overwrite it.
Now, building and running the exercise, making sure to include the flag to use the custom convergence:
boston@boston-SYS-540A-TR:~/DATA_DRIVE/PETSC_DIRS/petsc_3.22/src/ksp/ksp/tutorials$ ./ex2f -my_ksp_convergence [0]PETSC ERROR: ------------------------------------------------------------------------ [0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably memory access out of range[...]
From my debugging, the issue is at line 1520 of iterativ.c:
KSPConvergedDefaultCtx *cctx = (KSPConvergedDefaultCtx *)ctx;
Because a dummy is used for the context object, this cast fails (my debugger says "cannot access memory..." for cctx). Then the crash happens when trying to access members of cctx:
if (cctx->convmaxits && n >= ksp->max_it) {
I'm not sure how to fix it. Crucially, we must note that that this did work in older versions of PETSc - I can repeat this test in 3.19.1, for example, and it works fine - a debugger shows the cast succeeding and producing some defaulted version of the ctx object, the subsequent crash does not happen, etc.
Does anybody have any advice for working around this for the time being? A piece of software I work with uses a custom ksp convergence test in the manner described above, and is only functional with older versions of petsc because of this. Like in ex2f, I have no need of the ctx object, and just as in ex2f, I use 0 instead.
Things I'll try next: defining a proper ctx object (I use 0, like in ex2f), or looking for some PETSC_NULL_CTX definition somewhere.
Many Thanks,
Daniel
participants (3)
-
Barry Smith -
Daniel Stone -
Matthew Knepley