Bug 11808 - smbd hangs while libtdb is initializing
smbd hangs while libtdb is initializing
Product: TDB
Classification: Unclassified
Component: libtdb
All All
: P5 normal
: ---
Assigned To: Uri Simchoni
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2016-03-23 10:35 UTC by Uri Simchoni
Modified: 2016-03-23 10:35 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Uri Simchoni 2016-03-23 10:35:33 UTC
On a specific system (x86_64 multiple cores), running a file server based on samba 4.3.6 with some vendor patches, smbd often hangs while loading. Getting a stack trace shows the following:

#0  0x00007fb98b4ef69e in waitpid () from rootfs/lib64/libpthread.so.0
#1  0x00007fb98556d4c5 in tdb_runtime_check_for_robust_mutexes () at ../lib/tdb/common/mutex.c:890
#2  0x00007fb980926163 in tdb_wrap_open (mem_ctx=0x0, name=0x958610 "/var/vol/12/.ctera/samba/lock/gencache_notrans.tdb", hash_size=0, tdb_flags=6337, open_flags=66, mode=420) at ../lib/tdb_wrap/tdb_wrap.c:151
#3  0x00007fb988c2ba83 in gencache_init () at ../source3/lib/gencache.c:126
#4  0x00007fb988c2c686 in gencache_parse (keystr=0x7fff135bcfe0 "IDMAP/GID2SID/4", parser=0x7fb988c32ed6 <idmap_cache_xid2sid_parser>, private_data=0x7fff135bcfc0) at ../source3/lib/gencache.c:489
#5  0x00007fb988c330e8 in idmap_cache_find_gid2sid (gid=4, sid=0x7fff135bd140, expired=0x7fff135bd11f) at ../source3/lib/idmap_cache.c:270
#6  0x00007fb9894fc574 in gid_to_sid (psid=0x7fff135bd140, gid=4) at ../source3/passdb/lookup_sid.c:1267
#7  0x00007fb988e7a4f6 in add_local_groups (result=0x9579b0, is_guest=true) at ../source3/auth/token_util.c:470
#8  0x00007fb988e7a622 in finalize_local_nt_token (result=0x9579b0, is_guest=true) at ../source3/auth/token_util.c:495
#9  0x00007fb988e79f4b in create_local_nt_token_from_info3 (mem_ctx=0x957810, is_guest=true, info3=0x957e90, extra=0x957d20, ntok=0x957810) at ../source3/auth/token_util.c:314
#10 0x00007fb988e84f9f in create_local_token (mem_ctx=0x955240, server_info=0x957cd0, session_key=0x0, smb_username=0x958020 "nobody", session_info_out=0x7fb989098058) at ../source3/auth/auth_util.c:555
#11 0x00007fb988e85a08 in make_new_session_info_guest (session_info=0x7fb989098058, server_info=0x7fb989098060) at ../source3/auth/auth_util.c:831
#12 0x00007fb988e867e3 in init_guest_info () at ../source3/auth/auth_util.c:1128
#13 0x000000000040ac9b in main (argc=5, argv=0x7fff135bdb78) at ../source3/smbd/server.c:1518

(gdb) info thread
* 1 Thread 1779  0x00007fb98b4ef69e in waitpid () from rootfs/lib64/libpthread.so.0

When this happening there are 2 smbd processes - the main one with this stack trace, and notifyd.

Close examination of the code shows there's a race condition between a signal handler and the main thread code.