>I was digging into the memory leak that occurs in plbuf, specifically in >rdbuf_text(). An array is allocated to store the unicode >characters that were stored in the buffer so that it can be replayed (e.g. >during a resize event). There are several ways to fix this >problem. This is a bit of a classic pointer problem that is often dealt with by C++ constructors and destructors. Basically who owns the pointer? I don't know exactly which pointer you are looking at, but presumably these same pointers are used in regular text output (i.e. text not from the buffer)? In which case there is probably a free call made somewhere in the tidy code when the stream is freed. Is this correct? Basically if these pointers are used elsewhere you need to ensure the way they are used is consistent. If you simply point to existing memory and elsewhere in the code this memory is freed and reallocated for a new string then this will cause havoc. The best way to keep things consistent would be to call the appropriate plplot text function with the buffer contents which will ensure that if the other plplot code changes the buffer code isn't left behind. If that's not possible then duplication of the behaviour for regular strings is required and then ideally a comment left in the regular string code that indicates that changes there need to be mirrored in the buffer code.
>Also, I think the BUFFERED_FILE blocks in plbuf.c at this point are just >clutter. Does anyone build plplot with BUFFERED_FILE >turned on? Has it even be tested? I have never used it and as far as I know it's use is not documented anywhere, but feel free to correct me on that. If it isn't documented I doubt that it is in use anywhere and I would have no objections to it being removed. Phil On 25 January 2015 at 00:03, Jim Dishaw <j...@dishaw.org> wrote: > I was digging into the memory leak that occurs in plbuf, specifically in > rdbuf_text(). An array is allocated to store the unicode characters that > were stored in the buffer so that it can be replayed (e.g. during a resize > event). There are several ways to fix this problem. > > 1) Add a free() at the end of rdbuf_text() > - Pros: A minor change and I think it fixed the problem > - Cons: With the memory buffer, the malloc is not necessary and we are > doing needless memcpy's > > 2) Remove the need to malloc and point the unicode array to the correct spot > in the buffer > - Pros: Avoids the malloc and a memcpy > - Cons: Would have to add a malloc() and free() to support the old > temporary file approach > > I prefer the second approach because I like to avoid unnecessary malloc() and > free(). Also, I think the BUFFERED_FILE blocks in plbuf.c at this point are > just clutter. Does anyone build plplot with BUFFERED_FILE turned on? Has it > even be tested? > ------------------------------------------------------------------------------ > New Year. New Location. New Benefits. New Data Center in Ashburn, VA. > GigeNET is offering a free month of service with a new server in Ashburn. > Choose from 2 high performing configs, both with 100TB of bandwidth. > Higher redundancy.Lower latency.Increased capacity.Completely compliant. > http://p.sf.net/sfu/gigenet > _______________________________________________ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
