a core since ykclient-2.13
Closed this issue · 6 comments
During my tests of yubico-pam module i discovered that on linux in 2.13 and master is a core which happens in ykclient_request.
I can reproduce this by 100% if use a newer version of ykclient-c-client than 2.12. If i use
2.12 everything is find. My stacktraces are very poor infact the pam module does very strange isolation where don't try to dig in for now. But it would be very helpful if somebody starts to figure out what happens to 2.13+
thx in advance
meno
#0 __GI___libc_free (mem=0x1) at malloc.c:2929
#1 0x00007f8275cf4d8a in __GI__IO_free_backup_area (fp=0x7f8268000b10) at genops.c:209
#2 0x00007f8275ce9c47 in _IO_seekoff_unlocked (fp=0x7f8268000b10, offset=offset@entry=0, dir=1, dir@entry=0, mode=mode@entry=3) at ioseekoff.c:64
#3 0x00007f8275cebc9d in __GI_rewind (fp=0x7f8268000b10) at rewind.c:36
#4 0x00007f8274bdcc26 in internal_setent (stayopen=0) at nss_files/files-XXX.c:119
#5 _nss_files_gethostbyname4_r (name=name@entry=0x7777d0 "api5.yubico.com", pat=pat@entry=0x7f82677fdbe0, buffer=buffer@entry=0x7f82677fd640 "",
buflen=buflen@entry=1064, errnop=errnop@entry=0x7f82677fdbb0, herrnop=herrnop@entry=0x7f82677fdc00, ttlp=ttlp@entry=0x0)
at nss_files/files-hosts.c:384
#6 0x00007f8275d462e7 in gaih_inet (name=, name@entry=0x7777d0 "api5.yubico.com", service=, req=req@entry=0x777520,
pai=pai@entry=0x7f82677fdd10, naddrs=naddrs@entry=0x7f82677fdd00) at ../sysdeps/posix/getaddrinfo.c:850
#7 0x00007f8275d4999d in __GI_getaddrinfo (name=0x7777d0 "api5.yubico.com", service=0x7f82677fdec0 "443", hints=0x777520, pai=0x7f82677fde78)
at ../sysdeps/posix/getaddrinfo.c:2406
#8 0x00007f8273b050f4 in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#9 0x00007f8273b11fa4 in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#10 0x00007f8273b0f84b in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#11 0x00007f8273d3a182 in start_thread (arg=0x7f82677fe700) at pthread_create.c:312
#12 0x00007f8275d7400d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
A better backtrace
#0 _int_malloc (av=av@entry=0x7f8a50995760 <main_arena>, bytes=bytes@entry=1752) at malloc.c:3775
#1 0x00007f8a50659e5c in __libc_calloc (n=, elem_size=) at malloc.c:3219
#2 0x00007f8a4e446d20 in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#3 0x00007f8a4e4595b0 in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#4 0x00007f8a4e45a101 in curl_multi_perform () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#5 0x00007f8a4f121acf in ykclient_request_send (ykc=ykc@entry=0xb2b8a0,
yubikey=yubikey@entry=0x7fff7eabfc70 "ccccccdhuvvvnkhulfddjedhjuidekkifllhhllfhrre",
nonce=nonce@entry=0xb8ef00 "bfdycinuywgfajfvirkafzdhweuyukhv", ykh=0xb2cd10, ykh=0xb2cd10) at ykclient.c:1181
#6 0x00007f8a4f122a7e in ykclient_request_process (ykc=ykc@entry=0xb2b8a0, ykh=0xb2cd10,
yubikey=yubikey@entry=0x7fff7eabfc70 "ccccccdhuvvvnkhulfddjedhjuidekkifllhhllfhrre") at ykclient.c:1386
#7 0x00007f8a4f122b2f in ykclient_request (ykc=0xb2b8a0, yubikey=0x7fff7eabfc70 "ccccccdhuvvvnkhulfddjedhjuidekkifllhhllfhrre") at ykclient.c:1420
#8 0x00007f8a4f32ea28 in pam_sm_authenticate (pamh=0xb12820, flags=0, argc=, argv=0xb12d70) at pam_yubico.c:995
#9 0x00007f8a50ba2dff in ?? () from /lib/x86_64-linux-gnu/libpam.so.0
#10 0x00007f8a50ba264d in pam_authenticate () from /lib/x86_64-linux-gnu/libpam.so.0
#11 0x0000000000403b0c in ?? ()
#12 0x0000000000402885 in ?? ()
#13 0x00007f8a505f7ec5 in __libc_start_main (main=0x4024e0, argc=1, argv=0x7fff7eabff88, init=, fini=,
rtld_fini=, stack_end=0x7fff7eabff78) at libc-start.c:287
I close these, but there is odd feeling behind.
I thing we need to call ykclient_global_init and ykclient_global_done.
But how could I figure when to call these function or not. If i use ykclient in a pam module where
my life cycle so so that somebody else could called these methods before!
Meno
@mabels did you come to a conclusion that this wasn't a problem in yubico-c-client?
the global init/done functions only call curls global init/cleanup which are reference counted, so it's not a problem to call them multiple times.
it's infact far more worse, the libcurl on linux has a unpreditable
behaviour. I tried hard to find the root cause, but in the end i compiled
my own version of libcurl and now it seams to be pretty stable.
I only happens if you use the yubico-pam(my fork) and run it in the system
pam-module for the su command.
And there is now relation between the yk-client versions, that i thought it
is. But is this related to the odd behaviour in the libcurl.
cheers
meno
On Mon, Feb 16, 2015 at 8:16 AM, Klas Lindfors notifications@github.com
wrote:
@mabels https://github.com/mabels did you come to a conclusion that
this wasn't a problem in yubico-c-client?the global init/done functions only call curls global init/cleanup which
are reference counted, so it's not a problem to call them multiple times.—
Reply to this email directly or view it on GitHub
#31 (comment)
.
Partially this might be related to Yubico/yubico-pam#31 where curl with the threaded resolver sometimes runs into race conditions in glibc. Many distributions compile curl with threaded resolver, but I don't think it's on by default.
i just found the reference to yubico-pam#31. It seams to be on by default.
I used for my tests on every run a pure newly generated ubuntu trusty
image. And the crash was there!, until i switches to my own libcurl. I just
double checked my compiled libcurl is also compiled with the threaded
resolver. But it is a 7.40 version in contrast to 7.35 running on ubuntu.
Cheers
meno
On Mon, Feb 16, 2015 at 8:24 AM, Klas Lindfors notifications@github.com
wrote:
Partially this might be related to Yubico/yubico-pam#31
Yubico/yubico-pam#31 where curl with the
threaded resolver sometimes runs into race conditions in glibc. Many
distributions compile curl with threaded resolver, but I don't think it's
on by default.—
Reply to this email directly or view it on GitHub
#31 (comment)
.