I got this error when doing update-eix. Building database (/var/cache/eix) .. [0] "gentoo" /media/gentoo-vdr_backup/repositories/portage/ (cache: metadata-flat) Reading 50%terminate called after throwing an instance of 'std::out_of_range' what(): basic_string::compare /usr/bin/eix-sync: line 180: 22560 Aborted "${@}" * update-eix failed Don't know if this is related to the latest stabilization of eix-0.13.3 as it worked before with this version.
same here. exactly the same error at 50%
I get the same, also at 50%.
Created attachment 165928 [details] Original backtrace I'm having this issue with app-portage/eix-0.13.4
Created attachment 165929 [details] Backtrace without throw specifier
Created attachment 165930 [details] gdb output It seems to fail somewhere in media-fonts/
Reading Portage settings .. Building database (/var/cache/eix) .. [0] "gentoo" /usr/portage/ (cache: metadata-flat) Reading 51%terminate called after throwing an instance of 'std::out_of_range' what(): basic_string::compare Abgebrochen It's not 50% but 51% on my system.
Created attachment 165938 [details, diff] Proposed patch In my case, in eixTk/compare.h:44 lstart was string::npos, this is because left only consisted of a single "0". This is why the comparison throws the out_of_range exception. Attached patch sets start to 0 if {lr}start is string::npos. I don't know if that is correct but it worked for me.
I used emerge-webrsync to check whether it is a problem with a bad commit. Now with the tree from yesterday update-eix works If the error is really in fonts my guess is: # gentoo-x86 commit in media-fonts/ja-ipafonts: ChangeLog ja-ipafonts-002.03.ebuild Matsuu Takuto (matsuu) # gentoo-x86 commit in licenses: IPAfont Matsuu Takuto (matsuu) This one has been updated recently.
(In reply to comment #7) > Created an attachment (id=165938) [edit] > Proposed patch > > In my case, in eixTk/compare.h:44 lstart was string::npos, this is because left > only consisted of a single "0". This is why the comparison throws the > out_of_range exception. > > Attached patch sets start to 0 if {lr}start is string::npos. I don't know if > that is correct but it worked for me. > The patch works for me, thanks.
In 0.13.4 still existent, patch works here also
Just tried the patch on 0.13.4 and it fixed the problem.
patch works for me too
(In reply to comment #0) > I got this error when doing update-eix. > > Building database (/var/cache/eix) .. > [0] "gentoo" /media/gentoo-vdr_backup/repositories/portage/ (cache: > metadata-flat) > Reading 50%terminate called after throwing an instance of > 'std::out_of_range' > what(): basic_string::compare > /usr/bin/eix-sync: line 180: 22560 Aborted "${@}" > * update-eix failed > > Don't know if this is related to the latest stabilization of eix-0.13.3 as it > worked before with this version. > (In reply to comment #8) > I used emerge-webrsync to check whether it is a problem with a bad commit. Now > with the tree from yesterday update-eix works > > If the error is really in fonts my guess is: > > # gentoo-x86 commit in media-fonts/ja-ipafonts: ChangeLog > ja-ipafonts-002.03.ebuild Matsuu Takuto (matsuu) > # gentoo-x86 commit in licenses: IPAfont Matsuu Takuto (matsuu) > > This one has been updated recently. > Wiping out the "ja-ipafonts" entries in /usr/portage/metadata allows update-eix to complete successfully.
same here! :) Update needed!
Created attachment 165970 [details, diff] Fix from upstream svn (for >=eix-0.12.4) Martin Vaeth fixed the bug in upstream svn, see https://projects.gentooexperimental.org/eix/changeset?new=trunk%2Fsrc%2FeixTk%2Fcompare.h%40730&old=trunk%2Fsrc%2FeixTk%2Fcompare.h%40590
devaway says that Stefan is away - "Feel free to fix my packages". Can somebody step in an create a -r1 version with numeric_compare.patch for eix-0.13.3 and eix-0.13.4? eix-0.10.2 is not affected and eix-0.12.4 could just be removed since no arch depends on it (http://packages.gentoo.org/package/app-portage/eix?arches=all). Thanks. Martin, are you ok with this?
The patch works fine...
I released eix-0.13.5 (which is only slightly more than the bugfix over 0.13.4) yesterday evening. I suggest to bump to 0.13.5 (and dump 0.13.4) instead of patching. For 0.13.3 the bugfix might be used if arch teams do not want stabilization immediately. In fact, 0.13.5 is hardly tested: originally I wanted to do some further tests this morning before the release, but after seeing all the traffic here, I changed my mind.
Granted, update-eix shouldn't crash when reading odd data. But are we sure that the metadata in /usr/portage/metadata/cache/media-fonts/ja-ipafonts-002.03 (the offending file) isn't also farked? It wouldn't be the first time a bad file got committed to the portage tree.
(In reply to comment #19) > /usr/portage/metadata/cache/media-fonts/ja-ipafonts-002.03 > (the offending file) isn't also farked? According to the pms, the first component of a version number is considered numerically. Thus, the version number is not cleverly chosen, because it is the same as 2.03. However, strictly speaking, this is not illegal, unless there would be also ja-ipafonts-2.03 in the tree.
*** Bug 238255 has been marked as a duplicate of this bug. ***
*** Bug 238258 has been marked as a duplicate of this bug. ***
*** Bug 238257 has been marked as a duplicate of this bug. ***
+*eix-0.13.5 (21 Sep 2008) + + 21 Sep 2008; Peter Alfredsen <loki_val@gentoo.org> -eix-0.13.4.ebuild, + +eix-0.13.5.ebuild: + Bump to 0.13.5 wrt bug #238216. +
*** Bug 238284 has been marked as a duplicate of this bug. ***
I suspected that I'm filing a dup, but I couldn't find any opened bug. Sorry about it, but search function returns 20 other unrelated to eix bug reports. Please do not leave 'stable' version broken for long.
*** Bug 238291 has been marked as a duplicate of this bug. ***
I'm reopening this until a fixed version is stable, hopefully it will reduce the number of dupes coming.
*** Bug 238303 has been marked as a duplicate of this bug. ***
Perhaps the summary should be changed since this also affects eix-0.12.4
how can I use the patch?
(In reply to comment #31) > how can I use the patch? > app-portage/eix-0.13.5 is already in the tree, try syncing
had the same bug eix-0.13.5 works well on amd64, hence you can remove the keyword to get a stable version in portage...
I can confirm that eix-0.13.5 solves the problem here (x86)
eix-0.13.5 works here too. Successful can of raid, can we switch to Bengal Gold? No bugs for 6 months at least. LOL
eix 0.13.5 working fine on x86 (at first sight).
I had the same problem eith app-portage/eix-0.13.3 I updated to app-portage/eix-0.13.3-r1 just minutes ago. update-eix works fine now. Thanx
13.3-r1 fixes this bug for me on amd64 no-multilib
I confirm, update-eix run successfull for me with app-portage/eix-0.13.3-r1 rether than eix-0.13.3 version. According Sa Wu (Comment #38), it's ok also for amd64 no-multilib. Then we close this bug or do we have to stabilize this for another archs ?
(In reply to comment #39) > Then we close this bug or do we have to stabilize this for > another archs ? "eix -le eix" shows that at least ppc64 is missing yet. Moreover, compared to 0.10.2 also arm, s390, and sh are missing.
*** Bug 239240 has been marked as a duplicate of this bug. ***
Same problem even with latest version available in portage (0.14.2). Problem exists in 0.13.3-r1 too
(In reply to comment #42) > Same problem even with latest version available in portage (0.14.2). > Problem exists in 0.13.3-r1 too I cannot observe any problem here. Maybe you use some overlay in which the problem appears? Can you give the backtrace?
First of all set in eixrc PORTDIR_CACHE_METHOD='parse' (I don't use portage cache since I use it as nfs share) eix fails with message: [0] "gentoo" /mnt/portage_nfs/ (cache: parse) Reading 51%terminate called after throwing an instance of 'std::out_of_range' what(): basic_string::at with following values of package name and directory path (backtrace will follow): package_name="exiv2" directory_path="/mnt/portage_nfs//media-gfx/exiv2" backtrace: Starting program: /usr/bin/update-eix Program received signal SIGABRT, Aborted. 0x0000003eaa030d55 in raise () from /lib/libc.so.6 #0 0x0000003eaa030d55 in raise () from /lib/libc.so.6 #1 0x0000003eaa0320ce in abort () from /lib/libc.so.6 #2 0x0000003eae4c1554 in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/libstdc++.so.6 #3 0x0000003eae4bf6d6 in ?? () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/libstdc++.so.6 #4 0x0000003eae4bf703 in std::terminate () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/libstdc++.so.6 #5 0x0000003eae4bf716 in ?? () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/libstdc++.so.6 #6 0x0000003eae4bf1b8 in __cxa_call_unexpected () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/libstdc++.so.6 #7 0x0000000000448ee9 in ParseCache::readPackage (this=0x72e2d0, vec=@0x1948470, pkg_name=@0x192e7a0, directory_path=@0x7fff8ebaea40, files=@0x7fff8ebaea50) at cache/parse/parse.cc:45 #8 0x0000000000449161 in ParseCache::readCategory (this=0x72e2d0, vec=@0x1948470) at cache/parse/parse.cc:164 #9 0x0000000000432b63 in update (outputfile=0x72e188 "/var/cache/eix", cache_table=@0x7fff8ebaf380, portage_settings=@0x7fff8ebaf140, will_modify=true, exclude_labels=@0x7fff8ebaf3a0) at update-eix.cc:484 #10 0x0000000000434540 in run_update_eix (argc=1, argv=0x7fff8ebaf928) at update-eix.cc:418 #11 0x00000000004baa30 in run_program (argc=1, argv=0x7fff8ebaf928) at main/main.cc:126 #12 0x00000000004baa97 in main (argc=1, argv=0x7fff8ebaf928) at main/main.cc:144
(In reply to comment #43) > I cannot observe any problem here. Maybe you use some overlay in which the > problem appears? No, I don't
The cause is an error in treating the useflag "--" (which occurs in the exiv2 ebuild with cache method parse). This has been fixed in current eix svn trunk (>=eix-0.14.3).
On eix 0.14.2 with funtoo portage, this problem still happens. Starting program: /home/keith/dev/eix-0.14.2/src/update-eix [Thread debugging using libthread_db enabled] Reading Portage settings .. Building database (/var/cache/eix) .. [0] "funtoo" /home/keith/git/portage/ (cache: parse|ebuild*) Reading 0%[New Thread 0x7f0b7d5e2700 (LWP 29105)] 51%terminate called after throwing an instance of 'std::out_of_range' what(): basic_string::at Program received signal SIGABRT, Aborted. [Switching to Thread 0x7f0b7d5e2700 (LWP 29105)] 0x00007f0b7c4a9235 in raise () from /lib/libc.so.6 (gdb) bt #0 0x00007f0b7c4a9235 in raise () from /lib/libc.so.6 #1 0x00007f0b7c4aa753 in abort () from /lib/libc.so.6 #2 0x00007f0b7cd2e284 in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/libstdc++.so.6 #3 0x00007f0b7cd2c686 in ?? () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/libstdc++.so.6 #4 0x00007f0b7cd2c6b3 in std::terminate () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/libstdc++.so.6 #5 0x00007f0b7cd2c6c6 in ?? () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/libstdc++.so.6 #6 0x00007f0b7cd2c048 in __cxa_call_unexpected () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/libstdc++.so.6 #7 0x00000000004df797 in ParseCache::readPackage (this=0x76f620, vec=@0x1a89e10, pkg_name=@0x1a4cb00, directory_path=@0x7fff8560cda0, files=@0x7fff8560cdb0) at cache/parse/parse.cc:45 #8 0x00000000004dfa1b in ParseCache::readCategory (this=0x76f620, vec=@0x1a89e10) at cache/parse/parse.cc:166 #9 0x00000000004c9d8f in update (outputfile=0x764608 "/var/cache/eix", cache_table=@0x7fff8560d7a0, portage_settings=@0x7fff8560d4e0, will_modify=true, exclude_labels=@0x7fff8560d7c0) at update-eix.cc:483 #10 0x00000000004cc601 in run_update_eix (argc=1, argv=0x7fff8560dd48) at update-eix.cc:416 #11 0x00000000004e2a38 in run_program (argc=1, argv=0x7fff8560dd48) at main/main.cc:126 #12 0x00000000004e2bed in main (argc=1, argv=0x7fff8560dd48) at main/main.cc:144
(In reply to comment #47) > On eix 0.14.2 with funtoo portage, this problem still happens. Do you have reason to assume that your problem differs from that of comment #44 - comment #46? Does current svn trunk of eix work for you?
the same here with eix-0.12.1 , and i also cannot upgrade to eix 0.14.2 which is a subject for another bug report. $ update-eix Reading Portage settings .. Building database (/var/cache/eix) .. [0] "gentoo" /usr/portage/ (cache: metadata) Reading 50%terminate called after throwing an instance of 'std::out_of_range' what(): basic_string::compare Aborted $ emerge --info Portage 2.1.4.4 (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.24-gentoo-r3 x86_64) ================================================================= System uname: 2.6.24-gentoo-r3 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz Timestamp of tree: Wed, 05 Nov 2008 20:36:01 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.4.4-r13 dev-python/pycrypto: 2.0.1-r6 dev-util/cmake: 2.4.6-r1 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.24 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=nocona -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=nocona -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distcc distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.linux.org.tr/pub/mirrors/gentoo http://ftp.uoi.gr/mirror/OS/gentoo/ http://distro.ibiblio.org/pub/linux/distributions/gentoo/ " LINGUAS="en_US en_GB tr" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X Xaw3d aac accessibility acl acpi akode alisp alsa amarok amd64 ao aoss arts audiofile automount bash-completion berkdb bindist branding bzip2 caps cjk cli cracklib crypt cups custom-cflags dbus directfb djvu dmx dri dvd dvdr dvdread emacs emovix encode examples exif ffmpeg fftw flac fortran ftp gdbm gif glep glitz gnokii gnutls gphoto2 gpm gstreamer gzip hal hardened iconv id3tag idn imlib immqt-bc injection ipv6 isdnlog java java6 javascript jbig jingle jpeg jpeg2k kde kdehiddenvisibility kig-scripting krb4 lcms ldap libnotify live livecd lm_sensors lyrics lzo madwifi md5sum midi mmx mp3 mp3rtp mpd mplayer mudflap musepack musicbrainz mysql nano-syntax ncurses network-cron networking nls nptl nptlonly nsplugin odbc ogg openexr opengl openmp oss overlays pam paste64 pcre pcsc-lite pda pdf perl php png ppds pppd python qt qt3 qt4 quicktime readline reflection samba sametime sasl sdl session slp smartcard smbkrb5passwd sndfile snmp solver sound speex spell spl spoof-source sqlite sqlite3 srt sse sse2 ssl startup-notification svg sysfs syslog taglib tcl tcpd theora tiff timidity tk toolbar truetype unicode utempter v4l v4l2 vcd vorbis wavpack wifi wma xattr xcb xcomposite xine xorg xprint xv xvid zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_US en_GB tr" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
*** Bug 245907 has been marked as a duplicate of this bug. ***
the same: root@kms0042 /home/zerkms # update-eix Reading Portage settings .. Building database (/var/cache/eix) .. [0] "gentoo" /mnt/nfs_portage/ (cache: parse) Reading 51%terminate called after throwing an instance of 'std::out_of_range' what(): basic_string::at
Same problem here when updating eix <=0.14.2 **over NFS via the PORTDIR_CACHE_METHOD="parse"**, on amd64. Reading Portage settings .. Building database (/var/cache/eix) .. [0] "gentoo" /usr/nfs_portage/ (cache: parse) Reading 51%terminate called after throwing an instance of 'std::out_of_range' what(): basic_string::at Aborted No problem when updating on local filesystems and metadata-flat method. (I manage many machines.) The issue is solved with an upgrade to 0.15.0.
Are there still problems with versions >=0.15.0. If not I think this bug should be closed.
(In reply to comment #53) > Are there still problems with versions >=0.15.0. If not I think this bug should > be closed. > Maybe not. eix-0.17.0 # eix-update Reading Portage settings .. Building database (/var/cache/eix) .. [0] "funtoo" /usr/portage/ (cache: metadata-flat) Reading 100% [1] "kde" /usr/local/portage/layman/kde-testing (cache: parse|ebuild*#metadata-flat#assign) Reading 47%^C Got signal 2 Reading 47% Hangs. Always reproducible.
(In reply to comment #54) > Maybe not. > > eix-0.17.0 > > # eix-update > Reading Portage settings .. > Building database (/var/cache/eix) .. > [0] "funtoo" /usr/portage/ (cache: metadata-flat) > Reading 100% > [1] "kde" /usr/local/portage/layman/kde-testing (cache: > parse|ebuild*#metadata-flat#assign) > Reading 47%^C > Got signal 2 > Reading 47% > > Hangs. Always reproducible. For me it too hangs at 47% of kde-testing for some time, but then completes everything successfully.
(In reply to comment #54) > Hangs. Always reproducible This is certainly not related with this bug here - if you really think it is an eix bug, open a new bug. However, be aware that the progress bar only counts in which category you are - since the kde-testing overlay has almost only one category, the progress bar is practically useless. Moreover, since the kde-testing overlay does not provide metadata and uses eclasses for basic data (therefore the "parse" method fails), eix-update will resort to the cache method "ebuild*" in your configuration which is rather slow. An hour or so can be normal. In addition, if one the ebuilds/eclasses in the overlay does not return, then also eix-update will not return, and this is not an eix bug... If you have installed very recent portage, you can call egencache --repo=kde-testing --update to let portage do the creation of the metadata - this is probably faster.
(In reply to comment #55 and #56) Thank you Martin and Michal. It was just the progress bar that was not moving as you described. So I let eix-update run and it did complete in about 5 minutes - same as Michał. Sorry about posting in the wrong place. BTW the egencache didn't work: # egencache --repo=kde-testing --update ecachegen: warning: automatically enabling FEATURES=metadata-transfer Unavailable repository 'gentoo' referenced by masters entry in '/usr/local/portage/layman/kde-testing/metadata/layout.conf' Usage: egencache [options] --update [atom] ... egencache: error: Unable to locate repository named 'kde-testing'
(In reply to comment #55 and #56) > Unable to locate repository named 'kde-testing' Maybe the label "kde-testing" was false: You must use the label for the overlay found in .../kde-testing/metadata/repo_name or in the eix output: [1] "label" /usr/local/portage/layman/kde-testing Anyway, I did not check, and maybe kde-testing does some tricky things egencache cannot cope with.
