[Date Prev][Date Next] [Chronological] [Thread] [Top]

Segfault on backsql_open_db_conn()



I can't get back_sql to work with a postgresql 8.1.0 backend through
odbc-postgresql 1:08.00.0102 and iodbc 3.52.3.

I've tried it with the newest OpenLDAP in Debian testing (2.2.26) and
with the newest stable source release (2.3.19).

The datasource is working fine with iodbctest.

slapd -d 255 -4 gives me the following output at the end:
slapd startup: initiated.
backend_startup: starting "o=sql,c=RU"
==>backsql_db_open(): testing RDBMS connection
backsql_db_open(): subtree search SQL condition not specified (use
"subtree_cond" directive in slapd.conf)
backsql_db_open(): setting "upper(ldap_entries.dn) LIKE upper('%'||?)"
as default
backsql_db_open(): setting "upper(ldap_entries.dn)=upper(?)" as default
backsql_db_open(): objectclass mapping SQL statement not specified
(use "oc_query" directive in slapd.conf)
backsql_db_open(): setting "SELECT
id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM
ldap_oc_mappings" by default
backsql_db_open(): attribute mapping SQL statement not specified (use
"at_query" directive in slapd.conf)
backsql_db_open(): setting "SELECT
name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u
FROM ldap_attr_mappings WHERE oc_map_id=?" by default
backsql_db_open(): entry deletion SQL statement not specified (use
"delentry_query" directive in slapd.conf)
backsql_db_open(): setting "DELETE FROM ldap_entries WHERE id=?" by default
backsql_db_open(): objclasses deletion SQL statement not specified
(use "delobjclasses_query" directive in slapd.conf)
backsql_db_open(): setting "DELETE FROM ldap_entry_objclasses WHERE
entry_id=?" by default
backsql_db_open(): referrals deletion SQL statement not specified (use
"delreferrals_query" directive in slapd.conf)
backsql_db_open(): setting "DELETE FROM ldap_referrals WHERE
entry_id=?" by default
==>backsql_get_db_conn()
==>backsql_open_db_conn()
Segmentation fault


Also, cat /tmp/odbc-trace.log
** iODBC Trace file
** Trace started on Sat Feb 04 19:20:03 2006
** Driver Manager: 03.52.0305.1107


[000000.000900]
slapd           00004000 ENTER SQLAllocEnv
               SQLHENV         * 0x81252a8

[000000.001107]
slapd           00004000 EXIT  SQLAllocEnv with return code 0 (SQL_SUCCESS)
               SQLHENV         * 0x81252a8 (0x81238d0)

[000000.093648]
slapd           00004000 ENTER SQLAllocConnect
               SQLHENV           0x81238d0
               SQLHDBC         * 0x8130504

[000000.093891]
slapd           00004000 EXIT  SQLAllocConnect with return code 0 (SQL_SUCCESS)
               SQLHENV           0x81238d0
               SQLHDBC         * 0x8130504 (0x8130510)

[000000.094107]
slapd           00004000 ENTER SQLConnect
               SQLHDBC           0x8130510
               SQLCHAR         * 0x811fa58
                                 | ldap2                                    |
               SQLSMALLINT       -3 (SQL_NTS)
               SQLCHAR         * 0x81255d8
                                 | postgres                                 |
               SQLSMALLINT       -3 (SQL_NTS)
               SQLCHAR         * 0x4009c108
                                 | ****                                     |
               SQLSMALLINT       -3 (SQL_NTS)

** Trace finished on Sat Feb 04 19:20:03 2006

This is pretty frustrating given that I have had this working a few
months ago with a lot less fuzz than the days I've spend with this
segfault by now ;-) Still, I hope it isn't a bug, because
configuration problems take less time to fix and I can only deploy
this DB once the LDAP gateway is working.

Also, I've tried the test data and configuration which comes with
OpenLDAP: same result.

 - Rowan

--
Morality is usually taught by the immoral.