Bug 244894 - x11-wm/xfce4-session: dumps core immediately after startup
Summary: x11-wm/xfce4-session: dumps core immediately after startup
Status: Closed Feedback Timeout
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-xfce (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-18 19:27 UTC by Chris Hutchinson
Modified: 2022-04-02 13:46 UTC (History)
1 user (show)

See Also:
madpilot: maintainer-feedback+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Hutchinson 2020-03-18 19:27:32 UTC
On a recent 12.1-STABLE install. I installed
the xfce meta-package, and slim. I then added
startxfce4 to my ~/.xinitrc file && bounced the
box. I was able to login via slim, starting
the xfce4 session. I then logged out, and later
restarted the computer. Afterwards I can successfully
log in, and xfce4 shows the bar at the top of the
screen, then (apparently) dies, and I'm returned
to the slim login window. Messages logged indicate
xfce4-session dumps core. Also confirmed by the
xfce4-session core file in ~/

versions:
FreeBSD 12.1-STABLE r357001 GENERIC  amd64
xorg-server-1.20.7_2,1
xfce-4.14
xfce4-session-4.14.1_1
slim-1.3.6_19

Thanks!

--Chris
Comment 1 Guido Falsi freebsd_committer freebsd_triage 2020-03-18 22:35:59 UTC
This is not an easy thing to address. I have never seen this happen and there are a bunch of possible causes.

You flagged this bug as "affects some people", do you have actual reports from other people having the same issue?

One thing that could help is if you could rebuild the xfce4-session port with debugging support. It can be done by setting WITH_DEBUG_PORTS=x11-wm/xfce4-session in the relevant make.conf in poudriere or the one in /etc for locally built ports.

With that you could extract a backtrace from the core dump which could shed some light. Without a backtrace there's really no way of knowing why it has crashed.

Are you using official binary packages? your own package set built using tools like poudriere or building ports on the live system?

Are you using any custom options?

If you are building local ports, I'd ask you to try rebuilding at least xfce4-sesion, but also others could be needed. The world has become much more complex than years ago and building ports on a live system has become an unreliable process causing strange local breakage. This sometimes can be "fixed" by rebuilding the right part.

ANother thing that comes to my mind is you say you're using slim. slim is an unmaintained software and has seen no development for years, in the while the Xorg world has gone forward and things have really changed in the session management world.

I'd ask you to test using a modern display manager light LightDM and see if the issue happens with that too.

I hope these pointers can give you ideas on how to diagnose the issue.
Comment 2 Chris Hutchinson 2020-03-18 23:10:49 UTC
(In reply to Guido Falsi from comment #1)
Thanks for the reply, Guido!
I've not been a fan of using pkg. But felt it might be
time to give it another chance. So *everything* is straight
from FreeBSD. That is; the kernel, and world are that which
came from the install medium, and everything else is straight
from pkg(8).
pkg install xorg-server xorg-fonts xorg-drivers xorg-apps \
xfce-4 slim drm-legacy-kmod
echo startxfce4 >~/.xinitrc
echo 'kld_list="/boot/modules/i915kms.ko'>>/etc/rc.conf
make.conf(5) is empty

bounce the box. which brings up the slim logon screen.
login. xfce4 starts. I confirm that it works. I bounce
the box again. login via slim. xfce4 starts. the moment
the desktop appears, the screen goes black, then slim
login screen reappears. I try again. Same sequence of events.
Ctrl+Alt+F1
login
kill -HUP <slim-pid-number>
check any associated log files. messages indicates xfce4-session
dumps core on signal 11.
Delete *all* ports via pkg. confirm I have zero ports installed.
Only package left is pkg. Install all ports as above. But no joy.
xfce4-session *still* dumps core.
So. I decided to test against slim;
pkg install icewm
echo icewm-session>~/.xinitrc
bounce box
login via slim. Which presents the IceWM desktop. Everything
works fine. IceWM still works. So I think we can rule out slim.
I have no ports(7) or source tree on this box. Are you suggesting
that I build everything from source? Is there no flag I can
append to xfce4-session that might make more noise in the log(s)
and perhaps provide more clues?

Thanks again for the reply, Guido!

--Chris
Comment 3 Guido Falsi freebsd_committer freebsd_triage 2020-03-18 23:50:02 UTC
(In reply to Chris Hutchinson from comment #2)

> I've not been a fan of using pkg. But felt it might be
> time to give it another chance. So *everything* is straight
> from FreeBSD. That is; the kernel, and world are that which
> came from the install medium, and everything else is straight
> from pkg(8).

SO I guess you're using packages from the quarterly set. One test worth a try would be to upgrade to the latest package set and check if the bug still happens.

> So. I decided to test against slim;
> pkg install icewm
> echo icewm-session>~/.xinitrc
> bounce box
> login via slim. Which presents the IceWM desktop. Everything
> works fine. IceWM still works. So I think we can rule out slim.

This is not completely true.

If xfce4-session dumps core it's probable it has a bug somewhere, but this bug could be triggered by slim, and not triggered by another display manager. So while your test proves that slim does it's job for IceWM it does not prove that slim is not doing something wrong which upsets xfce4-session.

Please try with another display manager.

I can try making a test with a setup similar to yours in a virtual machine, but even if I can reproduce your bug I'm not an xfce4 developer. I'd suggest you file a bug report upstream, but then again without a backtrace of the crash they can do very little. Understanding what is going wrong without a backtrace is like divination.


> I have no ports(7) or source tree on this box. Are you suggesting
> that I build everything from source? Is there no flag I can
> append to xfce4-session that might make more noise in the log(s)
> and perhaps provide more clues?

If you want to extract some backtrace information which could at least indicate in which part of the code xfce-session is crashing there is no other option than building it with debug enabled. I can try to reproduce your bug and in that case build with debugging enabled and test that. But it will require time, at least some days, providing I can reproduce the bug.

And no, I don't know of any special flag, in fact I know relatively little about xfce4-session, of which I'm just a user actually.
Comment 4 Guido Falsi freebsd_committer freebsd_triage 2020-03-18 23:57:52 UTC
(In reply to Chris Hutchinson from comment #2)

I now really notice this is happening on every second login.

Are you doing some kind of setup of xfce? Maybe you are enabling some xfce component or other x11 program  which is causing problem I start thinking about some more complex interaction.

To make sure I understand. Your first xfce login works and all the ones after that fail, even after a reboot. Correct?

Looks like something gets into your xfce configuration that causes the crash.

Another idea, which locale are you using? Could be a locale related bug. Such a bug would need reporting upstream, if identified correctly.
Comment 5 Guido Falsi freebsd_committer freebsd_triage 2020-03-19 00:20:14 UTC
I now remembered another thing about slim and xfce. I'm not sure since I stopped using slim some time ago but could you try using:

startxfce4 --with-ck-launch

in your .xinitrc?

I remember something about slim not properly setting up the session and this workaround being required.

It should not crash anyway, but the thing could be related.
Comment 6 Chris Hutchinson 2020-03-19 00:22:10 UTC
(In reply to Guido Falsi from comment #4)
Hello. Right you are!
I've been trying to ferret out some clues as to
what the underlying cause may be. So after a failed
session (xfce4-session core dump), which is *always*
the second attempt to login. I delete all xfce4 related
articles from ~/.cache/ && ~/.config/, and lo everything
works again! After even further investigation. I have
been able to get the Desktop, and related icons upon
the second login. I am also able to right-click on the
Desktop to perform additional operations. But Panel
is *not* functioning, and it appears that it is due to
compositor.
I'm going to now take your advise, and try all of this
with lightdm.

I'll report back shortly.

Thanks for all your time, and consideration, Guido!

--Chris
Comment 7 Chris Hutchinson 2020-03-19 00:24:01 UTC
(In reply to Guido Falsi from comment #5)
My last reply crashed into *your* last comment.
I'll *first* try with your suggestion, before
moving on to lightdm.

Thanks!

--Chris
Comment 8 Chris Hutchinson 2020-03-19 00:32:55 UTC
OK
startxfce4 --with-ck-launch
didn't work (no difference). I'm almost positive
it's related to the compositor. I'll need to get
some clues on the mailing list, before I can move
forward on this. So I'll report back regardless.

Thank you very much for all your time on this, Guido!

--Chris
Comment 9 Guido Falsi freebsd_committer freebsd_triage 2022-03-05 16:04:04 UTC
Is this still happening? Or can this issue be closed?
Comment 10 Guido Falsi freebsd_committer freebsd_triage 2022-04-02 13:46:36 UTC
Closing due to no feedback.

If this keeps happening please reopen or open a new bug report.