New-delete-type-mismatch in Problem

[benjaminfaber]

I am running mango with an address sanitizer using petsc_pounders, I have encountered the following memory issue:

==============================================
==19584==ERROR: AddressSanitizer: new-delete-type-mimatch on 0x6120000034c0 in thread T0:
  object passed to delete has wrong type:
  size of the allocated type:     280 bytes;
  size of the deallocated type: 216 bytes.
    #0 0x7f804b3c89f7 in operator delete(void*, unsigned long) ../../../../libsanitizer/asan/asan_new_delete.cpp:172
    #1 0x689281 in mango::Problem::~Problem()  src/api/Problem.cpp:39
    #2 0x68f949 in mango::Least_squares_problem::~Least_squares__problem() src/api/Least_squares_problem.cpp:55
    ...

This isn't a fatal error if not using an address sanitizer, but I don't think it should be ignored. This error occurred well into the petsc_pounders iteration loop, 226 iterations were computed before this error was detected, though I would doubt this error has anything to do with the POUNDERS algorithm.

[landreman]

This problem may be related to src/api/Least_squares_problem.cpp lines 32-34. There, a pointer to a Solver is made to point to an instance of a subclass of Solver, Least_squares_solver. That much should be ok, but maybe then it is not legal to call delete using this pointer later (in the destructor of Problem)?

Are you getting this error while using PET? It would be nice to have a minimal example that triggers this error on my end. Do you know if the error occurs for any of the examples in mango/examples/src/? Does it only occur for pounders, or also for other optimization algorithms? (The lines flagged by AddressSanitizer are called for any algorithm, suggesting the problem would occur for any algorithm, whenever it completes.) It would also be useful to know if the problem occurs even when there is only 1 MPI process, or if it requires >1 processes.

[landreman]

I've been trying to reproduce the error message using mango's examples, but so far have not succeeded. I'm building mango on my macbook using gcc 8.4.0. I'm engaging AddressSanitizer by adding flags -fsanitize=address -fno-omit-frame-pointer (this is how it's done right?), and I verified that AddressSanitizer reports an error if I intentionally access an array element out of bounds. Running make test, some of the algorithms like nlopt_ld_lbfgs and nlopt_ld_tnewton_* strangely don't seem to converge as well as without the flags, but AddressSanitizer does not report any problems for any of the examples.

[benjaminfaber]

Let me see if I can reproduce the problem, I have been using PET for this. Running PET with the address sanitzer active hasn't produced any warnings or errors, so I don't think it's on the PET end. I ran this with GCC 10.2.0, PETSc 3.13.2 on Ubuntu 18.04 and it's strange that it occurred deep into the optimization loop, not on the first iteration. I can also try running different optimizers, I've only tried the PETSc ones so far.

[benjaminfaber]

A simple test where I reduced the number of iterations shows that the address sanitizer is throwing the error on destruction of the Least_squares_problem object. After some digging, I found this error for an unrelated code, but with a similar structure, where the address sanitizer throws an error after the destructor for the base class is called, but not the instantiated child class object. I'm testing out a fix by making the Problem and Least_squares_problem destructors virtual, but it did not fix the error. Based on that other issue, it looks like this isn't a problem and can be safely ignored by setting the environment variable ASAN_OPTIONS=new_delete_type_mismatch=0