[mturcios777]

So I've been playing around with multiple injectors using the code I had earlier using a PrtList (in this thread). So far so good, I only have one issue that is at best an annoyance and could at worst lead so spectacular failure. I've been lucky so far and don't want to press my luck, so I'm looking for help.

When the simulation I have ends and then crashes. The last time step is written properly, there is no lost data, but I get the following type of error message:

*** glibc detected *** sprayFoamMulti_test2 : double free or corruption: (!prev)

Looking up the error, it seems a pointer is being deleted twice, which is a big no. This only seems to happen at the end when the objects are being destroyed. Is there something I should be doing to prevent this, or is this at the deeper level of OF?

Thanks!

EDIT: I've attached the full error message, as it was longer than would reasonably fit in a thread message. I tried adding a call to PrtList.clear() right before the return(0) and get the same result. I wonder if its the use of new in creating the sprays?

[l_r_mcglashan]

Run your application through valgrind with --leak-check=full to get more information. Is this occuring with a solver you have written yourself?

[mturcios777]

I've adapted the sprayFoam solver to use multiple lagrangian injectors (the parcels don't interact directly but I don't need them to right now). I ran a quick check with valGrind and it does indeed mention problems with memory allocation and deletion.

I'll post the full valgrind log results once the run is finished, but I was curious if there was a workaround to this problem. The lagrangian spray/cloud classes in turn spawn their own parcels, so its easy to imagine a case where memory can get stomped all over. I'm looking at the old dieselSpray class, there is a section in the header that reads:

//- Return a pointer to a new injector created on freestore
//  from Istream
class iNew
{
    const Time& time_;
 
    public:
 
    iNew(const Time& t)
     :
         time_(t)
         {}
 
         autoPtr<injector> operator()(Istream& is) const
         {
              return autoPtr<injector>(new injector(time_, is));
         }
};

Would this fix the memory problem? Would I need to implement this in the library, or could I do this at the solver level. I filed multiple injectors as a feature request, but until then I'd like to be able to implement them safely somehow.

Thanks!

EDIT: I've attached the full valgrind log.

[mturcios777]

Oh, and just to be clear, the simulation runs to completion, and I get the error messages right as the main function exits. The total memory loss with valgrind is about 3 kB, and it appears to come from an area totally unrelated to Lagrangian spray (chemistryModel).

[mturcios777]

Ok, so here is the full valgrind log. I'm using a modified version of libchemistryModel (I call it libChemistryModelILDM) that has worked well in the past. I added several entities, including some dynamically allocated arrays, but there was never any problem with them until I tried to use a PtrList. As it turns out, that was merely coincidental as the problem doesn't occur when I use the old chemistryModel.

It almost seems like the destructor for both chemistryModel and chemistryModelILDM are being called, even though I haven't linked to the chemistryModel at all. The filenames and structure of chemistryModelILDM are the same as chemistryModel, save I've added entities and member functions inside basicChemistryModel and ODEChemistryModel. The library gets compiled to libchemistryModelILDM.so, so as not to mess with other solvers that use the original.

EDIT: Found the problem, it had to do with including both a combustionModel (which contains a chemistryModel) and chemistryModelILDM (whose member functions look just like chemistryModel) when linking. I don't use any combustionModel calls in the code, but just linking to it is enough to get confusion.