Issue 5199 - slapd sometimes hangs with back-sql
Summary: slapd sometimes hangs with back-sql
Status: VERIFIED DUPLICATE of issue 5095
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: backends (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-24 12:31 UTC by david@dasz.at
Modified: 2020-03-18 20:36 UTC (History)
0 users

See Also:


Attachments
bt_full (5.84 KB, application/octet-stream)
2007-10-31 13:09 UTC, david@dasz.at
Details

Note You need to log in before you can comment on or make changes to this issue.
Description david@dasz.at 2007-10-24 12:31:59 UTC
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.

Comment 1 ando@openldap.org 2007-10-24 13:14:08 UTC
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
---------------------------------------


Comment 2 david@dasz.at 2007-10-25 07:39:02 UTC
-----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-----

Comment 3 david@dasz.at 2007-10-31 13:09:33 UTC
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
Comment 4 Hallvard Furuseth 2007-10-31 14:09:17 UTC
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

Comment 5 Hallvard Furuseth 2007-10-31 15:34:26 UTC
changed notes
moved from Incoming to Software Bugs
Comment 6 Hallvard Furuseth 2007-10-31 17:11:38 UTC
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

Comment 7 OpenLDAP project 2014-08-01 21:04:13 UTC
fixed?
Comment 8 Quanah Gibson-Mount 2020-03-18 20:36:33 UTC

*** This issue has been marked as a duplicate of issue 5095 ***