Bug 512078 - GNOME panel 2.27.4 crashes
GNOME panel 2.27.4 crashes
Status: CLOSED DUPLICATE of bug 512937
Product: Fedora
Classification: Fedora
Component: prelink (Show other bugs)
rawhide
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
: 512570 (view as bug list)
Depends On:
Blocks: F12Alpha/F12AlphaBlocker
  Show dependency treegraph
 
Reported: 2009-07-16 04:08 EDT by Joachim Frieben
Modified: 2009-07-21 11:47 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-21 11:47:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Output file from 'tar cjhf /tmp/gnome-panel-prelinked.tar.bz2 ...' (9.63 MB, application/octet-stream)
2009-07-21 07:51 EDT, Joachim Frieben
no flags Details

  None (edit)
Description Joachim Frieben 2009-07-16 04:08:53 EDT
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 12:31:52 EDT
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-18 21:59:22 EDT
prelink error. 
Try again after prelink --undo /usr/bin/gnome-panel
Comment 3 Tom London 2009-07-19 17:55:31 EDT
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-19 21:49:26 EDT
Moving to prelink to find out.
Comment 5 Matthias Clasen 2009-07-20 19:53:32 EDT
*** Bug 512570 has been marked as a duplicate of this bug. ***
Comment 6 Jakub Jelinek 2009-07-20 20:06:25 EDT
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-20 21:51:08 EDT
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 03:37:32 EDT
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 04:13:00 EDT
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 04:21:55 EDT
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 04:30:45 EDT
(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 07:51:13 EDT
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 08:27:20 EDT
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 11:47:58 EDT
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@GLIBC_2.2.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 ***

Note You need to log in before you can comment on or make changes to this bug.