Bug 512078

Summary: GNOME panel 2.27.4 crashes
Product: [Fedora] Fedora Reporter: Joachim Frieben <jfrieben>
Component: prelinkAssignee: Jakub Jelinek <jakub>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: jakub, lpoetter, mclasen, nicolas.mailhot, rstrode, schaiba, selinux, tbzatek
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-07-21 15:47:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 507676    
Attachments:
Description Flags
Output file from 'tar cjhf /tmp/gnome-panel-prelinked.tar.bz2 ...' none

Description Joachim Frieben 2009-07-16 08:08:53 UTC
Description of problem:
After upgrading gnome-panel and some other GNOME packages to version 2.27.x, gnome-panel crashes when logging in. Any attempt to launch it from the shell yields

  $ gnome-panel 
  Segmentation fault

Version-Release number of selected component (if applicable):
gnome-panel-2.27.4-1.fc12.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Log in to GNOME.
2. Notice that no panel appears.
3. Run gnome-panel from a shell.
  
Actual results:
No panel appears after logging in. When run from the shell, "Segmentation fault" is returned to the user.

Expected results:
A usable panel appears on the desktop.

Additional info:
Downgrading to gnome-panel-2.26.2-3.fc12.x86_64 allows to recover a working panel application.

Comment 1 Tom London 2009-07-17 16:31:52 UTC
I'm seeing this too.

From a core image:

Core was generated by `gnome-panel'.
Program terminated with signal 11, Segmentation fault.
#0  __strcmp_sse2 () at ../sysdeps/x86_64/strcmp.S:30
30		cmpb	(%rsi), %al
(gdb) where
#0  __strcmp_sse2 () at ../sysdeps/x86_64/strcmp.S:30
#1  0x00000034fb610dab in elf_machine_rela (
    reloc_addr_arg=<value optimized out>, version=<value optimized out>, 
    sym=<value optimized out>, reloc=<value optimized out>, 
    map=<value optimized out>) at ../sysdeps/x86_64/dl-machine.h:448
#2  _dl_resolve_conflicts (reloc_addr_arg=<value optimized out>, 
    version=<value optimized out>, sym=<value optimized out>, 
    reloc=<value optimized out>, map=<value optimized out>) at dl-conflict.c:72
#3  0x00000034fb602830 in ?? () at rtld.c:752 from /lib64/ld-2.10.90.so
#4  0x0000003136065828 in g_get_current_dir () at gutils.c:993
#5  0x00007f27c9d88000 in ?? ()
#6  0x00007f27c9dc3000 in ?? ()
#7  0x00007fff404acf90 in ?? ()
#8  0x0000000000000001 in ?? ()
#9  0x0000000000000026 in ?? ()
#10 0x00000000ed3405f4 in ?? ()
#11 0x00007f27c9d88800 in ?? ()
#12 0x00000034fb603b1d in dl_main (phdr=<value optimized out>, 
    phnum=<value optimized out>, user_entry=<value optimized out>)
    at rtld.c:2167
#13 0x0000000000000000 in ?? ()
Current language:  auto; currently asm
(gdb) 

More info I can provide?

Comment 2 Matthias Clasen 2009-07-19 01:59:22 UTC
prelink error. 
Try again after prelink --undo /usr/bin/gnome-panel

Comment 3 Tom London 2009-07-19 21:55:31 UTC
Ran "prelink --undo /usr/sbin/gnome-panel", and it booted fine the next time.

Is there a fix for prelink for this, or will this recur?

Comment 4 Matthias Clasen 2009-07-20 01:49:26 UTC
Moving to prelink to find out.

Comment 5 Matthias Clasen 2009-07-20 23:53:32 UTC
*** Bug 512570 has been marked as a duplicate of this bug. ***

Comment 6 Jakub Jelinek 2009-07-21 00:06:25 UTC
Are you sure this wasn't reprelinking using prelink-0.4.1-1.fc12 or earlier?
If you can reproduce it even with prelink-0.4.2-1.fc12, I'll need /usr/bin/gnome-panel binary (prelinked) and all the shared libraries it depends on.

Tried to reproduce this myself, but gnome-panel works just fine.

Comment 7 Matthias Clasen 2009-07-21 01:51:08 UTC
Yes, I see this with prelink 0.4.2.
I also see it with some simpler binaries, e.g. gtk-demo.

Comment 8 Aioanei Rares 2009-07-21 07:37:32 UTC
I ran prelink -uva and it ran OK after login; however, after today's update, including a new kernel, ran top -d 1 and saw prelink running, so after a reboot gnome-panel didn't appear again. Re-ran prelink -uva and now I have my panel back.

Comment 9 Joachim Frieben 2009-07-21 08:13:00 UTC
gnome-panel was updated to version 2.27.4-1.fc12 while prelink-0.4.2-1.fc12 was already installed. As described in comment #8, 'prelink --undo /usr/bin/gnome-panel' temporarily cures the issue for a while, but after the next run of prelink triggered by CRON, the binary segfaults again. gtk-demo segfaults as well as reported in comment #7.
Regarding comment #6, I wonder whether the system without issue is x86_64, too.

Comment 10 Jakub Jelinek 2009-07-21 08:21:55 UTC
Of course I was testing on x86-64, though in a mock chroot (don't have rawhide installed anywhere).

Can anyone who can reproduce this please provide the requested files?
Just
tar cjhf /tmp/gnome-panel-prelinked.tar.bz2 `LD_TRACE_PRELINKING=1 LD_WARN= /usr/bin/gnome-panel | awk '{print $3}'`
when gnome-panel is prelinked and crashes?
Thanks.

Comment 11 Nicolas Mailhot 2009-07-21 08:30:45 UTC
(In reply to comment #10)
> Of course I was testing on x86-64, though in a mock chroot (don't have rawhide
> installed anywhere).

Well given all the prelink/glibc problems which have been piling up those past weeks and have caused many people to waste hours/days, maybe you could install it somewhere? That is, before the project earns another 'terminally broken' lwn.net headline?

Comment 12 Joachim Frieben 2009-07-21 11:51:13 UTC
Created attachment 354476 [details]
Output file from 'tar cjhf /tmp/gnome-panel-prelinked.tar.bz2 ...'

Output file from: tar cjhf /tmp/gnome-panel-prelinked.tar.bz2 `LD_TRACE_PRELINKING=1 LD_WARN=1 /usr/bin/gnome-panel | awk '{print $3}'`

Archive file gnome-panel-prelinked.tar.bz2 gets created but tar returns a number of errors before terminating:

  ..
  tar: 0x0000000000000428: Cannot stat: No such file or directory
  tar: 0x0000000000000410: Cannot stat: No such file or directory
  tar: Exiting with failure status due to previous errors .

Comment 13 Jakub Jelinek 2009-07-21 12:27:20 UTC
What does:
LD_TRACE_PRELINKING=1 LD_WARN=1 /usr/bin/gnome-panel | awk '{print $3}'
print?
Also, /usr/lib64/libXrandr.so.2 in the tarball isn't prelinked, so the dynamic linker can't use prelink info
LD_DEBUG=all /usr/bin/gnome-panel
shows
prelink checking: failed
in its output (among other things) and thus _dl_resolve_conflicts isn't called at all.  Thus I don't believe it will crash in that function with these libraries.

Apparently we have a buggy ld, at least had when many of the libraries were linked, there are tons of STT_GNU_IFUNC SHN_UNDEF symbols where there should be none, but that shouldn't have effect on this.  I'll talk to binutils maintainer.

Comment 14 Jakub Jelinek 2009-07-21 15:47:58 UTC
Thanks to Tomas Bzatek for providing me tarball I could reproduce it with.
This is indeed a ld bug, not glibc or prelink bug.
I've verified that prelink -u /usr/bin/gnome-panel followed by
prelink /usr/bin/gnome-panel; /usr/bin/gnome-panel still crashes, but after another
prelink -u /usr/bin/gnome-panel
if I hand edit the .dynsym section to fix up the undefined symbols and then prelink again, it works just fine.  The problem is that gnome-panel apparently takes address of strcmp in the binary (passes it to qsort or whatever else), so
the binary has
  1240: 000000000041d5f0     0 IFUNC   GLOBAL DEFAULT  UND strcmp.5 (3)
symbol in its .dynsym (SHN_UNDEF with st_value non-0 is used for the case where
non-pic binary takes address of the local PLT, the value is the PLT).  But ld incorrectly marks the PLT symbol as STT_GNU_IFUNC when it is not indirect function, but normal PLT slot, which makes the glibc dynamic linker say in LD_TRACE_PRELINKING output that the lookup is indirect and prelink creates R_X86_64_IRELATIVE relocation in .gnu.conflict for 0x41d5f0 address.

*** This bug has been marked as a duplicate of bug 512937 ***