just did emerge -vaudN world, emerge died after glibc. had glibc in packages.keywords for gcc 4.3 emerge now just gives: # emerge Traceback (most recent call last): File "/usr/bin/emerge", line 27, in <module> import portage File "/usr/lib64/portage/pym/portage.py", line 98, in <module> from portage_data import ostype, lchown, userland, secpass, uid, wheelgid, \ File "/usr/lib64/portage/pym/portage_data.py", line 106, in <module> mystatus, myoutput = getstatusoutput("id -G portage") File "/usr/lib64/python2.5/commands.py", line 53, in getstatusoutput pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r') OSError: [Errno 38] Function not implemented Reproducible: Always Steps to Reproduce: 1. upgrade to newest glibc 2. try emerge 3.
todays parts of /var/log/emerge.log 1228789626: Started emerge on: Dec 09, 2008 03:27:06 1228789626: *** emerge sync 1228789626: === sync 1228789626: >>> Starting rsync with rsync://88.156.78.16/gentoo-portage 1228789670: === Sync completed with rsync://88.156.78.16/gentoo-portage 1228789752: *** terminating. 1228790910: Started emerge on: Dec 09, 2008 03:48:30 1228790910: *** emerge --newuse --deep --ask --update --verbose world 1228790917: >>> emerge (1 of 5) dev-java/java-config-1.3.7-r1 to / 1228790917: === (1 of 5) Cleaning (dev-java/java-config-1.3.7-r1::/usr/portage/dev-java/java-config/java-config-1.3.7-r1.ebuild) 1228790917: === (1 of 5) Compiling/Merging (dev-java/java-config-1.3.7-r1::/usr/portage/dev-java/java-config/java-config-1.3.7-r1.ebuild) 1228790926: >>> AUTOCLEAN: dev-java/java-config 1228790926: === Unmerging... (dev-java/java-config-1.3.7) 1228790928: >>> unmerge success: dev-java/java-config-1.3.7 1228790928: === (1 of 5) Post-Build Cleaning (dev-java/java-config-1.3.7-r1::/usr/portage/dev-java/java-config/java-config-1.3.7-r1.ebuild) 1228790928: ::: completed emerge (1 of 5) dev-java/java-config-1.3.7-r1 to / 1228790928: >>> emerge (2 of 5) x11-terms/xterm-237 to / 1228790928: === (2 of 5) Cleaning (x11-terms/xterm-237::/usr/portage/x11-terms/xterm/xterm-237.ebuild) 1228790928: === (2 of 5) Compiling/Merging (x11-terms/xterm-237::/usr/portage/x11-terms/xterm/xterm-237.ebuild) 1228790958: >>> AUTOCLEAN: x11-terms/xterm 1228790959: === Unmerging... (x11-terms/xterm-235) 1228790960: >>> unmerge success: x11-terms/xterm-235 1228790960: === (2 of 5) Post-Build Cleaning (x11-terms/xterm-237::/usr/portage/x11-terms/xterm/xterm-237.ebuild) 1228790960: ::: completed emerge (2 of 5) x11-terms/xterm-237 to / 1228790960: >>> emerge (3 of 5) x11-apps/xclock-1.0.3 to / 1228790960: === (3 of 5) Cleaning (x11-apps/xclock-1.0.3::/usr/portage/x11-apps/xclock/xclock-1.0.3.ebuild) 1228790960: === (3 of 5) Compiling/Merging (x11-apps/xclock-1.0.3::/usr/portage/x11-apps/xclock/xclock-1.0.3.ebuild) 1228790970: >>> AUTOCLEAN: x11-apps/xclock 1228790970: --- AUTOCLEAN: Nothing unmerged. 1228790970: === (3 of 5) Post-Build Cleaning (x11-apps/xclock-1.0.3::/usr/portage/x11-apps/xclock/xclock-1.0.3.ebuild) 1228790970: ::: completed emerge (3 of 5) x11-apps/xclock-1.0.3 to / 1228790970: >>> emerge (4 of 5) sys-libs/glibc-2.9_p20081201 to / 1228790970: === (4 of 5) Cleaning (sys-libs/glibc-2.9_p20081201::/usr/portage/sys-libs/glibc/glibc-2.9_p20081201.ebuild) 1228790970: === (4 of 5) Compiling/Merging (sys-libs/glibc-2.9_p20081201::/usr/portage/sys-libs/glibc/glibc-2.9_p20081201.ebuild) 1228791523: >>> AUTOCLEAN: sys-libs/glibc 1228791523: === Unmerging... (sys-libs/glibc-2.8_p20080602) 1228791525: >>> unmerge success: sys-libs/glibc-2.8_p20080602 1228791525: === (4 of 5) Post-Build Cleaning (sys-libs/glibc-2.9_p20081201::/usr/portage/sys-libs/glibc/glibc-2.9_p20081201.ebuild) 1228791525: ::: completed emerge (4 of 5) sys-libs/glibc-2.9_p20081201 to / 1228791525: >>> emerge (5 of 5) www-client/mozilla-firefox-3.0.4-r2 to / 1228791525: === (5 of 5) Cleaning (www-client/mozilla-firefox-3.0.4-r2::/usr/portage/www-client/mozilla-firefox/mozilla-firefox-3.0.4-r2.ebuild) 1228791525: === (5 of 5) Compiling/Merging (www-client/mozilla-firefox-3.0.4-r2::/usr/portage/www-client/mozilla-firefox/mozilla-firefox-3.0.4-r2.ebuild) 1228791528: *** exiting unsuccessfully with status '1'. 1228791534: *** terminating.
What's the output of: id -G portage echo $?
what kernel version are you running ? what version of linux-headers ?
#id -G portage 250 #echo $? 0 sys-kernel/gentoo-sources-2.6.27-r5 sys-kernel/linux-headers-2.6.23-r3 had to switch to latest kernels (other bug) otherwise the hdd would hang up on boot half of the time. seems i only put gentoo-sources into package.keywords. everything else works fine though, well almost. equery gives same error and fetchmail spouts nonsense about MDA open failed, might be related, but frankly i have no clues what might be nice would be a way to get emerge working again to at least try recompiling etc. thanks a lot.
added needed data. anything else? thanks
I had the same problem. This is how I came around: 1) change line 106 in /usr/lib/portage/pym/portage_data.py to: mystatus, myoutput = 0, '250' (or whatever "id -G portage" returns) 2) unmask sys-kernel/linux-headers 3) emerge sys-kernel/linux-headers (upgrading to 2.6.27-r2) 4) emerge -1 sys-libs/glibc 5) emerge -1 dev-lang/python 6) change line 106 in /usr/lib/portage/pym/portage_data.py back to: mystatus, myoutput = getstatusoutput("id -G portage")
Thanks a lot, this works just fine for me.
for the next person who hits this failure, run `strace -f -s 4096 -o log emerge` and post the log as an attachment
*** Bug 250440 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > for the next person who hits this failure, run `strace -f -s 4096 -o log > emerge` and post the log as an attachment http://www.stud.fit.vutbr.cz/~xdudka00/log (unable to upload 1.6MB file)
This bug is not fixed. Don't indicate that it is by RESOLVING, just because you found a workaround.
Note that portage is not the only thing broken by glibc update on my box. X11 forwarding over SSH stop working as well, kio sftp protocol and maybe some other stuff...
where can I upload log file 1.7M. Facing same issue. Thanks
it's called compression. use it. i.e. `lzma`. this bug is only about the original python error. any other issue is not to be posted here, so dont do it.
I had portage 2.1.5.6 installed to get automatically resolve the e2fsprogs/com_err/ss issue. 2.1.5.6 also was broken with glibc2.9. I commented out the offending section of code in /usr/lib64/portage/pym/portage_data.py and then simultaneously rebuilt python and upgraded to portage 2.1.6. Portage now works correctly. After doing a diff on portage_data.py, 2.1.6 eliminates that section of code all together. I'd say make glibc 2.9 require portage 2.1.6 or higher.
Created attachment 174931 [details] strace.log.bz2 not that the strace log shows anything other than it looks like glibc itself returning ENOSYS without actually making a syscall
since strace wasnt useful, someone do ltrace: ltrace -f -o log -s 4096 emerge and then compress/attach that log
# ltrace -f -o log -s 4096 /usr/lib/portage/bin/emerge ltrace: Can't open ELF file "/usr/lib/portage/bin/emerge" :/ I'm been hitted by this bug but can keep this machine with python broken to help you dev to find and fix the problem...
(In reply to comment #18) > # ltrace -f -o log -s 4096 /usr/lib/portage/bin/emerge > ltrace: Can't open ELF file "/usr/lib/portage/bin/emerge" # ltrace -f -o log -s 4096 /usr/bin/python /usr/lib/portage/bin/emerge
(In reply to comment #17) > since strace wasnt useful, someone do ltrace: > ltrace -f -o log -s 4096 emerge root # ltrace -f -o log -s 4096 /usr/bin/python /usr/lib/portage/bin/emerge Traceback (most recent call last): File "/usr/lib/portage/bin/emerge", line 27, in <module> import portage File "/usr/lib/portage/pym/portage.py", line 98, in <module> from portage_data import ostype, lchown, userland, secpass, uid, wheelgid, \ File "/usr/lib/portage/pym/portage_data.py", line 106, in <module> mystatus, myoutput = getstatusoutput("id -G portage") File "/usr/lib/python2.5/commands.py", line 53, in getstatusoutput pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r') OSError: [Errno 38] Function not implemented root # cat log 28288 __libc_start_main(0x8048694, 2, 0xbf901364, 0x80486e0, 0x80486d0 <unfinished ...> 28288 Py_Main(2, 0xbf901364, 0xbf901364, 0xbf901364, 0xbf9012e0) = 1 28288 +++ exited (status 1) +++ Thank you Kamil ;)
Created attachment 174979 [details] ltrace -f -o log -s 4096 /usr/bin/python /usr/lib/portage/bin/emerge
Created attachment 175118 [details] strace -f -s 4096 -o log emerge strace, please use lzma -d <file name>
Comment on attachment 175118 [details] strace -f -s 4096 -o log emerge Please use lzma -d to get the text file
I booted my system with an old kernel (2.6.26-gentoo-r2) and the problem disappeared. I've found a 3d related to this problem : http://www.nabble.com/system-broken--td20915308.html for completeness i report here all version of all tools involved : sys-kernel/linux-headers-2.6.23-r3 sys-kernel/gentoo-sources-2.6.26-r2 Ok sys-kernel/gentoo-sources-2.6.27-r5 Ko I haven't tried to recompile eventually linux-headers, without upgrading them, but now that portage works, I can do every try I want. SpanKY couldn't be worth to put a dependency to glibc to a particular version of linux-headers?
so this only happens for people mixing stable and unstable systems ...
cant really reproduce this at all dev-lang/python-2.5.2-r8 sys-apps/portage-2.2_rc17 sys-kernel/linux-headers-2.6.23-r3 sys-libs/glibc-2.9_p20081201-r1 and emerge still works ...
portage >=2.1.6 no longer contains the call which triggers the error. happened to me with: dev-lang/python-2.5.2-r7 sys-kernel/linux-headers-2.6.23-r3 sys-libs/glibc-2.9_p20081201 and.. sys-apps/portage-2.1.5.6 This was the offending section of code, specifically, the call to getstatusoutput: userpriv_groups = [portage_gid] if secpass >= 2: # Get a list of group IDs for the portage user. Do not use grp.getgrall() # since it is known to trigger spurious SIGPIPE problems with nss_ldap. from commands import getstatusoutput mystatus, myoutput = getstatusoutput("id -G portage") if mystatus == os.EX_OK: for x in myoutput.split(): try: userpriv_groups.append(int(x)) except ValueError: pass del x userpriv_groups = list(set(userpriv_groups)) del getstatusoutput, mystatus, myoutput running "id -G portage" in a shell works fine.
see if this test code works: #include <stdio.h> main() { if (!popen("ls -d /", "re")) perror("popen() failed"); } if it fails, then post the strace and ltrace output of it
and so we're clear, you guys arent setting NPTL_KERN_VER in your environment right ? the build log of glibc should show: --enable-kernel=2.6.9
No errors running your snippet of code and NPTL_KERN_VER is not set. no weird cflags or anything. From the build log Building GLIBC with NPTL... ABI: amd64 CBUILD: x86_64-pc-linux-gnu CHOST: x86_64-pc-linux-gnu CTARGET: x86_64-pc-linux-gnu CBUILD_OPT: x86_64-pc-linux-gnu CTARGET_OPT: x86_64-pc-linux-gnu CC: x86_64-pc-linux-gnu-gcc CFLAGS: -mtune=athlon64 -pipe -O2 -fno-strict-aliasing Configuring GLIBC for nptl with: --disable-stackguard-randomization --enable-old-ssp-compat --enable-add-ons=nptl,c_stubs,libidn,ports --enable-kernel=2.6.9 --without-selinux --without-cvs --enable-bind-now --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --disable-profile --with-gd --with-headers=/usr/include --prefix=/usr --libdir=/usr/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --libexecdir=/usr/lib64/misc/glibc
i dont suppose you're on a fast connection and can create/upload a binary package of your glibc ? or give me a temp non root account on the machine ? http://dev.gentoo.org/~vapier/ssh-pub-key
I just did a reboot for the first time since hitting this... and klive also fails to start at boot with a popen error in a python module. Your snippet of C code still works fine. Perhaps a problem in python 2.5.2-r7? Sending you an email with login info # /etc/init.d/klive start * Starting KLive ... Traceback (most recent call last): File "/usr/lib64/python2.5/site-packages/twisted/application/app.py", line 614, in run runApp(config) File "/usr/lib64/python2.5/site-packages/twisted/scripts/twistd.py", line 23, in runApp _SomeApplicationRunner(config).run() File "/usr/lib64/python2.5/site-packages/twisted/application/app.py", line 330, in run self.application = self.createOrGetApplication() File "/usr/lib64/python2.5/site-packages/twisted/application/app.py", line 416, in createOrGetApplication application = getApplication(self.config, passphrase) --- <exception caught here> --- File "/usr/lib64/python2.5/site-packages/twisted/application/app.py", line 427, in getApplication application = service.loadApplication(filename, style, passphrase) File "/usr/lib64/python2.5/site-packages/twisted/application/service.py", line 368, in loadApplication application = sob.loadValueFromFile(filename, 'application', passphrase) File "/usr/lib64/python2.5/site-packages/twisted/persisted/sob.py", line 214, in loadValueFromFile exec fileObj in d, d File "/usr/share/klive/klive.tac", line 154, in <module> pci_id = os.popen('lspci -n').readlines() exceptions.OSError: [Errno 38] Function not implemented Failed to load application: [Errno 38] Function not implemented
it all boils down to popen() ... there's either a disconnect somewhere with glibc's internal handling of popen() and pipe vs pipe2, or python. but i havent been able to reproduce this disconnect. glibc-2.9 did include changes to the popen implementation for pipe2 handling in the kernel.
(In reply to comment #28) > see if this test code works: worked like a charm: deadhead $ ldd test linux-gate.so.1 => (0xffffe000) libc.so.6 => /lib/libc.so.6 (0xb7ee0000) /lib/ld-linux.so.2 (0xb8046000) deadhead $ strace ./test execve("./test", ["./test"], [/* 72 vars */]) = 0 brk(0) = 0x8a99000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=101747, ...}) = 0 mmap2(NULL, 101747, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f81000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`h\1\0004\0\0\0,"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1352852, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f80000 mmap2(NULL, 1357360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e34000 mmap2(0xb7f7a000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x146) = 0xb7f7a000 mmap2(0xb7f7d000, 9776, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f7d000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e33000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e336c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0xb7f7a000, 8192, PROT_READ) = 0 mprotect(0x8049000, 4096, PROT_READ) = 0 mprotect(0xb7fb8000, 4096, PROT_READ) = 0 munmap(0xb7f81000, 101747) = 0 brk(0) = 0x8a99000 brk(0x8aba000) = 0x8aba000 pipe([3, 4]) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7e33708) = 6725 close(4) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 exit_group(145330184) = ? ltrace -d ./test DEBUG: read_config_file.c:182: read_config_file(): Reading config file `/etc/ltrace.conf'... DEBUG: read_config_file.c:182: read_config_file(): Reading config file `/home/deadhead/.ltrace.conf'... DEBUG: elf.c:38: do_init_elf(): Reading ELF from ./test... DEBUG: elf.c:265: do_init_elf(): ./test_vapier 4 PLT relocations DEBUG: execute_program.c:76: execute_program(): Executing `./test'... DEBUG: execute_program.c:91: execute_program(): PID=6768 DEBUG: breakpoints.c:106: enable_all_breakpoints(): Enabling breakpoints for pid 6768... DEBUG: breakpoint.c:25: enable_breakpoint(): enable_breakpoint(6768,0x804831c) DEBUG: breakpoint.c:25: enable_breakpoint(): enable_breakpoint(6768,0x804832c) DEBUG: breakpoint.c:25: enable_breakpoint(): enable_breakpoint(6768,0x804833c) DEBUG: breakpoint.c:25: enable_breakpoint(): enable_breakpoint(6768,0x804834c) DEBUG: process_event.c:108: process_event(): event: none DEBUG: process_event.c:129: process_event(): event: syscall (SYS_brk [45]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_brk [45]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_access [33]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_access [33]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_open [5]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_open [5]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_fstat64 [197]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_fstat64 [197]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_mmap2 [192]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_mmap2 [192]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_close [6]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_close [6]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_open [5]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_open [5]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_read [3]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_read [3]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_fstat64 [197]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_fstat64 [197]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_mmap2 [192]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_mmap2 [192]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_mmap2 [192]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_mmap2 [192]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_mmap2 [192]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_mmap2 [192]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_mmap2 [192]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_mmap2 [192]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_close [6]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_close [6]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_mmap2 [192]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_mmap2 [192]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_set_thread_area [243]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_set_thread_area [243]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_mprotect [125]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_mprotect [125]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_mprotect [125]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_mprotect [125]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_mprotect [125]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_mprotect [125]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_munmap [91]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_munmap [91]) DEBUG: process_event.c:151: process_event(): event: breakpoint __libc_start_main(0x8048434, 1, 0xbfed1c94, 0x8048490, 0x8048480 <unfinished ...> DEBUG: breakpoint.c:25: enable_breakpoint(): enable_breakpoint(6768,0x8048381) DEBUG: process_event.c:151: process_event(): event: breakpoint DEBUG: breakpoint.c:25: enable_breakpoint(): enable_breakpoint(6768,0x804833c) DEBUG: process_event.c:151: process_event(): event: breakpoint popen("ls -d /", "re" <unfinished ...> DEBUG: breakpoint.c:25: enable_breakpoint(): enable_breakpoint(6768,0x8048459) DEBUG: process_event.c:151: process_event(): event: breakpoint DEBUG: breakpoint.c:25: enable_breakpoint(): enable_breakpoint(6768,0x804831c) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_brk [45]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_brk [45]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_brk [45]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_brk [45]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_pipe [42]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_pipe [42]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_clone [120]) DEBUG: breakpoints.c:125: disable_all_breakpoints(): Disabling breakpoints for pid 6768... DEBUG: process_event.c:135: process_event(): event: sysret (SYS_clone [120]) DEBUG: breakpoints.c:106: enable_all_breakpoints(): Enabling breakpoints for pid 6768... DEBUG: breakpoint.c:25: enable_breakpoint(): enable_breakpoint(6768,0x804831c) DEBUG: breakpoint.c:25: enable_breakpoint(): enable_breakpoint(6768,0x804832c) DEBUG: breakpoint.c:25: enable_breakpoint(): enable_breakpoint(6768,0x804833c) DEBUG: breakpoint.c:25: enable_breakpoint(): enable_breakpoint(6768,0x804834c) DEBUG: breakpoint.c:25: enable_breakpoint(): enable_breakpoint(6768,0x8048381) DEBUG: breakpoint.c:25: enable_breakpoint(): enable_breakpoint(6768,0x8048459) DEBUG: process_event.c:113: process_event(): event: signal (SIGCHLD [17]) --- SIGCHLD (Child exited) --- DEBUG: process_event.c:129: process_event(): event: syscall (SYS_close [6]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_close [6]) DEBUG: process_event.c:129: process_event(): event: syscall (SYS_fcntl64 [221]) DEBUG: process_event.c:135: process_event(): event: sysret (SYS_fcntl64 [221]) DEBUG: process_event.c:151: process_event(): event: breakpoint <... popen resumed> ) = 0x97aa008 DEBUG: process_event.c:129: process_event(): event: syscall (SYS_exit_group [252]) DEBUG: process_event.c:117: process_event(): event: exit (8) +++ exited (status 8) +++ DEBUG: process_event.c:194: remove_proc(): Removing pid 6768 DEBUG: wait_for_something.c:30: wait_for_something(): No more children talking about glibc this is mine : * ABI: default * CBUILD: i686-pc-linux-gnu * CHOST: i686-pc-linux-gnu * CTARGET: i686-pc-linux-gnu * CBUILD_OPT: * CTARGET_OPT: * CC: * CFLAGS: -march=pentium-m -pipe -O2 -fno-strict-aliasing * Configuring GLIBC for nptl with: --disable-stackguard-randomization --enable-old-ssp-compat --enable-add-ons=nptl,c_stubs,libidn,ports --enable-kernel=2.6.9 --without-selinux --without-cvs --enable-bind-now --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --disable-profile --without-gd --with-headers=/usr/include --prefix=/usr --libdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --libexecdir=/usr/lib/misc/glibc
(In reply to comment #31) > i dont suppose you're on a fast connection and can create/upload a binary > package of your glibc ? Could be useful to you having a copy of glibc-2.6.1 and glibc-2.9.2.9_p20081201 built in a system with : kernel 2.6.27-r6 kernel-headers-2.6.23-r3 gcc-4.3.2 python-2.5.2 portage-2.1.4.5 Tell me, and i'll provide them to you. I'm on x86 arch, but the problem is the same and it's fixed if I use
... if I use linux-headers-2.6.27-r2
I've been working on some test cases for this in python since it seems to be restricted to that in some way (I'm not having any errors with anything else at this point). I'm no python expert (in fact, all of my python experience pretty much comes down to debugging this), but I'm starting to think that python itself has some type of internal problems (maybe some kind of stack corruption) with the python-2.5.2 implementation of the grp code when used with glibc-2.9. I just wanted to update you with what I've found so far... I'm going to keep poking around. I left the test cases in your user directory on my machine too test1.py: #call popen directly as per commands.py instead of using os.popen #this works import os pipe = os.popen('{ id -G portage; } 2>&1', 'r') text = pipe.read() sts = pipe.close() print sts print text test2.py: #boiled down the portage code to produce the error #this fails with #Traceback (most recent call last): # File "test2.fails.py", line 5, in <module> # pipe = os.popen('{ id -G portage; } 2>&1', 'r') # OSError: [Errno 38] Function not implemented import os, grp portage_gid=grp.getgrnam("portage")[2] pipe = os.popen('{ id -G portage; } 2>&1', 'r') test3.py: #elimated the call to grp.getgrnam #this works import os, grp pipe = os.popen('{ id -G portage; } 2>&1', 'r') test4.py: #test the return of grp.getgrnam #this works import os, grp portage_gid=grp.getgrnam("portage")[2] print portage_gid
thanks, with your reduced python and system, i was able to distill the C code: #include <grp.h> #include <stdio.h> int main() { getgrnam("portage"); if (!popen("ls", "r")) perror("popen()"); return 0; } without the getgrnam() call, it works. i can reproduce this on my system now, so i'll debug glibc itself ... thanks a ton
*** Bug 251596 has been marked as a duplicate of this bug. ***
Just re-installed glibc-2.9 after upgrading to linux-headers-2.6.27-r2 and the problem no longer exists. My failed distilled test case now works as does your C test case. Looks like kernels > 2.6.26 require a newer linux-headers for glibc-2.9 to function properly.
fixed in glibc-2.9_p20081201-r1 ... thanks to saellaven for his help http://sources.gentoo.org/gentoo/src/patchsets/glibc/2.9/1095_all_glibc-2.9-assume-pipe2.patch?rev=1.1
here you can find glibc : http://goodfellow.it/gentoo/
Created attachment 176486 [details] output of C code to test grp
Created attachment 176488 [details] output of C code to test grp
just upgrade to glibc-2.9_p20081201-r1 as the issue should be fixed there
(In reply to comment #45) > just upgrade to glibc-2.9_p20081201-r1 as the issue should be fixed there Yes, just tried: thank you for spending your time on such a particular situation, analising and fixing this weirdness :D
I really don't know if it's related, but it seems so, so i'm reopening. http://bugs.gentoo.org/show_bug.cgi?id=252302
it isnt
(In reply to comment #45) > just upgrade to glibc-2.9_p20081201-r1 as the issue should be fixed there > I've recently upgraded to glibc-2.9_p20081202-r2 on 32-bit PPC and am now getting these errors with portage... # emerge Traceback (most recent call last): File "/usr/bin/emerge", line 29, in <module> import _emerge File "//usr/lib/portage/pym/_emerge/__init__.py", line 26, in <module> import portage File "//usr/lib/portage/pym/portage/__init__.py", line 96, in <module> from portage.data import ostype, lchown, userland, secpass, uid, wheelgid, \ File "//usr/lib/portage/pym/portage/data.py", line 101, in <module> mystatus, myoutput = getstatusoutput("id -G portage") File "/usr/lib/python2.5/commands.py", line 53, in getstatusoutput pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r') OSError: [Errno 9] Bad file descriptor Python and Portage are as follows... # eix dev-lang/python [I] dev-lang/python Available versions: (2.4) 2.4.6 (2.5) 2.5.4-r2 2.5.4-r3 (2.6) ~2.6.2-r1 {berkdb bootstrap build cxx doc elibc_uclibc examples gdbm ipv6 ncurses readline sqlite ssl threads tk ucs2 wininst xml} Installed versions: 2.5.4-r3(2.5)(23:50:06 07/28/09)(berkdb gdbm ipv6 ncurses readline sqlite ssl threads xml -build -doc -elibc_uclibc -examples -tk -ucs2 -wininst) Homepage: http://www.python.org/ Description: Python is an interpreted, interactive, object-oriented programming language. # eix sys-apps/portage [I] sys-apps/portage Available versions: 2.1.4.5 2.1.6.7 2.1.6.13 [M]~2.2_rc33 {build doc epydoc linguas_pl selinux} Installed versions: 2.1.6.13(16:42:27 06/10/09)(-build -doc -epydoc -linguas_pl -selinux) Homepage: http://www.gentoo.org/proj/en/portage/index.xml Description: Portage is the package management and distribution system for Gentoo Aside from the fact that I've installed a version of glibc that shouldn't be affected by this problem as it was fixed in glibc-2.9_p20082101-r1 how would you go about updating a package (e.g. glibc) if portage/python are broken, would it be a case of booting a livecd and chrooting?
After upgrading to glibc-2.9_p20081201-r2 at ppc64, I also ran into the popen() issue. After changing getstatusoutput("id -G portage") to 0, '250' in /usr/lib/portage/pym/portage/data.py, I can run emerge again. This test code fails with: popen() failed: Bad file descriptor #include <stdio.h> main() { if (!popen("ls -d /", "re")) perror("popen() failed"); } When I try to recompile glibc-2.9_p20081201-r2 I get this error: gawk: scripts/versions.awk:72: (FILENAME=- FNR=3) fatal: can't open pipe `sort > /tmp/portage/portage/sys-libs/glibc-2.9_p20081201-r2/work/build-ppc64-powerpc64 -unknown-linux-gnu-nptl/Versions.tmp' for output (Bad file descriptor) In several other programs I also get the 'Bad file descriptor' error. Emerge won't let me downgrade my glibc, so I'm stuck with a broken system. My kernel is the latest stable ps3-sources kernel, which is 2.6.23-r1. I want to try installing a new kernel, however, with a broken glibc, I don't know if my system will boot again. What should I do? Is there a quick workaround for the popen() issue? And: Could anybody please reopen this bug?
Bug #271367 says I need a new kernel, so I'll try that, and continue any discussion over there.
*** Bug 250513 has been marked as a duplicate of this bug. ***
