Bug 241219 - x11-wm/xfce4-wm: XFCE Screensavers Causes User Forced Reboots After FreeBSD Update
Summary: x11-wm/xfce4-wm: XFCE Screensavers Causes User Forced Reboots After FreeBSD U...
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-xfce (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-12 20:19 UTC by John
Modified: 2020-09-13 02:08 UTC (History)
2 users (show)

See Also:
madpilot: maintainer-feedback+


Attachments
Console when system was booted days prior to 12 October 2019 14:45+000 FreeBSD Upgrade and the Upgrade Leading to Bug (468.02 KB, text/plain)
2019-10-12 20:19 UTC, John
no flags Details
System information with no active screensaver yet XFCE screen blanks with no keyboard or mouse response to restore display of XFCE DE resulting in forcing a system reboot (387.55 KB, text/plain)
2019-10-13 20:19 UTC, John
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description John 2019-10-12 20:19:13 UTC
Created attachment 208272 [details]
Console when system was booted days prior to 12 October 2019 14:45+000 FreeBSD Upgrade and the Upgrade Leading to Bug

I have logged this issue against x11-wm/xfce4-wm as it is the only package that was in the "pkg upgrade" 12 October 2019 14:58+000 UTC that I can guess as the package causing the bug.  If this is an incorrect guess for ports package as cause then for certain the bug "Summary" will need to be changed to reflect the ports package causing the issue once confirmed as the source of the bug.

Since doing a FreeBSD "pkg upgrade" 12 October 2019 14:58+000 UTC both x11/xfce4-screensaver and x11/xscreensaver fail in exact same manner resulting in user having to force a system reboot or power cycle the system.

The last 'pkg upgrade" done was 02 October 2019 0326+000 UTC where both x11/xfce4-screensaver and x11/xscreensaver behaved as expected.

The bug is identical for both x11/xfce4-screensaver and x11/xscreensaver.  The bug is when either screensaver activates to black screen (current configurations for both) neither mouse nor keyboard activity results in the dialog box appearing asking for user password to unlock the screen.  Both have been extensively tested and always fail exactly as described.
Comment 1 John 2019-10-12 20:22:17 UTC
One possible consideration for cause of this bug is via the 12 October 2019 14:58+000 UTC "pkg upgrade" is:

xorg-libraries-7.7_4 (direct dependency changed: libXScrnSaver)
Comment 2 Guido Falsi freebsd_committer freebsd_triage 2019-10-13 08:25:14 UTC
Hi, I'm not sure I understand your description of the issue.

It looks very similar to bug #240804.

You say "(current configurations for both)" what does this mean? That both are enabled at the same time in XFCE? this cannot work, you need to enable only one.

Also you say that you performed pkg upgrade on 12 October 2019 14:58+000 UTC and x11-wm/xfce4-wm was the only package updated, but later you state also xorg-libraries-7.7_4 was upgraded. So what really happened?

Also, while I know this is no solution, rebooting looks overkill, I think killing the screensaver process as root should unlock your session (although I have not tested it so I could be wrong), you can do this by going to a virtual terminal with ctrl-alt-1 or also connecting via ssh .

Just to be on the safe side, since you keep experiencing this issue, have you tested forcing reinstallation of all the affected packages with fresh ones?

For all I mean at least all of XFCE, Xorg libraries, xscreensaver.

Finally you have provided a wealth of information in your console output, but I could not find a list pf running processes (output of ps(1)) in there, created while the bug is happening, that is, while the screen is locked and you're unable to unlock it. That could at least make it clear if one or both screensavers are running.
Comment 3 Guido Falsi freebsd_committer freebsd_triage 2019-10-13 08:49:59 UTC
In detail what could be useful is simply the output of:

ps -ax | grep -i saver


thanks.
Comment 4 John 2019-10-13 14:42:26 UTC
(In reply to Guido Falsi from comment #2)

This bug is not the same as bug #240804.

This bug is not when both screensavers x11/xfce4-screensaver and x11/xscreensaver are active.  I did state "The bug is identical for both x11/xfce4-screensaver and x11/xscreensaver.  I needed to determine if the issue was  x11/xfce4-screensaver or x11/xscreensaver, therefore I had to test both  x11/xfce4-screensaver and x11/xscreensaver to determine if (I was not expecting) both to fail, let alone fail exactly the same way.

I did state "both x11/xfce4-screensaver and x11/xscreensaver fail in exact same manner".  That means they failed in exact same manner and does not mean both screensavers were running at same time.

The bug is when either screensaver ..." I should know both screensavers cannot be active as I was the one that reported bug #240804.

At time of this bug and for few weeks I had only the x11/xfce4-screensaver configured to run at XFCE startup.  I checked a few times via a forced reboot that the bug would still occur with x11/xfce4-screensaver still enabled.  Once that was confirmed, I would disable x11/xfce4-screensaver and then enable x11/xscreensaver.  To my surprise the exact same bug occurred.  This likely meant the bug was not x11/xfce4-screensaver or x11/xscreensaver.  I have been running the system since with both x11/xfce4-screensaver and x11/xscreensaver disabled and as expected no issue as no screensaver is enabled.

I did not state "you say that you performed pkg upgrade on 12 October 2019 14:58+000 UTC and x11-wm/xfce4-wm was the only package updated".  I did state:

"I have logged this issue against x11-wm/xfce4-wm as it is the only package that was in the 'pkg upgrade' 12 October 2019 14:58+000 UTC that I can guess as the package causing the bug."

The key point here I am stating I do not know the package that may be the cause of this bug and why I chose the ports package I did to report the bug.

You state "later you state also xorg-libraries-7.7_4 was upgraded. So what really happened?"  What I stated was:

"One possible consideration for cause of this bug is via the 12 October 2019 14:58+000 UTC "pkg upgrade" is:

xorg-libraries-7.7_4 (direct dependency changed: libXScrnSaver)"

I was trying to suggest a port as possible cause to the bug instead of my guess that x11-wm/xfce4-wm is the source of the bug.  

You will note I have referred to the same "pkg upgrade" in all of the references to the update that caused this bug.  That being the 12 October 2019 14:45+000 FreeBSD Upgrade.  The attached file for the bug shows the packages and versions installed prior to the 12 October 2019 14:45+000 FreeBSD Upgrade, The details of the 12 October 2019 14:45+000 FreeBSD Upgrade that occurred, and other information I cause my system to generate automatically when starting terminal session.

I should not have to:

"Just to be on the safe side, since you keep experiencing this issue, have you tested forcing reinstallation of all the affected packages with fresh ones?

For all I mean at least all of XFCE, Xorg libraries, xscreensaver."

Clearly there is a bug.  Clearly something is wrong.  The bug of what is wrong and why bug occurred after the packages updated, installed and reinstalled from the 12 October 2019 14:45+000 FreeBSD Upgrade is the bug at hand.
Comment 5 John 2019-10-13 14:53:33 UTC
(In reply to Guido Falsi from comment #3)

I do not need to provide output from "ps -ax | grep -i saver".  I know only one screensaver was running at any given time.  I have stated which screensaver was initially running and just fine prior to this bug.  I also stated only one screensaver was running at time of bug and there was no screensaver issue prior to the upgrade of 12 October 2019 14:58+000 UTC.  I also stated how I tested both screensavers x11/xfce4-screensaver and x11/xscreensaver ensuring only one screensaver was running at time and ensuring a clean slate by rebooting and not just killing process and starting a new/different screensaver process that may leave artifacts that could either cause the same bug to occur when otherwise would not or cause a different bug that would otherwise not occur when staring system with a clean slate.

One has to test from known reference point.  This is why the first thing I did was reboot the system after the upgrade.  There are key libraries that were upgraded which means all kinds of mismatched structures/offsets and similar that can result with such core system and/or DE libraries upgraded unless the system is rebooted after such key core libraries are upgraded.
Comment 6 Guido Falsi freebsd_committer freebsd_triage 2019-10-13 15:56:22 UTC
(In reply to John from comment #4)

> This bug is not the same as bug #240804.

I did not say it is the same, only that it looks very similar.

There is clearly some language barrier between me and you. I'm not a native English speaker, so sometimes I could misunderstand you or not express myself clearly in English. Please try to give me some leeway.

I'm trying to help you, but we need to cooperate, I'm not saying the bug does not exist and never thought it, so no need to be defensive about this.

> Clearly there is a bug.  Clearly something is wrong.  The bug of what
> is wrong and why bug occurred after the packages updated, installed
> and reinstalled from the 12 October 2019 14:45+000 FreeBSD Upgrade is
> the bug at hand.

I agree there is something broken after the upgrade. But I don't know what and the information you provided is not shedding light for me.

I use the term "issue" and "something broken" to generally describe unexpected ot unwanted behaviour.

The word bug, to me, means a programming error in some software, in the source code. For reasons I will explain shortly while we are evidently seeing an unwanted behaviour I cannot be sure such a behaviour is caused by a software bug. I need you to perform some tests to try to understand the cause of this unwanted behaviour.

I have tried to reproduce the issue on my system but I could not.

This reply of yours gave me new information I could not gather from your previous message, that the issue appears with any of the two screensavers in isolation, this makes it even more improbable that the problem is caused by a single bug. it's quite improbable for the same programming error causing the same broken behaviour to be present in two separate projects developed by different people.

Now, about the tests, I asked you to reinstall a bunch of software because my previous experience with FreeBSD ports (and also with software on other OSes) has shown that in the life of a system with the periodic updating of software, which causes updating of libraries without updating the software depending on them sometime misalignments happen. In some cases new library versions have slight incompatibilities or internal structures change that software inappropriately access directly or other such things.

When this happens strange problems show up which are difficult to diagnose and are not really bugs but problems which show up on specific PCs and nowhere else and can only be solved by reinstalling the right piece of software, but that's not easy to guess.

You issue looks to me like a possible case of misalignment brought by incremental updates with time, so I'm kindly asking you, as a test, to try reinstalling the libraries on which xscreensaver an xfce4-screensaver depend on and see if the problem just goes away.

(In reply to John from comment #5)


While the specific output from ps I asked for may not be needed, it was a very fast thing to do, as I said I have no idea what is causing your issue, I've not been able to reproduce it, I'm trying to gather information, and since I'm not infallible I also can make mistakes in the process.

Anyway, while I generally agree that testing should start from known reference point unluckily debugging issues on a live system is not pure science, and it's quite difficult to get a known reference point.

That's also why I'm asking you to try reinstalling some packages, to be sure we are using a coherent set of libraries and binaries, because that could not be the case on a system which has been getting incremental updates over time.
Comment 7 John 2019-10-13 19:05:51 UTC
(In reply to Guido Falsi from comment #6)

I am not being defensive.  I am trying to ensure facts as stated without having to cover all the possibilities covered in validating the bug as a bug. You have implied in manner you reply that the facts were not as stated or such.  That then forces me to repeat what I have stated and state more than I need to state for the bug in order to keep the issue focused.

I do not write code for XFCE nor do FreeBSD packaging. That said if something is wrong with packaging of the port, or related port, or with change management, or configuration files, documentation, et al then these and similar are bugs and not issues.  Issues are about matters where the current behaviour of something that is working as intended wishes to be changed in some manner.  Unwanted or unexpected behaviour can be a bug or an issue depending on context of if intended behaviour or not intended behaviour.

It is not a correct assumption to make that there is more than one bug simply because in this bug instance the same incorrect symptoms occur.  The very nature of the screensaver function implies there may be common code both of these screensavers use, such as a library, that may be where the bug is. For example the suggestion as a possible port for cause of the bug may be x11/xorg-libraries because the upgrade indicated "(direct dependency changed: libXScrnSaver)" which means that x11/libXScrnSaver may be the source of the bug.  I do not know where the bug is, let alone if code, packaging, configuration, et al.

Reinstalling various packages to see if the bug goes away is not an approach to solving the bug.  All that does is allow the bug to persist and perhaps get worse in doing so.  Reinstalling can itself cause new or worse bug, that by rights should not occur.  They do and often due to underlying bugs not being addressed that start to compound the bugs on top of bugs.  Added to this due to how packages are created and made reinstalling is not the same as when installing base packages initially.  That means there is a much wider scope of indirect packages in scope that is makes the idea of reinstalling a major issue as that may compound and mask the current bug as a result of other unknown and unrelated bugs.

I understand you do not have enough information to identify the bug.  I understand "new library versions have slight incompatibilities or internal structures change that software inappropriately access directly or other such things".  I believe I indicated this in my last reply comment #4.   I have been in that situation many times professionally of not enough information to identify a bug and have to find the bug even when engineering or development teams says there is no bug once I have identified and duplicated the bug more times than you can imagine.

The ps command you asked to be down would not show anything related to the screensavers running as first I know and only had one enabled.  Second I disabled both screensavers so my system does not lock me out forcing me to reboot or power cycle the system.

The "issue looks to me like a possible case of misalignment brought by incremental updates with time" may be the cause of the bug, or as all too often occurs there is a difference between the environment the test is being attempted on vs the system that has the problem.  Again, I have been there many many times professionally.  The task is to find the difference which tends to lead to being able to duplicate the bug.  Again I have been there professionally many many times and an area I am very good at.  I have often never been able to test on the live system to figure out if the firmware and/or OS are the cause of the bug as often these are many miles or many km away.  So I have to figure out how to find the information I need to duplicate the bug using my skills, knowledge and creative approaches.

This bug has a known reference point.  The state when the system is booted and only the XFCE DE is started (in my case via CLI startx) and just leave the XFCE desktop as started to sit until one of the two screensavers takes effect.  That will be the same no matter which screen saver or no screensaver is active.  That is consistent and same and for now no FreeBSD updates will be done until this bug is resolved.

If there is a missing element of packaging that means there is a difference in version of library or such then that needs to be identified. I already know, but have not reported yet, there are a few other packaging problems that result in applications not working that have no relationship to this bug at all.  There are at least three bugs of this type outstanding for me to log still.  If there is a library that is not at the right version as source of this issue then that needs to be identified as that means likely means there is a missing dependency in the packaging, ergo bug in the packaging.
Comment 8 Guido Falsi freebsd_committer freebsd_triage 2019-10-13 19:32:07 UTC
(In reply to John from comment #7)

While I can agree with much of what you wrote, all this lecturing is not going to help fix the bug or gather more information.

I have already accepted that the ps command would have not helped, and stated I can make mistakes.

I have no specific knowledge about libXScrnSaver, and can't help much with that, except suggesting you to revert to a previous version.

With present information I have no idea how to help with the problem you describe.

If the issue is happening only on one single machine it could well be a problem with that single machine (with many possible factors, misalignment of libraries, misconfiguration, etc.).

If you have more than one machine showing the issue that could be a stronger indication an actual software bug.

In this respect the suggestion to try reinstalling libraries is a request for a test which would clear out some of these problems that can show up on a single installation and make such unreproducible bugs show up.

If you are unwilling to perform this test (I don't care who is right and wrong) I have no further ideas and can't add much to this conversation.

I can only suggest you furtheer investigate the issue whatever way you see fit and try to gather more information so that someone (me included, since I will look at new information and act  on it if I can) can understand the problem and help you.
Comment 9 John 2019-10-13 20:17:17 UTC
This bug is much worse than I was assuming.  I had to be away from the system for 30+ minutes and when I returned the screen was blank with no response to keyboard nor mouse.  I had to do a forced reboot.  There was no screen saver running prior and I have crossed checked since rebooting the system, XFCE, and and "ps -ALF" no screensaver is shown as running.  Something is trigging the screensaver or something is blanking the XFCE desktop such that the keyboard and mouse do not allow either to wake the XFCE desktop up from what is clearly a screensaver like event based on the timeouts of the screensavers when either screensaver was active.  This is beginning to look like a ghost screensaver is some manner is running, but not as a process name one would see a a screensaver.  Again this is only started to occur since the pkg upgrade' 12 October 2019 14:58+000 UTC.  The 'pkg upgrade' of 02 October 2019 03:26+000 UTC that included updates to the  x11/xfce4-screensaver and x11/xscreensaver ports did not cause any change in the XFCE screensaver prior to the 'pkg upgrade" 02 October 2019 03:26+000 UTC.

This is a more serious problem than was thought and I never thought I need to test the system for a screensaver like behaviour after disabling both x11/xfce4-screensaver and x11/xscreensaver in the XFCE Settings Startup that also shows neither is running.
Comment 10 John 2019-10-13 20:19:54 UTC
Created attachment 208286 [details]
System information with no active screensaver yet XFCE screen blanks with no keyboard or mouse response to restore display of XFCE DE resulting in forcing a system reboot

System information via CLI showing no active screensaver yet XFCE screen blanks with no keyboard or mouse response to restore display of XFCE DE.  This results in user forcing a system reboot.
Comment 11 John 2019-10-13 20:25:19 UTC
2019-10-13 20:22:33+0000 UTC 1570998153 h440nndytpo3mqsdvcmtoeu3tppdnchwt85snd.h440nndytpo3mqsdvcmtoeu3tppdnchwt85snd 0 ~ $ date ; sudo pkg install libXScrnSaver
Sun Oct 13 20:24:32 UTC 2019
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The most recent versions of packages are already installed
2019-10-13 20:24:33+0000 UTC 1570998273 h440nndytpo3mqsdvcmtoeu3tppdnchwt85snd.h440nndytpo3mqsdvcmtoeu3tppdnchwt85snd 0 ~ $
Comment 12 Guido Falsi freebsd_committer freebsd_triage 2019-10-13 20:33:17 UTC
(In reply to John from comment #10)

The XFCE power manager can also blank the display or put it to sleep/stdby/off after a delay.

You should check under Settings - Power Manager.

First off I'd try disabling the functionality.

I am unable to tell if your system is not detecting the keyboard/mouse input, or it is detecting it and is unable to wake up the display, both options are possible.

If you are able to switch to VTY with crtl-alt-f1 I'd say the second option is the most probable.
Comment 13 Guido Falsi freebsd_committer freebsd_triage 2019-10-13 20:37:46 UTC
(In reply to Guido Falsi from comment #12)

I'd add that, based on the information you posted, you're using a laptop system.

It's not unheard of for laptop systems to have non standard displays which don't act as expected to ACPI and DPMS signaling.

But I admit this is a shot in the dark.
Comment 14 John 2019-10-14 21:39:41 UTC
(In reply to Guido Falsi from comment #13)
 From the moment I installed FreeBSD 11.3 in mid July 2019 until now other than the bug #240804, which as a software bug and not a laptop issue, both screensavers x11/xfce4-screensaver and x11/xscreensaver have worked just fine.  That means there is no issue with this laptop with respect to ACPI and screen saver, blanking, and power off display issues.  That very strongly suggests this issue is not an issue for this laptop.
Comment 15 John 2019-10-14 21:51:20 UTC
(In reply to Guido Falsi from comment #12)
I believe this bug may be related to x11/libXScrnSaver and not x11-wm/xfce4-wm based on extensive testing I have done thus far.  I have more testing to do to validate that x11/libXScrnSaver is a strong possibility of being source of this bug rather than x11/libXScrnSaver.

A number of other bugs have started showing up with XFCE. I am suspect these are related to a larger bug than the bug I suspect is at the root of the x11/libXScrnSaver bug.  Sadly I have seen this sort of bug repeated a few times since August 2019 with different and unrelated to XFCE which suggests there is a larger set of bugs affecting FreeBSD specifically.

The testing is very time consuming.  There are a number of combinations that need to be tested. So far the results are interesting to say the least.
Comment 16 John 2019-10-15 00:07:50 UTC
I have not completed the intended testing as there are new multiple bugs showing up and variations on the tests for this bug I have been doing for two days now.  It is the new and variations of this bug that are evolving into longer and more complex test results and combinations. 

This bug and the many other new bugs and variations since doing the "pkg upgrade" 12 October 2019 14:58+000 UTC are occurring that never occurred before with XFCE prior to the 'pkg upgrade' 12 October 2019 14:58+000 UTC since installing FreeBSD mid July 2019.  I believe this bug needs a different ports audience for what I suspect this, and other instances of similar bugs of lessor scope of impact, needs a discussion.  I have some thoughts as to possible causes, but I like to suggest some approaches that may help in being able to duplicate the bugs which would enable finding root causes and solutions.
Comment 17 John 2019-10-15 00:42:57 UTC
Some examples of additional bugs now occurring is random when XFCE "Suspend" "Shutdown", "Restart" become greyed out.  VTTY switching will stop working at random times or take several minutes to effect with no sense of additional CPU loading as factor resulting in blank screens.  This is just the tip of the bugs and random nature of when bugs will occur.  Another factor in the cause and effect of this is how many web pages are loaded active in web browser, and how many times switch to VTTY and how many times have to repeat key sequence for a specific VTTY.
Comment 18 John 2019-10-15 00:46:29 UTC
Another clearly obvious side effect of the "pkg upgrade" of 12 October 2019 14:58+000 UTC is XFCE now takes 45 seconds to present the XFCE DE from time enter startx whereas prior to the update and since installing FreeBSD mid July 2019 this was 20 seconds.
Comment 19 John 2020-09-13 02:08:56 UTC
This bug is still ongoing despite number of times XFCE, xscreensaver, xfce screensaver have been updated to date.  FreeBSD system is current of 08 September 202 and "pkg update" as of this bug update still indicated system is up to date 9since 08 September 2020)"