Bug 4228 - PANIC with LDAP
Summary: PANIC with LDAP
Status: RESOLVED INVALID
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Domain Control (show other bugs)
Version: 3.0.23c
Hardware: x86 Linux
: P3 critical
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-15 06:04 UTC by Marcin Giedz
Modified: 2008-12-17 18:33 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcin Giedz 2006-11-15 06:04:14 UTC
Hello again,

Here is description of my first problem I encountered during setting up samba 3.0.23c and LDAP 2.3.28. Linux box is one of intel server platforms and debian etch (unstable) on board. Debian has its own ldap libraries in /usr/ldap.... and there are more then one but with different version ldap files. Despite of these I always compile almost everything from sources so this time I tried ldap-2.3.28. I compiled it, installed in opt/ldap, populated and run. So far so good.
Next I started compiling samba 3.0.23c but theres is no switch to pass LDAP directory so I simply exported CPPFLAGS and LDFLAGS so samba can find ldap.h and appropriate libraries. Done OK. Next I checked samba's libs with ldd to be sure that there are linked to good ldap libraries.

So I run samba. First attempt to authorize and PANIC:

[2006/11/13 11:23:10, 3] smbd/connection.c:yield_connection(69)
 Yielding connection to
[2006/11/13 11:23:10, 3] smbd/server.c:exit_server(655)
 Server exit (normal exit)
[2006/11/13 11:23:10, 0] lib/fault.c:fault_report(36)
 ===============================================================
[2006/11/13 11:23:10, 0] lib/fault.c:fault_report(37)
 INTERNAL ERROR: Signal 11 in pid 27144 (3.0.22)
 Please read the Trouble-Shooting section of the Samba3-HOWTO
[2006/11/13 11:23:10, 0] lib/fault.c:fault_report(39)

 From: http://www.samba.org/samba/docs/Samba3-HOWTO.pdf
[2006/11/13 11:23:10, 0] lib/fault.c:fault_report(40)
 ===============================================================
[2006/11/13 11:23:10, 0] lib/util.c:smb_panic2(1554)
 PANIC: internal error
[2006/11/13 11:23:10, 0] lib/util.c:smb_panic2(1562)
 BACKTRACE: 13 stack frames:
  #0 /opt/samba-3.0.22/sbin/smbd(smb_panic2+0x1ac) [0x7572b13d]
  #1 /opt/samba-3.0.22/sbin/smbd(smb_panic+0x19) [0x7572b21d]
  #2 /opt/samba-3.0.22/sbin/smbd [0x75716d03]
  #3 [0xffffe420]
  #4 /usr/lib/libldap_r.so.2 [0xa7b1ecf1]
  #5 /usr/lib/libldap_r.so.2 [0xa7b05190]
  #6 /usr/lib/libldap_r.so.2 [0xa7b2b4ba]
  #7 /lib/ld-linux.so.2 [0xa7f4eede]
  #8 /lib/tls/libc.so.6(exit+0xd0) [0xa7da24f0]
  #9 /opt/samba-3.0.22/sbin/smbd [0x757b1f12]
  #10 /opt/samba-3.0.22/sbin/smbd(main+0x1633) [0x757b38c3]
  #11 /lib/tls/libc.so.6(__libc_start_main+0xc8) [0xa7d8bea8]
  #12 /opt/samba-3.0.22/sbin/smbd [0x755904e1]
[2006/11/13 11:23:10, 3] smbd/sec_ctx.c:push_sec_ctx(256)
 push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1
[2006/11/13 11:23:10, 3] smbd/uid.c:push_conn_ctx(393)
 push_conn_ctx(0) : conn_ctx_stack_ndx = 0
[2006/11/13 11:23:10, 3] smbd/sec_ctx.c:set_sec_ctx(288)
 setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1
[2006/11/13 11:23:10, 3] smbd/sec_ctx.c:pop_sec_ctx(386)
 pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0


Why /usr/lib/libldap_2.so.2 in this log??? Hmmm it was strange, but I compiled samba with debug mode but it was too much helpfull or maybe I did something wrong:
1) compile with --enable-debug --enable-developer
2) run: gdb ; attach PID; bt;  -> NOTHING - much less than in samba log file.
...so I can't provide this time more.... maybe you can help me what to do with this gdb and backtrace to get more details?

Anyway I found workaround .... I simply changed link /usr/lib/libldap_r.so.2 to point to /opt/ldap/lib/libldapxxxx - now it works. But it doesn't really explain why samba uses libldap_2 from /usr/lib/ since I've switched to /opt/ldap/???

Regards,
Marcin
Comment 1 Björn Jacke 2008-12-17 18:33:15 UTC
this is really a screwed up setup. having different ldap libs around and use samba with the non-default ones is always a bad thing as the default system ldap libs almost always come in through other libs being used that are linked against the system ldap libs.