[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] More on 1.1.6 Memory leaks

From: David Lawrence Ramsey
Subject: Re: [Nano-devel] More on 1.1.6 Memory leaks
Date: Mon, 18 Feb 2002 08:02:16 -0800 (PST)

--- Steven Kneizys <address@hidden> wrote:
>My meory paranoia may be starting to pay off ...
>After sending my patch in my previous email I noticed I wasn't actually
>releasing the multibuffer at the end properly, I was forgetting about
>the ->path_name and the ->file parts.  After I put that in I got
>leak-free code for one file loaded, but not for loading 2 or more
>files.  In about 5 mins of 'hard' editing the distribution files (load,
>unload, reload, change, save) I had 1.4Meg of unfreed buffers!  It
>seems to be making a copy with copy_filestruct that somehow isn't
>getting released.  If that rings any bells with anybody let me know, I
>haven't been able to see it for myself!

Notice that this snippet of code shows up twice in add_open_file():

    /* if open_files->file is NULL at the nrealloc() below, we get a
    open_files->file = open_files; */

And notice the nmalloc() at this point; it used to be an nrealloc() as the 
comment above said, but it got changed for some reason when the memory 
corruption in null_at() was fixed in 1.1.3.

    /* if we're in view mode and updating, the file contents won't
       have changed, so we won't bother resaving the filestruct
       then; otherwise, we will */
    if (!(ISSET(VIEW_MODE) && !update)) {
        /* save current filestruct and restore full file position
           afterward */
        open_files->file = nmalloc(sizeof(filestruct));
        open_files->file = copy_filestruct(fileage);
        do_gotopos(open_files->lineno, open_files->file_current_x, 
open_files->file_current_y, open_files->file_placewewant);

That's my best guess as to the source of the memory leak.

Sluggy.Net: The Sluggy Freelance Community!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]