Bug 7655 - Isn't thread safe suddenly?
Isn't thread safe suddenly?
Status: RESOLVED DUPLICATE of bug 6358
Product: Samba 4.0
Classification: Unclassified
Component: DCE-RPCs and pipes
unspecified
Other Linux
: P3 critical
: ---
Assigned To: Andrew Bartlett
samba4-qa@samba.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-27 09:03 UTC by Milan Crha
Modified: 2010-09-12 04:52 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Milan Crha 2010-08-27 09:03:46 UTC
I'm at samba4 git commit 44b2a79 and I'm using samba4 through openchange in evolution-mapi and thus e-addressbook-factory and this e-addressbook-factory is crashing when I'm trying to open more than one address book at once, on the same connection. The error it crashes on is:
../librpc/rpc/dcerpc.c:181: Type mismatch: name[DATA_BLOB: ../../librpc/ndr/ndr_basic.c:1132] expected[struct tevent_req]

Note the first "name[xxx]" can vary.

There seem to be two threads interleaving dcerpc calls. (I didn't paste other threads, because they seem irrelevant, in a waiting state, not in the samba4 code). I do not recall seeing this in a version about two months ago or so. At least not reproducible.

Thread 12 (Thread 0xb67ffb70 (LWP 7214)):
#0  0x003a8424 in __kernel_vsyscall ()
#1  0x02b5a0b6 in epoll_wait () at ../sysdeps/unix/syscall-template.S:82
#2  0x06c2c1e8 in epoll_event_loop (std_ev=0x80a8ba8, tvalp=0xb67febe4) at ../tevent_standard.c:264
#3  0x06c2ca4d in std_event_loop_once (ev=0x80a8bf0, location=0x6c2e8e5 "../tevent_req.c:193") at ../tevent_standard.c:544
#4  0x06c28ed1 in _tevent_loop_once (ev=0x80a8bf0, location=0x6c2e8e5 "../tevent_req.c:193") at ../tevent.c:494
#5  0x06c2a509 in tevent_req_poll (req=0xb5c00778, ev=0x80a8bf0) at ../tevent_req.c:193
#6  0x066b4f1f in dcerpc_binding_handle_call (h=0x80a8718, object=0x0, table=0x642dac0, opnum=2, r_mem=0xb5c01738, r_ptr=0xb67fed90)
    at ../../librpc/rpc/binding_handle.c:475
#7  0x063c6de4 in dcerpc_EcDoRpc_r (h=<value optimized out>, mem_ctx=<value optimized out>, r=<value optimized out>) at gen_ndr/ndr_exchange_c.c:12792
#8  0x063c6e3c in dcerpc_EcDoRpc_compat (p=<value optimized out>, mem_ctx=<value optimized out>, r=<value optimized out>) at gen_ndr/ndr_exchange_c.c:12803
#9  0x0631053e in emsmdb_transaction (emsmdb_ctx=<value optimized out>, mem_ctx=<value optimized out>, req=<value optimized out>, 
    repl=<value optimized out>) at libmapi/emsmdb.c:447
#10 0x06310770 in emsmdb_transaction_wrapper (session=<value optimized out>, mem_ctx=<value optimized out>, req=<value optimized out>, 
    repl=<value optimized out>) at libmapi/emsmdb.c:599
#11 0x06328fc7 in Release (obj=<value optimized out>) at libmapi/IUnknown.c:149
#12 0x0632eb6c in mapi_object_release (obj=<value optimized out>) at libmapi/mapi_object.c:99
#13 0x045a1edd in exchange_mapi_connection_resolve_named_props (conn=0xb7403808, fid=16276290528293683205, named_ids_list=0xb67feff8, 
    named_ids_n_elems=11, perror=0x0) at exchange-mapi-connection.c:2326


Thread 9 (Thread 0xb3dfcb70 (LWP 7202)):
#0  0x003a8424 in __kernel_vsyscall ()
#1  0x02aa9a81 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0x02aab34a in abort () at abort.c:92
#3  0x00c88a6c in talloc_abort (
    reason=0xb7400710 "../librpc/rpc/dcerpc.c:181: Type mismatch: name[DATA_BLOB: ../../librpc/ndr/ndr_basic.c:1132] expected[struct tevent_req]")
    at ../talloc.c:199
#4  0x00c89e0a in talloc_abort_type_missmatch (location=0x66d50c3 "../librpc/rpc/dcerpc.c:181", 
    name=0x64b0f68 "DATA_BLOB: ../../librpc/ndr/ndr_basic.c:1132", expected=0x66d50de "struct tevent_req") at ../talloc.c:986
#5  0x00c89eab in _talloc_get_type_abort (ptr=0xb743cff8, name=0x66d50de "struct tevent_req", location=0x66d50c3 "../librpc/rpc/dcerpc.c:181")
    at ../talloc.c:1003
#6  0x066a3b6e in dcerpc_bh_raw_call_done (subreq=0xb743ccc0) at ../librpc/rpc/dcerpc.c:180
#7  0x066a632b in dcerpc_request_recv_data (c=0xb743cf20, raw_packet=0xb3dfbc98, pkt=0xb3dfbc10) at ../librpc/rpc/dcerpc.c:1297
#8  0x066a5564 in dcerpc_recv_data (conn=0xb743cf20, blob=0xb3dfbc98, status=...) at ../librpc/rpc/dcerpc.c:962
#9  0x066ae361 in sock_process_recv (private_data=0xb743cf20, blob=...) at ../librpc/rpc/dcerpc_sock.c:122
#10 0x01794fe9 in packet_recv (pc=0xb7442210) at ../lib/stream/packet.c:414
#11 0x066ae3ea in sock_io_handler (ev=0xb743c110, fde=0xb74421a8, flags=1, private_data=0xb743cf20) at ../librpc/rpc/dcerpc_sock.c:146
#12 0x06c2c3b6 in epoll_event_loop (std_ev=0xb743cc38, tvalp=0xb3dfbdf4) at ../tevent_standard.c:309
#13 0x06c2ca4d in std_event_loop_once (ev=0xb743c110, location=0x6c2e8e5 "../tevent_req.c:193") at ../tevent_standard.c:544
#14 0x06c28ed1 in _tevent_loop_once (ev=0xb743c110, location=0x6c2e8e5 "../tevent_req.c:193") at ../tevent.c:494
#15 0x06c2a509 in tevent_req_poll (req=0xb743d438, ev=0xb743c110) at ../tevent_req.c:193
#16 0x066b4f1f in dcerpc_binding_handle_call (h=0xb743d1f8, object=0x0, table=0x642d880, opnum=0, r_mem=0xb7439fe0, r_ptr=0xb3dfbf7c)
    at ../../librpc/rpc/binding_handle.c:475
#17 0x063cb334 in dcerpc_RfrGetNewDSA_r (h=<value optimized out>, mem_ctx=<value optimized out>, r=<value optimized out>) at gen_ndr/ndr_exchange_c.c:695
#18 0x063cb44c in dcerpc_RfrGetNewDSA_compat (p=<value optimized out>, mem_ctx=<value optimized out>, r=<value optimized out>)
    at gen_ndr/ndr_exchange_c.c:706
#19 0x0632994b in RfrGetNewDSA (session=<value optimized out>, server=<value optimized out>, userDN=<value optimized out>) at libmapi/IMSProvider.c:164
#20 0x06329a71 in Logon (session=<value optimized out>, provider=<value optimized out>, provider_id=<value optimized out>) at libmapi/IMSProvider.c:275
#21 0x0632d4b0 in MapiLogonProvider (session=<value optimized out>, profname=<value optimized out>, password=<value optimized out>, 
    provider=<value optimized out>) at libmapi/cdo_mapi.c:176
#22 0x0632d762 in MapiLogonEx (session=<value optimized out>, profname=<value optimized out>, password=<value optimized out>) at libmapi/cdo_mapi.c:67
Comment 1 Matthias Dieter Wallnöfer 2010-08-27 12:22:31 UTC
Generally we don't support threads yet - see bug #6356.
Comment 2 Milan Crha 2010-08-30 02:19:38 UTC
Is talloc also thread unsafe? We are using threads quite much, to have things done in parallel, but the application sometimes crashes in talloc with "bad talloc" or "double free" or similar. If using of talloc is also thread unsave, even on different memory contexts, then it may explain it.

Also, I didn't expect samba4 being thread unsafe, but with this information it makes sense it begun to crash "suddenly", I did more paralelism in our application recently, which might uncover this issue and invoke it more often than before.
Comment 3 Jeremy Allison 2010-09-03 18:35:26 UTC
talloc is thread unsafe if you use the null or autofree contexts, or if you pass talloc'ed pointers between threads and alloc/free on them (there are no mutex'es used when accessing internal talloc data structures).

Jeremy.
Comment 4 Matthias Dieter Wallnöfer 2010-09-12 04:52:39 UTC
I redirect this report to bug 6358 which is the tracking bug about thread safety for s4.
Let us discuss there further ideas how to fix this.

*** This bug has been marked as a duplicate of bug 6358 ***