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)
Created attachment 165601 [details, diff] proposed patch (to be applied 'epatch' from an ebuild)
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.
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.
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.
Please try the masked version (20090111.3.0) and let me now if it works
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!
(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
(In reply to Bertram Felgenhauer from comment #6) > Other than that, it works fine. Thanks! closing then since those versions are now stable
