| Summary: | x11-libs/libSM-1.0.2 prerm function failure | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Fab <netbox253> |
| Component: | Core - Interface (emerge) | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | Keywords: | InVCS |
| Priority: | High | ||
| Version: | 2.1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 147007 | ||
| Attachments: |
portage error ?
emerge --info libSM-1.0.2.tar exclude non-string values from the environment full log binary myargs env env |
||
|
Description
Fab
2006-10-29 07:10:03 UTC
Created attachment 100715 [details]
portage error ?
Created attachment 100716 [details]
emerge --info
Tarball /var/db/pkg/x11-libs/libSM-1.0.2 directory and attach it here. Created attachment 100719 [details]
libSM-1.0.2.tar
here it is.
Reopen. It seems that a non-string object leaked into the config somehow. Please post emrege --info. Created attachment 100742 [details, diff]
exclude non-string values from the environment
This patch should solve the problem and also help us diagnose the cause. It will cause the specific non-string value to be written to stderr. If the patch is saved as /tmp/environ.patch, then it can be applied as follows:
cd /usr/lib/portage
patch -p0 < /tmp/environ.patch
Please post any warning messages that this patch generates.
Created attachment 100751 [details]
full log
Patch applied, but it changed nothing : I don't see any difference. Very strange.
Any suggestion ?
Attached full log : emerge -1 libSM && emerge --info
(In reply to comment #8) > Patch applied, but it changed nothing : I don't see any difference. Very > strange. > Any suggestion ? That doesn't make any sense to me. The sanity check in the patch should catch any non-string values before they are returned from the config.environ() method. Between there and the execve call, the environment dictionary is never modified as far as I can see. Yes, there's something wrong :
-----------------------------------------------
...
for x, y in env.items():
if not isinstance(y, basestring):
print "%s=%s" % (x, y)
continue
# And switch to the new process.
os.execve(binary, myargs, env)
...
---------------------------
>>> Unmerging x11-libs/libSM-1.0.1...
execve() arg 3 contains a non-string value:
/bin/bash -c /usr/lib/portage/bin/ebuild.sh prerm
!!! FAILED prerm: 1
---------------------------
Maybe a python problem ? I rebuild it twice a few days ago, for another problem :
------------------------
Tue Oct 17 22:34:01 2006 >>> dev-lang/python-2.4.3-r4
merge time: 5 minutes and 6 seconds.
Wed Oct 18 01:12:51 2006 >>> dev-lang/python-2.4.3-r4
merge time: 5 minutes and 6 seconds.
------------------------
I'll attach content of the binary, myargs and env variables when the execve call fails.
I'm not expert in python. Is it possible to create a little program which read theses files, and try to run an os.execve() call ? If it fails, portage will be out of the problem.
Maybe you have a better/faster idea ?
Created attachment 100773 [details]
binary
Created attachment 100774 [details]
myargs
Created attachment 100775 [details]
env
Created attachment 100778 [details]
env
I was able to reproduce the problem(In reply to comment #13) > Created an attachment (id=100775) [edit] > env I was able to reproduce the problem locally using the dictionary from comment #13. I wrote a script to eliminate values until the os.execve call would succeed. It succeeded after the following value was removed: 'FEATURES': 'autoconfig buildpkg buildsyspkg candy ccache confcache distlocks metadata-transfer parallel-fetch sandbox sfperms strixt userfetch userpriv usersandbo\x00' Here is a minimal script to reproduce the problem:
#!/usr/bin/env python
import os
args=["/usr/bin/echo", "hello world"]
os.execve(args[0], args, {'FEATURES': '\x00'})
Yes, I can repro here with your minimal script. But I don't understand how this \x00 characters appeared in the FEATURES variable. My make.conf is clean, I just tried to rewrite the part which is concerned, but I have always the same error. And I don't understand why this bug is only with libSM ? Here is the FEATURES from my make.conf, from emerge --info and from the env dictionnary : ----------------- FEATURES="parallel-fetch candy buildpkg buildsyspkg userfetch userpriv usersandbox splitdebug" ----------------- FEATURES="autoconfig buildpkg buildsyspkg candy distlocks metadata-transfer parallel-fetch sandbox sfperms splitdebug strict userfetch userpriv usersandbox" ----------------- 'FEATURES': 'autoconfig buildpkg buildsyspkg candy ccache confcache distlocks metadata-transfer parallel-fetch sandbox sfperms strixt userfetch userpriv usersandbo\x00', ----------------- Is this normal that the splitdebug feature doesn't appear in the env dictionnary ? Will try to emerge --sync && emerge -uDN world to see if the bug appear with another packages. Very strange o_O (In reply to comment #17) > Is this normal that the splitdebug feature doesn't appear in the env > dictionnary ? That FEATURES value would have been loaded from /var/db/pkg/x11-libs/libSM-1.0.2/FEATURES just prior to the prerm phase. The usersandbo\x00 looks awfully strange, as if a null terminator somehow leaked into the environment and replaced the x in usersandbox. I can see why python would disallow null bytes in environment variables, since C strings are terminated by null bytes. I suppose portage could scan for null bytes and remove them if necessary. Here's a demonstration of a null byte causing part of an environment variable to be ignored: #include <unistd.h> int main() { char *const myargv[] = {"/usr/bin/env", NULL}; char *const myenvp[] = {"FEATURES=test\0 ignored text here", NULL}; execve(myargv[0], myargv, myenvp); } (In reply to comment #18) > That FEATURES value would have been loaded from > /var/db/pkg/x11-libs/libSM-1.0.2/FEATURES just prior to the prerm phase. Ok, the /var/db/pkg/x11-libs/libSM-1.0.1/FEATURES file seems to be corrupt : ----------------------------------- $ file /var/db/pkg/x11-libs/libSM-1.0.1/FEATURES /var/db/pkg/x11-libs/libSM-1.0.1/FEATURES: data $ file /var/db/pkg/x11-libs/libSM-1.0.2/FEATURES /var/db/pkg/x11-libs/libSM-1.0.2/FEATURES: ASCII text ----------------------------------- Can I remove it ? (In reply to comment #19) > Can I remove it ? Yes, that should be fine. Portage doesn't strictly need that file. Yes, it was that. Thanks for your help. Victory :o) # cd /var/db/pkg/x11-libs/libSM-1.0.1/ # mv FEATURES ~ # echo 'autoconfig buildpkg buildsyspkg candy ccache confcache distlocks metadata-transfer parallel-fetch sandbox sfperms strict userfetch userpriv usersandbox' > FEATURES # emerge -1 libSM Calculating dependencies ... done! >>> Emerging (1 of 1) x11-libs/libSM-1.0.2 to / [...] x11-libs/libSM selected: 1.0.1 protected: 1.0.2 omitted: none >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. >>> Waiting 5 seconds before starting... >>> (Control-C to abort)... >>> Unmerging in: 5 4 3 2 1 >>> Unmerging x11-libs/libSM-1.0.1... No package files given... Grabbing a set. <<< obj /usr/share/doc/libSM-1.0.1/ChangeLog.gz --- !mtime obj /usr/lib/pkgconfig/sm.pc --- !mtime obj /usr/lib/libSM.so.6.0.0 [...] In svn r4893, I've fixed it to skip files with null bytes and print a warning message. This has been released in 2.1.2_rc1-r2. |
