Bug 237882 – dev-libs/libedit-20050930 enters an infinite loop upon reading a history file

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Bertram Felgenhauer 2008-09-16 22:42:02 UTC]

When a program using libedit loads its history file, it will enter an (almost) infinite loop and run out of memory if the file exists.

The problem is caused by the  fgetln()  compatibility function in  glibc-bsd-glue/fgetln.c  in the source tarball. It assumes that the 'len' argument to 'getline' will reflect the number of bytes read (plus one). However, with current glibc versions that is not the case. Instead, the return value of  getline()  has to be used.

I'll attach a patch.

Note, Debian has a fix for this problem, but it's wrong: See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=358164

Reproducible: Always

Steps to Reproduce:
1. install readline.h (from netbsd-cvs in the source tarball) to /usr/include/editline (see also #153675)
2. take the example program from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=358164
3. add  #include <histedit.h>  at the top.
4. compile and run
5. watch the program enter an infinite loop and run out of memory after pressing ^D
(note: make sure that the 'foo.his' does not contain any important information before you try this)

[Comment 1 Bertram Felgenhauer 2008-09-16 22:45:34 UTC]

Created attachment 165601 [details, diff]
proposed patch (to be applied 'epatch'  from an ebuild)

[Comment 2 Ravi Nanavati 2008-10-21 16:39:48 UTC]

This problem exists with libedit-20061103 as well. See GHC bug #2716 (which is another instance of the same issue, it appears):

http://hackage.haskell.org/trac/ghc/ticket/2716

I've applied an adapted version of the Debian patch mentioned in the GHC bug and it fixed the issue, so I'd appreciate it if one of these patches to made it to an official libedit ebuild.

[Comment 3 Lennart Kolmodin (RETIRED) 2008-11-27 19:49:45 UTC]

Please have a look at this patched version of libedit, available through the haskell overlay:

http://code.haskell.org/gentoo/gentoo-haskell/dev-libs/libedit/libedit-20061103-r3.ebuild

That ebuild works fine for me.

[Comment 4 Lennart Kolmodin (RETIRED) 2009-03-07 08:57:54 UTC]

This bug is blocking the ghc 6.10.1 compiler, the main haskell compiler.

Could we please have a look at this? We would really like to put this ghc version into portage.

See bug #252176 and the comments there.

[Comment 5 Timothy Redaelli (RETIRED) 2009-03-07 11:24:25 UTC]

Please try the masked version (20090111.3.0) and let me now if it works

[Comment 6 Bertram Felgenhauer 2009-03-11 13:36:37 UTC]

20090111.3.0 has a completely different implementation of fgetln().

I've tried it (on x86; I had to add that keyword). I ran into one problem: My existing ghc 6.10.1 executable links to 'libedit.so' which is found in /usr/lib but is a linker script, confusing the dynamic linker (cf. #4411). Adding a symlink libedit.so -> libedit.so.0 in /lib helped. A fresh build of ghc picks up the 'libedit.so.0' name from the linker script, so that's a temporary problem.

Other than that, it works fine. Thanks!

[Comment 7 Timothy Redaelli (RETIRED) 2009-03-11 14:29:52 UTC]

(In reply to comment #6)
> 20090111.3.0 has a completely different implementation of fgetln().
> 
> I've tried it (on x86; I had to add that keyword). I ran into one problem: My
> existing ghc 6.10.1 executable links to 'libedit.so' which is found in /usr/lib
> but is a linker script, confusing the dynamic linker (cf. #4411). Adding a
> symlink libedit.so -> libedit.so.0 in /lib helped. A fresh build of ghc picks
> up the 'libedit.so.0' name from the linker script, so that's a temporary
> problem.
> 
> Other than that, it works fine. Thanks!

The proper solution is to re-emerge all the packages that depends on libedit

[Comment 8 Alexis Ballier 2013-08-28 16:44:24 UTC]

(In reply to Bertram Felgenhauer from comment #6)
> Other than that, it works fine. Thanks!

closing then since those versions are now stable