I'm using systemd --user rather heavily to manage my processes. Since I updated from 208 to 210 on Arch Linux, I experience sporadic segfaults on the user instance, which I can't reproduce for now, only wait for it to happen again. From a coredump and an unstripped binary compiled a posteriory, I managed get a partial stack trace, which I attach below. I'm not certain why there is still missing debug data... Is there anything else I can get from that coredump? Core was generated by `/usr/lib/systemd/systemd --user'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000000000048101e in get_user_creds (username=0x251b2f0, uid=0x3dd, gid=0x7fffa11d002f, home=0x0, shell=0x7fffa11dec10) at src/shared/util.c:4217 4217 if (p) (gdb) bt full #0 0x000000000048101e in get_user_creds (username=0x251b2f0, uid=0x3dd, gid=0x7fffa11d002f, home=0x0, shell=0x7fffa11dec10) at src/shared/util.c:4217 p = 0x0 u = 0 __PRETTY_FUNCTION__ = "get_user_creds" __PRETTY_FUNCTION__ = "get_user_creds" #1 0x00007fffa11dec10 in ?? () No symbol table info available. #2 0x00007fffa11dec10 in ?? () No symbol table info available. #3 0x0000000000000010 in ?? () No symbol table info available. #4 0x000000000248d1b0 in ?? () No symbol table info available. #5 0x000000000042322c in socket_add_default_dependencies (s=0x0) at src/core/socket.c:286 r = <optimized out> #6 socket_add_extras (s=0x0) at src/core/socket.c:356 u = 0x0 r = <optimized out> __PRETTY_FUNCTION__ = "socket_add_extras" #7 socket_load.9848 (u=<optimized out>) at src/core/socket.c:412 r = <optimized out> __PRETTY_FUNCTION__ = "socket_load" __PRETTY_FUNCTION__ = "socket_load" #8 0x00000000024ca280 in ?? () No symbol table info available. #9 0x0000000000000011 in ?? () No symbol table info available. #10 0x0000000000000001 in ?? () No symbol table info available. #11 0x00000000000003dd in ?? () No symbol table info available. #12 0x0000000000000000 in ?? () No symbol table info available.
I took an other look at the journal, and it seems it may have to do with a sudo root session. I hadn't noticed the close timestamps before, and figured the crash was random. Here is the relevant piece of journal: Mar 06 20:41:40 grothendieck sudo[957]: abdo : TTY=pts/3 ; PWD=/home/abdo ; USER=root ; COMMAND=/usr/bin/pacman -U /home/abdo/opt/paur/build/linkchecker-dev/linkchecker-dev-20140305.11-1-any.pkg.tar.xz Mar 06 20:41:40 grothendieck sudo[957]: pam_unix(sudo:session): session opened for user root by (uid=0) Mar 06 20:41:40 grothendieck sudo[957]: pam_unix(sudo:session): session closed for user root Mar 06 20:41:40 grothendieck sudo[984]: abdo : TTY=pts/3 ; PWD=/home/abdo ; USER=root ; COMMAND=/usr/bin/pacman -U /home/abdo/opt/paur/build/emacs-yasnippet-dev/emacs-yasnippet-dev-20140306.2-1-x86_64.pkg.tar.xz Mar 06 20:41:40 grothendieck sudo[984]: pam_unix(sudo:session): session opened for user root by (uid=0) Mar 06 20:41:40 grothendieck kernel: systemd[594]: segfault at b8 ip 000000000048101e sp 00007fffa11deb60 error 4 in systemd[400000+106000] Mar 06 20:41:40 grothendieck systemd-coredump[991]: Process 594 (systemd) dumped core.
The backtrace looks corrupted. Any chance you can trigger this with an unstripped systemd binary and then get us a correctl backtrace?
I'm running an unstripped systemd since yesterday, waiting for it to blow up again. It may take some time, since I don't know how to trigger it.
I forgot about this. It got fixed after some upgrade. I'll mark it as resolved then!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.