Re: kernel traps

On 01/07/16 17:00, René J.V. Bertin wrote:
> I have thus set up my session dbus daemon to know about /opt/local
> /share/dbus-1/services (through a session-local.conf file)

If the services that you're running from that location require special
environment variables in order to work correctly (most obviously
XDG_DATA_DIRS), then your dbus-daemon won't necessarily be starting them
with those environment variables, because they aren't in *its*
environment. If they *were* in its environment, you wouldn't need
session-local.conf, because <standard-session-servicedirs/> respects
XDG_DATA_DIRS.

You haven't given any indication that I could see about what
distribution you're using, but you should probably look into how your
distribution starts graphical login sessions and whether there is a way
you can ensure that these environment variables are already set *before*
dbus-daemon comes up, for example /etc/X11/Xsession.d/ on Debian (and
its derivatives like Ubuntu), or ~/.profile and
/etc/X11/xinit/xinitrc.d/ on Red Hat derivatives.

> The problem is that I'm seeing kernel traps when I log in with /opt/local already mounted, e.g.
> 
> Jul  1 12:16:21 Bola kernel: [ 3401.015570] traps: gnome-keyring-d[12469] trap int3 ip:7faf082c0c13 sp:7ffc11645480 error:0
> Jul  1 12:16:21 Bola kernel: [ 3401.027429] traps: gvfsd-http[12468] trap int3 ip:7f2184cefc13 sp:7ffede24e260 error:0

A trap like that is usually a result of an assertion failure: GLib-based
code calls int3 on assertion failures (when built for x86) so that it's
easy to break on assertion failures in a debugger. I would recommend
getting a backtrace from the crashing processes, probably via getting a
core dump using something like corekeeper or systemd-coredump.

Without being able to look at a backtrace you won't get far with this.

> A slightly more informative log entry:
> Jul  1 11:17:39 Bola kernel: [54332.688525] gsettings[22645]: segfault at 20 ip 00007f469016ff53 sp 00007ffcde1eb848 error 6 in libgio-2.0.so.0.4002.0[7f46900bd000+16c000]

That's a different error, but the same debugging steps apply: nobody is
going to be able to help you to debug this without a backtrace.

If you were using a distribution I'd say talk to your distribution
vendor's user support channels, but by installing a stack in /opt/local
you've essentially made your own mini-distribution, so to some extent
you *are* the vendor.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>

_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus