Teamviewer 15.37.3 Crash (GUI) after disconnect on Mint 20.1

Hi everyone :),

This message because I can't find an equivalent bug on the forum. I am under linux mint 20.1 Una, with Teamviewer 15.37.3.

Initial installation with the previous version, downloaded from the Teamviewer site. The update was performed by the update manager, from the official repository, Stable channel, from Teamviewer. My concern is that, once I have taken control of my linux workstation for the first time (from a Windows 11 workstation, in the same version 15.37.3), when I disconnect, it displays the sponsored session window, since which we can evaluate the connection, buy a license or simply click ok. As soon as I close this window (ok button, cross in the dialog box, ...), Teamviewer freezes and ends up crashing ... it seems that the service is still up but I may no longer be able to connect to my linux. when I still manage to reconnect, the interface has been relaunched.

I only found these few messages in the logs:

in le log opt/tieamviewer/logfile:

2022/12/21 17:07:24.288  871 139793991980800 S!! CMeetingControl[21]::Received_MeetingCloseStream(): participant doesn't exist: [***,***], Errorcode=11

2022/12/21 17:07:24.288  871 139793983588096 S!! CMeetingControl[21]::Received_MeetingCloseStream(): participant doesn't exist: [***,***], Errorcode=11

2022/12/21 17:07:24.315  871 139793991980800 S! Carrier[4092]::EndCarrierInternal: Discarded 2 commands, ClientID 1***, ShutdownGracefully 1, SessionType_RoutingSession

2022/12/21 17:07:48.469  871 139793991980800 S!! TcpProcessConnector::HandleRead error 104 reading from process 140836: Connection reset by peer, Errorcode=104

2022/12/21 17:07:48.470  871 139793991980800 S!! InterProcessNetwork::ProcessDisconnected(): ReadFailed session=3*** ptype=2, Errorcode=104

2022/12/21 17:07:48.470  871 139793991980800 S!! LegacyDataCmdSender[4075]::SetOnBuffersEmptyCb(): callback already set, Errorcode=104


in opt/tieamviewer/logfile/nicolas (My name lol)

2022/12/21 17:07:26.611 140836 140413327103744 GX0! XClipboard: Not selection owner (win 0x0 != 0x5a00001 || time 363084370 < 361956009)

2022/12/21 17:07:31.929 140836 140414195411840 GX0!!!Crash: stack dump has been written at '/home/nicolas/.local/share/teamviewer15/logfiles/TeamViewer_FI_15.37.3_2022-12-21-170731.amd64.stack', Errorcode=11

2022/12/21 17:07:47.063 140836 140414195411840 GX0!!!Crash: Coredump has been written at '/home/nicolas/.local/share/teamviewer15/logfiles/TeamViewer_FI_15.37.3_2022-12-21-170731.amd64.core', Errorcode=11

2022/12/21 17:07:47.063 140836 140414195411840 GX0  Process received fatal SIGSEGV

2022/12/21 17:07:48.471 141029 140697652819712 DX0  Received Control_DisconnectIPC processtype=2, reason=6 ReadFailed

2022/12/21 17:07:48.471 141029 140697652819712 DX0  Received Control_TerminateProcess

2022/12/21 17:07:48.471 141029 140697661138240 DX0  ==== Close Desktop! ====

2022/12/21 17:07:48.475 141029 140697661138240 DX0  ==== SPI state change to stopped ====

it's not completely unusable of course but it's a bit irritating

in advance, thank you very much to those who will look into this message :).

TeHoDenN.

Answers

  • ldweldon
    ldweldon Posts: 8
    edited January 2023

    I have a similar problem but I can still connect with **Third Party Product**

  • I have a similar problem, looking for a solution.

  • KenA
    KenA Posts: 2

    Yep, same here. I'm doing LinuxMint Cinnamon to LinuxMint Cinnamon connections and each time the Local GUI freezes after the session is done. Log files can be available upon request.

  • gmalsack
    gmalsack Posts: 3

    Same problem here - Linux Mint Cinnamon 21.1

  • This happens to me on Fedora when connecting to a mac

    I have 15.39.3 on fedora & 15.33.7 on mac os...

    update: I just updated the version on my mac to 15.39.5 and it fixed it...

  • Salmon1028
    Salmon1028 Posts: 1
    edited April 2023

    I have the exact same behaviour on my Ubuntu 22.04 machine (using XFCE as desktop environment) as described in the original post.

    Everything works fine, but upon closing the sponsored session popup, either by clicking the OK button or by clicking the x in the upper-right corner of the popup, the Teamviewer application stops responding. Teamviewer's window won't react to mouse clicks and you can't close it. Trying to close Teamviewer from the system tray doesn't work either.

    Only thing I can do is to log out of Ubuntu which then forcefully kills Teamviewer after 20 seconds or so.

  • TeHoDenN
    TeHoDenN Posts: 10

    Update made this morning (15.41.7) but problem still present, no positive evolution. As soon as we validate the promotional screen, when we reconnect to the workstation, teamviewer crashes after a few seconds.

    Really, is it possible to look into this problem???

    All my versions are up to date, on the Windows side (Windows 11 which connects to my Mint) and I even have Mint up to date, in version 21.1.

    Knowing that the problem is not related to the post that connects to my mint. Whatever the origin, when I'm on my mint, as soon as the commercial popup is validated, Teamviewer crashes.

  • MintPi
    MintPi Posts: 4

    Is anything being done about this? I have this problem on TV 15.41.7 using Linux Mint 21.1 Vera. Its been going on for about a year or so.

  • TeHoDenN
    TeHoDenN Posts: 10

    Version 15.42.4 and still the same concern. Honestly it's getting boring, to believe that nobody cares about this problem. Personally, I am actively starting to look for something else to connect to my pc.

  • TeHoDenN
    TeHoDenN Posts: 10

    Well, it seems that the problems encountered by Linux users are not important, so I uninstalled all my Teamviewers and switched to another solution, which was perfectly functional, on Linux and Windows. Bye everyone ;)

  • Almost September 2023, is it possible the issue is not yet fixed? Not even a reply?

  • cpsv
    cpsv Posts: 3
    edited December 2023

    I had a similar problem. TeamViewer would crash when I closed the sponsored session window.

    In response, I temporarily solved the problem by putting together a simple script with cron.

    It simply monitors TeamViewer every minute to see if it is running, and if it does not find the process, it starts it. Here is the cron configuration and shell script


    ・crontab -e

    * * * * * /home/<user>/restart_teamviewer.sh
    


    ・cat ~/restart_teamviewer.sh

    #!/bin/bash
    
    export DISPLAY=:0
    export XAUTHORITY=/home/it/.Xauthority
    
    if ! pgrep -x "TeamViewer" > /dev/null
    then
        /usr/bin/teamviewer &
    fi