When updating to glibc-2.3.5-r2, nano-1.3.7 gives error "*** glibc detected *** realloc(): invalid next size: 0x080a63e8 *** Aborted" when opening /etc/fstab. The "next size" output may vary. Other files seems to open fine. Reproducible: Always Steps to Reproduce: 1.emerge nano-1.3.7 2.emerge glibc-2.3.5-r2 3.do 'nano /etc/fstab' Actual Results: nano-1.3.7 gives error "*** glibc detected *** realloc(): invalid next size: 0x080a63e8 *** Aborted" Expected Results: should have opened the fstab file Portage 2.0.51.22-r3 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r2, 2.6.13-gentoo-r3 i686) ================================================================= System uname: 2.6.13-gentoo-r3 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -pipe -O2 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -pipe -O2 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.du.se/pub/os/gentoo ftp://mirror.pudas.net/gentoo ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="x86 X alsa apm arts avi berkdb bitmap-fonts browserplugin cdr crypt cups curl dvd dvdr dvdread eds emboss encode esd exif fam ffmpeg foomaticdb fortran gd gdbm gif gphoto2 gpm gstreamer gtk2 imagemagick imlib ipv6 java jpeg junit kde libg++ libwww mad mikmod motif mozilla mp3 mpeg ncurses nls nsplugin ogg oggvorbis opengl oss pam pdflib perl png ppds python qt quicktime readline samba sdl spell ssl tcltk tcpd tiff truetype truetype-fonts type1-fonts udev vorbis win32codecs wxwindows xine xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
nano-1.3.9 gives the same error. nano-1.3.8 works fine, so emerging 1.3.8 should work as a workaround
*** Bug 88615 has been marked as a duplicate of this bug. ***
pust a file to the bug that causes this error
Created attachment 72243 [details] nano-1.3.7.ebuild first time I report a bug, so I am not quite sure what you mean. is the ebuild what you are looking for?
Comment on attachment 72243 [details] nano-1.3.7.ebuild attach a file that makes nano crash when you open it
Created attachment 72244 [details] fstab file aha, then it would be the fstab file...
try running `nano -I /etc/fstab` and see if it still crashes
it still crashes...
try moving away your history/rc files mkdir backup mv ~/.nano* backup/ mv /etc/nanorc backup/
done...and it still crashes
then try unpacking the nano 1.3.9 tarball and configure/build it yourself and see if the local nano bombs
did so, and no improvement
can you tar up the nano src dir you compiled and crashes and post the tarball here
For what it's worth, I'm getting something very similar on my boxes now. In my case, I run nano -w /etc/tomcat5/server.xml Then I hit ctrl-W (to do a search) Here's the odd part. If I search on the word "cluster" it crashes with the same error (except the invalid next size is 0x080e4628 if searching from the beginning of the file, others if from another part). This is consistent - happens every time I search the word "cluster". The odd part is that if I search another term, like "c", "cl", "clu" or even "clum" or "mbeans" everything works fine. If I search on "clus" it crashes, just like with "cluster". Why it crashes on "clus" but not "clu" or "clud" is beyond me. I hope the above helps. The system in this case is a dual-cpu XEON 2.8Ghz. Please let me know if I can do anything further to assist. FWIW I'm running the same versions of glibc and nano as the reporter (and revdep-rebuild doesn't show any need to update packages). I have also tried to re-emerge nano and this did not help.
Another oddity I just noticed. I can search the word "cluster" in other files without this error occurring (fstab or tomcat-users.xml or crontab, etc). It only seems to happen inside server.xml in particular. If I scroll downwards (either with arrow or ctrl-V) through the file, it also crashes at a certain point (right around <parameter><name>logAbandoned</name></parameter> with a similar error. Also the "-w" on the command-line I mentioned earlier isn't necessary to reproduce the error.
(In reply to comment #13) > can you tar up the nano src dir you compiled and crashes and post the tarball here where can I find nano src dir?
wherever you unpacked nano-1.3.9.tar.bz2 :p
Created attachment 72407 [details] nano-1.3.7 i had deleted the dir from the last time, so i unpacked it again and just did a ./configure and make on this one.
try running gdb on the nano in the src dir: $ gdb --args ./nano /etc/fstab (gdb) run ... hopefully it'll abort ... (gdb) bt and post the output
# gdb --args ./nano /etc/fstab GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"..../nano: No such file or directory. (gdb) run Starting program: /etc/fstab No executable file specified. Use the "file" or "exec-file" command. (gdb) bt No stack.
did you run gdb in the correct directory ? you have to run it in nano-1.3.7/src/
#0 0xb7dae941 in kill () from /lib/libc.so.6 #1 0xb7dae6e5 in raise () from /lib/libc.so.6 #2 0xb7dafa66 in abort () from /lib/libc.so.6 #3 0xb7de00bc in __fsetlocking () from /lib/libc.so.6 #4 0xb7de9542 in mallopt () from /lib/libc.so.6 #5 0xb7de89e1 in mallopt () from /lib/libc.so.6 #6 0xb7de717f in realloc () from /lib/libc.so.6 #7 0x0805921e in nrealloc (ptr=0x0, howmuch=3214948728) at utils.c:303 #8 0x08058f53 in null_at (data=0xbfa03a7c, index=81) at utils.c:125 #9 0x0805bc01 in display_string ( buf=0x807aec0 "none\t\t\t/dev/shm\ttmpfs\t\tnodev,nosuid,noexec\t\t0 0", start_col=88, len=81, dollars=235) at winio.c:2387 #10 0x0805d1e5 in update_line (fileptr=0x807aea8, index=0) at winio.c:3430 #11 0x0805d5fd in edit_refresh () at winio.c:3590 #12 0x08056dd0 in main (argc=2, argv=0xbfa03d44) at nano.c:4497
do you get the same back track with 1.3.9 ?
this is what I get from 1.3.9: #0 0xb7dda941 in kill () from /lib/libc.so.6 #1 0xb7dda6e5 in raise () from /lib/libc.so.6 #2 0xb7ddba66 in abort () from /lib/libc.so.6 #3 0xb7e0c0bc in __fsetlocking () from /lib/libc.so.6 #4 0xb7e15542 in mallopt () from /lib/libc.so.6 #5 0xb7e149e1 in mallopt () from /lib/libc.so.6 #6 0xb7e1317f in realloc () from /lib/libc.so.6 #7 0x08059cce in nrealloc (ptr=0x0, howmuch=3220370424) at utils.c:356 #8 0x080598a3 in null_at (data=0xbff2f4fc, index=81) at utils.c:132 #9 0x0805c66f in display_string ( buf=0x807bec0 "none\t\t\t/dev/shm\ttmpfs\t\tnodev,nosuid,noexec\t\t0 0", start_col=88, len=81, dollars=true) at winio.c:2451 #10 0x0805db1e in update_line (fileptr=0x807bea8, index=0) at winio.c:3468 #11 0x0805e018 in edit_refresh () at winio.c:3699 #12 0x080549aa in main (argc=2, argv=0xbff2f804) at nano.c:2419
Same here (nano-1.3.9 compiled from scratch with ./configure --enable-debug): #0 0xb7ea15f1 in kill () from /lib/libc.so.6 #1 0xb7ea11c5 in raise () from /lib/libc.so.6 #2 0xb7ea29f0 in abort () from /lib/libc.so.6 #3 0xb7ed31b9 in __fsetlocking () from /lib/libc.so.6 #4 0xb7edcc39 in mallopt () from /lib/libc.so.6 #5 0xb7edc07d in mallopt () from /lib/libc.so.6 #6 0xb7eda792 in realloc () from /lib/libc.so.6 #7 0x0805cbae in nrealloc (ptr=0x0, howmuch=3086524404) at utils.c:356 #8 0x0805cc37 in null_at (data=0xbfcc427c, index=112) at utils.c:132 #9 0x0805f8d8 in display_string (buf=0x80dcf68 "-\t\t\t\t\t\t\tid\t\t\t\t\t\t\t\t=>\t$content->{id},", start_col=120, len=112, dollars=120) at winio.c:2451 #10 0x08060d06 in update_line (fileptr=0x80dcf50, index=0) at winio.c:3468 #11 0x080611be in edit_scroll (direction=DOWN, nlines=35) at winio.c:3603 #12 0x08052fef in do_page_down () at move.c:138 #13 0x08056911 in do_input (meta_key=0x0, func_key=0x0, s_or_t=0xbfcc4385, ran_func=0xbfcc4386, finished=0xbfcc4387, allow_funcs=true) at nano.c:1690 #14 0x08057169 in main (argc=1, argv=0x19) at nano.c:2436 Line 7 looks very odd. B-) I've saved the bad text file so if anyone needs it, please drop me a mail! I don't want to make it public for everyone!
Found this via google. Just wanted yo let you know that I have the same problem on my system that is running Debian Unstable. $ nano --version GNU nano version 1.3.10 (compiled 02:51:18, Dec 25 2005) Email: nano@nano-editor.org Web: http://www.nano-editor.org/ Compiled options: --disable-wrapping-as-root --enable-color --enable-extra --enable-multibuffer --enable-nanorc --enable-utf8 $ ls -l /lib/libc.so.6 lrwxrwxrwx 1 root root 13 Jan 26 12:28 /lib/libc.so.6 -> libc-2.3.5.so
Recompiling nano from source did not help, soo I went back to google. I found some old posts on mailinglists with people having similar problems, all related to textfiles with lines ending i TAB. The files I was editing had alot of empty lines where tab-indented. After removing all of the TAB-characters at end of lines from my textfiles, the problem seems to have gone away!
(In reply to comment #27) > Recompiling nano from source did not help, soo I went back to google. I found > some old posts on mailinglists with people having similar problems, all related > to textfiles with lines ending i TAB. > > The files I was editing had alot of empty lines where tab-indented. > > After removing all of the TAB-characters at end of lines from my textfiles, the > problem seems to have gone away! > Hi all, This bug has been caught - I managed to get a reproduceable segfault, and hence a fix - please refer to nano mail archives: http://lists.gnu.org/archive/html/nano-devel/2006-02/msg00000.html Regards, Nick
should be fixed in 1.3.10-r1
