Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No longer see messages in gtklock #22

Closed
ldelossa opened this issue Jul 6, 2022 · 13 comments
Closed

No longer see messages in gtklock #22

ldelossa opened this issue Jul 6, 2022 · 13 comments

Comments

@ldelossa
Copy link
Contributor

ldelossa commented Jul 6, 2022

Hello,

I got a new laptop today and installed gtklock. Everything works as expected except for the messages shown when attempting a fingerprint scan. Any changes on gtklock's end that would cause this?

@jovanlanik
Copy link
Owner

No changes in gtklock... I tested both the 1.2.0 release and master with pam_echo and both show messages. Probably a configuration issue.

@ldelossa
Copy link
Contributor Author

ldelossa commented Jul 6, 2022

Hmm, odd. Can you point me into the direction of what config would play a role here? I have a pam file which works fine.

Also kinda odd, i see messages when i come back from leaving my laptop for awhile. I dont see messages when i manually lock my screen with a keyboard short cut.

@jovanlanik
Copy link
Owner

Can you show me the pam config?

@ldelossa
Copy link
Contributor Author

ldelossa commented Jul 6, 2022

@ldelossa
Copy link
Contributor Author

ldelossa commented Jul 6, 2022

Just checked it again, if swayidle invokes gtklock, i see messages.

If I trigger the lock screen, no messages. The invocation of gtklock is the same in both cases.

@jovanlanik
Copy link
Owner

jovanlanik commented Jul 6, 2022

Seems correct. Can you try adding auth optional pam_echo.so test to the top and see if the message appears after wrong password?

@jovanlanik
Copy link
Owner

Just checked it again, if swayidle invokes gtklock, i see messages.

If I trigger the lock screen, no messages. The invocation of gtklock is the same in both cases.

Do you use the deamonize option in both cases?

@ldelossa
Copy link
Contributor Author

ldelossa commented Jul 6, 2022

I do have that set, just havent pushed it up.

@ldelossa
Copy link
Contributor Author

I see why this is occuring.

Inside the password check switch case, glib is causing a coredump.

Here is the backtrace from the coredump:

#0  __pthread_kill_implementation
    (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0)
    at pthread_kill.c:44
#1  0x00007f0128745cb3 in __pthread_kill_internal (signo=6, threadid=<optimized out>)
    at pthread_kill.c:78
#2  0x00007f01286f59c6 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x00007f01286df7f4 in __GI_abort () at abort.c:79
#4  0x00007f0128739d9e in __libc_message
    (action=action@entry=do_abort, fmt=fmt@entry=0x7f0128871925 "%s\n")
    at ../sysdeps/posix/libc_fatal.c:155
#5  0x00007f012874f95c in malloc_printerr
    (str=str@entry=0x7f0128874320 "malloc_consolidate(): invalid chunk size")
    at malloc.c:5664
#6  0x00007f0128750648 in malloc_consolidate (av=av@entry=0x7f00f4000030) at malloc.c:4755
#7  0x00007f012875270f in _int_malloc (av=av@entry=0x7f00f4000030, bytes=bytes@entry=2032)
    at malloc.c:3965
#8  0x00007f01287549f9 in __libc_calloc (n=n@entry=1, elem_size=elem_size@entry=2032)
    at malloc.c:3679
#9  0x00007f01289133a1 in g_malloc0 (n_bytes=2032) at ../glib/gmem.c:155
#10 0x00007f012892bd9c in g_private_set_alloc0
    (size=<optimized out>, key=0x7f01289f3460 <private_thread_memory>)
    at ../glib/gthread.c:542
#11 thread_memory_from_self () at ../glib/gslice.c:564
#12 thread_memory_from_self () at ../glib/gslice.c:550
#13 g_slice_alloc (mem_size=48) at ../glib/gslice.c:1050
#14 0x00007f012890a8d0 in g_source_new
     (source_funcs=source_funcs@entry=0x7f01289f3300 <g_idle_funcs>, struct_size=struct_size@entry=96) at ../glib/gmain.c:993
#15 0x00007f012890c266 in g_idle_source_new () at ../glib/gmain.c:5960
#16 0x00007f012890d898 in g_main_context_invoke_full
    (context=0x1055360, priority=0, function=0x408000 <window_pw_message>, data=0x1165890, notify=0x0) at ../glib/gmain.c:6164
#17 0x0000000000407f42 in window_pw_wait ()
#18 0x00007f0128938302 in g_thread_proxy (data=0x1356800) at ../glib/gthread.c:827
#19 0x00007f0128743e2d in start_thread (arg=<optimized out>) at pthread_create.c:442
#20 0x00007f01287c9620 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

The kicker here is, the IOT is pretty deep from with glib - like in it's allocator?

Here is the installed glib package on my machine:

Installed Packages
Name         : glib2-devel
Version      : 2.72.3
Release      : 1.fc36
Architecture : x86_64
Size         : 3.0 M
Source       : glib2-2.72.3-1.fc36.src.rpm
Repository   : @System
From repo    : updates
Summary      : A library of handy utility functions
URL          : https://www.gtk.org
License      : LGPLv2+
Description  : The glib2-devel package includes the header files for the GLib library.

@jovanlanik
Copy link
Owner

Can you try running gtklock with valgrind and see if you get any memory errors?

@jovanlanik
Copy link
Owner

I did some testing on my side, found and fixed a couple of errors caused by a wrong allocation. I think this should fix the issue. Can you confirm it's fixed in master?

@jovanlanik
Copy link
Owner

I really think this is fixed, so I'll push out a release without your confirmation but leave the issue open.

@ldelossa
Copy link
Contributor Author

Fixed. And now all messages are back. Thanks a lot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants