TeamViewer 15.17.6 crash on Fedora 34

Barak Posts: 1

Recently upgraded Fedora 33 to 34 and since then TeamViewer constantly crashes with SEGV when trying to connect to it:

# coredumpctl dump

      PID: 20641 (TeamViewer)

      UID: 1000 (barak)

      GID: 1000 (barak)

    Signal: 11 (SEGV)

   Timestamp: Sun 2021-05-02 14:54:58 IDT (1min 23s ago)

 Command Line: /opt/teamviewer/tv_bin/TeamViewer

  Executable: /opt/teamviewer/tv_bin/TeamViewer

 Control Group: /user.slice/user-1000.slice/[email protected]/app.slice/app-dbus\x2d:1.2\x2dcom.teamviewer.TeamViewer.slice/dbus-:[email protected]

     Unit: [email protected]

   User Unit: dbus-:[email protected]

     Slice: user-1000.slice

   Owner UID: 1000 (barak)

    Boot ID: d4c68962d6c34c918e4a7ef40bdc162b

  Machine ID: 7725dfc225d14958a625ddaaaea5962b

   Hostname: barak

    Storage: /var/lib/systemd/coredump/core.TeamViewer.1000.d4c68962d6c34c918e4a7ef40bdc162b.20641.1619956498000000.zst (present)

   Disk Size: 9.0M

    Message: Process 20641 (TeamViewer) of user 1000 dumped core.


        Stack trace of thread 20647:

        #0 0x0000000000ea7e4e n/a (TeamViewer + 0xaa7e4e)

        #1 0x0000000000e7837a n/a (TeamViewer + 0xa7837a)

        #2 0x0000000000e74ac8 n/a (TeamViewer + 0xa74ac8)

        #3 0x0000000000e45b41 n/a (TeamViewer + 0xa45b41)

        #4 0x0000000000e45e03 n/a (TeamViewer + 0xa45e03)

        #5 0x0000000000e46174 n/a (TeamViewer + 0xa46174)

        #6 0x0000000000e46408 n/a (TeamViewer + 0xa46408)

        #7 0x0000000000e46a20 n/a (TeamViewer + 0xa46a20)

        #8 0x0000000000c1b01a n/a (TeamViewer + 0x81b01a)

        #9 0x0000000000c1c725 n/a (TeamViewer + 0x81c725)

        #10 0x0000000000c1b43d n/a (TeamViewer + 0x81b43d)

        #11 0x0000000000895661 n/a (TeamViewer + 0x495661)

        #12 0x000000000085d5b8 n/a (TeamViewer + 0x45d5b8)

        #13 0x000000000085b53e n/a (TeamViewer + 0x45b53e)

        #14 0x0000000000868121 n/a (TeamViewer + 0x468121)

        #15 0x0000000000853f3f n/a (TeamViewer + 0x453f3f)

        #16 0x0000000000853fc2 n/a (TeamViewer + 0x453fc2)

        #17 0x0000000000c573fd n/a (TeamViewer + 0x8573fd)

        #18 0x0000000000c4fecd n/a (TeamViewer + 0x84fecd)

        #19 0x00000000005501d5 n/a (TeamViewer + 0x1501d5)

        #20 0x0000000000c55ada n/a (TeamViewer + 0x855ada)

        #21 0x0000000000e3e4af n/a (TeamViewer + 0xa3e4af)

        #22 0x0000000000d4e8bb n/a (TeamViewer + 0x94e8bb)

        #23 0x0000000000d4e55f n/a (TeamViewer + 0x94e55f)

        #24 0x0000000000d4e6af n/a (TeamViewer + 0x94e6af)

        #25 0x0000000000d4eaeb n/a (TeamViewer + 0x94eaeb)

        #26 0x00000000012fdb2b n/a (TeamViewer + 0xefdb2b)

        #27 0x000000000131bfad n/a (TeamViewer + 0xf1bfad)

        #28 0x00007f9647070299 start_thread ( + 0x9299)

        #29 0x00007f9646e546a3 __clone ( + 0x1006a3)


  • domy_os
    domy_os Posts: 6 ✭✭

    I'm having the same problem. The session is running only for 15-20 seconds before TeamViewer crashes on the remote machine. Tried on Fedora 34 Cinnamon upgraded from 33 and Fedora 34 KDE fresh install (both X11 and Wayland).

    As a workaround, I have cleaned up all TeamViewer files, downgraded TeamViewer to the version 15.13.6 and it's running fine again. I have no idea what is screwed up in the new version but I don't care as long as this is working fine.

  • Rob22
    Rob22 Posts: 11 ✭✭

    Hi domy_os

    Do you know official TV repository url with older version of packages?

    I have the same problem under 'teamviewer-15.18.5-0.x86_64'.

    OP posted over month time ago. I'm afraid that TV is becoming abandonware.

  • domy_os
    domy_os Posts: 6 ✭✭
    edited June 2021

    Sorry, I have no idea about that. I keep older versions of apps locally on my PC so you can use mine, it was downloaded from the official TV website about 6 months ago.

    [The link has been removed as per the community guidelines.]

  • Rob22
    Rob22 Posts: 11 ✭✭
    edited June 2021

    I love you.

    Here are some links (remember to add https in front):

    [The links have been removed as per the community guidelines.]

    I'll check them tomorrow.

  • domy_os
    domy_os Posts: 6 ✭✭

    Thanks! I'll save them in my notes.

  • Rob22
    Rob22 Posts: 11 ✭✭

    I've done fast bisecting and:

    teamviewer-15.15.5-0.x86_64 - works

    teamviewer-15.16.8-0.x86_64 - crash

    teamviewer-15.17.6-0.x86_64 - crash

  • domy_os
    domy_os Posts: 6 ✭✭

    Maybe audio pass-through went wrong or not compatible with Pipewire?

  • Rob22
    Rob22 Posts: 11 ✭✭


    Now I'm running teamviewer_15.19.3.x86_64.rpm.

    Under client there is option: Extras / Options / Remote control / Play computer sounds and music.

    When I disable it connection is stable.

  • domy_os
    domy_os Posts: 6 ✭✭

    Nice to hear that! Anyways, I don't need remote sound so far but it's good to know that the sound implementation went wrong.

  • ajgor74
    ajgor74 Posts: 1

    I still have the same problem, connection is dropped after 30 sec , irrespectively of the the "Play computer sound" checked or unchecked; still with the lastest release 15.20.3 on Fedora34; and irrespectively of the platform I connect from (both windows, Android and Ubuntu). Moreover when the connection is dropped, the TV main window crashes: from the log file I see the daemon and main application is running and after the request for connection the TV desktop is launched; and after 20 sec of running the main application is duplicated (!) and subsequently it crash, with the error 104

    Have to rool out back again to 15.16.3

  • domy_os
    domy_os Posts: 6 ✭✭

    ajgor74, open your TeamViewer, go to Options and turn off Play computer sound BEFORE you connect to another PC. Then reopen TeamViewer and check if the option is unhooked. Finally, connect to your clients and test.

  • Naxs
    Naxs Posts: 1

    Same problem here, Fedora 34 Wayland modified systemctl to

    ExecStart=env QT_QPA_PLATFORM=xcb /opt/teamviewer/tv_bin/teamviewerd -d

    no effect, but when we disabled "play computer sounds" the connection is stable