Description of problem: This has happened in both RHEL 7.6 as well as Fedora 31. Started happening with Cinnamon Desktop (4.4), but also tested with Gnome3 (3.34) and MATE (1.22). Starting any of these desktop environments from the DM (RHEL 7.6) or LightDM display managers will start loading he desktop environment, then drop back to the display manager/login screen. Logging in as OpenBox (on RHEL 7.6) LXQt (0.14) or KDE Plasma (5.17) will load those desktops/shells with no problem. Have installed Fedora 31 on the system that used to have RHEL 7.6, so that particular test environment is not available anymore. Also, to verify this isn't an issue with my particular hardware, I copied the home directory from the primary machine (Lenovo ThinkPad P50) to another machine (Lenovo ThinkPad T430). Previously this method of copying the home directory had worked (testing a mogration from RHEL to Fedora), so it should be a comparable environment. As this happens in three desktops, I will be pasting this note to those reports as well. Version-Release number of selected component: cinnamon-session-4.4.1-1.fc31 Additional info: reporter: libreport-2.12.0 backtrace_rating: 4 cgroup: 0::/user.slice/user-1000.slice/session-7.scope cmdline: cinnamon-session --session cinnamon crash_function: match executable: /usr/bin/cinnamon-session journald_cursor: s=9f560bcd5b704e24adefe158709e8d7b;i=7856;b=81f58ca7c29144508286886819caf526;m=709bf484d;t=5a09267f6ea29;x=cc783b71d94b4d5d kernel: 5.5.8-200.fc31.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 1000 xsession_errors: Truncated backtrace: Thread no. 0 (1 frames) #0 match at pcre_exec.c:522
Created attachment 1669287 [details] File: backtrace
Created attachment 1669288 [details] File: core_backtrace
Created attachment 1669289 [details] File: cpuinfo
Created attachment 1669290 [details] File: dso_list
Created attachment 1669291 [details] File: environ
Created attachment 1669292 [details] File: exploitable
Created attachment 1669293 [details] File: limits
Created attachment 1669294 [details] File: maps
Created attachment 1669295 [details] File: mountinfo
Created attachment 1669296 [details] File: open_fds
Created attachment 1669297 [details] File: proc_pid_status
There is nothing in the backtrace to suggest it's a cinnamon or lightdm issue
The logs do not provide any clue on how the PCRE was used. Especially what was the regular expression and options passed to pcre_compile() and what options were passed to pcre_exec(). cinamon-session maintainer, if you believe the is an issue in pcre, please provides these data. Otherwise I have no reproducer and I cannot help you. A Non-truncated stack trace should show you where the pcre_exec() was called from. The backtrace shows an enormous number of recursive match() calls. It's probably caused by an ill-formed regular expression or a subject string that's prone to a stack exhaustion. Stack exhaustion is not considered as a bug by PCRE. A countermeasure is rephrasing the regular expression or setting lower PCRE recursion limit, or increasing a stack size for the running process.
(In reply to Petr Pisar from comment #13) > The logs do not provide any clue on how the PCRE was used. Especially what > was the regular expression and options passed to pcre_compile() and what > options were passed to pcre_exec(). cinamon-session maintainer, if you > believe the is an issue in pcre, please provides these data. Otherwise I > have no reproducer and I cannot help you. A Non-truncated stack trace should > show you where the pcre_exec() was called from. > I can't reproduce the issue so can't provide additional info. As far as I'm aware cinnamon doesn't use pcre.
The memory mapping shows /usr/bin/cinnamon-session as the program. E.g. /usr/bin/cinnamon-session loads /usr/lib64/libglib-2.0.so.0 and that library loads /usr/lib64/libpcre.so.1. I did not check if there other transitive dependencies on PCRE. The stack trace hints that the being matched text contains ";5;7:*.plt=38;5;7:*.pm=38;5;7:" string. That looks like a LS_COLORS environment variable content. However, my LS_COLORS variable does not contain e.g. ".plt=". Perhaps it comes from the reporter's shell profile.
(In reply to James E. LaBarre from comment #0) > Description of problem: > This has happened in both RHEL 7.6 as well as Fedora 31. Started happening > with Cinnamon Desktop (4.4), but also tested with Gnome3 (3.34) and MATE > (1.22). Starting any of these desktop environments from the DM (RHEL 7.6) > or LightDM display managers will start loading he desktop environment, then > drop back to the display manager/login screen. > > Logging in as OpenBox (on RHEL 7.6) LXQt (0.14) or KDE Plasma (5.17) will > load those desktops/shells with no problem. > > Have installed Fedora 31 on the system that used to have RHEL 7.6, so that > particular test environment is not available anymore. > > Also, to verify this isn't an issue with my particular hardware, I copied > the home directory from the primary machine (Lenovo ThinkPad P50) to another > machine (Lenovo ThinkPad T430). Previously this method of copying the home > directory had worked (testing a mogration from RHEL to Fedora), so it should > be a comparable environment. > > As this happens in three desktops, I will be pasting this note to those > reports as well. > > Version-Release number of selected component: > cinnamon-session-4.4.1-1.fc31 > > Additional info: > reporter: libreport-2.12.0 > backtrace_rating: 4 > cgroup: 0::/user.slice/user-1000.slice/session-7.scope > cmdline: cinnamon-session --session cinnamon > crash_function: match > executable: /usr/bin/cinnamon-session > journald_cursor: > s=9f560bcd5b704e24adefe158709e8d7b;i=7856;b=81f58ca7c29144508286886819caf526; > m=709bf484d;t=5a09267f6ea29;x=cc783b71d94b4d5d > kernel: 5.5.8-200.fc31.x86_64 > rootdir: / > runlevel: N 5 > type: CCpp > uid: 1000 > xsession_errors: > > Truncated backtrace: > Thread no. 0 (1 frames) > #0 match at pcre_exec.c:522 Can you log into the working session and run. gsettings set org.cinnamon.SessionManager debug true then try to log into cinnamon, then post the files as attachments. ~/.xsession-errors and ~/.xsession-errors.old also post the contents of /var/log/lightdm/ in .tar format as an attachment
Will run that later today, after a couple of upcoming calls. Also, as mentioned above, similar behavior was seen in https://bugzilla.redhat.com/show_bug.cgi?id=1812503 and https://bugzilla.redhat.com/show_bug.cgi?id=1794684, where the common factor is that they are all GTK-based environments. Whether that is relevant I couldn't say.
Created attachment 1669644 [details] .xsession-errors when starting Cinnamon Desktop
Created attachment 1669645 [details] .xsession-errors.old when starting Cinnamon Desktop
Created attachment 1669646 [details] tar of /var/log/lightdm/ after Cinnamon Desktop
Also noting; I don't have VMWare installed on this system, especially since I'm working on a different VM env, so I don't know why it would refer to "vmware-user" in the .xsession-error file (fresh install on this system, profile has never run vmware at all).
So I went through the steps I had done to migrate my profile to a fresh install, and came across the setting for customizing the colors for the "ls" command (which had been in my old .bashrc file but not the default one created by the install. Removed this and the login failure went away. https://github.com/trapd00r/LS_COLORS Hadn't changed any of it's default settings yet, so it would be whatever values the sample file has. Can't understand why a settings file for LS would mess up a login, unless it's because the variable would be large.
This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.