Debian Bug report logs - #493465
libncurses5: allocates memory that is never freed

Full log

🔗 View this message in rfc822 format

X-Loop: [email protected]
Subject: Bug#493465: libncurses5: allocates memory that is never freed
Reply-To: Lars Doelle <[email protected]>, [email protected]
Resent-To: "brian m. carlson" <[email protected]>
Resent-Date: Sat, 16 May 2009 21:18:08 +0000
Resent-Message-ID: <[email protected]>
Resent-Sender: [email protected]
X-Debian-PR-Message: report 493465
X-Debian-PR-Package: libncurses5
X-Debian-PR-Keywords: 
X-Debian-PR-Source: ncurses
Received: via spool by [email protected] id=U493465.12425084565538
          (code U ref 493465); Sat, 16 May 2009 21:18:08 +0000
Received: (at 493465-submitter) by bugs.debian.org; 16 May 2009 21:14:16 +0000
X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02
	(2007-08-08) on rietz.debian.org
X-Spam-Level: 
X-Spam-Bayes: score:0.0000 Tokens: new, 19; hammy, 150; neutral, 211; spammy,
	1. spammytokens:0.987-1--uis hammytokens:0.000-+--H*u:KDE, 0.000-+--H*UA:KDE,
	0.000-+--H*u:x86_64, 0.000-+--H*UA:x86_64, 0.000-+--H*u:4.2.2
X-Spam-Status: No, score=-7.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
	autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02
Received: from genix.net
	([213.239.196.28] helo=box.genix.net ident=postfix)
	by rietz.debian.org with esmtp (Exim 4.63)
	(envelope-from <[email protected]>)
	id 1M5RCx-0001Qu-Nn
	for [email protected]; Sat, 16 May 2009 21:14:16 +0000
Received: from x64.localnet (localhost [127.0.0.1])
	by box.genix.net (Postfix) with ESMTP id B9EE4300C2;
	Sat, 16 May 2009 21:14:12 +0000 (UTC)
From: Lars Doelle <[email protected]>
To: [email protected]
Date: Sat, 16 May 2009 23:14:05 +0200
User-Agent: KMail/1.11.2 (Linux/2.6.30-rc3-00425-g27b1833; KDE/4.2.2; x86_64; ; )
References: <[email protected]> <[email protected]> <[email protected]>
In-Reply-To: <[email protected]>
Cc: [email protected],
 Daniel Baumann <[email protected]>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[email protected]>

Thomas

> > > But doing that, some features of ncurses (like any curses implementation)
> > > would not work.  In short the _nc_freeall, etc., are only useful for
> > > debugging, not for a production library.
> > 
> > But this precisely is the point i do not understand. If i call '_nc_freeall' under
> > the obligation not to call any ncurses routine again, how on earth could this
> > change the semantics?
> 
> man endwin gives a hint:
> 
>        A  program  should  always  call endwin before exiting or escaping from
>        curses mode temporarily.  This routine restores tty  modes,  moves  the
>        cursor  to the lower left-hand corner of the screen and resets the ter-
>        minal into the proper non-visual mode.  Calling refresh or doupdate af-
>        ter a temporary escape causes the program to resume visual mode.
> 
> (note the "temporarily")

If this means that the semantics is /not/ affected under the obligation /not/ to
issue any other ncurses calls /after/ calling '_nc_freeall', i do not see why this
call cannot be distributed in a production library.

(It is not even distributed in the debugging library, btw. right now, and that alone
would not help much, since everything upstream is properly infected by the
storage policy. E.g.
$ ldd /usr/lib/debug/libreadline.so.5
        libncurses.so.5 => /lib/libncurses.so.5)

Personally, i do not think, this is an issue aside. Right now it is not possible to write
/any/ program providing a non-trivial UI with a balanced memory. This does not
only break the local storage policy (which could demand that all memory is returned
/before/ exit), but also development tools and the development methods. I for one,
prefer to run all my programs with valgrind /while/ developing to detect not only
memory leaks but a lot of other hard to diagnose issues in the moment i introduce
them. Not possible to do that as soon as libncurses get involved. The policy imposed
creeps upstream. See, i add a single call (readline) and get 4 or 5 pages of error
messages in valgrind, covering everything that could of /real/ interest. Ok, i could do
an #ifdef and use getline to test /my/ stuff, but i cannot longer use 'readline' while
developing which only makes life harder for no reason.

Though off-topic, the same issue at precisely the same place under Xlib (mostly
configuration database stuff), successfully preventing any decision whether one
of the graphical programs truly leaks memory or not. Hmm, they almost certainly
all do, and the problem starts with Xlib's memory policy.

It is not that bad with character based UIs, but only because the upstream chain
is shorter. Repeating the summary, it is not possible right now to write /any/
memory balanced program with a decent UI (graphical or character) for a pure
policy issue.

Thomas, i'm well aware that preserving semantics with a thing like curses is a
delicate issue to say the least, but to impose a particular policy (i.e. not to allow
to balance memory before exit) is another to the very best of my understanding.
Thus my asking for any technical reason. If there are non, i vote to include
'_nc_freeall' for production.

As said, though the '_nc_freeall' feature exists (thank you, Thomas), right now it
is not distributed on debian at all, which leaves only to compile a local version.
Thus, technically, it appears to be solved for ncurses, but the solution is simply
not distributed.

 
> > Likely, keeping track of the allocated items, as needed for '_nc_freeall' to do
> > its work, is also something that should be absolutely transparent for the items
> > themselves. So no semantics should be affected either by the 'debugging'
> > mode as far as storage is concerned.
> > 
> > So '_nc_freeall' (which is a storage policy thingy, IMO) and semantic changing
> > debugging features got mixed, or what is it?

Kind regards,
   Lars 

Send a report that this bug log contains spam.