Problem with AD membership in an AD with more the 100.000 group (possible regression in 4.12?)
Dr. Hansjörg Maurer
hansjoerg.maurer at itsd.de
Wed May 19 05:56:35 UTC 2021
Hi Andrew
tnak you for your quick reply
Am 18.05.21 um 21:59 schrieb Andrew Bartlett:
>
>> (gdb)
>> 567 NDR_CHECK(ndr_pull_array_length(ndr,
>> &r->name));
>> (gdb) cont
>> Continuing.
> OK, so this case it doesn't happen, which is the one I patched.
the gdb run took place with the unpatched version
>
>> Breakpoint 1, ndr_pull_array_size (ndr=ndr at entry=0x5555558cf020,
>> p=p at entry=0x7fffdca0a018)
>> at ../../librpc/ndr/ndr.c:1089
>> 1089 ret = ndr_token_store(ndr, &ndr->array_size_list, p,
>> size);
>> (gdb) step
>> ndr_token_store (mem_ctx=mem_ctx at entry=0x5555558cf020,
>> list=list at entry=0x5555558cf068,
>> key=key at entry=0x7fffdca0a018, value=31) at
>> ../../librpc/ndr/ndr.c:979
>> 979 {
>> (gdb)
>> 980 if (list->tokens == NULL) {
>> (gdb)
>> 987 uint32_t alloc_count =
>> talloc_array_length(list->tokens);
>> (gdb)
>> talloc_get_size (context=0x5555573f97b0) at
>> ../../lib/talloc/talloc.c:2821
>> 2821 {
>> (gdb)
>> 2824 if (context == NULL) {
>> (gdb)
>> 2828 tc = talloc_chunk_from_ptr(context);
>> (gdb)
>> talloc_get_size (context=0x5555573f97b0) at
>> ../../lib/talloc/talloc.c:2830
>> 2830 return tc->size;
>> (gdb)
>> ndr_token_store (mem_ctx=mem_ctx at entry=0x5555558cf020,
>> list=list at entry=0x5555558cf068,
>> key=key at entry=0x7fffdca0a018, value=31) at
>> ../../librpc/ndr/ndr.c:994
>> 994 if (list->count >= NDR_TOKEN_MAX_LIST_SIZE) {
>> (gdb)
>> 1017 return NDR_ERR_SUCCESS;
>> (gdb)
>> ndr_pull_array_size (ndr=ndr at entry=0x5555558cf020,
>> p=p at entry=0x7fffdca0a018) at ../../librpc/ndr/ndr.c:1090
>> 1090 if (ret == NDR_ERR_RANGE) {
>> (gdb)
>> 1091 return ndr_pull_error(ndr, ret,
>> (gdb)
>> _ndr_pull_error (ndr=ndr at entry=0x5555558cf020,
>> ndr_err=ndr_err at entry=NDR_ERR_RANGE,
>> function=function at entry=0x7ffff7bcd650 <__FUNCTION__.9556>
>> "ndr_pull_array_size",
>> location=location at entry=0x7ffff7bcc431
>> "../../librpc/ndr/ndr.c:1093",
>> format=format at entry=0x7ffff7bcce00 "More than %d NDR tokens
>> stored
>> for array_size")
>> at ../../librpc/ndr/ndr.c:606
>> 606 {
>> (gdb)
>> 607 char *s=NULL;
> If you can get me the 'bt full' (or even just 'bt') from here, we can
> determine which structure was over-full of things needing these
> array_size tokens.
below the gdb output with bt full
ndr_pull_array_size (ndr=ndr at entry=0x5555558cf020,
p=p at entry=0x7fffdca0a018) at ../../librpc/ndr/ndr.c:1090
1090 if (ret == NDR_ERR_RANGE) {
(gdb)
1091 return ndr_pull_error(ndr, ret,
(gdb)
_ndr_pull_error (ndr=ndr at entry=0x5555558cf020,
ndr_err=ndr_err at entry=NDR_ERR_RANGE,
function=function at entry=0x7ffff7bcd650 <__FUNCTION__.9556>
"ndr_pull_array_size",
location=location at entry=0x7ffff7bcc431 "../../librpc/ndr/ndr.c:1093",
format=format at entry=0x7ffff7bcce00 "More than %d NDR tokens stored
for array_size")
at ../../librpc/ndr/ndr.c:606
606 {
(gdb)
607 char *s=NULL;
(gdb) bt full
#0 _ndr_pull_error (ndr=ndr at entry=0x5555558cf020,
ndr_err=ndr_err at entry=NDR_ERR_RANGE,
function=function at entry=0x7ffff7bcd650 <__FUNCTION__.9556>
"ndr_pull_array_size",
location=location at entry=0x7ffff7bcc431 "../../librpc/ndr/ndr.c:1093",
format=format at entry=0x7ffff7bcce00 "More than %d NDR tokens stored
for array_size")
at ../../librpc/ndr/ndr.c:607
s = 0x7fffe07ca49c "w10_lgrm.admin_ptid-l-200846_b"
ap = {{gp_offset = 1, fp_offset = 0,
overflow_arg_area = 0x7ffff47363fc
<convert_string_talloc_handle+428>, reg_save_area = 0xff070}}
ret = <optimized out>
__FUNCTION__ = "_ndr_pull_error"
#1 0x00007ffff7bc6ee2 in ndr_pull_array_size
(ndr=ndr at entry=0x5555558cf020, p=p at entry=0x7fffdca0a018)
at ../../librpc/ndr/ndr.c:1091
ret = <optimized out>
size = 31
__FUNCTION__ = "ndr_pull_array_size"
#2 0x00007ffff504adc9 in ndr_pull_wbint_Principal
(ndr=ndr at entry=0x5555558cf020,
ndr_flags=ndr_flags at entry=512, r=0x7fffdca09fd0) at
librpc/gen_ndr/ndr_winbind.c:566
_status = <optimized out>
_ptr_name = 512652
size_name_1 = 0
length_name_1 = 0
_mem_save_name_0 = 0x7fffdc50a070
__FUNCTION__ = "ndr_pull_wbint_Principal"
#3 0x00007ffff504b224 in ndr_pull_wbint_Principals
(ndr=ndr at entry=0x5555558cf020,
ndr_flags=ndr_flags at entry=768, r=0x55555591b1b0) at
librpc/gen_ndr/ndr_winbind.c:651
_status = <optimized out>
size_principals_0 = <optimized out>
cntr_principals_0 = <optimized out>
_mem_save_principals_0 = 0x55555591b1b0
__FUNCTION__ = "ndr_pull_wbint_Principals"
#4 0x00007ffff504dc9b in ndr_pull_wbint_QueryGroupList
(ndr=0x5555558cf020, flags=<optimized out>,
r=0x555555916770) at librpc/gen_ndr/ndr_winbind.c:2070
_status = <optimized out>
_mem_save_groups_0 = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--c
__FUNCTION__ = "ndr_pull_wbint_QueryGroupList"
#5 0x00007ffff735c44c in dcerpc_binding_handle_call_done
(subreq=0x5555559171c0) at ../../librpc/rpc/binding_handle.c:492
req = 0x55555591b260
state = 0x55555591b410
h = 0x5555558f9a30
error = {v = 0}
out_flags = 0
ndr_err = <optimized out>
#6 0x00005555555e86d1 in wbint_bh_raw_call_domain_done
(subreq=0x555555917850) at ../../source3/winbindd/winbindd_dual_ndr.c:204
req = 0x55555591ba40
state = 0x55555591bbf0
ret = 0
err = 21845
#7 0x00005555555e6010 in wb_domain_request_done (subreq=0x555555917500)
at ../../source3/winbindd/winbindd_dual.c:734
req = 0x555555917850
state = <optimized out>
ret = 0
err = 21845
#8 0x00005555555e4041 in wb_child_request_done (subreq=0x55555591ceb0)
at ../../source3/winbindd/winbindd_dual.c:298
req = 0x555555917500
state = <optimized out>
ret = <optimized out>
err = 21845
#9 0x00007ffff004548b in wb_simple_trans_read_done
(subreq=0x55555591d540) at ../../nsswitch/wb_reqtrans.c:432
req = 0x55555591ceb0
state = <optimized out>
ret = 9738888
err = 21845
#10 0x00007ffff0044cba in wb_resp_read_done (subreq=0x55555591d1f0) at
../../nsswitch/wb_reqtrans.c:275
req = 0x55555591d540
state = 0x55555591d6f0
buf = 0x7fffe0a15070 <error: Cannot access memory at address
0x7fffe0a15070>
err = 32767
#11 0x00007ffff713eb53 in tevent_common_invoke_fd_handler
(fde=fde at entry=0x5555558cdd00, flags=<optimized out>,
removed=removed at entry=0x0) at ../../lib/tevent/tevent_fd.c:138
handler_ev = 0x5555558ad350
#12 0x00007ffff71450ef in epoll_event_loop (tvalp=0x7fffffffd510,
epoll_ev=0x5555558c2f60) at ../../lib/tevent/tevent_epoll.c:736
fde = 0x5555558cdd00
flags = <optimized out>
mpx_fde = <optimized out>
ret = <optimized out>
i = 0
timeout = <optimized out>
wait_errno = 4
events = {{events = 1, data = {ptr = 0x5555558cdd00, fd =
1435294976, u32 = 1435294976, u64 = 93824995876096}}}
ret = <optimized out>
i = <optimized out>
events = <optimized out>
timeout = <optimized out>
wait_errno = <optimized out>
fde = <optimized out>
flags = <optimized out>
mpx_fde = <optimized out>
handled_fde = <optimized out>
handled_mpx = <optimized out>
#13 epoll_event_loop_once (ev=<optimized out>, location=<optimized out>)
at ../../lib/tevent/tevent_epoll.c:937
epoll_ev = 0x5555558c2f60
tval = {tv_sec = 3, tv_usec = 886026}
panic_triggered = false
#14 0x00007ffff71430fb in std_event_loop_once (ev=0x5555558ad350,
location=0x555555615828 "../../source3/winbindd/winbindd.c:1949") at
../../lib/tevent/tevent_standard.c:110
glue_ptr = <optimized out>
glue = 0x5555558c2ed0
ret = <optimized out>
#15 0x00007ffff713e225 in _tevent_loop_once (ev=0x5555558ad350,
location=0x555555615828 "../../source3/winbindd/winbindd.c:1949") at
../../lib/tevent/tevent.c:772
ret = <optimized out>
nesting_stack_ptr = 0x0
#16 0x000055555557f1a4 in main (argc=<optimized out>, argv=<optimized
out>) at ../../source3/winbindd/winbindd.c:1949
is_daemon = false
Fork = false
log_stdout = true
no_process_group = true
long_options = {{longName = 0x0, shortName = 0 '\000', argInfo
= 4, arg = 0x7fffefbf2160 <poptHelpOptions>, val = 0, descrip =
0x55555561337b "Help options:", argDescrip = 0x0}, {longName =
0x555555613390 "stdout", shortName = 83 'S', argInfo = 0, arg = 0x0, val
= 1003, descrip = 0x555555613389 "Log to stdout", argDescrip = 0x0},
{longName = 0x555555613397 "foreground", shortName = 70 'F', argInfo =
0, arg = 0x0, val = 1001, descrip = 0x5555556133a2 "Daemon in foreground
mode", argDescrip = 0x0}, {longName = 0x5555556133bc "no-process-group",
shortName = 0 '\000', argInfo = 0, arg = 0x0, val = 1002, descrip =
0x555555614e70 "Don't create a new process group", argDescrip = 0x0},
{longName = 0x555555658a7e "daemon", shortName = 68 'D', argInfo = 0,
arg = 0x0, val = 1000, descrip = 0x5555556133cd "Become a daemon
(default)", argDescrip = 0x0}, {longName = 0x5555556133e7 "interactive",
shortName = 105 'i', argInfo = 0, arg = 0x0, val = 105, descrip =
0x5555556133f3 "Interactive mode", argDescrip = 0x0}, {longName =
0x555555613404 "no-caching", shortName = 110 'n', argInfo = 0, arg =
0x0, val = 110, descrip = 0x55555561340f "Disable caching", argDescrip =
0x0}, {longName = 0x0, shortName = 0 '\000', argInfo = 4, arg =
0x7ffff4f37280 <popt_common_samba>, val = 0, descrip = 0x55555561341f
"Common samba options:", argDescrip = 0x0}, {longName = 0x0, shortName =
0 '\000', argInfo = 0, arg = 0x0, val = 0, descrip = 0x0, argDescrip = 0x0}}
lp_sub = <optimized out>
pc = <optimized out>
opt = <optimized out>
frame = 0x5555559144d0
status = <optimized out>
ok = <optimized out>
__FUNCTION__ = "main"
__func__ = "main"
>>> Then we have more hope of being able to modify the structure to be
>>> less
>>> resource-consuming.
>>>
>>> I wonder if changing to a different string type would
>>> help. Thankfully
>>> this isn't a public protocol, so we can be flexible.
>>>
>>> Try the attached patch. It uses an encoding that stores the
>>> strings as
>>> <num bytes><string> rather than <num bytes><pointer> .... <string>,
>>> which needs these 'tokens' to get between the stages.
>> the patch did not help,
> No worries. I think I'll propose it anyway, as it just more efficient,
> but lets keep looking for where you hit your error.
>
>> Let me know if I should file a bug or can provide additional
>> information
> A bug would be a good idea regardless, so yes, please file one.
submitted bug
https://bugzilla.samba.org/show_bug.cgi?id=14710
with the current traces
Best regards
Hansjörg
>
> Thanks!
>
> Andrew Bartlett
>
--
Dr. Hansjörg Maurer
itsystems Deutschland AG
Erzgießereistr. 22
80335 München
Tel: +49-89-52 04 68-41
Fax: +49-89-52 04 68-59
E-Mail: hansjoerg.maurer at itsd.de
Web: http://www.itsd.de
Amtsgericht München HRB 132146
USt-IdNr. DE 812991301
Steuer-Nr. 143/100/81575
Aufsichtsratsvorsitzender:
Stefan Adam
Vorstand:
Dr. Michael Krocka
Dr. Hansjörg Maurer
More information about the samba-technical
mailing list