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
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.
(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
(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.
(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.
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.
(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
(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
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
Is this still happening? Or can this issue be closed?
Closing due to no feedback. If this keeps happening please reopen or open a new bug report.