started bitlbee with /etc/init.d/bitlbeed start connected to bitlbee with irssii then went to channel #bitlbee issued command: register xxxxx (where xxxxx is my pasword) got this message: 18:20 <@r080> register xxxxx 18:20 <@root> fprintf() wrote too little. Disk full? 18:20 <@root> Configuration could not be saved! df -h output: robo@ivanka ~ $ df -h Filesystem Size Used Avail Use% Mounted on /dev/hda5 6.5G 5.3G 849M 87% / none 252M 388K 252M 1% /dev /dev/hda2 72M 15M 54M 22% /boot /dev/hda6 21G 21G 45M 100% /home /dev/hda1 9.9G 9.7G 229M 98% /fatdata none 252M 0 252M 0% /dev/shm /fatdata/movies 9.9G 9.7G 229M 98% /home/guest/movies1 /fatdata/music 9.9G 9.7G 229M 98% /home/guest/music2 /home/movies 21G 21G 45M 100% /home/guest/movies2 /tmp/movies 6.5G 5.3G 849M 87% /home/guest/movies3 /home/unsorted 21G 21G 45M 100% /home/guest/unsorted /home/music 21G 21G 45M 100% /home/guest/music1 /home/books 21G 21G 45M 100% /home/guest/books Reproducible: Always Steps to Reproduce: 1. /etc/init.d/bitlbeed start 2. irssi 3. /connect localhost 4. /join #bitlbee 5. register xxxxx Actual Results: 18:20 <@r080> register xxxxx 18:20 <@root> fprintf() wrote too little. Disk full? 18:20 <@root> Configuration could not be saved! Expected Results: save password without problems Gentoo Base System version 1.6.6 Portage 2.0.51-r3 (default-linux/x86/2004.3, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.9-gentoo i686) ============================================================ ===== System uname: 2.6.9-gentoo i686 Intel(R) Pentium(R) M processor 1400MHz Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.92.0.2-r1 Headers: sys-kernel/linux26-headers-2.6.8.1-r1 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-Os -march=pentium-m -mtune=pentium-m -fomit-frame-pointer -fforce-addr - pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/ config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-Os -march=pentium-m -mtune=pentium-m -fomit-frame-pointer -fforce-addr - pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks nodoc noinfo sandbox sfperms" GENTOO_MIRRORS="http://gentoo.inode.at/ http://mirror.switch.ch/mirror/gentoo/ http:// gentoo.ynet.sk/pub ftp://gentoo.inode.at/source/ http://mirror.uni-c.dk/gentoo/ http://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.gentoo.org/gentoo-portage" USE="X aalib apm avi bitmap-fonts cdr crypt directfb dvd encode f77 fam flac fortran freetype gif gphoto2 gpm gtk gtk2 imagemagick imap imlib java jpeg libg++ libwww mad mikmod mmx motif mpeg ncurses nls nptl oggvorbis opengl oss pdflib perl png python qt quicktime readline samba sdl slang sse ssl svga tiff truetype usb x86 xft xinerama xml2 xmms xv zlib"
Double-check that user running bitlbee has write access to /var/lib/bitlbee
drwxr-xr-x 14 root root 4096 Oct 27 09:17 var drwxr-xr-x 17 root root 4096 Nov 23 20:23 lib drwx------ 2 nobody nobody 4096 Nov 23 20:22 bitlbee but even if I change all permissions to 777 I'm still getting the same message
forgot to mention that previous version 0.84 works well
My guess this is due to the gcc and/or glibc in use in ~x86, as x86, sparc and ~sparc work as expected here. Please provide the versions of gcc and glibc you are using. Thanks.
glibc - 2.3.4.20041102 gcc - 3.4.3
This is what upstream developer said: 00:20:22 ( wilmer) Ticho: don't know what it is. one other gentoo user reported it, we did some stracing then which looked okay to me 00:20:35 ( wilmer) and the problem suddenly went away I suggest coming to irc.oftc.net, channel #bitlbee and trying to communicate with bitlbee devs directly. They're very nice.
ok, I went to the suggested irc channel and asked: 15:08 < r080> hi guys, yesterday I filled this bug http://bugs.gentoo.org/show_bug.cgi?id=72260 15:08 < r080> thought it'd be interesting for you 15:10 < wilmer> yeah. so far i've seen it on gentoo only, and it's probably strange libc behaviour 15:10 < wilmer> if you can add some debugging code to see what fprintf actually returns? 15:15 < r080> yes, printf returns 1 15:15 < r080> fprintf... 15:17 < r080> if I compile previous version available for gentoo (0.84) everything works 15:18 < wilmer> eek 15:18 < wilmer> that sucks 15:18 < wilmer> hrmm, the manpage doesn't mention anything about retvals... 15:20 < r080> it mentions, here : "These functions return the number of characters printed..." 15:20 < r080> from man fprintf on old redhat 7.3 15:20 < wilmer> oops, yes it does. searching error. 15:22 < wilmer> and according to strace, it *did* write more than just one byte. at least that was the case last time the problem occured 15:38 < r080> yes, that's right, just tried it, it writes everything it should, but fprintf returns 1 which is apparently not right ;) 15:40 < wilmer> indeed. don't know what to do about this. strangest thing is that the person who reported this also told me that the problem suddenly went away 15:41 < wilmer> maybe you should post a question about this on the gentoo devvers or libc mailing list 15:41 < wilmer> because i don't think this can be considered a bitlbee bug 15:44 < r080> yes, I think so too
I did forget to mention that in my testing yesterday, the user does in fact register even though the message you see says otherwise. I'm going to hopefully do some additional testing tonight, but right now I'm leaning towards the latest glibc not returning correctly on this call.
Just letting you know that I will be away from the 28th of November through the 2nd of December so if I don't reply to this again today, don't expect anything until the 3rd of December. Andrej, if you want to work this issue in my absense, please feel free to do so any commit any changes and note them here in the bug so I will see them when I return. Thanks.
I'm also having this problem, same as previously reported.
As an update, this problem seems to be related to the newer glibc in use on ~x86. Using gcc-3.4.3 doesn't cause this issue to replicate for me. Going to talk to the bitlbee guys and see what they say.
I've narrowed it down to a bug in the fprintf function. (used on line 419 of bitlbee.c) If you use fprintf to write a string without a trailing newline to a file it returns 1 instead of the real amount of written bytes. with the following fix it works but also messes up the config so you won't be able to load your config anymore!!! (so don't use it) bitlbee.c line 419: - if( fprintf( fp, "%s", hash ) != strlen( hash ) ) + if( fprintf( fp, "%s\n", hash ) != strlen( hash ) + 1 ) So this is a glibc bug.
base-system peeps. It appears that this is a glibc bug in the fprintf call. Please advise on how you would like to fix glibc as it works fine for anyone not using glibc version 2.3.4.20041102. Thanks.
Created attachment 49476 [details, diff] patch for fprintf() wilmer (bitlbee dev) has provided this patch to "fix" this bug. Jason, what do you think?
My current thought is that, until we get a fixed glibc from toolchain *hint hint*, that not a lot needs to be done here. While the error message shows the password cannot be registered, that is not in fact the case. Also Wilmer's patch mentions that it is possibily hazardous to your system's health, so I'd like to shy away from a hack patch and get glibc fixed, since it's really the problem here.
As I see it, it is only hazardous when one has too little free space on hdd. If we modify the message to express this, the patch might be more useful. I think this is a good solution until our glibc guys get to fix this fprintf() issue.
toolchain@, what's the status on this fix going into glibc, please?
Please try 2.3.4.20050125
No change here after using glibc-2.3.4.20050125 and rebuilding bitlbee.
Created attachment 51808 [details] ebuild with Wilmer's patch This is a bitlbee ebuild, 0.91, with Wilmer's fprintf() fix. cd to your PORTDIR_OVERLAY and extract. It's worth noting that bitlbee runs as the 'nobody' user, so it can't really wreck your system, which some previous commenters were concerned about. Would be nicer if the gentoo glibc maintainers fixed fprintf(), but this is the best solution I could find for now. :\
Created attachment 52234 [details] bitlbee 0.92 ebuild with Wilmer's patch Same as my previous 0.91 ebuild with this patch, just with a version bump.
I've just committed bitlbee-0.92 to portage with Wilmer's patch. toolchain peeps, any chance anyone can take a look at fprintf?
As a follow-up note, this appears to persist in glibc-2.3.5
This seems to have been fixed in 2.3.5-r1 or -r2
was probably Bug 87631 which is indeed fixed now *** This bug has been marked as a duplicate of 87631 ***
