[petsc-dev] [petsc-users] MatPreallocatorPreallocate segfault with PETSC 3.16

[Patrick Sanan]

There is also the hedge of adding a parameter and API function to control
which of these two behaviors is used, and if trying to preallocate twice,
throwing an error that instructs the user how to change the behavior,
noting that it will increase peak memory usage.

Am Di., 1. Feb. 2022 um 17:07 Uhr schrieb Jed Brown <jed at jedbrown.org>:

> Stefano Zampini <stefano.zampini at gmail.com> writes:
>
> > Il giorno mar 1 feb 2022 alle ore 18:34 Jed Brown <jed at jedbrown.org> ha
> > scritto:
> >
> >> Patrick Sanan <patrick.sanan at gmail.com> writes:
> >>
> >> > Am Di., 1. Feb. 2022 um 16:20 Uhr schrieb Jed Brown <jed at jedbrown.org
> >:
> >> >
> >> >> Patrick Sanan <patrick.sanan at gmail.com> writes:
> >> >>
> >> >> > Sorry about the delay on this. I can reproduce.
> >> >> >
> >> >> > This regression appears to be a result of this optimization:
> >> >> > https://gitlab.com/petsc/petsc/-/merge_requests/4273
> >> >>
> >> >> Thanks for tracking this down. Is there a reason to prefer
> preallocating
> >> >> twice
> >> >>
> >> >>    ierr =
> >> >> MatPreallocatorPreallocate(preallocator,PETSC_TRUE,A);CHKERRQ(ierr);
> >> >>    ierr =
> >> >>
> >>
> MatPreallocatorPreallocate(preallocator,PETSC_TRUE,A_duplicate);CHKERRQ(ierr);
> >> >>
> >> >> versus using MatDuplicate() or MatConvert()?
> >> >>
> >>
> >
> > Jed
> >
> > this is not the point. Suppose you pass around only a preallocator, but
> do
> > not pass around the matrices. Reusing the preallocator should be allowed.
>
> The current code is not okay (crashing is not okay), but we should decide
> whether to consume the preallocator or to retain the data structure. Peak
> memory use is the main reason hash-based allocation hasn't been default and
> wasn't adopted sooner. Retaining the hash until the preallocator is
> destroyed increases that peak.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20220202/438d191a/attachment.html>