Full_Name: David Schmitt Version: 2.3.38 OS: Debian etch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.170.138.34) Hi! I have OSX clients authenticating via slapd against my postgres database. Once every fortnight slapd stops responding to requests. I got this backtrace out of it: 0x00002b28372e20f5 in pthread_join () from /lib/libpthread.so.0 (gdb) bt full #0 0x00002b28372e20f5 in pthread_join () from /lib/libpthread.so.0 No symbol table info available. #1 0x00000000004230d2 in slapd_daemon () at /root/tmp/openldap2.3-2.3.38/servers/slapd/daemon.c:2579 listener_tid = 1082132832 rc = 0 #2 0x000000000041665f in main (argc=5, argv=0x7fff748e4288) at /root/tmp/openldap2.3-2.3.38/servers/slapd/main.c:859 save_errno = <value optimized out> fp = (FILE *) 0x6a4f70 i = <value optimized out> no_detach = 0 rc = 1 urls = <value optimized out> username = 0x605030 "gidNumber" groupname = 0x605010 "\226{P7(+" sandbox = 0x0 syslogUser = 160 configfile = <value optimized out> configdir = <value optimized out> serverName = <value optimized out> scp = <value optimized out> scp_entry = <value optimized out> debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 l = <value optimized out> slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 __PRETTY_FUNCTION__ = "main" (gdb) When testing with ldapsearch, the client connects, but doesn't receive any data. This is running on a 2.6.21-2-vserver-amd64 kernel, within a vserver container.
The stack backtrace you provide is useless, as it refers to the main thread. Please run "thread apply all bt full". p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 24 October 2007, you wrote: > The stack backtrace you provide is useless, as it refers to the main > thread. Please run "thread apply all bt full". Hmpf. Thanks for your answer, I will try to get a better trace upon the next hang. Regards, David - -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHIEgZ/Pp1N6Uzh0URAjTPAJ4oiB8IlYjeDKxIGDKHDFCtQEKr2QCgnECE x5GwRPbtZ4Cl5bMy0NlOsTc= =nnG/ -----END PGP SIGNATURE-----
Hi! Please find attached the output of "thread apply all bt full". Regards, David -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
It looks like thread 5 runs amok in sql_dbconn_mutex() while locking sql_dbconn_mutex. That mutex lacks an unlock operation in 2.3.38 where slapd logs "backsql_open_db_conn(...): duplicate connection ID". (Which doesn't sound too good to me either, but then I don't know back-sql.) If that's the problem, it was fixed in OpenLDAP 2.3.39 for ITS#5095. -- Regards, Hallvard
changed notes moved from Incoming to Software Bugs
h.b.furuseth@usit.uio.no writes: > It looks like thread 5 runs amok in sql_dbconn_mutex() while locking > sql_dbconn_mutex. Oops, cut&paste error. I meant in backsql_free_db_conn(). Anyway, does your log contain that message some time before? > "backsql_open_db_conn(...): duplicate connection ID". The (...) is the (connection id). -- Hallvard
fixed?
*** This issue has been marked as a duplicate of issue 5095 ***