I've noticed that sometimes the fortune-mod program drops little "turds" in its output text. In tracking down the problem further, I've found that it is a problem with the recode_string() function in recode-3.6. I have a small test program which demonstrates the bug more consisely. Reproducible: Always Steps to Reproduce: 1.compile program (which I'll attach to this bug) 2.run it 3.see gratuitous text on third output line Actual Results: The demo program produces: abcdefghijklmnopqrst ABCDEFGHIJKLMNOPQRST ................................... PQRS Expected Results: given this output: abcdefghijklmnopqrst ABCDEFGHIJKLMNOPQRST ................................... $ emerge info Portage 2.0.50-r11 (default-x86-2004.0, gcc-3.3.4, glibc-2.3.3.20040420-r2, 2.6. 4-rc1) ================================================================= System uname: 2.6.4-rc1 i686 VIA Nehemiah Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -pipe -march=c3 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/s hare/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/ dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/c onfig/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe -march=c3 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="ftp://gentoo.ccccom.com http://mirror.tucdemonic.org/gentoo/ htt p://gentoo.ccccom.com http://mirrors.tds.net/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X Xaw3d acpi berkdb bitmap-fonts cdr crypt curl dga dvd dvdr esd ethereal f 77 fbcon gphoto2 gpm gps gtk gtk2 guile imgemagick imlib ipv6 jpeg libg++ libwww memlimit mmx mozilla ncurses offensive oggvorbis opengl pam pda perl png qt qui cktime readline slang snmp speex spell sse ssl tcltk tetex theora tiff truetype unicode usb vhosts x86 xml2 xmms xosd xprint xv zlib"
Created attachment 42245 [details] program which demos the "bad result text" bug in recode_string()
On the recode homepage (http://recode.progiciels-bpi.ca/showfile.html?name=dist/TODO), the first item listed is "Memory leaks: see add_to_sequence, ALLOC, recode_{m,re}alloc}", which I suspect is the cause of this problem (and also occasional segfaults on some architectures). So this may be a known issue upstream....
I discovered another thing in recode that is sort of related to this. fortune was seg-faulting so I fixed it. At least, I fixed the one bit that was seg-faulting for me. It still produces extra output sometimes. When it reallocates memory to make more space for a possible 4-byte terminator, it's off by one. In recode's src/request.c function guarantee_nul_terminator, line 1077, change +4 to +5.
When compiling recode with --with-dmalloc (I was going to add this to the recode ebuild for USE=debug but lack of keywords for dmalloc currently prevents this), I noticed that anything that uses recode (confirmed with both recode-bug.c and fortune-mod) and then tries to free the char pointer allocated by recode_string(), will die with a glibc free() invalid pointer message. For example, recode-bug (and fortune too) dies with: abcdefghijklmnopqrst ABCDEFGHIJKLMNOPQRST *** glibc detected *** free(): invalid pointer: 0x0804af00 *** Aborted (core dumped) I'm not really sure why it's considered an invalid pointer, but recode_string() does NOT return NULL. When I compiled recode-bug with dmalloc support (#include <dmalloc.h> and link with -ldmalloc), it works as it should (no remaining PQRS)... go figure. I thought about compiling recode-bug with efence support, but figured that'd probably cause a boat load of problems (mixing efence with the dmalloc support in librecode), but actually it's given me the only clue so far as to the real problem: ElectricFence Aborting: Electric Fence: free(804af00): address not from malloc(). Illegal instruction (core dumped) Unfortunately, I'm not really sure where to go from here :/ I've tried going through the relevant recode source, but have yet to find anything that really sticks out; it's not the easiest code to read (*much* pointer magic) ;p
Sorry for interruption. Posted just for convenience. The homepage of app-text/recode-3.6-r1.ebuild is outdated. The current one is: http://recode.progiciels-bpi.ca/ Thanks.
i just fixed this since it was breaking fortune-mod update to recode-3.6-r2 and make sure it works for you please
Created attachment 69209 [details] More agressive test program While the proposed recode_3.6-11.diff.gz patch (gentoo recode-3.6-r2) does appear to work fine for the simple test case in my first attachment, and so far I haven't noticed a problem from fortune-mod, this more agressive test program shows me that recode still has at *least* one more pointer/buffer bug (I variously get segfaults or a fatal error from glibc).
*** Bug 103593 has been marked as a duplicate of this bug. ***
Modifying the title of this bug to be more general; reopening.
http://recode.progiciels-bpi.ca/ has some testing 3.6[abc] versions you could try
*** Bug 101705 has been marked as a duplicate of this bug. ***
*** Bug 68065 has been marked as a duplicate of this bug. ***
This bug is 10 years old but whatever. I've just bumped recode to version 3.7. You might consider giving it a try and report back whether you still experience this error. Thanks!
Downloaded zip-ball from https://github.com/pinard/Recode [3.7-beta2, plus whatever extra commits might be on HEAD]. Attachment 69209 [details] still trips an error for me (malloc() variously reports either "memory corruption" or "corrupted double-linked list", spews a stack backtrace, and coredumps). A note about attachment 69209 [details]: the printf() on line 55 of test.c is missing an argument. There should be a ``i,'' between the format string and the reference to ``text,''. There also should be a ``#include <string.h>'' at the top. My re-test this afternoon included these two fixes; I'll attach a new version of the code incorporating these two fixes.
Created attachment 487884 [details] agressive test program, with code fixes