slimlock segfaults after unlock

[ghost]

I have installed slimlock-0.11 in gentoo. Many times after unlocking I get a segfault.

The segfault ocurrs at line 228 in simlock.cpp (XCloseDisplay)

(gdb) bt

0 0x00007ffff5eed8e8 in ?? () from /lib64/libc.so.6

1 0x00007ffff5eee1a8 in ?? () from /lib64/libc.so.6

2 0x00007ffff5ef148c in free () from /lib64/libc.so.6

3 0x00007ffff7b4319c in XkbFreeClientMap () from /usr/lib64/libX11.so.6

4 0x00007ffff7b45a8d in XkbFreeKeyboard () from /usr/lib64/libX11.so.6

5 0x00007ffff7b38475 in ?? () from /usr/lib64/libX11.so.6

6 0x00007ffff7ad2357 in _XFreeDisplayStructure () from /usr/lib64/libX11.so.6

7 0x00007ffff7abdebf in XCloseDisplay () from /usr/lib64/libX11.so.6

8 0x0000000000413d35 in main (argc=1, argv=0x7fffffffdf88) at slimlock.cpp:228

    themefile = "/usr/share/slim/themes/slim-gentoo-simple/slim.theme"
    themedir = "/usr/share/slim/themes/slim-gentoo-simple"
    ret = 0
    rc = -1
    themebase = "/usr/share/slim/themes/"
    loaded = true
    display = 0x7fffffffef44 ":0.0"
    cfg_dpms_off = 600
    raise_thread = 140737253328640
    wa = {background_pixmap = 8431389920, background_pixel = 0, border_pixmap = 0, 
      border_pixel = 4203517, bit_gravity = -1, win_gravity = 1, 
      backing_store = -134402048, backing_planes = 140737329803336, 
      backing_pixel = 140737353953280, save_under = 3071272, event_mask = 0, 
      do_not_propagate_mask = 4294967295, override_redirect = 1, 
      colormap = 140737329825200, cursor = 140737353953280}
    root = 172
    prev_fn = 0
    lock_file = -1
    cfg_passwd_timeout = 2
    pos = 18446744073709551615
    cfg_dpms_standby = 60

[Guff]

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?

[ghost]

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.

[Guff]

Hrm. That is indeed weird.

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

And do you compile with any optimizations?

[ghost]

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.

[Guff]

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?

[ghost]

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...

[ghost]

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.

[Guff]

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.

[ghost]

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_freeimage (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.

[Guff]

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?

[ghost]

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!

[Guff]

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.