Great. And thanks also for the patch. We plan to maintain two branches (2.x for stable, 3.x for new features). Your patch will be handy for the 2.x branch.
Best, - Gene On Mon, Aug 27, 2012 at 10:42:27PM +0000, Fredine, John wrote: > Thanks for the response. My patch appears to be working, so just wanted to > report this so the dmtcp team could get whatever they deem to be the proper > fix into a future release. No need for an urgent fix on this. > > Thanks, > John > > -----Original Message----- > From: Gene Cooperman [mailto:[email protected]] > Sent: Monday, August 27, 2012 3:37 PM > To: Fredine, John > Cc: [email protected] > Subject: Re: [Dmtcp-forum] popen/pclose bug > > Thanks very much for reporting this bug to us, along with a clear way to > reproduce it. This should be a relatively simple bug for us to fix. > If you can wait a few weeks for the fix, that will be easiest for us (see > next paragraph). But if you need a fix urgently, please tell us now. > Kapil, I'll be travelling during this week, and classes start next week. > Is this the type of bug that your code reorganization for the 3.x branch of > DMTCP should fix? Either way, could you write back to John Fredine to let > him know what to expect? > > Thanks, > - Gene > > On Mon, Aug 27, 2012 at 03:00:31PM +0000, Fredine, John wrote: > > Hi, > > > > I have run into what appears to be a bug in the popen()/pclose() > > implementation in dmtcp 1.2.6. It can be seen with a simple program like: > > > > #include <stdio.h> > > #include <stdlib.h> > > int main(int argc, char *argv) > > { > > FILE *f; > > int c; > > > > f = popen("ls -l", "r"); > > while ((c = fgetc(f)) != EOF) putchar(c); > > pclose(f); > > > > f = popen("ls -l", "r"); > > while ((c = fgetc(f)) != EOF) putchar(c); > > pclose(f); > > } > > > > In my case the second popen will fail with a "double free" error. It looks > > like dmtcp is trying to track file handles opened by popen() and after > > spawning the child process, close any file handles in the child which were > > opened by previous popen calls. The problem is that the pclose() function > > does not remove any file handles from the list of open file handles being > > tracked. A subsequent call to popen() will cause a problem because it > > tries to close a file handle which is not open. In my case a simple fix > > was to erase the file handle from _dmtcpPopenPidMap() in pclose(). > > > > Thanks, > > John Fredine > > > ---------------------------------------------------------------------- > > -------- > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. > > Discussions will include endpoint security, mobile security and the > > latest in malware threats. > > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > _______________________________________________ > > Dmtcp-forum mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/dmtcp-forum > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Dmtcp-forum mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dmtcp-forum
