Greetd + Tuigreet dumped core

I’m using greetd + tuigreet to login. The problem is that it randomly segfaults after login.

When it happens, tuigreet keeps saying Please Wait... and freezes, forcing me to restart the service to be able to try again.

It may be related to pam login using ecryptfs to mount my home folder, but I can’t be sure because:

  • it only happens sometimes
  • it may happen even if I already have my home mounted and decrypted

Version information:

local/greetd 0.7.0-1
    Generic greeter daemon
local/greetd-tuigreet 0.8.0-0
    A console UI greeter for greetd

Coredump read with sudo coredumpctl debug greetd:

           PID: 750 (greetd)
           UID: 0 (root)
           GID: 0 (root)
        Signal: 11 (SEGV)
     Timestamp: Tue 2022-10-11 10:39:23 -03 (14min ago)
  Command Line: /usr/bin/greetd --session-worker 15
    Executable: /usr/bin/greetd
 Control Group: /system.slice/greetd.service
          Unit: greetd.service
         Slice: system.slice
       Boot ID: 56f09dceaa7a4997bbcde4c40b072ec3
    Machine ID: a3ef4cdf3b704c73ac611e60325fb5ea
      Hostname: paulodiovani-thinkpad
       Storage: /var/lib/systemd/coredump/core.greetd.0.56f09dceaa7a4997bbcde4c40b072ec3.750.1665495563000000.zst (present)
     Disk Size: 180.6K
       Message: Process 750 (greetd) of user 0 dumped core.
                Module with build-id 67833441db018a149e7d23dfead684f2edcb2d3d
                Module with build-id 7742b911aa659b14561dade58e27806632303093
                Module with build-id 5b73faf8abe96fd6b460ef6c703cb127fe8e312b
                Module with build-id 023269774049f20683b13e4304d7e254a1c7a0b2
                Module with build-id 3e5628e90ede9cbb845cd94c13dcf2feee8eb7cd
                Module with build-id 2e76a4a0eb21f3217a766329838b850a7085b16b
                Module with build-id f3ed720bd88c652152737c440039dd0b9589174c
                Module with build-id 904f399db1e3e4b168ab6fcd9152c52a52d41d3f
                Module with build-id 6bd2a336d004dc8458f1c4cdf8fcd941d1c4925f
                Module with build-id 45bcbb167aef0cae946704ce218c4a8f442393ad
                Module with build-id 27045c468605f64203a35fa2d83d7c423220c298
                Module with build-id 9e188fc5620336bf5919f51c25952325ff4de10e
                Module with build-id e28d502d7e4820f936437d20d459e51036d1a243
                Module with build-id 59f4a785cc0a8400f0438321eac923ff96c34bdd
                Module with build-id 7810f60fbe92aa8395979eb46f16f4dac61e6a93
                Module with build-id ae18d68f01288868c93380064a1517522f3a844f
                Module with build-id 26c6c93ab7e9b7022734be96a91d0959b4c84fe5
                Module with build-id c8cd9a21ff69a279996b72edb84ecce486d69115
                Module with build-id da49468b4b8a69c37de11aba959d1f9088ce8ffc
                Module with build-id 728e791498d969203036d9e8b8885412e6f26bcd
                Module with build-id 2d43ea7722be0a6a7e8d25c1a756a37421214d8d
                Module with build-id b7d5a4e635fea6d633ee2787627beb85f61cc756
                Module with build-id 2b24c825d7aa270839da4c1383a0e104972f05f3
                Module with build-id 7e77b47f30b05ee697676df775656b89aabece99
                Module with build-id 2e70cfe9f2972fb13487eeefcb10e4afafed6157
                Module with build-id ac405ddd17be10ce538da3211415ee50c8f8df79
                Module with build-id 9a22a372b2157fb05da1bad94b92d9617513af81
                Module with build-id 3360a28740ffbbd5a5c0c21d09072445908707e5
                Module with build-id 47d53a3ea2b172eb3db1be0ae0272c7c045267e8
                Module with build-id 1fc969c1f54103d87e400237751b4804569a2730
                Module with build-id a10eaeef6e9969e80048d247666a3af155716afc
                Module with build-id 8f5e329f75d897df033d761ca1f742f90619c1b6
                Module with build-id a0a45f81771945f0559d04e93726d245159930da
                Module with build-id 608e03b3693ba42760a2b836763d41d1c079a2bf
                Module with build-id 2c8ff1d29b255da5b7371efd5caf57444d622838
                Module with build-id 9b38b08de708f439a9d0a4f8b9914151bc8d4b50
                Module with build-id 17f782ccef93f588aa7b8cdd49fbdc9b4d241d6f
                Module with build-id 7e42bd70303fbc079e452d777b6907bb5614df5d
                Module with build-id 827b2de32a5ec108462699009e6e441b42792b26
                Module with build-id 9f749b8e7bd55bfb75e294bc32aaa56ac353d6c0
                Module with build-id f50f4594f4bc962c6e9b8d75b3219dfb610f27d1
                Module with build-id 707f9d3134a43306625e3dab8662899ea368ac91
                Module with build-id 075a6ad9f1c3f9cbb5f3301186bbe68c6a477808
                Module with build-id 53c797475ffeed05918d78f49f85dbf4127fb174
                Module with build-id 90b9e4f641f8752292698389f241cbf0ff49d687
                Module with build-id 3954d7fd57fa4db438d0ccdd8e2c6f7cc97c2e46
                Module with build-id 85db482c4585a328d95ec41124337a967bb24d8f
                Module with build-id 414d1d630bc04818a150b9c73e4493f3395e8869
                Module with build-id 74aaf2951cb6eb6cf89a69339285a6015876bee4
                Module with build-id bb11b2685fe89555938ffd330ea44d82b0f8701c
                Module greetd with build-id 71ec96721db89afaf1f076b3981ad5412671a0d1
                Stack trace of thread 750:
                #0  0x00007fdad9e5768b n/a ( + 0x5968b)
                #1  0x00007fdad9e7952d n/a ( + 0x7b52d)
                #2  0x00007fdad9f15213 __asprintf_chk ( + 0x117213)
                #3  0x00007fdad9a6b129 n/a ( + 0x2129)
                #4  0x00007fdad9a6b83a pam_sm_authenticate ( + 0x283a)
                #5  0x00007fdada01691a n/a ( + 0x391a)
                #6  0x00007fdada016181 pam_authenticate ( + 0x3181)
                #7  0x0000557616c58105 n/a (greetd + 0x1e105)
                #8  0x0000557616c67c17 n/a (greetd + 0x2dc17)
                #9  0x0000557616c48281 n/a (greetd + 0xe281)
                #10 0x0000557616c688e3 n/a (greetd + 0x2e8e3)
                #11 0x00007fdad9e21290 n/a ( + 0x23290)
                #12 0x00007fdad9e2134a __libc_start_main ( + 0x2334a)
                #13 0x0000557616c4407e n/a (greetd + 0xa07e)
                ELF object binary architecture: AMD x86-64

Greetd is an AUR package. Did you rebuild it after updating your system?

PS: And it’sversion 0.8.0 in AUR.

Did you rebuild it after updating your system


PS: And it’sversion 0.8.0 in AUR.

Oh I had the community/greetd version installed, which is still on version 0.7.0. I didn’t notice v0.8.0 was available.

I’ll upgrade and check if the error persists. Thanks.

Hm. Didn’t know it was part of the Manjaro repo. @Chrysostomus was the last to package it. I wonder why it was not updated yet.

Not anymore. It’s unmaintained and nothing requires it.

1 Like

[update] version 0.8.0 still errors.

I also opened a bug at greet source hut and the developer pointed out that:

The segfault is triggered from with, somewhere in this function: src/pam_ecryptfs/pam_ecryptfs.c#L125.

Get debug symbols for (ecryptfs-utils) to get a more useful stacktrace.

I’ll try to get debug symbols from ecryptfs-utils when I have the time.

Hi i am facing the same issue, I will try to find more details too (ecryptfs library with shared symbols).

Did you find anything ?

I managed to build greetd, and with debuggin symbols.

I ran into the same issue but I don’t understand where the SIGSEV happens. everything seems fine to me.

see bellow the stack trace I get almost every time I try to login:

Reading symbols from /usr/bin/greetd...
[New LWP 886]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/".
Core was generated by `/usr/bin/greetd --session-worker 12'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f2bd63ea072 in __vfscanf_internal (s=s@entry=0x7ffd3666c3c0, format=format@entry=0x7f2bd6527a6a " %d %d ", 
    argptr=argptr@entry=0x7ffd3666c3a8, mode_flags=mode_flags@entry=2) at vfscanf-internal.c:278
278	{
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /usr/bin/greetd.
Use `info auto-load python-scripts [REGEXP]' to list them.
(gdb) bt
#0  0x00007f2bd63ea072 in __vfscanf_internal (s=s@entry=0x7ffd3666c3c0, format=format@entry=0x7f2bd6527a6a " %d %d ", 
    argptr=argptr@entry=0x7ffd3666c3a8, mode_flags=mode_flags@entry=2) at vfscanf-internal.c:278
#1  0x00007f2bd63dd4e3 in __GI___isoc99_sscanf (s=0x558a980fa728 "0 0", format=format@entry=0x7f2bd6527a6a " %d %d ") at isoc99_sscanf.c:31
#2  0x00007f2bd648c91b in get_mnt_entry (stream=stream@entry=0x558a980d02a0, mp=mp@entry=0x558a980fa6d0, 
    buffer=buffer@entry=0x558a980fa6f8 "proc", bufsiz=bufsiz@entry=4096) at mntent_r.c:166
#3  0x00007f2bd648cdc3 in __GI___getmntent_r (stream=0x558a980d02a0, mp=0x558a980fa6d0, buffer=0x558a980fa6f8 "proc", bufsiz=4096)
    at mntent_r.c:191
#4  0x00007f2bd5fa9019 in ecryptfs_private_is_mounted (dev=0x0, mnt=0x558a980f96c0 "/home/alexander", sig=0x0, mounting=1) at main.c:161
#5  0x00007f2bd5fe79c5 in pam_sm_authenticate (pamh=0x558a980d8f90, flags=0, argc=1, argv=0x558a980e7f40) at pam_ecryptfs.c:172
#6  0x00007f2bd659d91a in ?? () from /usr/lib/

the code in ecrypts can be looked at here (where we try to go through ecryptfs_private_is_mounted)

and the function definition of ecryptfs_private_is_mounted can be looked at here

good luck to who ever can find the issue here :expressionless: I don’t see why it triggers some segfaults.

I found the following interesting point during GDB debugging:

(gdb) disas
Dump of assembler code for function __vfprintf_internal:
   0x00007f4939ce1820 <+0>:	endbr64 
   0x00007f4939ce1824 <+4>:	push   %r15
   0x00007f4939ce1826 <+6>:	push   %r14
   0x00007f4939ce1828 <+8>:	push   %r13
   0x00007f4939ce182a <+10>:	push   %r12
   0x00007f4939ce182c <+12>:	mov    %rdx,%r12
   0x00007f4939ce182f <+15>:	push   %rbp
   0x00007f4939ce1830 <+16>:	push   %rbx
   0x00007f4939ce1831 <+17>:	mov    %rdi,%rbx
   0x00007f4939ce1834 <+20>:	sub    $0x508,%rsp
=> 0x00007f4939ce183b <+27>:	mov    %rsi,(%rsp)

from what I understand we try to push 0x508 on the stack, which seems to be 1288 bytes. From what I read online I see that the stack is limited to 128KB, or here we are way over the limit.

Some solutions could be: raise the thread stack size, reduce the quantity of memory put on the stack and put it on the head (we can’t do that so it should be the first solution I suppose ?)

or here we are way over the limit

Sorry I got confused, we are not way over the limit, this is trying to allocate 1.25KB, which is fine but the stack might already be just on the edge.

it does not change the solution that is needed to solve this issue.

reduce the quantity of memory put on the stack and put it on the head

… and put it on the heap (not the head, I should stop writing post from my phone :laughing: )