Bug 1793609 - glibc 2.30-10 causing Steam to fail to start
Summary: glibc 2.30-10 causing Steam to fail to start
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 31
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Carlos O'Donell
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-01-21 16:44 UTC by bojego6142
Modified: 2023-09-14 05:50 UTC (History)
11 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2020-01-21 19:03:53 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description bojego6142 2020-01-21 16:44:37 UTC
Description of problem: Update newly pushed out version 2.30-10 from 2.30-8 the previous available version and Steam fails to start.


Version-Release number of selected component (if applicable): 2.30-10


Steps to Reproduce:
1. Install it
2. Try to start Steam

(downgrade and Steam starts again)


Expected results: Steam should start

Comment 1 Florian Weimer 2020-01-21 16:46:04 UTC
Would you please provide more information what actually fails?  Are there any diagnostics in log files?

Comment 2 bojego6142 2020-01-21 16:51:32 UTC
$ steam
...
/home/user/.local/share/Steam/steam.sh: line 722:  6890 Segmentation fault      (core dumped) $STEAM_DEBUGGER "$STEAMROOT/$STEAMEXEPATH" "$@"

I'm not finding much, sorry. Its just royally borked.

Comment 3 Florian Weimer 2020-01-21 16:53:29 UTC
Can you see with coredumpctl if there is a captured backtrace?

Or try to launch steam with STEAM_DEBUGGER="gdb --args"?

Comment 4 bojego6142 2020-01-21 17:05:54 UTC
How about this?

$ coredumpctl info 6890
           PID: 6890 (steam)
           UID: 1000 (user)
           GID: 1000 (user)
        Signal: 11 (SEGV)
     Timestamp: Tue 2020-01-21 11:47:35 EST (14min ago)
  Command Line: /home/user/.local/share/Steam/ubuntu12_32/steam
    Executable: /home/user/.local/share/Steam/ubuntu12_32/steam
 Control Group: /user.slice/user-1000.slice/user/gnome-terminal-server.service
          Unit: user
     User Unit: gnome-terminal-server.service
         Slice: user-1000.slice
     Owner UID: 1000 (user)
       Boot ID: f4d0fde2b6a140838fe86e1b318a970c
    Machine ID: 1e91241c041641b18760af07ad5c563d
      Hostname: localhost-localdomain
       Storage: /var/lib/systemd/coredump/core.steam.1000.f4d0fde2b6a140838fe86e1b318a970c.6890.1579625255000000000000.lz4
       Message: Process 6890 (steam) of user 1000 dumped core.
                
                Stack trace of thread 6890:
                #0  0x00000000f7fd461e do_lookup_x (ld-linux.so.2)
                #1  0x00000000f7fd50cd _dl_lookup_symbol_x (ld-linux.so.2)
                #2  0x00000000f7af11e0 _dl_vdso_vsym (libc.so.6)
                #3  0x00000000f7a68690 time (libc.so.6)
                #4  0x00000000f7fd71da _dl_relocate_object (ld-linux.so.2)
                #5  0x00000000f7fce0c5 dl_main (ld-linux.so.2)
                #6  0x00000000f7fe4339 _dl_sysdep_start (ld-linux.so.2)
                #7  0x00000000f7fcbfc5 _dl_start (ld-linux.so.2)
                #8  0x00000000f7fcb13b _start (ld-linux.so.2)

Comment 5 Florian Weimer 2020-01-21 18:12:40 UTC
Is it possible that the program is invoked with an outdated version of the dynamic linker, but with a newer copy of libc.so.6 (or vice versa)?

If you run

  coredumpctl info 6890

and then enter

  info sharedlibrary

at the GDB prompt, that might shed some light on this issue.

Comment 6 bojego6142 2020-01-21 18:55:48 UTC
I'm not very familiar with gdb debugger but maybe this is what you're looking for?

(gdb) info sharedlibrary
From        To          Syms Read   Shared Object Library
0xf7fd3110  0xf7ff00d3  Yes (*)     /lib/ld-linux.so.2
0xf7e58300  0xf7ee6448  No          /usr/lib/wine/libX11.so.6
0xf7e38780  0xf7e3c398  No          /usr/lib/wine/librt.so.1
0xf7e31280  0xf7e323c8  No          /usr/lib/wine/libdl.so.2
0xf7cb6060  0xf7dc1a58  No          /usr/lib/wine/libstdc++.so.6
0xf7c1cb90  0xf7c2d618  No          /usr/lib/wine/libpthread.so.0
0xf7b501c0  0xf7bdd097  No          /usr/lib/wine/libm.so.6
0xf79b0190  0xf7ad7089  No          /usr/lib/wine/libc.so.6
0xf796eda0  0xf79845c8  No          /usr/lib/wine/libxcb.so.1
0xf79485e0  0xf795c24d  No          /usr/lib/wine/libgcc_s.so.1
0xf79413e0  0xf79421c8  No          /usr/lib/wine/libXau.so.6

Comment 7 bojego6142 2020-01-21 19:03:00 UTC
That did it. I removed Wine and Steam works now with glibc 2.30-10. Interesting to see that they conflict.

Thanks for your help. It got it resolved to an extent =)

Comment 8 Florian Weimer 2020-01-21 19:03:53 UTC
I'm not familiar with Wine, but this looks like a problem specific to your system. If /usr/lib/wine/libc.so.6 is an outdated copy of /usr/lib/libc.so.6, this is likely the source of the problem. These files should only exist in /usr/lib, not in /usr/lib/wine.

Comment 9 bojego6142 2020-01-21 19:12:13 UTC
Yeah, I wiped out /usr/lib/wine and re-installed - both work now. Don't see libc.so.6 there anymore so something must have put it there at some point. Weird.

Comment 10 Red Hat Bugzilla 2023-09-14 05:50:27 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days


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