Home/ Questions/Q 6205597
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T05:18:11+00:00

In my code I have a class lipid which holds three bead s: struct

  • 0

In my code I have a class lipid which holds three beads:

struct lipid{
  particle mainPart;
  bead * head;
  bead * body;
  bead * tail;
  int LID;
  vec direction;
  bead * operator[](int index){
    switch(index){
    case 0: return head;
    case 1: return body;
    case 2: return tail;
    default: return body;
    }
  }
};


struct bead{
  particle mainPart;
  int charge;
  int type;
  double rho;
  double nextRho;
  int LID;
  double U;
  double nextU;
  bool touch;
};


struct particle{
  vec pos;
  vec oldPos;
  vec vel;
  vec oldVel;
  vec F;
  vec oldF;
 };

class vec{
  velarry<double> coor;
  double x;
  double y;
  double z;
}

When I try to create a lipid, I create three beads using new

lipid * l = new lipid;
l->head = new bead;
l->body = new bead;
l->tail = new bead;

When I valgrind my code, I get an error which claims that there is loads of block missing… How concerned should I be about that? I should state that I’m pushing the beads and the lipids into (several) vectors.

Edit
Ok, adding delete head .. fixed that but I still have an aching problem, I have a line: 

this->beadBoxes[t[0]][t[1]][t[2]].push_back(b);

Where t is a vector<int> of size 3 and beadsBoxes is:

<vector<vector<vector<vector<bead*> > > > beadBoxes;

This guy gives me 5 times a memory leak error:

==22458== 48 bytes in 2 blocks are definitely lost in loss record 11 of 106
==22458==    at 0x4A0666E: operator new(unsigned long) (vg_replace_malloc.c:220)
==22458==    by 0x419A3C: __gnu_cxx::new_allocator<bead*>::allocate(unsigned long, void const*) (new_allocator.h:88)
==22458==    by 0x419A64: std::_Vector_base<bead*, std::allocator<bead*> >::_M_allocate(unsigned long) (stl_vector.h:127)
==22458==    by 0x423E1F: std::vector<bead*, std::allocator<bead*> >::_M_insert_aux(__gnu_cxx::__normal_iterator<bead**, std:\
:vector<bead*, std::allocator<bead*> > >, bead* const&) (vector.tcc:275)
==22458==    by 0x424073: std::vector<bead*, std::allocator<bead*> >::push_back(bead* const&) (stl_vector.h:610)
==22458==    by 0x409664: membrane::updateBox(bead*) (membrane.cpp:874)
==22458==    by 0x40ACA5: membrane::decide(lipid*) (membrane.cpp:793)
==22458==    by 0x40DF01: membrane::rotate() (membrane.cpp:529)
==22458==    by 0x40DFAF: membrane::MCstep() (membrane.cpp:480)
==22458==    by 0x401B54: main (main.cpp:15)

Which I suspect might be related to a segmentation fault which happens is that line. Why does the new (unsigned long) occur and why might it throw a segmentation fault?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Like the other posters excellently explained, these lost blocks are memory that was allocated, but never freed, and thus will never be usable again in the same run of your program.

    When you try to run your program for a longer time and need many new lipid structures, this is a definitive problem. From a software engineering POV, you must deallocate your memory. However, you seem to program in a scientific context, and thus I’d like to add that your results are not influenced by the missing deallocation and, from the scientists’ POV, you might be able to afford being sloppy here.

    • 0