Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 192458 - update-eix progress percentage broken on ppc64
Summary: update-eix progress percentage broken on ppc64
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Third-Party Tools (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage Tools Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-09-13 20:05 UTC by Mark J. Olah
Modified: 2007-09-21 19:03 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
patch for formatstring of progress bar (eixprogress.patch,351 bytes, patch)
2007-09-14 08:40 UTC, Martin Väth
Details | Diff
Dubugging output showing corruption of m_step_size (update-eix-progbar-debug.txt,21.16 KB, text/plain)
2007-09-14 21:32 UTC, Mark J. Olah
Details
Patch to avoid floats in progress bar (progress_nofloat.patch,819 bytes, patch)
2007-09-15 11:31 UTC, Martin Väth
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mark J. Olah 2007-09-13 20:05:44 UTC
For app-portage/eix-0.9.12, on ppc64, the update-eix executable produces garbage for the percent complete output.  Example below.  

Reproducible: Always

Actual Results:  
Example output:

# update-eix
Reading Portage settings ..
Building database (/var/cache/eix) ..
[0] "gentoo" /usr/portage/ (cache: metadata)
     Reading 10015020025030035040045048052996650700750800850900950100010501100115012001250130013501400145015001550165017001750180018501950000200020502100215022002250230023502400245025002550260026502700275028002850290029502890293829863034308231303179322732753323337135503600365037000375038003850395040004050410041504200425043004350440044504500455046004650470047504800485049004950500050505100515052005250530053505400545055000555056005650570057505800585059005950578258305878592659742000201640646400645065006550660066506700675068006850690069507000705071007150720072500730073507400100%
[1] "oal" /nfs/roothome/portage (cache: none)
     Reading 85090095010001050110011501200125013001350140014501500155016001650100%
Applying masks ..
Database contains 11954 packages in 149 categories.


Expected Results:  
# update-eix
Reading Portage settings ..
Building database (/var/cache/eix) ..
[0] "gentoo" /usr/portage/ (cache: metadata)
     Reading 100%
[1] "oal" /nfs/roothome/portage (cache: none)
     Reading 100%
Applying masks ..
Database contains 11954 packages in 149 categories.


This behavior was not noticed before, and is now present in older versions of eix as well, so it is possibly an effect of a new glibc, or gcc.

 emerge --info
Portage 2.1.3.9 (default-linux/ppc/ppc64/2007.0/64bit-userland, gcc-4.1.2, glibc-2.6.1-r0, 2.6.22-gentoo-r1 ppc64)
=================================================================
System uname: 2.6.22-gentoo-r1 ppc64 PPC970, altivec supported
Timestamp of tree: Thu, 13 Sep 2007 14:00:01 +0000
app-shells/bash:     3.2_p17-r1
dev-lang/python:     2.3.6-r2, 2.4.4-r4, 2.5.1-r2
dev-python/pycrypto: 2.0.1-r6
sys-apps/baselayout: 1.12.10-r4
sys-apps/sandbox:    1.2.18.1
sys-devel/autoconf:  2.13, 2.61-r1
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.18
sys-devel/gcc-config: 1.4.0-r2
sys-devel/libtool:   1.5.24
virtual/os-headers:  2.6.22-r2
ACCEPT_KEYWORDS="ppc64 ~ppc64"
CBUILD="powerpc64-unknown-linux-gnu"
CFLAGS="-O2 -pipe -mcpu=970 -maltivec -mabi=altivec"
CHOST="powerpc64-unknown-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d"
CXXFLAGS="-O2 -pipe -mcpu=970 -maltivec -mabi=altivec"
DISTDIR="/nfs/distfiles"
FEATURES="autoconfig buildpkg digest distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="ftp://gentoo.chem.wisc.edu/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/nfs/roothome/portage"
SYNC="rsync://tau.cs.unm.edu/gentoo-portage"
USE="X Xaw3d aac acl alsa altivec arts automount bash-completion berkdb bitmap-fonts blas bzip2 cairo cli cracklib crypt cups curl exif fftw flac fontocnfig fortran gd gdbm gif gimpprint gnome gpm graphviz gs gtk icecast iconv imagemagick imlib isdnlog jpeg jpeg2k kde lapack midi motif mozsvg mp3 mpeg mudflap musepack nas ncurses netpbm nis nls nptl nptlonly objc ogg opengl openmp pam pcre pdf pdflib perl plotutils png ppc64 pppd python qt3 quicktime readline reflection ruby samaba session smaba snmp spell spl ssl subversion svg tcl tcpd tetex tiff tk toolbar truetype truetype-fonts type1-fonts umagemagick unicode usb userlocales vorbis wmf wxwindows xemacs xml xorg xprint xv zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nv"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 1 Martin Väth 2007-09-13 21:35:23 UTC
Maybe your TERM is not appropriate.
update-eix just uses \b for the progress bar.
Does echo -e 'eeeeee\b\b\b\bfg' correctly output "eefgee"?
Comment 2 Mark J. Olah 2007-09-13 22:28:35 UTC
Yes, it does work correctly.  In fact the problem also occurs when update-eix is not run interactively from a terminal.  Output from my cron jobs show the same problem with update-eix.

-Mark

(In reply to comment #1)
> Maybe your TERM is not appropriate.
> update-eix just uses \b for the progress bar.
> Does echo -e 'eeeeee\b\b\b\bfg' correctly output "eefgee"?
> 

Comment 3 Martin Väth 2007-09-14 08:40:00 UTC
Created attachment 130892 [details, diff]
patch for formatstring of progress bar

eix' progress bar indeed used a nonstandard printf format. The attached patch should fix this.

update-eix makes no difference for the progress bar whether the output is to a file or to a screen. You can check whether it was really eix fault by piping update-eix to (or viewing the output file with) od -c: You should see repeatedly four '\b' and then four symbols (three numbers, one % sign). If this is the case, your problems lies elsewhere (terminal, ...). However, if the number of symbols printed is wrong, please recompile eix with the attached patch and try again.
Comment 4 Mark J. Olah 2007-09-14 21:29:33 UTC
Thanks for the patch Martin.  Unfortunately that was not the problem, but the patch may still be useful to correct the non-standard format string.

Upon further investigation, the problem occurs because the 'm_step_size' member of the PercentStatus class is getting corrupted.  I will attach a debugging output to show the corruption.  I am at a loss to explain this.  Possibly a compiler error?  The machine is otherwise stable, so I doubt this is a hardware error.  It is too repeatable.

To complicate the matter even further, I have a second ppc64 machine with a nearly identical emerge --info and there is no problem there.  Thus, the problem is not necessarily a ppc64 problem.

I will try an emerge -e world, but I am unsure how to debug this further.

-Mark

(In reply to comment #3)
> Created an attachment (id=130892) [edit]
> patch for formatstring of progress bar
> 
> eix' progress bar indeed used a nonstandard printf format. The attached patch
> should fix this.
> 
> update-eix makes no difference for the progress bar whether the output is to a
> file or to a screen. You can check whether it was really eix fault by piping
> update-eix to (or viewing the output file with) od -c: You should see
> repeatedly four '\b' and then four symbols (three numbers, one % sign). If this
> is the case, your problems lies elsewhere (terminal, ...). However, if the
> number of symbols printed is wrong, please recompile eix with the attached
> patch and try again.
> 

Comment 5 Mark J. Olah 2007-09-14 21:32:23 UTC
Created attachment 130950 [details]
Dubugging output showing corruption of m_step_size
Comment 6 Martin Väth 2007-09-15 11:31:22 UTC
Created attachment 130980 [details, diff]
Patch to avoid floats in progress bar

It can never happen that m_step_size is larger than 100 except if there is some compiler bug or if there is some wrong pointer handling in some other part of eix. If the latter is the case, this might be very hard to find. (BTW: there was another non-reproducible bug concerning NULL pointers reported for eix-0.9.12. But you said this problem appears also in earlier versions of eix? Can you find out the latest working version?)

Maybe there is a bug with floats in the compiler. Since floats are not really needed for eix and it is doubtful whether their usage in the progress bar really speeds things up (which for some few operations plays no role anyway), I will drop the usage of floats completely. If there is no problem with the new patch (which has to be applied instead of the previous one), my guess is that there is a compiler bug concerning floats.
Comment 7 Martin Väth 2007-09-21 09:09:08 UTC
I hope that the problem disappeared in eix-0.10.0
Comment 8 Mark J. Olah 2007-09-21 19:03:11 UTC
Thanks Martin.  The problem is indeed fixed in eix-0.10.0.  I still have no idea what was going wrong in previous versions.