occasional application crashes, usually at launch

[brudan]

Hello again, jggimi and friends.

I'm on OpenBSD 6.4-stable amd64. Once or twice a day (depending on how much time I spend on my laptop) an application will crash on me, usually immediately after launch. What I observe is the application's window existing for a split second, then disappearing. Re-launching the application almost always proceeds without incident. No applications are immune--it happens to GTK as well as Qt apps, in MATE as well as in LXQt--and the timing seems completely random.

Until yesterday this was just cosmetic, but yesterday it happened to an app while I was working in it (causing lost work) so I finally decided to investigate.

My installation is very basic. I just installed a desktop environment, installed my favorite applications, and enabled a handful of additional services (hotplugd, xenodm, apmd). That's it. Specifically, I have not enabled or disabled any security features.

I realize this is very little information, but was hoping that someone will recognize it and know the cause/fix. I will be happy to provide more information, and will start collecting coredumps (which up until now I've been deleting).

[jggimi]

I have only two bits of advice:

1. Consider starting the failing application from a shell. Errors and warnings sent to stderr(4) may not be logged anywhere, and certainly aren't seen, if you start applications from your graphical environment.
2. Check your userid's login class. Due to OpenBSD's restrictive resource limits -- data size, stack size, total memory, number of allowed processes, number of open files -- for the default class, graphical workstation users will have better success if they use the staff login class. You can change the class with # chpass <your.userid>. For more info on login classes, see login.conf(5).

[brudan]

Thank you for the advice, jggimi.

1. The crashes are sporadic and unpredictable, so always opening applications in the terminal (as opposed to keyboard shortcuts) is not practical. On the bright side, a lot of applications running without an associated terminal send their stdout and stderr to ~/.xsession-errors, so I'll keep an eye on that file and will also save coredumps.

2. Good thought. I'm already in the staff login class. Bummer.

jggimi, can you take a look at this link: https://www.c0ffee.net/blog/openbsd-on-a-laptop/
In the Initial Configuration section, are the changes for /etc/login.conf and /etc/sysctl.conf really needed?

[jggimi]

I find the default staff values sufficient for my workstation needs. But I'm not a "power" user from an application resource perspective.

If any of these applications leave core dumps, you may find gdb(1) or devel/gdb (the executable is /usr/local/bin/egdb) helpful for problem diagnosis.

[brudan]

I don't need a lot of resources, either. So I'll just go along with the staff settings.

They do leave core dumps. I'll keep them around next time and will poke them to see if they tell anything useful. I didn't know there was both a base system gdb(1) and ports gdb (devel/gdb). Thanks for the tip. I'll use both tools to get as much information as possible.

[brudan]

I collected some cordumps, but inspecting them didn't yield anything useful. Just the usual "Segmentation fault".

However, I did notice a pattern with the applications that crash: They are all GUI apps that I sometimes run as regular user, sometimes run as root with doas(1).

The real breakthrough came when I noticed that after running the apps with doas, I couldn't change application preferences as regular user because the owner of the configuration files in ~/.config was mysteriously changed to root.

So everything pointed to a problem with doas's environment.

After much head scratching, I found that the solution was to change my /etc/doas.conf from this:

permit nopass keepenv bruno
permit nopass keepenv root

To this:

permit nopass keepenv setenv { USER=root HOME=/root DISPLAY=:0.0 XAUTHORITY=/home/bruno/.Xauthority } bruno
permit nopass keepenv root

And restoring ownership of all files in my home directory to myself:

find /home/bruno -user root | xargs doas chown bruno

No crashes since the above changes. Also, because now the doas environment seems correct, none of the files in my home directory are mysteriously changing ownership.

P.S. The punchline is that the apps were crashing when running as regular user after running as root, because they couldn't write to their own config files.

[jggimi]

Interesting!

Glad you got the problem resolved. You may want to share your findings with the Project. Two ways I can think of: starting on informal discussion on the misc@ mailing list, or submitting a diff(1) against src/etc/examples/doas.conf to the tech@ mailing list for consideration. If the second is of any interest, time is of the essence to get the change into 6.5; the ports tree was just locked a couple of hours ago.

[brudan]

Good idea! I opted for the informal option: https://tinyurl.com/yxwehet7