slimlock segfaults after unlock about slimlock HOT 12 CLOSED

Hrm. I just made a small change (that I should have had in there to begin with) to the awful window-raising thread thing. Can you try again and see if that helps?

I don't think it will, but I don't have a better idea right now. I checked, and I don't think there's anything else that should be closing the display or changing dpy, so I dunno.

Does it segfault at random, or is there anything else that seems to be associated with it?

from slimlock.

I've tried the latest git version. It still segfaults.

It only segfaults when run as a regular user and I enter the correct password the first time. It has never segfaulted when I enter an incorrect password and then the correct one, or when run as superuser.

Weird.

from slimlock.

Hrm. That is indeed weird.

Could you make a gist or something of your slimlock.conf?

And do you compile with any optimizations?

from slimlock.

My slimlock.conf is the default:

dpms_standby_timeout 60
dpms_off_timeout 600
wrong_passwd_timeout 2
passwd_feedback_x 50%
passwd_feedback_y 10%
passwd_feedback_msg Authentication failed
show_username 1
show_welcome_msg 0
tty_lock 0

I'm compiling with CFLAGS="-g -O0" make. No difference.

I've tried calling loginPanel->ResetPasswd() and loginPanel->WrongPassword(cfg_passwd_timeout) by hand before calling AuthenticateUser, in case there is something in those functions that prevents the segfault, but it doesn't cahnge the result: first login correct => segfault; first login incorrect => no segfault. In fact I can remove both lines and leave only

while (true) if (AuthenticateUser()) break;

and I STILL get the same results.

from slimlock.

Okay, so presumably something is being done in Panel::WrongPassword that prevents a segfault. That being said, I have no idea what is actually going on.

I'm still looking into it.

Edit: oh duh, you already ruled that out. Whoops. I'm not quite sure how to proceed now, but I'm looking.

Have you ever noticed segfaults with other X11 programs?

from slimlock.

No, as I said even if I simply leave

while (true) if (AuthenticateUser()) break;

I don't get a segfault when I enter the wrong password and get one if I enter the correct one the first time. So maybe the cause is something that happens with pam_authenticate. The weird thing is it always happens in XCloseDisplay...

from slimlock.

And another thing: if I remove the loop, i.e.:

pthread_t raise_thread;
pthread_create(&raise_thread, NULL, RaiseWindow, NULL);

// Main loop
loginPanel->ResetPasswd();

// AuthenticateUser returns true if authenticated
if (AuthenticateUser());

loginPanel->WrongPassword(cfg_passwd_timeout);

// kill thread before destroying the window that it's supposed to be raising
pthread_cancel(raise_thread);

... so the program always exits, no matter if the password is right or wrong, I get the same results again. Enter the correct password -> segfault; enter an incorrect password -> exit correctly. So there is something weird in pam_authenticate.

from slimlock.

Erm, I dunno much about gentoo, but do you by chance happen to use sys-auth/openpam instead of sys-libs/pam? I noticed gentoo's repository thing has both.

from slimlock.

Nope, just regular pam.

And to add to the confusion, the segfaults only happen with certain themes. I ran valgrind over the program and saw a bunch of things like:

==3942== Invalid read of size 4
==3942== at 0x57E6760: ??? (in /usr/lib64/libImlib2.so.1.4.4)
==3942== by 0x57C9C6D: imlib_free_image (in /usr/lib64/libImlib2.so.1.4.4)
==3942== by 0x40DBDA: Image::~Image() (image.cpp:30)
==3942== by 0x40FB41: Panel::Panel(XDisplay, int, unsigned long, Cfg_, std::string const&) (panel.cpp:166)
==3942== by 0x413A04: main (slimlock.cpp:173)
==3942== Address 0x824a158 is 56 bytes inside a block of size 112 free'd
==3942== at 0x4C28A6E: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3942== by 0x57E532B: ??? (in /usr/lib64/libImlib2.so.1.4.4)l
==3942== by 0x57C9C6D: imlib_free_image (in /usr/lib64/libImlib2.so.1.4.4)
==3942== by 0x40DD9C: Image::Merge(Image_, int, int) (image.cpp:68)
==3942== by 0x40FA96: Panel::Panel(XDisplay, int, unsigned long, Cfg*, std::string const&) (panel.cpp:160)
==3942== by 0x413A04: main (slimlock.cpp:173)

so, seeing that many (if not all) were imlib-related, I changed the theme. I was using "slim-gentoo-simple", now I'm using "flat". And don't see any segfault anymore. I still see lots of valgrind messages regarding imlib, but at least no segfault.

You may as well close the bug. It seems it only happens with a weird combination of things, and not always. I simply can't debug it. I'll use the flat theme (looks good) and simply forget about it.

from slimlock.

Actually, what you said made me look at the image handling code, and I found the source of the valgrind issues. One reason you might have gotten the segfault with the gentoo theme but not flat is because the former uses the "tile" background_style, whereas most others, including flat, use "stretch". The method that tiles the background image had a major issue.

So, I just pushed out the fix. Can you let me know if it still segfaults?

from slimlock.

So, I just pushed out the fix. Can you let me know if it still segfaults?

Nope :). No more segfaults, and the valgrind errors regarding imlib2 have disappeared. I still see some fontconfig errors:

==28611== Invalid read of size 4
==28611== at 0x6F12263: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==28611== by 0x6F145F4: FcConfigFilename (in /usr/lib64/libfontconfig.so.1.4.4)
==28611== by 0x6F278E5: FcConfigParseAndLoad (in /usr/lib64/libfontconfig.so.1.4.4)
==28611== by 0x6F1D1C6: FcInitLoadConfig (in /usr/lib64/libfontconfig.so.1.4.4)
==28611== by 0x6F1D2B5: FcInitLoadConfigAndFonts (in /usr/lib64/libfontconfig.so.1.4.4)
==28611== by 0x6F1D4D4: FcInit (in /usr/lib64/libfontconfig.so.1.4.4)
==28611== by 0x5384EAE: XftInit (in /usr/lib64/libXft.so.2.2.0)
==28611== by 0x53816E1: XftFontMatch (in /usr/lib64/libXft.so.2.2.0)
==28611== by 0x5381A04: XftFontOpenName (in /usr/lib64/libXft.so.2.2.0)
==28611== by 0x412587: Panel::Panel(XDisplay, int, unsigned long, Cfg_, std::string const&) (in /usr/local/home/fran/work/slimlock)
==28611== by 0x4044E9: main (in /usr/local/home/fran/work/slimlock)
==28611== Address 0x80d7a54 is 20 bytes inside a block of size 22 alloc'd
==28611== at 0x4C2990D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==28611== by 0x6F121BC: ??? (in /usr/lib64/libfontconfig.so.1.4.4)
==28611== by 0x6F145F4: FcConfigFilename (in /usr/lib64/libfontconfig.so.1.4.4)
==28611== by 0x6F278E5: FcConfigParseAndLoad (in /usr/lib64/libfontconfig.so.1.4.4)
==28611== by 0x6F1D1C6: FcInitLoadConfig (in /usr/lib64/libfontconfig.so.1.4.4)
==28611== by 0x6F1D2B5: FcInitLoadConfigAndFonts (in /usr/lib64/libfontconfig.so.1.4.4)
==28611== by 0x6F1D4D4: FcInit (in /usr/lib64/libfontconfig.so.1.4.4)
==28611== by 0x5384EAE: XftInit (in /usr/lib64/libXft.so.2.2.0)
==28611== by 0x53816E1: XftFontMatch (in /usr/lib64/libXft.so.2.2.0)
==28611== by 0x5381A04: XftFontOpenName (in /usr/lib64/libXft.so.2.2.0)
==28611== by 0x412587: Panel::Panel(XDisplay, int, unsigned long, Cfg_, std::string const&) (in /usr/local/home/fran/work/slimlock)
==28611== by 0x4044E9: main (in /usr/local/home/fran/work/slimlock)

but they don't cause any segfault (I don't know if they are caused by the program). Right now it's solid as a rock.

Good work!

from slimlock.

Ah, sweet. Thanks.

And from what I've been told, the fontconfig issues are "normal". Whether that means they are false positives or actual errors in the library, I have no idea. But, I've never seen it cause any problems, so I figure I'll close this now.

from slimlock.