Panic in gencache_stabilize

[RégisC]

I noticed some mail about samba panic today.

** Stacktrace **

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f011c4d5687 in __GI___waitpid (pid=11376, stat_loc=stat_loc@entry=0x7ffecfd0772
8, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
#0 0x00007f011c4d5687 in __GI___waitpid (pid=11376, stat_loc=stat_loc@entry=0x7ffecfd
07728, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
#1 0x00007f011c440067 in do_system (line=<optimized out>) at ../sysdeps/posix/system.
c:149
#2 0x00007f011f9ffaf1 in smb_panic_s3 () from /usr/lib/x86_64-linux-gnu/libsmbconf.so
.0
#3 0x00007f0122b1c5af in smb_panic () from /usr/lib/x86_64-linux-gnu/libsamba-util.so
.0
#4 0x00007f0122b1c7c6 in ?? () from /usr/lib/x86_64-linux-gnu/libsamba-util.so.0
#5 <signal handler called>
#6 0x00007f01247f13fc in __pthread_mutex_unlock_full (mutex=0x7f0124afda78, decr=1) a
t pthread_mutex_unlock.c:147
#7 0x00007f011d286fd3 in ?? () from /usr/lib/x86_64-linux-gnu/libtdb.so.1
#8 0x00007f011d2802e5 in ?? () from /usr/lib/x86_64-linux-gnu/libtdb.so.1
#9 0x00007f011fa1973f in gencache_stabilize () from /usr/lib/x86_64-linux-gnu/libsmbc
onf.so.0
#10 0x000055a5e1195164 in ?? ()
#11 0x000055a5e119524a in ?? ()
#12 0x00007f011c7e9fe9 in tevent_common_check_signal () from /usr/lib/x86_64-linux-gnu
/libtevent.so.0
#13 0x00007f011c7ebe02 in ?? () from /usr/lib/x86_64-linux-gnu/libtevent.so.0
#14 0x00007f011c7ea357 in ?? () from /usr/lib/x86_64-linux-gnu/libtevent.so.0
#15 0x00007f011c7e67cd in _tevent_loop_once () from /usr/lib/x86_64-linux-gnu/libteven
t.so.0
#16 0x000055a5e11c0478 in ?? ()
#17 0x000055a5e11c0985 in ?? ()
#18 0x00007f011c7e71a4 in tevent_common_loop_immediate () from /usr/lib/x86_64-linux-g
nu/libtevent.so.0
#19 0x00007f011c7ebcfb in ?? () from /usr/lib/x86_64-linux-gnu/libtevent.so.0
#20 0x00007f011c7ea357 in ?? () from /usr/lib/x86_64-linux-gnu/libtevent.so.0
#21 0x00007f011c7e67cd in _tevent_loop_once () from /usr/lib/x86_64-linux-gnu/libteven
t.so.0
#22 0x000055a5e11922f0 in main ()

** lsb_release -a **

LSB Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch
Distributor ID: Ubuntu
Description: Ubuntu 18.04 LTS
Release: 18.04
Codename: bionic

** apt-cache policy samba **

samba:
  Installé : 2:4.7.6+dfsg~ubuntu-0ubuntu2
  Candidat : 2:4.7.6+dfsg~ubuntu-0ubuntu2
 Table de version :
 *** 2:4.7.6+dfsg~ubuntu-0ubuntu2 500
        500 http://eu.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
        100 /var/lib/dpkg/status

[RégisC (regis-caspar)]

I've also this in log.winbindd:

[2018/06/24 23:32:21.438678, 0] ../source3/winbindd/winbindd.c:243(winbindd_sig_term_handler)
  Got sig[15] terminate (is_parent=1)
[2018/06/25 06:33:59.854508, 0] ../source3/winbindd/winbindd_cache.c:3170(initialize_winbindd_cache)
  initialize_winbindd_cache: clearing cache and re-creating with version number 2
[2018/06/25 06:34:00.195147, 0] ../lib/util/become_daemon.c:124(daemon_ready)
  STATUS=daemon 'winbindd' finished starting up and ready to serve connections

[Andreas Hasenack (ahasenack)]

Thanks

Could you check if there is a crash file in /var/crash about samba, and then attach it to this bug? Note that it may contain sensitive information.

Alternatively you may install the debug symbols packages (see https://wiki.ubuntu.com/Debug%20Symbol%20Packages) and extract the core dump from the crash file with apport-unpack.

[RégisC (regis-caspar)]

Hi Andreas,

My /var/crash was empty (and still is; I got a new crash mail yesterday).

Regards

[Launchpad Janitor (janitor)]

[Expired for samba (Ubuntu) because there has been no activity for 60 days.]

[RégisC (regis-caspar)]

Hum,

Date: Wed, 22 Aug 2018 07:40:05 +0200 (CEST)
From: root <root@xxxx>

The Samba 'panic action' script, /usr/share/samba/panic-action,
was called for PID 2004 (/usr/sbin/winbindd).

This means there was a problem with the program, such as a segfault.
Below is a backtrace for this process generated with gdb, which shows
the state of the program at the time the error occurred. The Samba log
files may contain additional information about the problem.

But OK, that's a new fancy way to handle bug..

[Andreas Hasenack (ahasenack)]

It's difficult to do anything about this without the crash file, or steps to reproduce it.