I tried to use smbc_* API calls found in source3/libsmb/* in a multi-threaded environment, but it keeps crashing in smbc_calls. Most of the stack trace looks like below (on linux x64), Thread 1 (Thread 0x7fc5b3d68700 (LWP 26204)): #0 0x00007fc5b71fb7bb in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007fc5b71e6535 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007fc5b70d9395 in _talloc_free.cold.18 () from /usr/lib/samba/libtalloc.so.2 #3 0x00007fc5b7aaef1f in lp_load_ex () from /lib/libsmbconf.so.0 #4 0x00007fc5b7aaf490 in lp_load_global () from /lib/libsmbconf.so.0 #5 0x00007fc5b7bbcb01 in SMBC_module_init () from /lib/libsmbclient.so.0 #6 0x00007fc5b7bbd097 in smbc_new_context () from /lib/libsmbclient.so.0 Can someone confirm whether libsmb client APIs are safe to use in a multi-threaded environment? I understand same SMBCCTX cannot be used on different threads simultaneously, but is it possible to use different contexts in different threads (one context per thread), each used in different API calls, at same time in a process? - Vivek
libsmbclient is not MT-safe, sorry.
Thank you @Jeremey Allison for clarification. Is there any pointers to make this MT safe outside libsmb? I think allowing only one SMBC_* call at a time in a process will do it (at least no crashes as far as I have seen), but would like to know if there are other possibilities available. - Vivek
Putting locks around calls into libsmbclient to prevent concurrent use is the only way at present. It's the parameter and debug library access that will probably cause most of the problems here.
Thank you..