Re: [petsc-users] Error Norm_2

[Smith, Barry F. via petsc-users]

   Note that your sum is over more and more values (as n gets larger) so unless 
the individual values are decreasing very rapidly to zero the sum will 
increase. You need the L2 weighted norm. If your problem is in one dimension, 
which it appears to be, you need to divide the VecNorm() result by the square 
root of n

   Barry

   Read up on some book on finite difference methods where they discuss the 
convergence rates and note how they define the weighted norm.


> On Feb 25, 2019, at 8:37 PM, Fazlul Huq  wrote:
> 
> Hello PETSc Developers,
> 
> Thanks for the response!
> 
> To calculate error, I first calculate the analytical solution and put it 
> inside vector s.
> Then I took difference between analytical solution and numerical solution and 
> put it inside vector x.
> Then I calculate the NORM_2 of x.
> The code is as follows:
> /*
>  Check the error
>   */
>   for (i = 0; i < n; i++)
> {
>   k1 = (float) (i+1)/(n+1);
>   k2 = -0.5 * k1 * k1 + 5.5 * k1 + 10;
>   ierr = VecSetValues(s, 1, , , INSERT_VALUES);CHKERRQ(ierr);
> }
>   ierr = VecAXPY(x,-1.0,s);CHKERRQ(ierr);
>   ierr = VecNorm(x,NORM_2,);CHKERRQ(ierr);
>   if (norm > tol) {
> ierr = PetscPrintf(PETSC_COMM_WORLD,"Second Norm of error 
> %g\n",(double)norm);CHKERRQ(ierr);
>   }
> 
> Thanks again.
> Sincerely,
> Huq
> 
> On Mon, Feb 25, 2019 at 5:15 PM Smith, Barry F.  wrote:
> 
>How are you computing the error norm? 
> 
>You need to use the L2 norm in the computations, not the l2 norm. 
> 
>Also you need to make sure the convergence criteria you use for the 
> algebraic system is smaller than the descritzation error 
> 
> 
>Barry
> 
> 
> > On Feb 25, 2019, at 1:55 PM, Fazlul Huq via petsc-users 
> >  wrote:
> > 
> > Hello PETSc Developers,
> > 
> > I have solved a very simple poisson problem with different matrix sizes (10 
> > to 10^7).
> > But when I have compared error norm_2 for the solution, I got the attached 
> > curve.
> > It looks like error norm_2 increases with increasing matrix size. Shouldn't 
> > it decrease rather with increasing matrix size?
> > 
> > Thanks.
> > 
> > Sincerely,
> > Huq
> > -- 
> > 
> > Fazlul Huq
> > Graduate Research Assistant
> > Department of Nuclear, Plasma & Radiological Engineering (NPRE)
> > University of Illinois at Urbana-Champaign (UIUC)
> > E-mail: huq2...@gmail.com
> > 
> 
> 
> 
> -- 
> 
> Fazlul Huq
> Graduate Research Assistant
> Department of Nuclear, Plasma & Radiological Engineering (NPRE)
> University of Illinois at Urbana-Champaign (UIUC)
> E-mail: huq2...@gmail.com

Re: [petsc-users] AddressSanitizer: attempting free on address which was not malloc()-ed

[Jed Brown via petsc-users]

The compiler doesn't know anything special about PetscFinalize.
Destructors are called after all executable statements in their scope.
So you need the extra scoping if the destructor should be called
earlier.

Yuyun Yang  writes:

> Oh interesting, so I need to add those extra brackets around my class object 
> and function calls. I thought the destructor is automatically at Finalize.
>
> Thanks!
> Yuyun
>
> -Original Message-
> From: Jed Brown  
> Sent: Sunday, March 3, 2019 2:19 PM
> To: Yuyun Yang ; Matthew Knepley 
> Cc: petsc-users@mcs.anl.gov
> Subject: Re: [petsc-users] AddressSanitizer: attempting free on address which 
> was not malloc()-ed
>
> If you run this with MPICH, it prints
>
>   Attempting to use an MPI routine after finalizing MPICH
>
> You need to ensure that the C++ class destructor is called before 
> PetscFinalize.  For example, like this:
>
> diff --git i/test_domain.cpp w/test_domain.cpp index 0cfe22f..23545f2 100644
> --- i/test_domain.cpp
> +++ w/test_domain.cpp
> @@ -8,11 +8,12 @@ int main(int argc, char **argv) {
>PetscErrorCode ierr = 0;
>PetscInitialize(, , NULL, NULL);
>  
> -  Domain d;
> +  {
> +Domain d;
>  
> -  ierr = d.setFields(); CHKERRQ(ierr);
> -  ierr = d.setScatters(); CHKERRQ(ierr);
> -  
> +ierr = d.setFields(); CHKERRQ(ierr);
> +ierr = d.setScatters(); CHKERRQ(ierr);  }
>PetscFinalize();
>return ierr;
>  }
>
>
> Yuyun Yang via petsc-users  writes:
>
>> Yes, please see the attached files for a minimal example. Thanks a lot!
>>
>> Best regards,
>> Yuyun
>>
>> From: Matthew Knepley 
>> Sent: Sunday, March 3, 2019 12:46 PM
>> To: Yuyun Yang 
>> Cc: Zhang, Junchao ; petsc-users@mcs.anl.gov
>> Subject: Re: [petsc-users] AddressSanitizer: attempting free on 
>> address which was not malloc()-ed
>>
>> On Sun, Mar 3, 2019 at 3:05 PM Yuyun Yang 
>> mailto:yyan...@stanford.edu>> wrote:
>> Actually, I tried just creating a domain object (since the address sanitizer 
>> was complaining about that code to start with). Simply creating that object 
>> gave me a core dump, so I suppose the issue must be there. I got the 
>> following message when running the code with -objects_dump flag on the 
>> command line, but couldn’t find a problem with the code (I’ve attached it 
>> here with only the relevant functions).
>>
>> I think what we are going to need from you is a minimal example that 
>> has the error. I am guessing you have a logic bug in the C++, which we 
>> cannot debug by looking.
>>
>>   Thanks,
>>
>>  Matt
>>
>> Thanks a lot for your help!
>>
>> The following objects were never freed
>> -
>> [0] Vec seq y
>>   [0]  VecCreate() in 
>> /home/yyy910805/petsc/src/vec/vec/interface/veccreate.c
>> [0] Vec seq Vec_0x8400_0
>>   [0]  VecCreate() in 
>> /home/yyy910805/petsc/src/vec/vec/interface/veccreate.c
>> [0] Vec seq Vec_0x8400_1
>>   [0]  VecCreate() in 
>> /home/yyy910805/petsc/src/vec/vec/interface/veccreate.c
>> [0] VecScatter seq VecScatter_0x8400_2
>>   [0]  VecScatterCreate() in 
>> /home/yyy910805/petsc/src/vec/vscat/interface/vscreate.c
>> [0] VecScatter seq VecScatter_0x8400_3
>>   [0]  VecScatterCreate() in 
>> /home/yyy910805/petsc/src/vec/vscat/interface/vscreate.c
>> [0] VecScatter seq VecScatter_0x8400_4
>>   [0]  VecScatterCreate() in 
>> /home/yyy910805/petsc/src/vec/vscat/interface/vscreate.c
>> [0] VecScatter seq VecScatter_0x8400_5
>>   [0]  VecScatterCreate() in 
>> /home/yyy910805/petsc/src/vec/vscat/interface/vscreate.c
>> Attempting to use an MPI routine after finalizing MPICH
>>
>> --
>> --
>> -
>> From: Matthew Knepley mailto:knep...@gmail.com>>
>> Sent: Sunday, March 3, 2019 11:28 AM
>> To: Yuyun Yang mailto:yyan...@stanford.edu>>
>> Cc: Zhang, Junchao mailto:jczh...@mcs.anl.gov>>; 
>> petsc-users@mcs.anl.gov
>> Subject: Re: [petsc-users] AddressSanitizer: attempting free on 
>> address which was not malloc()-ed
>>
>> On Sun, Mar 3, 2019 at 1:03 PM Yuyun Yang via petsc-users 
>> mailto:petsc-users@mcs.anl.gov>> wrote:
>> I tried compiling without the sanitizer and running on valgrind. Got a bunch 
>> of errors “Uninitialised value was created by a stack allocation at 
>> 0x41B280: ComputeVel_qd::computeVel(double*, double, int&, int)”.
>>
>> There is no memory management code here, so other parts of the code must be 
>> relevant.
>>
>>   Thanks,
>>
>> Matt
>>
>>
>> HEAP SUMMARY:
>> ==74== in use at exit: 96,637 bytes in 91 blocks
>> ==74==   total heap usage: 47,774 allocs, 47,522 frees, 308,253,653 bytes 
>> allocated
>> LEAK SUMMARY:
>> ==74==definitely lost: 0 bytes in 0 blocks
>> ==74==indirectly lost: 0 bytes in 0 blocks
>> ==74==  possibly lost: 0 bytes in 0 blocks
>> ==74==still reachable: 96,637 bytes in 91 

Re: [petsc-users] AddressSanitizer: attempting free on address which was not malloc()-ed

[Yuyun Yang via petsc-users]

Oh interesting, so I need to add those extra brackets around my class object 
and function calls. I thought the destructor is automatically at Finalize.

Thanks!
Yuyun

-Original Message-
From: Jed Brown  
Sent: Sunday, March 3, 2019 2:19 PM
To: Yuyun Yang ; Matthew Knepley 
Cc: petsc-users@mcs.anl.gov
Subject: Re: [petsc-users] AddressSanitizer: attempting free on address which 
was not malloc()-ed

If you run this with MPICH, it prints

  Attempting to use an MPI routine after finalizing MPICH

You need to ensure that the C++ class destructor is called before 
PetscFinalize.  For example, like this:

diff --git i/test_domain.cpp w/test_domain.cpp index 0cfe22f..23545f2 100644
--- i/test_domain.cpp
+++ w/test_domain.cpp
@@ -8,11 +8,12 @@ int main(int argc, char **argv) {
   PetscErrorCode ierr = 0;
   PetscInitialize(, , NULL, NULL);
 
-  Domain d;
+  {
+Domain d;
 
-  ierr = d.setFields(); CHKERRQ(ierr);
-  ierr = d.setScatters(); CHKERRQ(ierr);
-  
+ierr = d.setFields(); CHKERRQ(ierr);
+ierr = d.setScatters(); CHKERRQ(ierr);  }
   PetscFinalize();
   return ierr;
 }


Yuyun Yang via petsc-users  writes:

> Yes, please see the attached files for a minimal example. Thanks a lot!
>
> Best regards,
> Yuyun
>
> From: Matthew Knepley 
> Sent: Sunday, March 3, 2019 12:46 PM
> To: Yuyun Yang 
> Cc: Zhang, Junchao ; petsc-users@mcs.anl.gov
> Subject: Re: [petsc-users] AddressSanitizer: attempting free on 
> address which was not malloc()-ed
>
> On Sun, Mar 3, 2019 at 3:05 PM Yuyun Yang 
> mailto:yyan...@stanford.edu>> wrote:
> Actually, I tried just creating a domain object (since the address sanitizer 
> was complaining about that code to start with). Simply creating that object 
> gave me a core dump, so I suppose the issue must be there. I got the 
> following message when running the code with -objects_dump flag on the 
> command line, but couldn’t find a problem with the code (I’ve attached it 
> here with only the relevant functions).
>
> I think what we are going to need from you is a minimal example that 
> has the error. I am guessing you have a logic bug in the C++, which we cannot 
> debug by looking.
>
>   Thanks,
>
>  Matt
>
> Thanks a lot for your help!
>
> The following objects were never freed
> -
> [0] Vec seq y
>   [0]  VecCreate() in 
> /home/yyy910805/petsc/src/vec/vec/interface/veccreate.c
> [0] Vec seq Vec_0x8400_0
>   [0]  VecCreate() in 
> /home/yyy910805/petsc/src/vec/vec/interface/veccreate.c
> [0] Vec seq Vec_0x8400_1
>   [0]  VecCreate() in 
> /home/yyy910805/petsc/src/vec/vec/interface/veccreate.c
> [0] VecScatter seq VecScatter_0x8400_2
>   [0]  VecScatterCreate() in 
> /home/yyy910805/petsc/src/vec/vscat/interface/vscreate.c
> [0] VecScatter seq VecScatter_0x8400_3
>   [0]  VecScatterCreate() in 
> /home/yyy910805/petsc/src/vec/vscat/interface/vscreate.c
> [0] VecScatter seq VecScatter_0x8400_4
>   [0]  VecScatterCreate() in 
> /home/yyy910805/petsc/src/vec/vscat/interface/vscreate.c
> [0] VecScatter seq VecScatter_0x8400_5
>   [0]  VecScatterCreate() in 
> /home/yyy910805/petsc/src/vec/vscat/interface/vscreate.c
> Attempting to use an MPI routine after finalizing MPICH
>
> --
> --
> -
> From: Matthew Knepley mailto:knep...@gmail.com>>
> Sent: Sunday, March 3, 2019 11:28 AM
> To: Yuyun Yang mailto:yyan...@stanford.edu>>
> Cc: Zhang, Junchao mailto:jczh...@mcs.anl.gov>>; 
> petsc-users@mcs.anl.gov
> Subject: Re: [petsc-users] AddressSanitizer: attempting free on 
> address which was not malloc()-ed
>
> On Sun, Mar 3, 2019 at 1:03 PM Yuyun Yang via petsc-users 
> mailto:petsc-users@mcs.anl.gov>> wrote:
> I tried compiling without the sanitizer and running on valgrind. Got a bunch 
> of errors “Uninitialised value was created by a stack allocation at 0x41B280: 
> ComputeVel_qd::computeVel(double*, double, int&, int)”.
>
> There is no memory management code here, so other parts of the code must be 
> relevant.
>
>   Thanks,
>
> Matt
>
>
> HEAP SUMMARY:
> ==74== in use at exit: 96,637 bytes in 91 blocks
> ==74==   total heap usage: 47,774 allocs, 47,522 frees, 308,253,653 bytes 
> allocated
> LEAK SUMMARY:
> ==74==definitely lost: 0 bytes in 0 blocks
> ==74==indirectly lost: 0 bytes in 0 blocks
> ==74==  possibly lost: 0 bytes in 0 blocks
> ==74==still reachable: 96,637 bytes in 91 blocks
> ==74== suppressed: 0 bytes in 0 blocks
>
> The error is located in the attached code (I’ve extracted only the relevant 
> functions), but I couldn’t figure out what is wrong. Is this causing the 
> memory corruption/double free error that happens when I execute the code?
>
> Thanks a lot for your help.
>
> Best regards,
> Yuyun
>
> From: Zhang, Junchao mailto:jczh...@mcs.anl.gov>>
> 

Re: [petsc-users] AddressSanitizer: attempting free on address which was not malloc()-ed

[Jed Brown via petsc-users]

If you run this with MPICH, it prints

  Attempting to use an MPI routine after finalizing MPICH

You need to ensure that the C++ class destructor is called before
PetscFinalize.  For example, like this:

diff --git i/test_domain.cpp w/test_domain.cpp
index 0cfe22f..23545f2 100644
--- i/test_domain.cpp
+++ w/test_domain.cpp
@@ -8,11 +8,12 @@ int main(int argc, char **argv) {
   PetscErrorCode ierr = 0;
   PetscInitialize(, , NULL, NULL);
 
-  Domain d;
+  {
+Domain d;
 
-  ierr = d.setFields(); CHKERRQ(ierr);
-  ierr = d.setScatters(); CHKERRQ(ierr);
-  
+ierr = d.setFields(); CHKERRQ(ierr);
+ierr = d.setScatters(); CHKERRQ(ierr);
+  }
   PetscFinalize();
   return ierr;
 }


Yuyun Yang via petsc-users  writes:

> Yes, please see the attached files for a minimal example. Thanks a lot!
>
> Best regards,
> Yuyun
>
> From: Matthew Knepley 
> Sent: Sunday, March 3, 2019 12:46 PM
> To: Yuyun Yang 
> Cc: Zhang, Junchao ; petsc-users@mcs.anl.gov
> Subject: Re: [petsc-users] AddressSanitizer: attempting free on address which 
> was not malloc()-ed
>
> On Sun, Mar 3, 2019 at 3:05 PM Yuyun Yang 
> mailto:yyan...@stanford.edu>> wrote:
> Actually, I tried just creating a domain object (since the address sanitizer 
> was complaining about that code to start with). Simply creating that object 
> gave me a core dump, so I suppose the issue must be there. I got the 
> following message when running the code with -objects_dump flag on the 
> command line, but couldn’t find a problem with the code (I’ve attached it 
> here with only the relevant functions).
>
> I think what we are going to need from you is a minimal example that has the 
> error. I am guessing you have a logic
> bug in the C++, which we cannot debug by looking.
>
>   Thanks,
>
>  Matt
>
> Thanks a lot for your help!
>
> The following objects were never freed
> -
> [0] Vec seq y
>   [0]  VecCreate() in 
> /home/yyy910805/petsc/src/vec/vec/interface/veccreate.c
> [0] Vec seq Vec_0x8400_0
>   [0]  VecCreate() in 
> /home/yyy910805/petsc/src/vec/vec/interface/veccreate.c
> [0] Vec seq Vec_0x8400_1
>   [0]  VecCreate() in 
> /home/yyy910805/petsc/src/vec/vec/interface/veccreate.c
> [0] VecScatter seq VecScatter_0x8400_2
>   [0]  VecScatterCreate() in 
> /home/yyy910805/petsc/src/vec/vscat/interface/vscreate.c
> [0] VecScatter seq VecScatter_0x8400_3
>   [0]  VecScatterCreate() in 
> /home/yyy910805/petsc/src/vec/vscat/interface/vscreate.c
> [0] VecScatter seq VecScatter_0x8400_4
>   [0]  VecScatterCreate() in 
> /home/yyy910805/petsc/src/vec/vscat/interface/vscreate.c
> [0] VecScatter seq VecScatter_0x8400_5
>   [0]  VecScatterCreate() in 
> /home/yyy910805/petsc/src/vec/vscat/interface/vscreate.c
> Attempting to use an MPI routine after finalizing MPICH
>
> -
> From: Matthew Knepley mailto:knep...@gmail.com>>
> Sent: Sunday, March 3, 2019 11:28 AM
> To: Yuyun Yang mailto:yyan...@stanford.edu>>
> Cc: Zhang, Junchao mailto:jczh...@mcs.anl.gov>>; 
> petsc-users@mcs.anl.gov
> Subject: Re: [petsc-users] AddressSanitizer: attempting free on address which 
> was not malloc()-ed
>
> On Sun, Mar 3, 2019 at 1:03 PM Yuyun Yang via petsc-users 
> mailto:petsc-users@mcs.anl.gov>> wrote:
> I tried compiling without the sanitizer and running on valgrind. Got a bunch 
> of errors “Uninitialised value was created by a stack allocation at 0x41B280: 
> ComputeVel_qd::computeVel(double*, double, int&, int)”.
>
> There is no memory management code here, so other parts of the code must be 
> relevant.
>
>   Thanks,
>
> Matt
>
>
> HEAP SUMMARY:
> ==74== in use at exit: 96,637 bytes in 91 blocks
> ==74==   total heap usage: 47,774 allocs, 47,522 frees, 308,253,653 bytes 
> allocated
> LEAK SUMMARY:
> ==74==definitely lost: 0 bytes in 0 blocks
> ==74==indirectly lost: 0 bytes in 0 blocks
> ==74==  possibly lost: 0 bytes in 0 blocks
> ==74==still reachable: 96,637 bytes in 91 blocks
> ==74== suppressed: 0 bytes in 0 blocks
>
> The error is located in the attached code (I’ve extracted only the relevant 
> functions), but I couldn’t figure out what is wrong. Is this causing the 
> memory corruption/double free error that happens when I execute the code?
>
> Thanks a lot for your help.
>
> Best regards,
> Yuyun
>
> From: Zhang, Junchao mailto:jczh...@mcs.anl.gov>>
> Sent: Friday, March 1, 2019 7:36 AM
> To: Yuyun Yang mailto:yyan...@stanford.edu>>
> Subject: Re: [petsc-users] AddressSanitizer: attempting free on address which 
> was not malloc()-ed
>
>
> On Fri, Mar 1, 2019 at 1:02 AM Yuyun Yang 
> mailto:yyan...@stanford.edu>> wrote:
> Actually, I also saw a line at the beginning of valgrind saying "shadow 
> memory range interleaves with an existing memory mapping. ASan cannot 

Re: [petsc-users] Get global column indices thay belong to another process?

[Smith, Barry F. via petsc-users]

> On Mar 3, 2019, at 3:04 PM, Appel, Thibaut via petsc-users 
>  wrote:
> 
> Assuming you preallocate/assemble a MPIAIJ matrix “by hand” using a 
> ISLocalToGlobalMapping object obtained from DMDA: what’s the easiest way to 
> get global column indices that do not belong to a process? 
> 
> Say, if you have a finite-difference stencil and the stencil exceeds the 
> portion owned by the process.
> 
> I think the way to go is to preallocate a MPIAIJ matrix using local 
> information with MatPreallocateSetLocal and then fill values with 
> MatSetLocal, those routines can’t work with rows/columns not owned by the 
> process right?

   Yes, MatSetValuesLocal() cannot write for matrix locations that are NOT in 
the ghosted region of the process.

> 
> Thank you,
> 
> Thibaut

Re: [petsc-users] AddressSanitizer: attempting free on address which was not malloc()-ed

[Yuyun Yang via petsc-users]

Yes, please see the attached files for a minimal example. Thanks a lot!

Best regards,
Yuyun

From: Matthew Knepley 
Sent: Sunday, March 3, 2019 12:46 PM
To: Yuyun Yang 
Cc: Zhang, Junchao ; petsc-users@mcs.anl.gov
Subject: Re: [petsc-users] AddressSanitizer: attempting free on address which 
was not malloc()-ed

On Sun, Mar 3, 2019 at 3:05 PM Yuyun Yang 
mailto:yyan...@stanford.edu>> wrote:
Actually, I tried just creating a domain object (since the address sanitizer 
was complaining about that code to start with). Simply creating that object 
gave me a core dump, so I suppose the issue must be there. I got the following 
message when running the code with -objects_dump flag on the command line, but 
couldn’t find a problem with the code (I’ve attached it here with only the 
relevant functions).

I think what we are going to need from you is a minimal example that has the 
error. I am guessing you have a logic
bug in the C++, which we cannot debug by looking.

  Thanks,

 Matt

Thanks a lot for your help!

The following objects were never freed
-
[0] Vec seq y
  [0]  VecCreate() in 
/home/yyy910805/petsc/src/vec/vec/interface/veccreate.c
[0] Vec seq Vec_0x8400_0
  [0]  VecCreate() in 
/home/yyy910805/petsc/src/vec/vec/interface/veccreate.c
[0] Vec seq Vec_0x8400_1
  [0]  VecCreate() in 
/home/yyy910805/petsc/src/vec/vec/interface/veccreate.c
[0] VecScatter seq VecScatter_0x8400_2
  [0]  VecScatterCreate() in 
/home/yyy910805/petsc/src/vec/vscat/interface/vscreate.c
[0] VecScatter seq VecScatter_0x8400_3
  [0]  VecScatterCreate() in 
/home/yyy910805/petsc/src/vec/vscat/interface/vscreate.c
[0] VecScatter seq VecScatter_0x8400_4
  [0]  VecScatterCreate() in 
/home/yyy910805/petsc/src/vec/vscat/interface/vscreate.c
[0] VecScatter seq VecScatter_0x8400_5
  [0]  VecScatterCreate() in 
/home/yyy910805/petsc/src/vec/vscat/interface/vscreate.c
Attempting to use an MPI routine after finalizing MPICH

-
From: Matthew Knepley mailto:knep...@gmail.com>>
Sent: Sunday, March 3, 2019 11:28 AM
To: Yuyun Yang mailto:yyan...@stanford.edu>>
Cc: Zhang, Junchao mailto:jczh...@mcs.anl.gov>>; 
petsc-users@mcs.anl.gov
Subject: Re: [petsc-users] AddressSanitizer: attempting free on address which 
was not malloc()-ed

On Sun, Mar 3, 2019 at 1:03 PM Yuyun Yang via petsc-users 
mailto:petsc-users@mcs.anl.gov>> wrote:
I tried compiling without the sanitizer and running on valgrind. Got a bunch of 
errors “Uninitialised value was created by a stack allocation at 0x41B280: 
ComputeVel_qd::computeVel(double*, double, int&, int)”.

There is no memory management code here, so other parts of the code must be 
relevant.

  Thanks,

Matt


HEAP SUMMARY:
==74== in use at exit: 96,637 bytes in 91 blocks
==74==   total heap usage: 47,774 allocs, 47,522 frees, 308,253,653 bytes 
allocated
LEAK SUMMARY:
==74==definitely lost: 0 bytes in 0 blocks
==74==indirectly lost: 0 bytes in 0 blocks
==74==  possibly lost: 0 bytes in 0 blocks
==74==still reachable: 96,637 bytes in 91 blocks
==74== suppressed: 0 bytes in 0 blocks

The error is located in the attached code (I’ve extracted only the relevant 
functions), but I couldn’t figure out what is wrong. Is this causing the memory 
corruption/double free error that happens when I execute the code?

Thanks a lot for your help.

Best regards,
Yuyun

From: Zhang, Junchao mailto:jczh...@mcs.anl.gov>>
Sent: Friday, March 1, 2019 7:36 AM
To: Yuyun Yang mailto:yyan...@stanford.edu>>
Subject: Re: [petsc-users] AddressSanitizer: attempting free on address which 
was not malloc()-ed


On Fri, Mar 1, 2019 at 1:02 AM Yuyun Yang 
mailto:yyan...@stanford.edu>> wrote:
Actually, I also saw a line at the beginning of valgrind saying "shadow memory 
range interleaves with an existing memory mapping. ASan cannot proceed 
properly. ABORTING." I guess the code didn't really run through valgrind since 
it aborted. Should I remove the address sanitizer flag when compiling?
From the message, it seems ASan (not valgrind) aborted. You can try to compile 
without sanitizer and then run with valgrind. If no problem, then it is 
probably a sanitizer issue.


Get Outlook for iOS

From: Yuyun Yang
Sent: Thursday, February 28, 2019 10:54:57 PM
To: Zhang, Junchao
Subject: Re: [petsc-users] AddressSanitizer: attempting free on address which 
was not malloc()-ed

Hmm, still getting the same error from address sanitizer even though valgrind 
shows no errors and no leaks are possible.

Should I ignore that error? My results did run alright.

Best,
Yuyun

Get Outlook for iOS

From: Zhang, Junchao mailto:jczh...@mcs.anl.gov>>
Sent: 

[petsc-users] Get global column indices thay belong to another process?

[Appel, Thibaut via petsc-users]

Assuming you preallocate/assemble a MPIAIJ matrix “by hand” using a 
ISLocalToGlobalMapping object obtained from DMDA: what’s the easiest way to get 
global column indices that do not belong to a process? 

Say, if you have a finite-difference stencil and the stencil exceeds the 
portion owned by the process.

I think the way to go is to preallocate a MPIAIJ matrix using local information 
with MatPreallocateSetLocal and then fill values with MatSetLocal, those 
routines can’t work with rows/columns not owned by the process right?

Thank you,

Thibaut

Re: [petsc-users] AddressSanitizer: attempting free on address which was not malloc()-ed

[Yuyun Yang via petsc-users]

Actually, I tried just creating a domain object (since the address sanitizer 
was complaining about that code to start with). Simply creating that object 
gave me a core dump, so I suppose the issue must be there. I got the following 
message when running the code with -objects_dump flag on the command line, but 
couldn’t find a problem with the code (I’ve attached it here with only the 
relevant functions).

Thanks a lot for your help!

The following objects were never freed
-
[0] Vec seq y
  [0]  VecCreate() in 
/home/yyy910805/petsc/src/vec/vec/interface/veccreate.c
[0] Vec seq Vec_0x8400_0
  [0]  VecCreate() in 
/home/yyy910805/petsc/src/vec/vec/interface/veccreate.c
[0] Vec seq Vec_0x8400_1
  [0]  VecCreate() in 
/home/yyy910805/petsc/src/vec/vec/interface/veccreate.c
[0] VecScatter seq VecScatter_0x8400_2
  [0]  VecScatterCreate() in 
/home/yyy910805/petsc/src/vec/vscat/interface/vscreate.c
[0] VecScatter seq VecScatter_0x8400_3
  [0]  VecScatterCreate() in 
/home/yyy910805/petsc/src/vec/vscat/interface/vscreate.c
[0] VecScatter seq VecScatter_0x8400_4
  [0]  VecScatterCreate() in 
/home/yyy910805/petsc/src/vec/vscat/interface/vscreate.c
[0] VecScatter seq VecScatter_0x8400_5
  [0]  VecScatterCreate() in 
/home/yyy910805/petsc/src/vec/vscat/interface/vscreate.c
Attempting to use an MPI routine after finalizing MPICH

-
From: Matthew Knepley 
Sent: Sunday, March 3, 2019 11:28 AM
To: Yuyun Yang 
Cc: Zhang, Junchao ; petsc-users@mcs.anl.gov
Subject: Re: [petsc-users] AddressSanitizer: attempting free on address which 
was not malloc()-ed

On Sun, Mar 3, 2019 at 1:03 PM Yuyun Yang via petsc-users 
mailto:petsc-users@mcs.anl.gov>> wrote:
I tried compiling without the sanitizer and running on valgrind. Got a bunch of 
errors “Uninitialised value was created by a stack allocation at 0x41B280: 
ComputeVel_qd::computeVel(double*, double, int&, int)”.

There is no memory management code here, so other parts of the code must be 
relevant.

  Thanks,

Matt


HEAP SUMMARY:
==74== in use at exit: 96,637 bytes in 91 blocks
==74==   total heap usage: 47,774 allocs, 47,522 frees, 308,253,653 bytes 
allocated
LEAK SUMMARY:
==74==definitely lost: 0 bytes in 0 blocks
==74==indirectly lost: 0 bytes in 0 blocks
==74==  possibly lost: 0 bytes in 0 blocks
==74==still reachable: 96,637 bytes in 91 blocks
==74== suppressed: 0 bytes in 0 blocks

The error is located in the attached code (I’ve extracted only the relevant 
functions), but I couldn’t figure out what is wrong. Is this causing the memory 
corruption/double free error that happens when I execute the code?

Thanks a lot for your help.

Best regards,
Yuyun

From: Zhang, Junchao mailto:jczh...@mcs.anl.gov>>
Sent: Friday, March 1, 2019 7:36 AM
To: Yuyun Yang mailto:yyan...@stanford.edu>>
Subject: Re: [petsc-users] AddressSanitizer: attempting free on address which 
was not malloc()-ed


On Fri, Mar 1, 2019 at 1:02 AM Yuyun Yang 
mailto:yyan...@stanford.edu>> wrote:
Actually, I also saw a line at the beginning of valgrind saying "shadow memory 
range interleaves with an existing memory mapping. ASan cannot proceed 
properly. ABORTING." I guess the code didn't really run through valgrind since 
it aborted. Should I remove the address sanitizer flag when compiling?
From the message, it seems ASan (not valgrind) aborted. You can try to compile 
without sanitizer and then run with valgrind. If no problem, then it is 
probably a sanitizer issue.


Get Outlook for iOS

From: Yuyun Yang
Sent: Thursday, February 28, 2019 10:54:57 PM
To: Zhang, Junchao
Subject: Re: [petsc-users] AddressSanitizer: attempting free on address which 
was not malloc()-ed

Hmm, still getting the same error from address sanitizer even though valgrind 
shows no errors and no leaks are possible.

Should I ignore that error? My results did run alright.

Best,
Yuyun

Get Outlook for iOS

From: Zhang, Junchao mailto:jczh...@mcs.anl.gov>>
Sent: Wednesday, February 27, 2019 8:27:17 PM
To: Yuyun Yang
Cc: Matthew Knepley; petsc-users@mcs.anl.gov
Subject: Re: [petsc-users] AddressSanitizer: attempting free on address which 
was not malloc()-ed

Try the following to see if you can catch the bug easily: 1) Get error code for 
each petsc function and check it with CHKERRQ; 2) Link your code with a petsc 
library with debugging enabled (configured with --with-debugging=1); 3) Run 
your code with valgrind

--Junchao Zhang


On Wed, Feb 27, 2019 at 9:04 PM Yuyun Yang 
mailto:yyan...@stanford.edu>> wrote:
Hi Junchao,

This code actually involves a lot of classes and is pretty big. Might be an 
overkill for me to send 

Re: [petsc-users] AddressSanitizer: attempting free on address which was not malloc()-ed

[Yuyun Yang via petsc-users]

I tried compiling without the sanitizer and running on valgrind. Got a bunch of 
errors “Uninitialised value was created by a stack allocation at 0x41B280: 
ComputeVel_qd::computeVel(double*, double, int&, int)”.

HEAP SUMMARY:
==74== in use at exit: 96,637 bytes in 91 blocks
==74==   total heap usage: 47,774 allocs, 47,522 frees, 308,253,653 bytes 
allocated
LEAK SUMMARY:
==74==definitely lost: 0 bytes in 0 blocks
==74==indirectly lost: 0 bytes in 0 blocks
==74==  possibly lost: 0 bytes in 0 blocks
==74==still reachable: 96,637 bytes in 91 blocks
==74== suppressed: 0 bytes in 0 blocks

The error is located in the attached code (I’ve extracted only the relevant 
functions), but I couldn’t figure out what is wrong. Is this causing the memory 
corruption/double free error that happens when I execute the code?

Thanks a lot for your help.

Best regards,
Yuyun

From: Zhang, Junchao 
Sent: Friday, March 1, 2019 7:36 AM
To: Yuyun Yang 
Subject: Re: [petsc-users] AddressSanitizer: attempting free on address which 
was not malloc()-ed


On Fri, Mar 1, 2019 at 1:02 AM Yuyun Yang 
mailto:yyan...@stanford.edu>> wrote:
Actually, I also saw a line at the beginning of valgrind saying "shadow memory 
range interleaves with an existing memory mapping. ASan cannot proceed 
properly. ABORTING." I guess the code didn't really run through valgrind since 
it aborted. Should I remove the address sanitizer flag when compiling?
From the message, it seems ASan (not valgrind) aborted. You can try to compile 
without sanitizer and then run with valgrind. If no problem, then it is 
probably a sanitizer issue.


Get Outlook for iOS

From: Yuyun Yang
Sent: Thursday, February 28, 2019 10:54:57 PM
To: Zhang, Junchao
Subject: Re: [petsc-users] AddressSanitizer: attempting free on address which 
was not malloc()-ed

Hmm, still getting the same error from address sanitizer even though valgrind 
shows no errors and no leaks are possible.

Should I ignore that error? My results did run alright.

Best,
Yuyun

Get Outlook for iOS

From: Zhang, Junchao mailto:jczh...@mcs.anl.gov>>
Sent: Wednesday, February 27, 2019 8:27:17 PM
To: Yuyun Yang
Cc: Matthew Knepley; petsc-users@mcs.anl.gov
Subject: Re: [petsc-users] AddressSanitizer: attempting free on address which 
was not malloc()-ed

Try the following to see if you can catch the bug easily: 1) Get error code for 
each petsc function and check it with CHKERRQ; 2) Link your code with a petsc 
library with debugging enabled (configured with --with-debugging=1); 3) Run 
your code with valgrind

--Junchao Zhang


On Wed, Feb 27, 2019 at 9:04 PM Yuyun Yang 
mailto:yyan...@stanford.edu>> wrote:
Hi Junchao,

This code actually involves a lot of classes and is pretty big. Might be an 
overkill for me to send everything to you. I'd like to know if I see this sort 
of error message, which points to this domain file, is it possible that the 
problem happens in another file (whose operations are linked to this one)? If 
so, I'll debug a little more and maybe send you more useful information later.

Best regards,
Yuyun

Get Outlook for iOS

From: Zhang, Junchao mailto:jczh...@mcs.anl.gov>>
Sent: Wednesday, February 27, 2019 6:24:13 PM
To: Yuyun Yang
Cc: Matthew Knepley; petsc-users@mcs.anl.gov
Subject: Re: [petsc-users] AddressSanitizer: attempting free on address which 
was not malloc()-ed

Could you provide a compilable and runnable test so I can try it?
--Junchao Zhang


On Wed, Feb 27, 2019 at 7:34 PM Yuyun Yang 
mailto:yyan...@stanford.edu>> wrote:
Thanks, I fixed that, but I’m not actually calling the testScatters() function 
in my implementation (in the constructor, the only functions I called are 
setFields and setScatters). So the problem couldn’t have been that?

Best,
Yuyun

From: Zhang, Junchao mailto:jczh...@mcs.anl.gov>>
Sent: Wednesday, February 27, 2019 10:50 AM
To: Yuyun Yang mailto:yyan...@stanford.edu>>
Cc: Matthew Knepley mailto:knep...@gmail.com>>; 
petsc-users@mcs.anl.gov
Subject: Re: [petsc-users] AddressSanitizer: attempting free on address which 
was not malloc()-ed


On Wed, Feb 27, 2019 at 10:41 AM Yuyun Yang via petsc-users 
mailto:petsc-users@mcs.anl.gov>> wrote:
I called VecDestroy() in the destructor for this object – is that not the right 
way to do it?
In Domain::testScatters(), you have many VecDuplicate(,), You need to 
VecDestroy() before doing new VecDuplicate(,);
How do I implement CHECK ALL RETURN CODES?
For each PETSc function, do ierr = ...;  CHKERRQ(ierr);

From: Matthew Knepley mailto:knep...@gmail.com>>
Sent: Wednesday, February 27, 2019 7:24 AM
To: Yuyun Yang mailto:yyan...@stanford.edu>>
Cc: petsc-users@mcs.anl.gov
Subject: Re: [petsc-users]