Description of problem: Cleanup : glibc-2.10.90-10 13/18 /var/tmp/rpm-tmp.znJgz6: line 3: 4339 Segmentation fault /usr/sbin/redhat_lsb_trigger.x86_64 Version-Release number of selected component (if applicable): How reproducible: yum updated from glibc-2.10.90-10 to 2.10.90-11 Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
See this: Aug 2 09:31:36 tlondon kernel: redhat_lsb_trig[6612]: segfault at 7ffff1c76ed8 ip 000000000040e971 sp 00007ffff1c76ee0 error 6 in redhat_lsb_trigger.x86_64[400000+9f000] Generates an enormous (1010G!!!!!) core file: [root@tlondon ~]# ls -lh core.* -rw-------. 1 root root 1010G 2009-08-02 09:34 core.6612 [root@tlondon ~]# [Almost certainly mostly zeros....] Running gdb: warning: core file may not match specified executable file. Core was generated by `/usr/sbin/redhat_lsb_trigger.x86_64 --help'. Program terminated with signal 11, Segmentation fault. #0 0x000000000040e971 in _dl_discover_osversion () (gdb) where #0 0x000000000040e971 in _dl_discover_osversion () #1 0x0000000000400528 in __libc_start_main () #2 0x00000000004002a9 in _start () (gdb) _dl_discover_osversion() ??????
Running "gdb /usr/sbin/redhat_lsb_trigger.x86_64" interactively: (gdb) run Starting program: /usr/sbin/redhat_lsb_trigger.x86_64 Program received signal SIGSEGV, Segmentation fault. 0x000000000040e971 in _dl_discover_osversion () (gdb) where #0 0x000000000040e971 in _dl_discover_osversion () #1 0x0000000000400528 in __libc_start_main () #2 0x00000000004002a9 in _start () (gdb) list 434 { 435 char buf[sizeof LSBLDSO + 1 + strlen (LSBVER)]; 436 p = buf; 437 p = mempcpy (p, LSBLDSO, sizeof LSBLDSO - 1); 438 *p++ = '.'; 439 strcpy (p, LSBVER); 440 if (is_ia64 ()) 441 INTERNAL_SYSCALL (symlink, err, 2, "/emul/ia32-linux/lib/" LDSO, buf); 442 else 443 INTERNAL_SYSCALL (symlink, err, 2, LDSO, buf); (gdb)
Downgrading to redhat-lsb-3.2-4.fc12.x86_64.rpm seems to make it "work for me".
*** Bug 515537 has been marked as a duplicate of this bug. ***
After removing redhat-lsb (not sure what pulled it in, but I had no problems removing it and the few dependencies), I have no problem updating to glibc.x86_64 0:2.10.90-13. Is redhat-lsb "vestigial"?
*** Bug 523270 has been marked as a duplicate of this bug. ***
When you dupe blocker bugs please move the blocker tag the the report remaining open
tom: redhat-lsb basically exists to make the distro LSB-compliant when installed. it's not a vestigial package. Bug was discussed at blocker bug review meeting today. jlaska will ping llim to see what's going on here. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 366147 [details] redhat-lsb-trigger.patch The reason redhat_lsb_trigger.c is written in the weird way it is is to keep the stripped statically linked binary small. Normally statically linked binaries are in the .5MB-2MB range because all kinds of stuff gets linked in, the intent was that only very few object files if anything from libc.a gets linked into the binary. You can add -Wl,-M to see what is being linked in. One needs to choose either to keep redhat_lsb_trigger.c correct and uptodate with glibc changes, or just give up on the size. In that case most of the file can be dropped, you'd use normal symlink, exit, etc. calls instead of *_SYSCALL macros, just have everything in main, etc. One of the changes since I had anything to do with that file was added underscore to __libc_start_main, that makes absolutely no sense. The reason for the routine to be defined there is to avoid linking in __libc_start_main from libc.a and all of its numerous dependencies. Unfortunately due to the ia64 emulation braindamage the trigger can't be written in LUA, at least not solely in LUA :(. With the attached patch redhat_lsb_trigger.x86_64 is again very small (3KB), haven't tried other arches, if you compile it with additional -fno-stack-protector (although __stack_chk_fail could be stubbed, the provided __libc_start_main doesn't setup %gs/%fs on x86_64/i?86 and doesn't initialize the stack canary). The reason for the segfaults was IFUNC, the relocations to call strcpy weren't initialized because __libc_csu_start was stubbed.
Jakub, even with that patch applied, the trigger binary still segfaults: [spot@pterodactyl devel]$ sudo /usr/sbin/redhat_lsb_trigger.x86_64 Segmentation fault Gdb isn't much help either: [root@pterodactyl ~]# gdb /usr/sbin/redhat_lsb_trigger.x86_64 GNU gdb (GDB) Fedora (7.0-3.fc12) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/sbin/redhat_lsb_trigger.x86_64...Reading symbols from /usr/lib/debug/usr/sbin/redhat_lsb_trigger.x86_64.debug...done. done. (gdb) run Starting program: /usr/sbin/redhat_lsb_trigger.x86_64 Program received signal SIGSEGV, Segmentation fault. main (argc=<value optimized out>, argv=0x7fffffffe518) at redhat_lsb_trigger.c:495 495 { (gdb) bt #0 main (argc=<value optimized out>, argv=0x7fffffffe518) at redhat_lsb_trigger.c:495 (gdb) list 490 while ((*dst++ = *src++) != '\0'); 491 return ret; 492 } 493 494 int main (int argc, char **argv) 495 { 496 INTERNAL_SYSCALL_DECL (err); 497 char lsbsover[] = LSBSOVER; 498 char *LSBVER, *p = lsbsover; 499 while ((LSBVER = strtok (p, " \t")) != NULL) (gdb)
Was that really compiled with -fno-stack-protector? It worked for me well when compiled that way (and with the patch applied).
Aha, sorry, that wasn't clear to me at first that it was necessary. It works when compiled that way. I'll get this fix pushed out.
Fixed in F-12 (redhat-lsb-3.2-7.fc12) and rawhide.
i'm no expert so prepared for you to laugh at me, but it was my understanding that disabling compiler security features is not the right way to 'fix' problems? the correct approach would be to make the code with with stack protection enabled? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This whole proglet is just 2 syscalls, it is easily provable there is no stack overflow. -fstack-protect only triggers in main, no other function has any arrays on the stack, and main never returns in this proglet, because it invokes the exit syscall instead. As -fstack-protector only checks the canary when returning from a function, it would never trigger here. And the initialization of the thread mmapping etc. would need to be arch specific and would probably double the size of the proglet, for no security improvement at all.
Thank you for laughing at me in such a kind and informative way :) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers