On Wed, Nov 3, 2010 at 10:48 AM, Tim Kroeger <tim.kroe...@cevis.uni-bremen.de> wrote: > On Fri, 22 Oct 2010, John Peterson wrote: > > Also, in the code that you mentioned, another thing happens which I think is > dangerous: That is, you are having a > > std::vector<Parallel::Request> node_send_requests; > > (and a number of similar vectors), and then, each time you want to send > something, you do > > node_send_requests.push_back(Parallel::request()); > Parallel::send(...,node_send_requests.back(),...); > > While this looks perfectly alright, I noticed that there is a subtle problem > with this (because I tried to do it the same way in my code and found it not > working and traced it back), that is: push_back() may possibly have to > re-allocate memory and copy all elements. In that case, for all previous > requests, the copy constructor will be called, and then the destructor. But > the destructor calls MPI_Request_free(), which makes the copy become > invalid.
Wow, yeah... this is a serious issue we should resolve ASAP. It's like having an auto_ptr in an STL container ... a big C++ no-no. What do you think Roy? We could change the Request class's destructor so that it does not attempt to manage the lifetime... as I understand it, it's not necessary to call MPI_Request_free unless you want to actually cancel an Isend/Irecv operation. So for that we could have an explicit Request::free() interface. Otherwise I don't think we leak memory since there is no malloc/new in the first place. -- John ------------------------------------------------------------------------------ Achieve Improved Network Security with IP and DNS Reputation. Defend against bad network traffic, including botnets, malware, phishing sites, and compromised hosts - saving your company time, money, and embarrassment. Learn More! http://p.sf.net/sfu/hpdev2dev-nov _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
