| Summary: | app-portage/eix-0.22.5 is broken: 'regcomp(xxx(): Unmatched ( or \(' | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Tom Lloyd <napalmllama> |
| Component: | Current packages | Assignee: | Martin Väth <martin> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | darkside |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
strace of eix 0.22.5 running and failing
strace of eix 0.20.5 running and hanging Patch experiment for a compiler error Fix of previous patch |
||
|
Description
Tom Lloyd
2011-02-19 21:07:27 UTC
Created attachment 263105 [details]
strace of eix 0.22.5 running and failing
Created attachment 263107 [details]
strace of eix 0.20.5 running and hanging
Interestingly, eix-0.20.5 fails too, but in a different way: it just hangs. I've added straces of both cases if they're useful.
Maybe your eix cache is broken? Please retry after eix-update. If this does not help, please try the following: 1. Try whether the problem occurs also when you temporarily rename your local /etc/portage/* files. In this case, please find out (e.g. by binary search) which file is responsible (if possible, even which line of the file is responsible) and attach it. 2. If you use overlays, try whether the problem is related with them: Does the problem occur also after eix-update --exclude-overlay /usr/portage (replace /usr/portage by the path to your portage directory if it differs)? If yes, please try to find a minimal eix cache file for which your problem occurs, i.e. call PORTDIR_OVERLAY="..." eix-update --exclude-overlay /usr/portage where "..." contains as few of your overlays as is necessary to produce the error. Then please attach the produced cache file /var/cache/eix (In reply to comment #3) In the first sentence of 1. I meant the opposite: > 1. Try whether the problem *vanishes* when you temporarily rename [...] Please try also instead of empty argument whether eix -zs works. OK, I've just remerged eix-0.22.5: * Moving /etc/portage to /etc/portage.bak has no effect. * Excluding repositories from eix-update has no effect. * Running 'eix -zs some_argument' has no effect. * Running 'eix -zs' exhibits the same hanging behaviour as eix-0.20.5. Created attachment 263381 [details, diff] Patch experiment for a compiler error (In reply to comment #6) > * Running 'eix -zs some_argument' has no effect. What does this mean? Everything works as it should in this case? Or does it always print "no matches" even if "eix -zs eix" should print matches? > * Running 'eix -zs' exhibits the same hanging behaviour as eix-0.20.5. This is a very bad sign which hints to some memory corruption _somewhere_; it might even be a compiler bug. Since I cannot reproduce the problem here, I see almost no chance that I can debug it. Anyway, I attach a patch which does some things different (avoiding auto_ptr and a complicated casting in connection with Regex); so if it is a compiler bug, it might solve something. Created attachment 263383 [details, diff]
Fix of previous patch
Removed Patch of ChangeLog which was added by mistake
(In reply to comment #7) > > * Running 'eix -zs some_argument' has no effect. > What does this mean? I mean that 'eix -zs some_argument' behaves the same as 'eix some_argument', ie. it fails with the regcomp error. Thanks for the patch. Unfortunately it doesn't appear to make any difference: I still get the same regcomp error as before. I have static IP, I can give you a login to my box if necessary. Usually when something breaks on this machine it's uClibc to blame, either directly by lacking features or indirectly by software authors making invalid assumptions. regcomp is from libc, right? (In reply to comment #9) > I mean that 'eix -zs some_argument' behaves the same as > 'eix some_argument', ie. it fails with the regcomp error. This is very strange, since regcomp is then only called in one place which is unchanged since eix-0.15.something. It looks more and more like a memory corruption somewhere else... > I can give you a login to my box if necessary. I am afraid that without this, I will not be able to debug this problem. More on private mali. > it's uClibc to blame, either directly by lacking features > or indirectly by software authors making invalid assumptions. I was rather carefully to use only POSIX. It is probably a bug - either in compiler or some library or in eix. > regcomp is from libc, right? The problem is not regcomp: Obviously, when it is called, there is already some garbage in memory. Thanks for letting me debug. I finally found the bug, although I do not understand it: There is a variable "argreader" of type std::list, and a function got the iterators argreader.begin() and argreader.end() as parameter. However, although argreader is not accessed in a writable manner in this function, it seems that the "true" value of argreader.end() changes within the function causing the loop within the function to never reach the originally passed value of argreader.end(). (Hence, the loop gets infinite which caused eix to interpret random memory content as passed arguments). The fix is of course to access argreader.end() only dynamically, although this should not be necessary according to any C++ standard which I know. The corresponding fix is now in eix svn trunk (>=eix-0.22.8). Excellent, thanks for taking the time to do this! How long does it normally take for the SVN trunk to reach Portage? +*eix-0.22.8 (12 Mar 2011) + + 12 Mar 2011; Jeremy Olexa <darkside@gentoo.org> +eix-0.22.8.ebuild: + Version bump from upstream, fixes bugs 354071, 355623, 353562, 353705 |
