I reverted back to samba 4.6.x as this branch didn't show this issues.

Samba 4.6.x causes regular core dumps of child pids, but seems to be working fine in general (except that winbindd hangs about once a week, unfortunately I can't tell whether this has been fixed in newer Samba versions, because of the original bug):

#0  0x00007f42fb2b4f60 in raise () from /lib64/libc.so.6
#1  0x00007f42fb2b6c2a in abort () from /lib64/libc.so.6
#2  0x00007f42fcc27d42 in dump_core () at ../source3/lib/dumpcore.c:338
#3  0x00007f42fcc192fb in smb_panic_s3 (why=<optimized out>)
    at ../source3/lib/util.c:814
#4  0x00007f42fecf3e9f in smb_panic (
    why=why@entry=0x7f42fea3a818 "assert failed: lock_ref_count >= 0")
    at ../lib/util/fault.c:166
#5  0x00007f42fe92ea20 in decrement_lock_ref_count (
    fsp=fsp@entry=0x55e380b58bb0) at ../source3/locking/posix.c:455
#6  0x00007f42fe92ec1f in decrement_posix_lock_count (fsp=0x55e380b58bb0, 
    smblctx=<optimized out>) at ../source3/locking/posix.c:1237
#7  0x00007f42fe930dbc in release_posix_lock_posix_flavour (
    fsp=0x55e380b58bb0, u_offset=<optimized out>, u_count=<optimized out>, 
    lock_ctx=lock_ctx@entry=0x7ffdcbce9290, 
    plocks=plocks@entry=0x55e380b45e10, num_locks=num_locks@entry=0)
    at ../source3/locking/posix.c:1408
#8  0x00007f42fe92ce96 in brl_unlock_posix (plock=0x7ffdcbce9290, 
    br_lck=0x55e380b45b50, msg_ctx=0x55e380a366d0)
    at ../source3/locking/brlock.c:1286
#9  brl_unlock (msg_ctx=msg_ctx@entry=0x55e380a366d0, 
    br_lck=br_lck@entry=0x55e380b45b50, smblctx=smblctx@entry=3245055878, 
    pid=..., start=start@entry=0, size=size@entry=9223372036854775808, 
---Type <return> to continue, or q <return> to quit---
    lock_flav=lock_flav@entry=POSIX_LOCK) at ../source3/locking/brlock.c:1380
#10 0x00007f42fe928cae in do_unlock (msg_ctx=0x55e380a366d0, 
    fsp=fsp@entry=0x55e380b58bb0, smblctx=smblctx@entry=3245055878, 
    count=count@entry=9223372036854775808, offset=offset@entry=0, 
    lock_flav=lock_flav@entry=POSIX_LOCK) at ../source3/locking/locking.c:328
#11 0x00007f42fe88af80 in smb_set_posix_lock (fsp=0x55e380b58bb0, 
    total_data=24, pdata=<optimized out>, req=0x55e380b45760, conn=0x0)
    at ../source3/smbd/trans2.c:7209
#12 smbd_do_setfilepathinfo (conn=conn@entry=0x55e380afbb10, 
    req=req@entry=0x55e380b45760, mem_ctx=mem_ctx@entry=0x55e380b45760, 
    info_level=info_level@entry=520, fsp=fsp@entry=0x55e380b58bb0, 
    smb_fname=<optimized out>, ppdata=0x55e380b3e640, total_data=24, 
    ret_data_size=0x7ffdcbce95a0) at ../source3/smbd/trans2.c:8607
#13 0x00007f42fe88ca9b in call_trans2setfilepathinfo (
    max_data_bytes=<optimized out>, total_data=24, ppdata=0x55e380b3e640, 
    total_params=<optimized out>, pparams=0x55e380b3e630, 
    tran_call=<optimized out>, req=0x55e380b45760, conn=0x55e380afbb10)
    at ../source3/smbd/trans2.c:8850
#14 handle_trans2 (conn=conn@entry=0x55e380afbb10, 
    req=req@entry=0x55e380b45760, state=state@entry=0x55e380b3e5d0)
    at ../source3/smbd/trans2.c:9391
#15 0x00007f42fe88f375 in reply_trans2 (req=0x55e380b45760)
    at ../source3/smbd/trans2.c:9620
---Type <return> to continue, or q <return> to quit---
#16 0x00007f42fe8b6b36 in switch_message (type=<optimized out>, 
    req=req@entry=0x55e380b45760) at ../source3/smbd/process.c:1726
#17 0x00007f42fe8b8f8a in construct_reply (deferred_pcd=0x0, 
    encrypted=<optimized out>, seqnum=0, unread_bytes=0, size=102, 
    inbuf=<optimized out>, xconn=0x55e380af1480)
    at ../source3/smbd/process.c:1762
#18 process_smb (xconn=xconn@entry=0x55e380af1480, inbuf=<optimized out>, 
    nread=102, unread_bytes=0, seqnum=0, encrypted=<optimized out>, 
    deferred_pcd=0x0) at ../source3/smbd/process.c:2009
#19 0x00007f42fe8b9f7c in smbd_server_connection_read_handler (
    xconn=0x55e380af1480, fd=33) at ../source3/smbd/process.c:2609
#20 0x00007f42fb63b673 in ?? () from /usr/lib64/libtevent.so.0
#21 0x00007f42fb639a47 in ?? () from /usr/lib64/libtevent.so.0
#22 0x00007f42fb635e3d in _tevent_loop_once () from /usr/lib64/libtevent.so.0
#23 0x00007f42fb63606b in tevent_common_loop_wait ()
   from /usr/lib64/libtevent.so.0
#24 0x00007f42fb6399e7 in ?? () from /usr/lib64/libtevent.so.0
#25 0x00007f42fe8bb2b9 in smbd_process (ev_ctx=0x55e380a361e0, 
    msg_ctx=<optimized out>, sock_fd=33, interactive=<optimized out>)
    at ../source3/smbd/process.c:4126
#26 0x000055e37ef5b134 in smbd_accept_connection (ev=0x55e380a361e0, 
    fde=<optimized out>, flags=<optimized out>, private_data=<optimized out>)
    at ../source3/smbd/server.c:1027
---Type <return> to continue, or q <return> to quit---
#27 0x00007f42fb63b673 in ?? () from /usr/lib64/libtevent.so.0
#28 0x00007f42fb639a47 in ?? () from /usr/lib64/libtevent.so.0
#29 0x00007f42fb635e3d in _tevent_loop_once () from /usr/lib64/libtevent.so.0
#30 0x00007f42fb63606b in tevent_common_loop_wait ()
   from /usr/lib64/libtevent.so.0
#31 0x00007f42fb6399e7 in ?? () from /usr/lib64/libtevent.so.0
#32 0x000055e37ef5634e in smbd_parent_loop (parent=0x55e380a390b0, 
    ev_ctx=0x55e380a361e0) at ../source3/smbd/server.c:1394
#33 main (argc=<optimized out>, argv=<optimized out>)
    at ../source3/smbd/server.c:2048

Maybe there the tdb files are corrupted or there is some bug in tdb?
Winbindd of Samba 3.6.15 also locks up during tdb access - see bug id 13443

See https://bugzilla.samba.org/show_bug.cgi?id=13443 and https://bugzilla.redhat.com/show_bug.cgi?id=1401665

What does this tell us? We can't use mutexes? We can easily disable them again, no problem.

It is not fixed at least in the RHEL7 Kernel yet :-( It looked like similar backtraces which were related to robust mutexes not fixed yet.

(In reply to Volker Lendecke from comment #4)

> What does this tell us? We can't use mutexes? We can easily disable them again, 
> no problem.

It tells us this is a Red Hat problem and we shouldn't change our code :-).

(In reply to Jeremy Allison from comment #6)
> It tells us this is a Red Hat problem and we shouldn't change our code :-).

Are you sure other distros don't have the same problem? For the better or worse, regarding this aspect of kernel and glibc, probably most other distros are just RH downstream.

At the worst this needs a change inside tdb_mutex_locking_supported() disabling mutexes for affected kernel versions. IMHO of course. Either that or a config variable to allow people to turn it off.

(In reply to Jeremy Allison from comment #8)
> At the worst this needs a change inside tdb_mutex_locking_supported()
> disabling mutexes for affected kernel versions. IMHO of course. Either that
> or a config variable to allow people to turn it off.

I was told by RH people that it's not that simple. It's a combination of bugs between glibc and the kernel. You can't upgrade one without the other to fix these bugs. But the authorities are of course the kernel/glibc developers working on this.

Can't we just add an smb.conf variable to turn off mutexes which we will advise affected users to set ? I don't want to rip out our working code for temporary glibc/kernel bugs.

(In reply to Jeremy Allison from comment #10)
I don't know if anyone of you has read Mr. Metzmacher's comment #1 on Samba bug id 13443:

Can you try "dbwrap_tdb_mutexes:*=no" in the [global] section.

This might be the undocumented (at least it is missing from man smb.conf) solution ... (at least it seems to have fixed the winbind issue)

(In reply to Jeremy Allison from comment #6)
Sorry - if this should have been a joke I didn't understand it as other distros seems to be affected as well (maybe because they are using glibc?!).

If I executed the test cases correctly, robust mutexes are still broken in other distros (i.e. Ubuntu 18.04 ... - see my comment on bug id 13443), so I fear when you are using Linux with glibc it currently is always broken in one or another way.

See comment #3 on Samba bug id 13443

Maybe people running Linux not suffering from this issue are using ctdb instead of tdb (maybe it is disabling mutexes in its default configuration).

(In reply to Sysadmin HTL-Leonding from comment #11)
Link is wrong (redirecting to this bug instead of 13443). Maybe this link works 13443#1 - if not please open the other bug manually.

Ah, thought I remembered we had a way to turn it off, but couldn't find it in my quick search (in my defence I am still horribly jet-lagged :-).

Probably for us this is a documentation fix then.

(In reply to Jeremy Allison from comment #14)
> Ah, thought I remembered we had a way to turn it off, but couldn't find it
> in my quick search (in my defence I am still horribly jet-lagged :-).
> 
> Probably for us this is a documentation fix then.

The dbwrap option does not help for gencache_notrans.tdb, FWIW

(In reply to Jeremy Allison from comment #14)
Documentation for this feature seems to be a big problem as I couldn't find any (at least man smb.conf is silent about this option).

The release notes for Samba 4.2.0 states that you can enable this feature by setting

"dbwrap_tdb_mutexes:* = yes"

If you read the "fine print" of the Samba 4.7.0 release notes you can read

Samba 4.7.0 (changes since 4.7.0rc2)
BUG 12891: Enable TDB mutexes in dbwrap and ctdb.

So the default values were changed (nearly silently) (which wouldn't be an issue if this feature wouldn't be broken on Linux (or do you know a distro on which Mr. Amitay's test code doesn't lock up?)).

It seems that your web servers are also still delivering old information

https://ctdb.samba.org/manpages/ctdb-tunables.7.html

states

TDBMutexEnabled
Default: 0

while the patch in BUG 12891 changed exactly this default value to 1 (the dbwrap default value was also changed with this commit)...

(In reply to Volker Lendecke from comment #15)

Would the use of "--disable-tdb-mutex-locking" as mentioned in
samba/blob/master/lib/tdb/wscript fix this? If the tdb library has no mutex locking built-in Samba won't be able to use it anymore (don't know if that really makes a difference to a runtime option, but maybe the runtime option is not being queried in special cases)?

Or will this cause other stability issues?

(In reply to Sysadmin HTL-Leonding from comment #17)
> (In reply to Volker Lendecke from comment #15)
> 
> Would the use of "--disable-tdb-mutex-locking" as mentioned in
> samba/blob/master/lib/tdb/wscript fix this? If the tdb library has no mutex
> locking built-in Samba won't be able to use it anymore (don't know if that
> really makes a difference to a runtime option, but maybe the runtime option
> is not being queried in special cases)?
> 
> Or will this cause other stability issues?

This will probably help you. Sorry for relying on a documented feature of glibc and the kernel that turns out to be broken so badly.

(In reply to Sysadmin HTL-Leonding from comment #1)
Do you have a reproducer that results in the other back trace mentioned?

(In reply to Sysadmin HTL-Leonding from comment #1)
Opened bug 13558 to track this smbd panic.