Learn more about these different git repos.
Other Git URLs
I saw this crash today on my laptop:
(gdb) bt #0 0x00000038cde35ba5 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:63 #1 0x00000038cde37358 in __GI_abort () at abort.c:90 #2 0x00000038d1a022e6 in talloc_abort (reason=0x38d1a08718 "Bad talloc magic value - access after free") at ../talloc.c:317 #3 0x00000038d1a02314 in talloc_abort_access_after_free () at ../talloc.c:336 #4 talloc_chunk_from_ptr (ptr=ptr@entry=0x223ccf0) at ../talloc.c:357 #5 0x00000038d1a06b23 in talloc_chunk_from_ptr (ptr=0x223ccf0) at ../talloc.c:355 #6 _talloc_steal_loc (new_ctx=new_ctx@entry=0x22484d0, ptr=0x223ccf0, location=location@entry=0x474f50 "src/resolv/async_resolv.c:1084") at ../talloc.c:952 #7 0x0000000000429409 in resolv_gethostbyname_dns_recv (rhostent=0x2248500, timeouts=0x224850c, status=0x2248508, mem_ctx=0x22484d0, req=0x2249590) at src/resolv/async_resolv.c:1084 #8 resolv_gethostbyname_done (subreq=0x2249590) at src/resolv/async_resolv.c:1384 #9 0x00000038d22050b7 in tevent_req_finish (location=0x474942 "src/resolv/async_resolv.c:984", state=TEVENT_REQ_USER_ERROR, req=0x2249590) at ../tevent_req.c:110 #10 _tevent_req_error (req=req@entry=0x2249590, error=error@entry=2, location=location@entry=0x474942 "src/resolv/async_resolv.c:984") at ../tevent_req.c:128 #11 0x000000000042a1e6 in resolv_gethostbyname_dns_query_done (arg=<optimized out>, status=<optimized out>, timeouts=<optimized out>, abuf=<optimized out>, alen=<optimized out>) at src/resolv/async_resolv.c:984 #12 0x00000038ce60c0b4 in end_squery (squery=squery@entry=0x2250d90, status=<optimized out>, abuf=<optimized out>, alen=<optimized out>) at ares_search.c:208 #13 0x00000038ce60c269 in search_callback (arg=0x2250d90, status=<optimized out>, timeouts=<optimized out>, abuf=<optimized out>, alen=<optimized out>) at ares_search.c:155 #14 0x00000038ce60beae in qcallback (arg=0x220eb30, status=<optimized out>, timeouts=<optimized out>, abuf=<optimized out>, alen=<optimized out>) at ares_query.c:180 #15 0x00000038ce60a7da in end_query (channel=channel@entry=0x2253920, query=query@entry=0x224f0a0, status=status@entry=0, abuf=abuf@entry=0x7fff39617830 "\237\205\205\200", alen=alen@entry=204) at ares_process.c:1266 #16 0x00000038ce60b522 in process_answer (channel=channel@entry=0x2253920, abuf=abuf@entry=0x7fff39617830 "\237\205\205\200", alen=204, whichserver=whichserver@entry=0, tcp=tcp@entry=0, now=now@entry= 0x7fff39617ab0) at ares_process.c:611 #17 0x00000038ce60b786 in process_answer (now=0x7fff39617ab0, tcp=0, whichserver=0, alen=<optimized out>, abuf=0x7fff39617830 "\237\205\205\200", channel=0x2253920) at ares_process.c:547 #18 read_udp_packets (channel=channel@entry=0x2253920, read_fds=read_fds@entry=0x0, read_fd=read_fd@entry=24, now=now@entry=0x7fff39617ab0) at ares_process.c:497 #19 0x00000038ce60bac7 in processfds (channel=0x2253920, read_fds=read_fds@entry=0x0, read_fd=24, write_fds=write_fds@entry=0x0, write_fd=write_fd@entry=-1) at ares_process.c:152 #20 0x00000038ce60bdce in ares_process_fd (channel=<optimized out>, read_fd=<optimized out>, write_fd=write_fd@entry=-1) at ares_process.c:173 #21 0x0000000000427c22 in fd_input_available (ev=<optimized out>, fde=<optimized out>, flags=1, data=<optimized out>) at src/resolv/async_resolv.c:196 #22 0x00000038d2207552 in epoll_event_loop (tvalp=0x7fff39617b90, std_ev=0x2205680) at ../tevent_standard.c:328 #23 std_event_loop_once (ev=<optimized out>, location=<optimized out>) at ../tevent_standard.c:567 #24 0x00000038d2204060 in _tevent_loop_once (ev=ev@entry=0x22055b0, location=location@entry=0x47ae17 "src/util/server.c:601") at ../tevent.c:507 #25 0x00000038d22041eb in tevent_common_loop_wait (ev=0x22055b0, location=0x47ae17 "src/util/server.c:601") at ../tevent.c:608 #26 0x0000000000452a63 in server_loop (main_ctx=0x22066c0) at src/util/server.c:601 #27 0x000000000040c149 in main (argc=<optimized out>, argv=<optimized out>) at src/providers/data_provider_be.c:2606
Seems like a use-after-free situation.
Fields changed
owner: somebody => jhrozek patch: 0 => 1 status: new => assigned
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=882076 (Red Hat Enterprise Linux 6)
rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=882076 882076]
milestone: NEEDS_TRIAGE => SSSD 1.9.4 resolution: => fixed status: assigned => closed
Metadata Update from @jhrozek: - Issue assigned to jhrozek - Issue set to the milestone: SSSD 1.9.4
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/2748
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.