Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1812501 - [abrt] mate-session-manager: match(): mate-session killed by SIGSEGV
Summary: [abrt] mate-session-manager: match(): mate-session killed by SIGSEGV
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: mate-session-manager
Version: 31
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Wolfgang Ulbrich
QA Contact: Fedora Extras Quality Assurance
URL: https://retrace.fedoraproject.org/faf...
Whiteboard: abrt_hash:f9a7529747410cc531de83551ff...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-03-11 12:57 UTC by James E. LaBarre
Modified: 2020-11-24 16:13 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-24 16:13:21 UTC
Type: ---


Attachments (Terms of Use)
File: backtrace (102.98 KB, text/plain)
2020-03-11 12:57 UTC, James E. LaBarre
no flags Details
File: core_backtrace (75.75 KB, text/plain)
2020-03-11 12:57 UTC, James E. LaBarre
no flags Details
File: cpuinfo (2.47 KB, text/plain)
2020-03-11 12:57 UTC, James E. LaBarre
no flags Details
File: dso_list (6.42 KB, text/plain)
2020-03-11 12:57 UTC, James E. LaBarre
no flags Details
File: environ (12.43 KB, text/plain)
2020-03-11 12:57 UTC, James E. LaBarre
no flags Details
File: exploitable (82 bytes, text/plain)
2020-03-11 12:57 UTC, James E. LaBarre
no flags Details
File: limits (1.29 KB, text/plain)
2020-03-11 12:57 UTC, James E. LaBarre
no flags Details
File: maps (40.58 KB, text/plain)
2020-03-11 12:57 UTC, James E. LaBarre
no flags Details
File: mountinfo (2.65 KB, text/plain)
2020-03-11 12:57 UTC, James E. LaBarre
no flags Details
File: open_fds (789 bytes, text/plain)
2020-03-11 12:57 UTC, James E. LaBarre
no flags Details
File: proc_pid_status (1.33 KB, text/plain)
2020-03-11 12:57 UTC, James E. LaBarre
no flags Details

Description James E. LaBarre 2020-03-11 12:57:12 UTC
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:
mate-session-manager-1.22.3-1.fc31

Additional info:
reporter:       libreport-2.12.0
backtrace_rating: 4
cgroup:         0::/user.slice/user-1000.slice/session-11.scope
cmdline:        mate-session
crash_function: match
executable:     /usr/bin/mate-session
journald_cursor: s=9f560bcd5b704e24adefe158709e8d7b;i=8dc2;b=7dc8ca86efd44eacac4331b758e34292;m=a82b24dc;t=5a09317240607;x=9fa76c0fca499da0
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

Comment 1 James E. LaBarre 2020-03-11 12:57:19 UTC
Created attachment 1669276 [details]
File: backtrace

Comment 2 James E. LaBarre 2020-03-11 12:57:23 UTC
Created attachment 1669277 [details]
File: core_backtrace

Comment 3 James E. LaBarre 2020-03-11 12:57:27 UTC
Created attachment 1669278 [details]
File: cpuinfo

Comment 4 James E. LaBarre 2020-03-11 12:57:30 UTC
Created attachment 1669279 [details]
File: dso_list

Comment 5 James E. LaBarre 2020-03-11 12:57:33 UTC
Created attachment 1669280 [details]
File: environ

Comment 6 James E. LaBarre 2020-03-11 12:57:37 UTC
Created attachment 1669281 [details]
File: exploitable

Comment 7 James E. LaBarre 2020-03-11 12:57:38 UTC
Created attachment 1669282 [details]
File: limits

Comment 8 James E. LaBarre 2020-03-11 12:57:40 UTC
Created attachment 1669283 [details]
File: maps

Comment 9 James E. LaBarre 2020-03-11 12:57:41 UTC
Created attachment 1669284 [details]
File: mountinfo

Comment 10 James E. LaBarre 2020-03-11 12:57:42 UTC
Created attachment 1669285 [details]
File: open_fds

Comment 11 James E. LaBarre 2020-03-11 12:57:44 UTC
Created attachment 1669286 [details]
File: proc_pid_status

Comment 12 Wolfgang Ulbrich 2020-03-11 14:11:51 UTC
epel7 use MATE 1.16 (gtk2) and not 1.22.
If you run 1.22 from an unofficial copr repo for rhel7 you should file out a report there. 
It has a reason that i never updated stable 1.16 (gtk2) to a gtk3 version for rhel7.
Please use only official version from epel7 repos.
Btw. i never run into this crash with mate-1.22/24 in f30/31/32.

Comment 13 James E. LaBarre 2020-03-11 17:28:04 UTC
Sorry, I wasn't clear on that.  The versions I reported were for the Fedora 31 install.  I didn't have Mate or KDE installed on the RHEL 7.6 environment, but the login failure occurs on two different machines with Fedora 3.1 (same profile).  The profile was only ever copied one direction (P50 to T430) so it wouldn't be a matter of the T430 env contaminating the P50 (and doing this had worked before).

Comment 14 James E. LaBarre 2020-03-11 17:33:11 UTC
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.

Comment 15 Wolfgang Ulbrich 2020-03-11 19:50:25 UTC
> 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.

Which DM (desktop-manger) you mean with `DM (RHEL 7.6)` , GDM ?
Which frontend for lightdm (backend) are you using?  lightdm-gtk or slick-greeter ?
The default for MATE in fedora is using lightdm with slick-greeter.

Comment 16 Wolfgang Ulbrich 2020-03-11 19:51:37 UTC
And very important question. Does it happen with a new fresh account?

Comment 17 James E. LaBarre 2020-03-12 21:20:44 UTC
"GDM" was the display manager on RHEL 7.6. (that system, Lenovo ThinkPad P50, has been reloaded with Fedora 31)

debug data above was gathered from the P50

On both Fedora 31 systems (one being the P50 above, plus another ThinkPad, a T430) the only file in /usr/share/xgreeters/ is slick-greeter.desktop, so thatt would presumably be what it's running, as the commented-out line in /etc/lightdm/lightdm.conf for greeter-session has "#greeter-session=example-gtk-gnome" (and I didn't' set anything manually)

Comment 18 James E. LaBarre 2020-03-12 21:30:07 UTC
also, a fresh account has no problem logging in

Comment 19 Wolfgang Ulbrich 2020-03-12 22:12:31 UTC
(In reply to James E. LaBarre from comment #17)
> "GDM" was the display manager on RHEL 7.6. (that system, Lenovo ThinkPad
> P50, has been reloaded with Fedora 31)
> 
> debug data above was gathered from the P50
> 
> On both Fedora 31 systems (one being the P50 above, plus another ThinkPad, a
> T430) the only file in /usr/share/xgreeters/ is slick-greeter.desktop, so
> thatt would presumably be what it's running, as the commented-out line in
> /etc/lightdm/lightdm.conf for greeter-session has
> "#greeter-session=example-gtk-gnome" (and I didn't' set anything manually)

good, this confirmed that you're running stick-greeter.

(In reply to James E. LaBarre from comment #18)
> also, a fresh account has no problem logging in

But with your default account it failed to login?
Sounds there is something in you config of the default account which prevent you from login, or not?
Not sure how i can help you more  to find the culprit?

Comment 20 Wolfgang Ulbrich 2020-03-12 22:21:00 UTC
> good, this confirmed that you're running stick-greeter.

error, good, this confirmed that you're running slick-greeter.


wtf, that bugzilla don't allow editing comments in the 20th.

Comment 22 Wolfgang Ulbrich 2020-03-13 12:21:12 UTC
Are you using a VM and maybe qemu-kvm?
If yes, which graphic driver are you using?
During testing Fedora-MATE_Compiz-Live-x86_64-32_Beta-1.2.iso live-image i noticed a problem with virtio graphic driver, i had to switch to QXL driver for login to session.

Comment 23 James E. LaBarre 2020-03-13 19:10:57 UTC
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.

Comment 24 Ben Cotton 2020-11-03 16:27:55 UTC
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.

Comment 25 Ben Cotton 2020-11-24 16:13:21 UTC
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.


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