Bug 18756

Summary: Apache core dump when using LDAP authentification.
Product: Apache httpd-2 Reporter: Laurent Faillie <l_faillie>
Component: mod_auth_ldapAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: RESOLVED DUPLICATE    
Severity: critical CC: apache, atlunde, bugzilla-apache, dave, dbb, jemiller, jessh, kate.ward, leesaikc, remi.nivet, somme, timothy.arnold
Priority: P3 Keywords: PatchAvailable
Version: 2.0.48   
Target Milestone: ---   
Hardware: Sun   
OS: Solaris   
URL: Intranet
Attachments: Termporary work-around
This patch correct ldap cache shm which is broken in apache 2.0
This patch correct ldap cache shm which is broken in apache 2.0
My latest patch for ldap cache using shared memory

Description Laurent Faillie 2003-04-07 10:39:30 UTC
Hi all,

I just upgraded my 2.0.44 apache to 2.0.45 due to the last security warning.

Unfortunatly, everytime I'm trying to access to a page protected by LDAP, the 
child crash : The error log says 

[Mon Apr 07 12:08:30 2003] [notice] child pid 23255 exit signal Bus error (10)

My .htaccess is :

AuthName "Protected"
AuthType Basic

AuthLDAPURL "ldap://ldapmain.mydomain.com 
ldapsecond.mydomain.com/ou=people,dc=mycompany,dc=com?uid?sub"
require valid-user

It seems it fails only when the authentification succeed (because w/ a wrong 
information, the authentification is reasked and the "access denied page" is 
displayed w/o problem).

Same behaviour on both HP-UX 10.20 and 11 :-(

Compiled using :

./configure --with-mpm=prefork -with-ldap --enable-ldap --enab
le-auth-ldap --enable-info --enable-cgi --enable-expires --enable-so

I have reinstalled 2.0.44 ...

Bye

Laurent
Comment 1 Jess Holle 2003-04-12 12:44:55 UTC
I have almost the same issue on Win32 -- at least when using Microsoft's LDAP 
(which is the default).  The difference: I get a crash on failed authentication 
challenges too...
Comment 2 Duncan Brannen 2003-04-24 10:03:02 UTC

I've the same problem on Solaris.


2.0.44 and 2.0.43 seem ok, but if you look at http://servername/ldap-status on 
these builds it says ldap cache is disabled.




Using OpenLdap libraries 2.1.8 originally, upgraded to 2.1.17, gives no change.




2.0.45 core dumps with Bus Error or Seg Fault when asking for a page (seems to 
do it every request)  I've tested on Suse linux and it segfaults far less 
frequently, <10 times for 5000 hits. I've set up an LDAP server with 5000 dummy 
users and a script to use wget to ask for an authenticated page using different 
users.




Configure options were 


./configure --prefix=/opt/apache/httpd/2.0.44 --with-ssl=/opt/SSL/default 
--enable-so --enable-ssl --enable-auth-ldap --with-ldap --enable-ldap 
--enable-proxy --sysconfdir=/etc/apache2/conf --with-ldap-include=/opt/ldap/2.1.
8/include --with-ldap-lib=/opt/ldap/2.1.8/lib --enable-rewrite 




Though I've removed everything but the ldap flags and still get the same 
problem.  Tried removing the ldap module and using the mod_auth_ldap from www.
muquit.com - works fine, but I don't want to have to get my users to change all 
their access files :)
Comment 3 Jess Holle 2003-04-24 14:30:53 UTC
Hmmm...

My problem on Windows went away when I installed and used the latest MSVC++
Service Pack and the latest Microsoft Platform SDK.

I had the LDAP modules working fine on Solaris at 2.0.43, but have not tried
them since (as the motivation to move to Apache 2 is not as great on UNIX).

For those trying 2.0.45 on HP you may be interested to note that HP now provides
a 2.0.45 build for their platform with an LDAP module, though I'm not sure which
one...
Comment 4 Laurent Faillie 2003-04-26 10:22:05 UTC
Hello,

> For those trying 2.0.45 on HP you may be interested to note that HP now 
provides
> a 2.0.45 build for their platform with an LDAP module, though I'm not 
sure which one...

I only use source tarball because I use several architectures (Sparc64/Solaris,
Sparc/NetBSD, HP-UX) and don't want to have many different customised version of
apache flying around. Anyway, I will check if HP has made some modification
about this problem ... I hope, if they found something, they have warn apache team.

Bye

Laurent
Comment 5 Jess Holle 2003-04-28 14:07:07 UTC
I have since learned that HP's 2.0.45 still contains their own port of auth_ldap
to Apache 2.0 from 1.3, unfortunately.

I'm guessing they'll jump to the normal Apache modules one of these days... 
Comment 6 Damian Marinaccio 2003-04-29 13:11:44 UTC
I successfully installed Apache 2.0.45 with mod_auth_ldap and mod_ldap using
the openldap 2.1.17 SDK and openSSL.

I created a test directory with the following .htaccess file:

AuthName "Test"
AuthType Basic
AuthLDAPURL "ldap://ldap.rit.edu:389/o=University Name, st=New
York, c=US?uid"
require valid-user

When trying to access the directory I get prompted for username & password
(as I should) but then I get a page cannot be displayed error (I know there
is no problem with the page) no matter what i type in.


I checked the Apache error log and this is what I see:

[Mon Apr 21 12:45:17 2003] [notice] child pid 22179 exit signal Bus error
(10)
[Mon Apr 21 12:45:17 2003] [notice] child pid 22166 exit signal Bus error
(10)
[Mon Apr 21 12:51:12 2003] [notice] child pid 22182 exit signal Bus error
(10)
[Mon Apr 21 12:55:42 2003] [notice] child pid 22169 exit signal Bus error
(10)
[Mon Apr 21 12:55:42 2003] [notice] child pid 22180 exit signal Bus error
(10)
[Mon Apr 21 12:56:56 2003] [notice] child pid 22224 exit signal Bus error
(10)
[Mon Apr 21 12:56:56 2003] [notice] child pid 22223 exit signal Bus error
(10)


Thank you very much,

Damian Marinaccio
Rochester Institute of Technology
RIT Library
585-475-7741
dxmwml@rit.edu
Comment 7 Erik Abele 2003-05-16 17:59:39 UTC
*** Bug 19820 has been marked as a duplicate of this bug. ***
Comment 8 Erik Abele 2003-05-16 18:00:08 UTC
*** Bug 19993 has been marked as a duplicate of this bug. ***
Comment 9 Maximilian Kolmhuber 2003-05-27 15:46:58 UTC
Created attachment 6512 [details]
Termporary work-around
Comment 10 Albert Lee 2003-06-12 02:36:01 UTC
I have tried the suggestion for the workaround, but it only work for the first 
connection, subsequent requests returned a failed id.

I am using apache 2.0.46, netscape ldap sdk, on solaris.
Comment 11 Patrice Bertrand 2003-06-20 09:41:43 UTC
I have the bug on apache to 2.0.46 on win2k (standard binary distribution) 
while binding to an AD on a win2k server.

The error log contains :
[Fri Jun 20 10:49:02 2003] [notice] Parent: child process exited with status 
3221225477 -- Restarting.

This error occurs when I first to access a protected page.

The only workaround was to use the mod_auth_ldap from www.muquit.com. It works 
works but I'd like to use the standard one, not using IPlanet libraries!
Comment 12 Patrice Bertrand 2003-06-20 09:45:28 UTC
I forgot to say that the bug happens with 2.0.44 too.
Comment 13 jemiller 2003-06-20 15:44:26 UTC
It doesn't seem like the developers who made all those changes to auth_ldap 
for version 2.0.45 tested it very well. Where are they now? 2.0.46 is already 
out and doesn't include a fix. While I'm appreciative of the workaround. 
Having an authentication occur everytime a protected resource is accessed 
without caching is pretty unacceptable. So is having to run an old version of 
the HTTP server that has security vulnerabilities. IMHO, if the developers 
aren't going to come up with a fix for version 2.0.47, they should roll the 
auth_ldap code back to 2.0.44 (which worked just fine).
Comment 14 softspt 2003-07-02 11:53:32 UTC
I believe the error is in the shared memory handling. After a lot of 
scaffolding, I found it was dying at line 396 of util_ldap_cache_mgr.c, in 
util_ald_cache_insert(), when node->add_time is set to the current time.

On the assumption this indicated some sort of memory allocation problem when 
creating node, I then had a look at util_ald_alloc(). If the call to 
apr_rmm_addr_get() is replaced with a simple calloc(), the problem goes away.
Comment 15 Matthieu Estrade 2003-07-04 11:15:20 UTC
Created attachment 7099 [details]
This patch correct ldap cache shm which is broken in apache 2.0
Comment 16 Matthieu Estrade 2003-07-04 11:16:02 UTC
Created attachment 7100 [details]
This patch correct ldap cache shm which is broken in apache 2.0
Comment 17 Matthieu Estrade 2003-07-04 11:21:38 UTC
I have just posted a patch i made one month ago to fix problems in ldap cache
and shm. This code has been ported from apache 1.3 and was broken when using SHM.

I tested the patch and it's working with worker MPM, i sent it on dev@httpd, but
didn't get answer at this time.

feedback are welcome

Matthieu

Sorry if i posted twice, i am new with bugzilla
Comment 18 Kate Ward 2003-07-14 10:30:35 UTC
The patch provided by Matthieu Estrade partially worked for me.  I applied the
patch to a clean 2.0.47 tree, and now I properly get a "LDAP: using file:
/var/run/apache2/mod_ldap_cache for shm cache" message in the logfile (after
setting the LDAPShmCacheFile option).  I still get the "ldap cache init: Error
0" message though (even though the configured shm file is correctly created),
but now the /ldap-status page correctly updates with cache information about the
LDAP entries that have been attempted (stayed empty before).

As mentioned in early comments, I also get the "exit signal Bus error (10)",
which has not changed after patching of 2.0.47 (also have same problem with 2.0.45).
Comment 19 Kate Ward 2003-07-14 13:04:07 UTC
Commenting out the LDAP cache directives from the Apache config now allows me to
successfully authenticate against my OpenLDAP 2.0.27 server, but no caching is
happening.  As my load is light, I can live with this :)

In my previous 2.0.44 install, I was not using the LDAP cache directives, so I
cannot comment as to whether they used to work or not.  I had enabled them for
my 2.0.47 install attempting to work around above mentioned bus errors.

Note, the provided patch was required before my original config that did not
include the LDAP cache directives worked successfully.  For my case (no
caching), the patch now works beautifully.
Comment 20 Laurent Faillie 2003-08-22 09:40:45 UTC
I have tryed to enable caching on my 2.0.44 environment.

I have added following lines in my httpd.conf (as explained in mod_ldap 
documentation):

#LDAP
LDAPSharedCacheSize 200000
LDAPCacheEntries 1024
LDAPCacheTTL 600
LDAPOpCacheEntries 1024
LDAPOpCacheTTL 600

<Location /ldap-status>
	SetHandler ldap-status
	Order deny,allow
	Deny from all
	Allow from mydomain.com

	AuthName "Protected"
	AuthType Basic
	AuthLDAPEnabled on
	AuthLDAPURL "ldap://ldapmain.mydomain.com 
ldapsecond.mydomain.com/ou=people,dc=mycompany,dc=com?uid?sub"

	AuthLDAPAuthoritative on
	require user "webmaster"
</Location>


Well, perhasp I miss something but /ldap-status always display :
Cache has not been enabled/initialised.

Does someone know if LDAP caching is always disabled in 2.0.44 or if I made a 
mistake ?

Bye

Laurent
Comment 21 Laurent Faillie 2003-08-28 16:32:00 UTC
I just make a test w/ latest 2.0.47

It doesn't crash but, /ldap-status says ldap caching is not enabled even if I
put directive of my previous messages in the configuration file.

I miss something or caching can't be done on my plateforme ?

Laurent
Comment 22 Matthieu Estrade 2003-09-12 10:32:39 UTC
Created attachment 8185 [details]
My latest patch for ldap cache using shared memory
Comment 23 Matthieu Estrade 2003-09-12 10:43:19 UTC
This is my latest and new patch fixing ldap cache using shared memory.
It is different than the latest one and more clean.

I fix a bug which could appear when apache is running vhosts
I tested it on httpd-2.0.47 and latest cvs version and it's working well on linux
ldap-status is displaying the correct information and it's caching ldap request
in each vhost using ldap Auth.

I added a directive: LDAPSharedCacheFile (filename)
i used LDAPSharedCacheFile logs/ldap_cache_file

i hope it will work entirely now

regards,

Matthieu
Comment 24 Markus Schiegl 2003-09-20 12:39:55 UTC
to summarize a few observations i made with 2.0.47, worker-mpm, solaris8 and 
openldap2.1.22:

1.) i must place the following statements outside of any virtual host 
statement otherwise the ldap-cache will not work (checked with the
ldap-status handler).

LDAPSharedCacheSize 200000
LDAPCacheEntries 1024 <- this seems to be the important one
LDAPCacheTTL 600
LDAPOpCacheEntries 1024
LDAPOpCacheTTL 600
[LDAPSharedCacheFile logs/ldap_cache_file]

using this configuration the ldap-cache seems to initialize just fine, e.g.
...
Cache Name Entries Avg. Chain Len. Hits Ins/Rem Purges Avg Purge Time 
LDAP URL Cache 0 (0% full) 0.0 0/0 100% 0/0 (none) 0 
...

but after the first successfull authentication the connection aborts.
error_log:
...
[Sat Sep 20 14:18:35 2003] [notice] child pid 14848 exit signal Bus error (10)
...

2. placing the above statement inside a virtual-host statement or setting the 
parameter LDAPCacheEntries to 0, results in a disabled LDAP cache, but 
authentication works at least.

3. applying the latest patch from Matthieu Estrade (09/12/03) doesn't help 
either. httpd creates a 6 byte LDAPSharedCacheFile, but the results are the 
same listed in 1) and 2)
Comment 25 Jeff Trawick 2003-09-26 13:03:24 UTC
For you folks who are getting crashes with the LDAP crashing (exit signal SIGBUS
or whatever)...  Can you post a backtrace from a core dump pretty please so we
know exactly which code is crashing?  Thanks!
Comment 26 Steve Waltner 2003-09-26 13:31:45 UTC
dumbo:~/apache-2.0.47/bin> ./apachectl startssl
Segmentation Fault - core dumped
dumbo:~/apache-2.0.47/bin> gdb httpd core
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.9"...
Core was generated by `/home/backuppc/apache-2.0.47/bin/httpd -k start -DSSL'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /home/backuppc/apache-2.0.47/lib/libaprutil-0.so.0...done.
Loaded symbols for /home/backuppc/apache-2.0.47/lib/libaprutil-0.so.0
Reading symbols from /usr/lib/libldap.so.5...done.
Loaded symbols for /usr/lib/libldap.so.5
Reading symbols from /usr/local/lib/liblber.so.2...dbxread.c:1732:
gdb-internal-error: sect_index_data not initialized

An internal GDB error was detected.  This may make further
debugging unreliable.  Quit this debugging session? (y or n) n

Create a core file containing the current state of GDB? (y or n) n

Reading symbols from /home/backuppc/apache-2.0.47/lib/libexpat.so.0...done.
Loaded symbols for /home/backuppc/apache-2.0.47/lib/libexpat.so.0
Reading symbols from /home/backuppc/apache-2.0.47/lib/libapr-0.so.0...done.
Loaded symbols for /home/backuppc/apache-2.0.47/lib/libapr-0.so.0
Reading symbols from /usr/lib/libsendfile.so.1...done.
Loaded symbols for /usr/lib/libsendfile.so.1
Reading symbols from /usr/lib/librt.so.1...done.
Loaded symbols for /usr/lib/librt.so.1
Reading symbols from /usr/lib/libm.so.1...done.
Loaded symbols for /usr/lib/libm.so.1
Reading symbols from /usr/lib/libsocket.so.1...done.
Loaded symbols for /usr/lib/libsocket.so.1
Reading symbols from /usr/lib/libnsl.so.1...done.
Loaded symbols for /usr/lib/libnsl.so.1
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/lib/libresolv.so.2...done.
Loaded symbols for /usr/lib/libresolv.so.2
Reading symbols from /usr/lib/libdl.so.1...done.
Loaded symbols for /usr/lib/libdl.so.1
Reading symbols from /usr/lib/libpthread.so.1...done.
Loaded symbols for /usr/lib/libpthread.so.1
Reading symbols from /usr/lib/libc.so.1...done.
Loaded symbols for /usr/lib/libc.so.1
Reading symbols from /usr/lib/libmd5.so.1...done.
Loaded symbols for /usr/lib/libmd5.so.1
Reading symbols from /usr/lib/libaio.so.1...done.
Loaded symbols for /usr/lib/libaio.so.1
Reading symbols from /usr/lib/libmp.so.2...done.
Loaded symbols for /usr/lib/libmp.so.2
Reading symbols from /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1...done.
Loaded symbols for /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1
Reading symbols from /usr/lib/libthread.so.1...done.
Loaded symbols for /usr/lib/libthread.so.1
#0  0xfeeb2f68 in strlen () from /usr/lib/libc.so.1
(gdb) bt
#0  0xfeeb2f68 in strlen () from /usr/lib/libc.so.1
#1  0xff16c990 in apr_pstrdup () from /home/backuppc/apache-2.0.47/lib/libapr-0.so.0
#2  0x0002ee48 in mod_auth_ldap_parse_url ()
#3  0x0006a4ec in invoke_cmd ()
#4  0x0006bda0 in ap_walk_config_sub ()
#5  0x0006be9c in ap_walk_config ()
#6  0x0008bc2c in dirsection ()
#7  0x0006a36c in invoke_cmd ()
#8  0x0006bda0 in ap_walk_config_sub ()
#9  0x0006be9c in ap_walk_config ()
#10 0x0006d2fc in ap_process_config_tree ()
#11 0x000716d8 in main ()
(gdb) quit
dumbo:~/apache-2.0.47/bin>

.../httpd.conf
==============
<Directory "/home/backuppc/apache-2.0.47/cgi-bin">
    AllowOverride None
    Options None
    Order allow,deny
    Allow from all

    AuthName "BackupPC Admin Page"
    AuthType Basic
    AuthLDAPEnabled on
    AuthLDAPAuthoritative on
    AuthLDAPURL ldap://...obfuscated...
    require valid-user
</Directory>

No matter what I put in the AuthLDAPURL config entry, the software segfaults on
startup. Looking at the backtrace, it is having trouble parsing the line for
some reason. This is Solaris 9 with Apache 2.0.47 compiled with GNU Make 3.80,
GCC 3.3 and OpenLDAP 2.1.22. I am not setting any entries related to LDAP
caching. The same config entries work fine on Apache 2.0.47 compiled on Linux
(RedHat 9, x86).
Comment 27 Jeff Trawick 2003-09-26 16:52:11 UTC
nice backtrace :)

there are a bunch of apr_pstrdup() calls in that function...  normal way to get
the debugger to tell us is to rebuild the server with debug symbols (add
--enable-maintainer-mode to configure invocation), start the server to get a new
coredump, and use gdb again... gdb this time should display the actual source
file line numbers

the ldap function that calls apr_pstrdup() also has a bunch of debug statements...
can you try starting Apache with "-e debug" option first to see if
mod_auth_ldap's debug messages get to the console or to the error log?  if this
works, we may be able to get a good hint without you rebuilding your server
Comment 28 Markus Schiegl 2003-09-27 09:36:21 UTC
my error_log (loglevel debug):

...starting apache...
[Sat Sep 27 11:18:23 2003] [notice] LDAP: Built with OpenLDAP LDAP SDK
[Sat Sep 27 11:18:23 2003] [notice] LDAP: SSL support unavailable
[Sat Sep 27 11:18:23 2003] [info] Init: Initializing OpenSSL library
[Sat Sep 27 11:18:23 2003] [info] Init: Seeding PRNG with 512 bytes of entropy
[Sat Sep 27 11:18:23 2003] [info] Init: Generating temporary RSA private keys 
(512/1024 bits)
[Sat Sep 27 11:18:24 2003] [info] Init: Generating temporary DH parameters 
(512/1024 bits)
[Sat Sep 27 11:18:24 2003] [debug] ssl_scache_dbm.c(422): Inter-Process 
Session Cache (DBM) Expiry: old: 0, new: 0, removed: 0
[Sat Sep 27 11:18:24 2003] [info] Init: Initializing (virtual) servers for SSL
[Sat Sep 27 11:18:24 2003] [info] Server: Apache/2.0.47, Interface: 
mod_ssl/2.0.47, Library: OpenSSL/0.9.7b
[Sat Sep 27 11:18:24 2003] [notice] LDAP: Built with OpenLDAP LDAP SDK
[Sat Sep 27 11:18:24 2003] [notice] LDAP: SSL support unavailable
[Sat Sep 27 11:18:24 2003] [info] Init: Initializing OpenSSL library
[Sat Sep 27 11:18:25 2003] [info] Init: Seeding PRNG with 512 bytes of entropy
[Sat Sep 27 11:18:25 2003] [info] Init: Generating temporary RSA private keys 
(512/1024 bits)
[Sat Sep 27 11:18:25 2003] [info] Init: Generating temporary DH parameters 
(512/1024 bits)
[Sat Sep 27 11:18:25 2003] [info] Init: Initializing (virtual) servers for SSL
[Sat Sep 27 11:18:25 2003] [info] Server: Apache/2.0.47, Interface: 
mod_ssl/2.0.47, Library: OpenSSL/0.9.7b
[Sat Sep 27 11:18:25 2003] [debug] util_ldap.c(1104): [5795] ldap cache init: 
Error 0
[Sat Sep 27 11:18:25 2003] [notice] Apache configured -- resuming normal 
operations
[Sat Sep 27 11:18:25 2003] [info] Server built: Sep 13 2003 13:31:41
[Sat Sep 27 11:18:25 2003] [debug] worker.c(1736): AcceptMutex: pthread 
(default: pthread)
[Sat Sep 27 11:18:42 2003] [notice] child pid 5795 exit signal Bus error (10)
[Sat Sep 27 11:18:43 2003] [debug] util_ldap.c(1104): [5796] ldap cache init: 
Error 0
[Sat Sep 27 11:18:44 2003] [notice] child pid 5796 exit signal Bus error (10)
[Sat Sep 27 11:18:45 2003] [debug] util_ldap.c(1104): [5797] ldap cache init: 
Error 0
[Sat Sep 27 11:19:10 2003] [info] removed PID file /opt/httpd/logs/httpd.pid 
(pid=5793)
[Sat Sep 27 11:19:10 2003] [notice] caught SIGTERM, shutting down
...shutdown...

at 11:18:42 i tried to authenticate the first time...

output to console on startup:

[Sat Sep 27 11:18:23 2003] [debug] util_ldap.c(958): [5792] ldap cache: 
Setting shared memory cache size to 200000 bytes.
[Sat Sep 27 11:18:23 2003] [debug] util_ldap.c(992): [5792] ldap cache: 
Setting search cache size to 1024 entries.
[Sat Sep 27 11:18:23 2003] [debug] util_ldap.c(973): [5792] ldap cache: 
Setting cache TTL to 600000000 microseconds.
[Sat Sep 27 11:18:23 2003] [debug] util_ldap.c(1025): [5792] ldap cache: 
Setting operation cache size to 1024 entries.
[Sat Sep 27 11:18:23 2003] [debug] util_ldap.c(1007): [5792] ldap cache: 
Setting operation cache TTL to 600000000 microseconds.
[Sat Sep 27 11:18:23 2003] [debug] mod_auth_ldap.c(737): [5792] auth_ldap url 
parse: `ldap://localhost:389/CN=AAAA,DC=BBBB,DC=CCCC?DDDD?one?
(objectClass=person)'
[Sat Sep 27 11:18:23 2003] [debug] mod_auth_ldap.c(758): [5792] auth_ldap url 
parse: Host: localhost
[Sat Sep 27 11:18:23 2003] [debug] mod_auth_ldap.c(760): [5792] auth_ldap url 
parse: Port: 389
[Sat Sep 27 11:18:23 2003] [debug] mod_auth_ldap.c(762): [5792] auth_ldap url 
parse: DN: CN=AAAA,DC=BBBB,DC=CCCC
[Sat Sep 27 11:18:23 2003] [debug] mod_auth_ldap.c(764): [5792] auth_ldap url 
parse: attrib: DDDD
[Sat Sep 27 11:18:23 2003] [debug] mod_auth_ldap.c(766): [5792] auth_ldap url 
parse: scope: onelevel
[Sat Sep 27 11:18:23 2003] [debug] mod_auth_ldap.c(771): [5792] auth_ldap url 
parse: filter: (objectClass=person)
[Sat Sep 27 11:18:23 2003] [debug] mod_auth_ldap.c(836): LDAP: auth_ldap not 
using SSL connections
...and a few more of these statements.

no core file was created, although coredump's should work

# coreadm 
     global core file pattern: 
       init core file pattern: core
            global core dumps: disabled
       per-process core dumps: enabled
      global setid core dumps: disabled
 per-process setid core dumps: disabled
     global core dump logging: disabled
# coreadm `ps -ef | grep httpd | grep root | awk '{print $2}'`
5529:   core
#

any hints how i can retrieve more helpful informations are appreciated.
Comment 29 Markus Schiegl 2003-09-27 22:51:57 UTC
okay, this one (being unable to create a core file) was my fault, after 
adjusting a few paramters if got the desired result:

# gdb httpd core
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.8"...
Core was generated by `/opt/httpd/bin/httpd -k start'.
Program terminated with signal 9, Killed.
Reading symbols from /opt/httpd/lib/libaprutil-0.so.0...done.
Loaded symbols for /opt/httpd/lib/libaprutil-0.so.0
Reading symbols from /opt/openldap/lib/libldap.so.2...done.
Loaded symbols for /opt/openldap/lib/libldap.so.2
Reading symbols from /usr/lib/libgen.so.1...done.
Loaded symbols for /usr/lib/libgen.so.1
Reading symbols from /opt/openldap/lib/liblber.so.2...done.
Loaded symbols for /opt/openldap/lib/liblber.so.2
Reading symbols from /opt/httpd/lib/libexpat.so.0...done.
Loaded symbols for /opt/httpd/lib/libexpat.so.0
Reading symbols from /usr/local/lib/libiconv.so.2...done.
Loaded symbols for /usr/local/lib/libiconv.so.2
Reading symbols from /opt/httpd/lib/libapr-0.so.0...done.
Loaded symbols for /opt/httpd/lib/libapr-0.so.0
Reading symbols from /usr/lib/libsendfile.so.1...done.
Loaded symbols for /usr/lib/libsendfile.so.1
Reading symbols from /usr/lib/librt.so.1...done.
Loaded symbols for /usr/lib/librt.so.1
Reading symbols from /usr/lib/libm.so.1...done.
Loaded symbols for /usr/lib/libm.so.1
Reading symbols from /usr/lib/libsocket.so.1...done.
Loaded symbols for /usr/lib/libsocket.so.1
Reading symbols from /usr/lib/libnsl.so.1...done.
Loaded symbols for /usr/lib/libnsl.so.1
Reading symbols from /usr/lib/libresolv.so.2...done.
Loaded symbols for /usr/lib/libresolv.so.2
Reading symbols from /usr/lib/libpthread.so.1...done.
Loaded symbols for /usr/lib/libpthread.so.1
Reading symbols from /usr/lib/libc.so.1...done.
Loaded symbols for /usr/lib/libc.so.1
Reading symbols from /usr/lib/libdl.so.1...done.
Loaded symbols for /usr/lib/libdl.so.1
Reading symbols from /usr/lib/libaio.so.1...done.
Loaded symbols for /usr/lib/libaio.so.1
Reading symbols from /usr/lib/libmp.so.2...done.
Loaded symbols for /usr/lib/libmp.so.2
Reading symbols from /usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1...done.
Loaded symbols for /usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1
Reading symbols from /usr/lib/libthread.so.1...done.
Loaded symbols for /usr/lib/libthread.so.1
Reading symbols from /usr/lib/nss_files.so.1...done.
Loaded symbols for /usr/lib/nss_files.so.1
Reading symbols from /opt/httpd/modules/libphp4.so...done.
Loaded symbols for /opt/httpd/modules/libphp4.so
Reading symbols from /opt/httpd/modules/mod_security.so...done.
Loaded symbols for /opt/httpd/modules/mod_security.so
#0  0x4a4f8 in util_ald_cache_insert (cache=0xfed501b0, payload=0xfe303828) at 
util_ldap_cache_mgr.c:396
396         node->add_time = apr_time_now();
(gdb) bt
#0  0x4a4f8 in util_ald_cache_insert (cache=0xfed501b0, payload=0xfe303828) at 
util_ldap_cache_mgr.c:396
#1  0x49184 in util_ldap_cache_checkuserid (r=0x350fe0, ldc=0x20d4a8, url=0x1 
<Address 0x1 out of bounds>, 
    basedn=0x36b260 "MyUsername", scope=0, attrs=0x233b00, 
filter=0xfe3038f0 "(&(objectClass=person)(sAMAccountName=MyUsername))", 
    bindpw=0x36b22f "MyPassword", binddn=0xfe3038e8, retvals=0xfe3038e4) at 
util_ldap.c:923
#2  0x4af14 in mod_auth_ldap_check_user_id (r=0x350fe0) at mod_auth_ldap.c:366
#3  0xaaa4c in ap_run_check_user_id (r=0x350fe0) at request.c:112
#4  0xab398 in ap_process_request_internal (r=0x350fe0) at request.c:235
#5  0x77b28 in ap_process_request (r=0x350fe0) at http_request.c:286
#6  0x72f7c in ap_process_http_connection (c=0x346ba0) at http_core.c:293
#7  0x9ef6c in ap_run_process_connection (c=0x346ba0) at connection.c:85
#8  0x9f258 in ap_process_connection (c=0x346ba0, csd=0x346ac0) at 
connection.c:211
#9  0x90448 in process_socket (p=0x346ba0, sock=0x346ac0, my_child_num=0, 
my_thread_num=2, bucket_alloc=0x2e53e0) at worker.c:632
#10 0x90b34 in worker_thread (thd=0x1e6830, dummy=0x346ba0) at worker.c:947
#11 0xff2756d0 in dummy_worker (opaque=0x1e6830) at thread.c:127
(gdb) quit
Comment 30 Duncan Brannen 2003-10-03 11:27:26 UTC
SunOS neutrino 5.8 Generic_108528-16 sun4u sparc SUNW,Sun-Fire-480R
OpenSSL 0.9.7c
OpenLdap 2.1.22
Apache 2.0.47
./configure --with-ssl --enable-so --enable-ssl --with-ldap --enable-ldap 
--enable-auth-ldap --enable-proxy --enable-rewrite --enable-maintainer-mode

It doesn't coredump, is there a way to keep it in the foreground & debug
for more info?

  Duncan

./httpd -e debug

error_log when logging -> debug
[Fri Oct 03 12:18:38 2003] [notice] LDAP: Built with OpenLDAP LDAP SDK
[Fri Oct 03 12:18:38 2003] [notice] LDAP: SSL support available
[Fri Oct 03 12:18:38 2003] [info] Init: Initializing OpenSSL library
[Fri Oct 03 12:18:38 2003] [info] Init: Seeding PRNG with 0 bytes of entropy
[Fri Oct 03 12:18:38 2003] [info] Init: Generating temporary RSA private keys 
(512/1024 bits)
[Fri Oct 03 12:18:38 2003] [info] Init: Generating temporary DH parameters 
(512/1024 bits)
[Fri Oct 03 12:18:38 2003] [warn] Init: Session Cache is not configured [hint: 
SSLSessionCache]
[Fri Oct 03 12:18:38 2003] [info] Init: Initializing (virtual) servers for SSL
[Fri Oct 03 12:18:38 2003] [info] Server: Apache/2.0.47, Interface: mod_ssl/2.0.
47, Library: OpenSSL/0.9.7c
[Fri Oct 03 12:18:38 2003] [notice] LDAP: Built with OpenLDAP LDAP SDK
[Fri Oct 03 12:18:38 2003] [notice] LDAP: SSL support available
[Fri Oct 03 12:18:38 2003] [info] Init: Initializing OpenSSL library
[Fri Oct 03 12:18:38 2003] [info] Init: Seeding PRNG with 0 bytes of entropy
[Fri Oct 03 12:18:38 2003] [info] Init: Generating temporary RSA private keys 
(512/1024 bits)
[Fri Oct 03 12:18:38 2003] [info] Init: Generating temporary DH parameters 
(512/1024 bits)
[Fri Oct 03 12:18:38 2003] [info] Init: Initializing (virtual) servers for SSL
[Fri Oct 03 12:18:38 2003] [info] Server: Apache/2.0.47, Interface: mod_ssl/2.0.
47, Library: OpenSSL/0.9.7c
[Fri Oct 03 12:18:38 2003] [debug] util_ldap.c(1104): [5615] ldap cache init: 
Error 0
[Fri Oct 03 12:18:38 2003] [notice] Apache/2.0.47 (Unix) mod_ssl/2.0.47 
OpenSSL/0.9.7c configured -- resuming normal operations
[Fri Oct 03 12:18:38 2003] [info] Server built: Oct  3 2003 12:07:30
[Fri Oct 03 12:18:38 2003] [debug] prefork.c(1037): AcceptMutex: pthread 
(default: pthread)
[Fri Oct 03 12:18:38 2003] [debug] util_ldap.c(1104): [5616] ldap cache init: 
Error 0
[Fri Oct 03 12:18:38 2003] [debug] util_ldap.c(1104): [5617] ldap cache init: 
Error 0
[Fri Oct 03 12:18:38 2003] [debug] util_ldap.c(1104): [5619] ldap cache init: 
Error 0
[Fri Oct 03 12:18:39 2003] [debug] util_ldap.c(1104): [5620] ldap cache init: 
Error 0
[Fri Oct 03 12:19:13 2003] [debug] mod_auth_ldap.c(343): [client xxx] [5615] 
auth_ldap authenticate: using URL ...
[Fri Oct 03 12:19:13 2003] [debug] mod_auth_ldap.c(343): [client xxx] [5616] 
auth_ldap authenticate: using URL ...
[Fri Oct 03 12:19:13 2003] [debug] mod_auth_ldap.c(343): [client xxx] [5617] 
auth_ldap authenticate: using URL ...
[Fri Oct 03 12:19:14 2003] [debug] mod_auth_ldap.c(343): [client xxx] [5619] 
auth_ldap authenticate: using URL ...
[Fri Oct 03 12:19:14 2003] [debug] mod_auth_ldap.c(343): [client xxx] [5620] 
auth_ldap authenticate: using URL ...
[Fri Oct 03 12:19:14 2003] [notice] child pid 5620 exit signal Bus error (10)
[Fri Oct 03 12:19:14 2003] [notice] child pid 5619 exit signal Bus error (10)
[Fri Oct 03 12:19:14 2003] [notice] child pid 5617 exit signal Bus error (10)
[Fri Oct 03 12:19:14 2003] [notice] child pid 5616 exit signal Bus error (10)
[Fri Oct 03 12:19:14 2003] [notice] child pid 5615 exit signal Bus error (10)
[Fri Oct 03 12:19:14 2003] [debug] util_ldap.c(1104): [5644] ldap cache init: 
Error 0
[Fri Oct 03 12:19:15 2003] [debug] util_ldap.c(1104): [5646] ldap cache init: 
Error 0
[Fri Oct 03 12:19:15 2003] [debug] util_ldap.c(1104): [5647] ldap cache init: 
Error 0
[Fri Oct 03 12:19:16 2003] [debug] util_ldap.c(1104): [5651] ldap cache init: 
Error 0
[Fri Oct 03 12:19:16 2003] [debug] util_ldap.c(1104): [5653] ldap cache init: 
Error 0
[Fri Oct 03 12:19:16 2003] [debug] util_ldap.c(1104): [5652] ldap cache init: 
Error 0
[Fri Oct 03 12:19:16 2003] [debug] util_ldap.c(1104): [5657] ldap cache init: 
Error 0
[Fri Oct 03 12:19:18 2003] [info] removed PID file /etc/apache2/logs/httpd.pid 
(pid=5614)
[Fri Oct 03 12:19:18 2003] [notice] caught SIGTERM, shutting down
Comment 31 Christian LECLERC 2003-10-22 16:58:44 UTC
Hello All,

I just compiled Apache 2.0.47 using ldap modules on Solaris with ldap libraires 
generated by compiling OpenLDAP 2.1.23. Apache core dump systematically in the 
mod_auth_ldap_parse_url function. Apparently the ldap url is never correctly 
parsed.

When I'm trying to access a page protected by an LDAP .htaccess, 
the child crashs and generates the following errors log on LDAP url parsing 
with strange server and port info:
[Wed Oct 22 17:52:32 2003] [debug] prefork.c(1037): AcceptMutex: pthread
(default: pthread)
[Wed Oct 22 17:52:39 2003] [debug] mod_auth_ldap.c(737): [25927] auth_ldap url 
parse: `ldap://myserver:389/mysearchbase?sAMAccountName?sub?(objectClass=*)'
[Wed Oct 22 17:52:39 2003] [debug] mod_auth_ldap.c(758): [25927] auth_ldap url 
parse: Host: mysearchbase
[Wed Oct 22 17:52:39 2003] [debug] mod_auth_ldap.c(760): [25927] auth_ldap url 
parse: Port: 1230072
[Wed Oct 22 17:52:40 2003] [notice] child pid 25927 exit signal Segmentation 
fault (11)

When I include the LDAP restrictions in my httpd.conf file, apachectl core 
dumps in the LDAP url parsing too. Here is the gdb traces:

#0  0x0002ae14 in mod_auth_ldap_parse_url (cmd=0xffbefbd8, config=0xdfb20, 
    url=0xdfc20 "ldap://myserver:389/searchBase?sAMAccountName?sub?
(objectClass=*)") at mod_auth_ldap.c:764
764         ap_log_error(APLOG_MARK, APLOG_DEBUG|APLOG_NOERRNO, 0,

My configure options were:
./configure --prefix=/usr/local/apache2_withldap --enable-so --with-ldap --
enable-ldap --enable-auth-ldap --libdir=/usr/local/openldap-2.1.23/li
b --includedir=/usr/local/openldap-2.1.23/include
 
Here is my .htaccess file:
AuthName "RCS Staff only"
AuthType Basic
AuthLDAPEnabled on
AuthLDAPAuthoritative on
#AuthLDAPBindDN username
#AuthLDAPBindPassword password
AuthLDAPURL "ldap://myserver:389/mysearchbase?sAMAccountName?sub(objectClass=*)"
require valid-user 

I followed the temporary workaround (disabling ldap cache) and recompile Apache 
after adding the last patch without success.

Christian
Comment 32 Matthieu Estrade 2003-10-29 11:50:52 UTC
Hi,

For the last comment, i agree it's not normal apache segfault parsing the url, 

You seem want to do authentication against active directory which is impossible
with mod_auth_ldap. 
Dealing with active directory for user/access is different than ldap auth.
First you have to bind with a authorized user/pass to the active directory and
get the name of the user (not the login), then you have to bind with this name
and password you receive and look if bind is ok,
if bind ok, then the user is valid.

I should get an access on a solaris (sparc) box soon (finally) and then continue
working on all these bugs. Somebody could tell me with which compiler (gcc or
sun) did they use to compile Apache ?

Matthieu
Comment 33 The Written Word 2003-11-05 02:44:08 UTC
Patch id #8185 appears to work fine on FreeBSD 4.8-STABLE.
Comment 34 Erwin Horjus 2003-11-06 09:37:50 UTC
Hi,

I'm using the following combinations with netscape sdk:
Solaris 9 with gcc version 3.3
Solaris 8 with gcc version 2.95.3

Both combinations produce the error "exit signal Bus error".

Erwin
Comment 35 jemiller 2003-11-06 15:01:39 UTC
What happened to the developer that made the changes that broke it? Why 
doesn't someone roll the changes back? It worked fine before. It's been broken 
for 8 months now. This is ridiculus.
Comment 36 Matthieu Estrade 2003-11-06 15:21:25 UTC
I dunno what you want to roll back, but after check again the CVS, nothing
important has been done after the port of ldap cache to apache 2.0., and it's
older more than 1 year...

Maybe you speak about apache 1.3 ??

I agree it maybe worked with mpm prefork, a lucky day, but be sure that
considering what the patch do, it's impossible it worked a day with mpm using
threads.

For the developper who did "the changes that brokes it", i hope he is still
alive and i don't think somebody should do something to him, even if he did an
error.

I think people are doing here an effort to make the shared memory ldap cache
working better and be stable, so please don't post such message if you find it
ridiculous...

Comment 37 jemiller 2003-11-06 16:37:49 UTC
All I know is that I had it working fine with 2.0.44. They made changes in 
2.0.45 including changes in the syntax for using TLS/SSL and it hasn't worked 
since.
Comment 38 Matthieu Estrade 2003-11-06 17:07:17 UTC
Hi again jemiller,

To help, you could tell us what OS are you using, the LDAP library you are
using, if you setup cache, the mpm you compiled with, and if you applyied one
patch posted here.

Them if your problem is when you startup apache 
-> so probably the url parsing problem

Or if the problem is when a client is trying to authenticate.
-> so probably the cache problem.

Thanks in advance
Comment 39 jemiller 2003-11-06 21:56:52 UTC
My original bug report is located at 
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19993.

I just tried it again using Solaris 8 with a recent patch cluster installed, 
Apache 2.0.48, OpenLDAP 2.1.23, and OpenSSL 0.9.7c. I'm using the default 
cache setting. According the the configure log, it's using "prefork" MPM. I 
didn't use any patches.

I used the following command line to configure it.

CPPFLAGS=-I/opt/include LDFLAGS=-L/opt/lib ./configure --
prefix=/opt/pkgs/httpd-2.0.48 --enable-ssl --with-ldap --enable-ldap --enable-
auth-ldap 2>&1 | tee configure.txt

According the the LDAP server logs, it is able to connection and bind 
successfully. I receive the following error in the error_log file.

[Thu Nov 06 15:35:56 2003] [notice] child pid 24270 exit signal Bus error (10)

Also, it doesn't appear to be using TLS like it should be. Until version 
2.0.45, you could use the AuthLDAPStartTLS directive to enable TLS. In version 
2.0.45, according to the documentation you have to use LDAPTrustedCA and 
LDAPTrustedCAType directives (AuthLDAPStartTLS is no longer recognized). This 
seemed to work in version 2.0.45. However, now, it doesn't seem to work.

To work around that problem, I reconfigured my LDAP server to allow non-
encrypted binds. This resulted in the bus error listed above.
Comment 40 Matthieu Estrade 2003-11-07 11:54:39 UTC
New patch fixing another possible segfault condition.
You can find all patches and howto at the following address:

http://www.apache.org/~trawick/
ldap.20031107.readme and ldap.20031107.tar.gz

Please when you report bugs here, be sure you applied correctly all patches.
You can also use CVS to checkout the latest and patched code of HTTP (2.1)

Thanks for your help

Comment 41 Erwin Horjus 2003-11-07 16:34:07 UTC
The patch ldap.20031107.tar.gz works for me on Solaris 9 and Apache 2.0.48 with
most simply settings (no ldap cache directives):

 <LocationMatch / >
    AuthName "some realm"
    AuthType basic
    AuthLDAPEnabled on
    AuthLDAPURL "<ldap-url>"
    AuthLDAPAuthoritative on
    require valid-user
 </LocationMatch>

Thanks
Comment 42 Markus Schiegl 2003-11-10 16:50:44 UTC
results when using the new patch (from Matthieu):

system:
SunOS 5.8 Generic_108528-23 sun4u sparc SUNW,UltraAX-i2
OpenSSL 0.9.7c
OpenLdap 2.1.23
Apache 2.0.48

this time i even have to use the LDAPSharedCacheFile statement
to enable the LDAP Cache, my settings:

   LDAPCacheEntries 1024
   LDAPCacheTTL 600
   LDAPOpCacheEntries 1024
   LDAPOpCacheTTL 600
   LDAPSharedCacheFile logs/ldap_cache_file

if i do not use this tag, the ldap-cache will not become initialized (verified 
with ldap-status) but authentication works ok.

nevertheless enabling the ldap-cache and authenticating a user with the 
correct password results in the following message in the error log

[Fri Nov 07 22:20:31 2003] [notice] child pid 29464 exit signal Bus error 
(10), possible coredump in /opt/httpd

backtrage of core file:

(gdb) bt
#0  util_ald_create_cache (st=0x1eab08, hashfunc=0x49b90 
<util_ldap_search_node_hash>, 
    comparefunc=0x49ba8 <util_ldap_search_node_compare>, copyfunc=0x49bc8 
<util_ldap_search_node_copy>, 
    freefunc=0x49cfc <util_ldap_search_node_free>) at util_ldap_cache_mgr.c:330
#1  0x4a44c in util_ald_create_caches (st=0x1eab08, 
    url=0x1db410 "ldap://host:389/CN=Users,DC=part1,DC=part2?sAMAccountName?
one?(objectClass=person)") at util_ldap_cache_mgr.c:258
#2  0x48f24 in util_ldap_cache_checkuserid (r=0x30dd90, ldc=0x20db28, 
    url=0x1db410 "ldap://host:389/CN=Users,DC=part1,DC=part2?sAMAccountName?
one?(objectClass=person)", basedn=0x1db480 "CN=Users,DC=part1,DC=part2", 
scope=1, attrs=0x1db4a0, 
    filter=0xfe2018f0 "(&(objectClass=person)(sAMAccountName=username))", 
bindpw=0x30faef "password", 
    binddn=0xfe2018e8, retvals=0xfe2018e4) at util_ldap.c:764
#3  0x4b228 in mod_auth_ldap_check_user_id (r=0x30dd90) at mod_auth_ldap.c:366
#4  0xab174 in ap_run_check_user_id (r=0x30dd90) at request.c:112
#5  0xabac0 in ap_process_request_internal (r=0x30dd90) at request.c:235
#6  0x77f90 in ap_process_request (r=0x30dd90) at http_request.c:286
#7  0x73378 in ap_process_http_connection (c=0x2e6890) at http_core.c:293
#8  0x9f66c in ap_run_process_connection (c=0x2e6890) at connection.c:85
#9  0x9f958 in ap_process_connection (c=0x2e6890, csd=0x2e67a0) at 
connection.c:211
#10 0x90964 in process_socket (p=0x2e6890, sock=0x2e67a0, my_child_num=0, 
my_thread_num=3, 
    bucket_alloc=0x2f7d88) at worker.c:632
#11 0x91044 in worker_thread (thd=0x1eb510, dummy=0x3) at worker.c:946
#12 0xff275d84 in dummy_worker (opaque=0x1eb510) at thread.c:127

if anyone needs more informations or if i should test anything feel free to 
ask...

have a nice day,
   MarkuS
Comment 43 Paul Querna 2003-11-16 19:35:00 UTC
All built from Source from CVS -HEAD
OS: FreeBSD 5.1-CURRENT

backtrace:
#0  apr_rmm_calloc (rmm=0xd0d0d0d0, reqsize=99) at apr_rmm.c:344
#1  0x2908c8a2 in util_ald_alloc (cache=0x8139288, size=3503345872) at
util_ldap_cache_mgr.c:141
#2  0x2908cbc0 in util_ald_create_cache (st=0x80d15b8, hashfunc=0xd0d0d0d0,
comparefunc=0xd0d0d0d0, copyfunc=0xd0d0d0d0, freefunc=0xd0d0d0d0)
    at util_ldap_cache_mgr.c:304
#3  0x2908c804 in util_ldap_cache_init (pool=0x809b018, st=0x80d15b8) at
util_ldap_cache.c:324
#4  0x2908c044 in util_ldap_post_config (p=0x809b018, plog=0x80c5018,
ptemp=0x80c7018, s=0x80b51e0) at util_ldap.c:1147
#5  0x08063752 in ap_run_post_config (pconf=0x809b018, plog=0x80c5018,
ptemp=0x80c7018, s=0x80b51e0) at config.c:131
#6  0x08068658 in main (argc=3, argv=0xbfbffb48) at main.c:618
#7  0x0805c269 in _start ()

It seems that in util_ldap_cache_mgr.c around line 300 we do this:

#if APR_HAS_SHARED_MEMORY
cache = (util_ald_cache_t *)util_ald_alloc(st->cache_rmm, sizeof(util_ald_cache_t));
#else


But the util_ald_alloc function expects a util_ald_cache_t type, and we are
passing in a apr_rmm_t. util_ald_alloc then does:

if (cache->rmm_addr) {
/* allocate from shared memory */
return (void *)apr_rmm_addr_get(cache->rmm_addr, apr_rmm_calloc(cache->rmm_addr,
size));
}

Since we passed in an apr_rmm_t, it does a nice crash when we try todo all the
stuff with cache->rmm_addr.
Comment 44 Dave Arcuri 2003-11-18 20:14:45 UTC
Solaris 8
OpenLDAP 2.1.23
Apache 2.0.48 with Mathieu's patch

Same problems as everyone else reports.  Apache child processes die with bus 
errors on the first LDAP query.  Applying the patch recommended above had no 
effect whatsoever.  I get bus errors multiple times, but I cannot get it to dump 
core anywhere.
Comment 45 Dave Arcuri 2003-11-18 20:36:40 UTC

Nevermind, I figured it out.  Sorry for the double.


GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.8"...
Core was generated by `bin/httpd -f conf/MYSITE_CENSORED.com.conf -k start'.
Program terminated with signal 9, Killed.
Reading symbols from /usr/local/apache2/lib/libaprutil-0.so.0...done.
Loaded symbols for /usr/local/apache2/lib/libaprutil-0.so.0
Reading symbols from /usr/local/lib/libldap.so.2...done.
Loaded symbols for /usr/local/lib/libldap.so.2
Reading symbols from /usr/lib/libgen.so.1...done.
Loaded symbols for /usr/lib/libgen.so.1
Reading symbols from /usr/local/ssl/lib/libssl.so.0.9.7...done.
Loaded symbols for /usr/local/ssl/lib/libssl.so.0.9.7
Reading symbols from /usr/local/ssl/lib/libcrypto.so.0.9.7...done.
Loaded symbols for /usr/local/ssl/lib/libcrypto.so.0.9.7
Reading symbols from /usr/local/lib/liblber.so.2...done.
Loaded symbols for /usr/local/lib/liblber.so.2
Reading symbols from /usr/local/BerkeleyDB.4.1/lib/libdb-4.1.so...done.
Loaded symbols for /usr/local/BerkeleyDB.4.1/lib/libdb-4.1.so
Reading symbols from /usr/local/lib/libexpat.so.0...done.
Loaded symbols for /usr/local/lib/libexpat.so.0
Reading symbols from /usr/local/apache2/lib/libapr-0.so.0...done.
Loaded symbols for /usr/local/apache2/lib/libapr-0.so.0
Reading symbols from /usr/lib/libsendfile.so.1...done.
Loaded symbols for /usr/lib/libsendfile.so.1
Reading symbols from /usr/lib/librt.so.1...done.
Loaded symbols for /usr/lib/librt.so.1
Reading symbols from /usr/lib/libm.so.1...done.
Loaded symbols for /usr/lib/libm.so.1
Reading symbols from /usr/lib/libsocket.so.1...done.
Loaded symbols for /usr/lib/libsocket.so.1
Reading symbols from /usr/lib/libnsl.so.1...done.
Loaded symbols for /usr/lib/libnsl.so.1
Reading symbols from /usr/lib/libresolv.so.2...done.
Loaded symbols for /usr/lib/libresolv.so.2
Reading symbols from /usr/lib/libdl.so.1...done.
Loaded symbols for /usr/lib/libdl.so.1
Reading symbols from /usr/lib/libpthread.so.1...done.
Loaded symbols for /usr/lib/libpthread.so.1
Reading symbols from /usr/lib/libc.so.1...done.
Loaded symbols for /usr/lib/libc.so.1
Reading symbols from /usr/local/lib/libgcc_s.so.1...done.
Loaded symbols for /usr/local/lib/libgcc_s.so.1
Reading symbols from /usr/lib/libaio.so.1...done.
Loaded symbols for /usr/lib/libaio.so.1
Reading symbols from /usr/lib/libmp.so.2...done.
Loaded symbols for /usr/lib/libmp.so.2
Reading symbols from /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1...done.
Loaded symbols for /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1
Reading symbols from /usr/lib/libthread.so.1...done.
Loaded symbols for /usr/lib/libthread.so.1
Reading symbols from /usr/lib/nss_nisplus.so.1...done.
Loaded symbols for /usr/lib/nss_nisplus.so.1
Reading symbols from /usr/lib/libdoor.so.1...done.
Loaded symbols for /usr/lib/libdoor.so.1
#0  util_ald_create_cache (st=0x105048, hashfunc=0x32068 
<util_ldap_search_node_hash>, 
    comparefunc=0x3207c <util_ldap_search_node_compare>, 
    copyfunc=0x320a0 <util_ldap_search_node_copy>, freefunc=0x321c4 
<util_ldap_search_node_free>)
    at util_ldap_cache_mgr.c:332
332     util_ldap_cache_mgr.c: No such file or directory.
(gdb) bt
#0  util_ald_create_cache (st=0x105048, hashfunc=0x32068 
<util_ldap_search_node_hash>, 
    comparefunc=0x3207c <util_ldap_search_node_compare>, 
    copyfunc=0x320a0 <util_ldap_search_node_copy>, freefunc=0x321c4 
<util_ldap_search_node_free>)
    at util_ldap_cache_mgr.c:332
#1  0x328a8 in util_ald_create_caches (st=0x0, 
    url=0x10e9d8 "ldap://CENSORED:389/o=CENSORED,c=us?uid?sub") at 
util_ldap_cache_mgr.c:258
#2  0x31834 in util_ldap_cache_checkuserid (r=0x179558, ldc=0x114468, 
    url=0x10e9d8 "ldap://CENSORED:389/o=CENSORED,c=us?uid?sub", basedn=0x10ea20 
"o=CENSORED,c=us", 
    scope=2, attrs=0x10ea30, filter=0xfdd07960 "(&(objectclass=*)(uid=CENSORED))
", 
    bindpw=0x17b304 "MY_PLAINTEXT_PASSWORD", binddn=0xfdd07958, 
retvals=0xfdd07954) at util_ldap.c:764
#3  0x335ac in mod_auth_ldap_check_user_id (r=0x179558) at mod_auth_ldap.c:366
#4  0x802ac in ap_run_check_user_id (r=0x179558) at request.c:112
#5  0x80b64 in ap_process_request_internal (r=0x179558) at request.c:259
#6  0x54ac4 in ap_process_request (r=0x179558) at http_request.c:286
#7  0x4ffb4 in ap_process_http_connection (c=0x173630) at http_core.c:293
#8  0x74d50 in ap_run_process_connection (c=0x173630) at connection.c:85
#9  0x66298 in process_socket (p=0x173508, sock=0x173540, my_child_num=0, 
my_thread_num=0, 
    bucket_alloc=0x177518) at worker.c:632
#10 0x669c0 in worker_thread (thd=0x115570, dummy=0x173508) at worker.c:946
#11 0xfef9459c in dummy_worker (opaque=0x115570) at thread.c:127
(gdb) 
Comment 46 Dave Arcuri 2003-11-18 21:11:45 UTC
And again ... Wish I could edit comments.

I manually defined APR_HAS_SHARED_MEMORY to be 0 and I successfully got the LDAP 
cache functionality to work without erroring.  The relevant file is 
modules/experimental/util_ldap_cache_mgr.c.  You basically want it to use the 
calloc() and free() functions instead of the apr_rmm_xxxx functions.

I hope this points someone in the right direction to make a real fix, but if you 
absolutely need this functionality, this is how you can get it.  Sorry, I have 
no official patch, because this is a temporary hack to get this to work in my 
environment.

Solaris 8, OpenLDAP 2.1.23, Apache 2.0.48 (with Matthieu's patch)
Comment 47 Matthieu Estrade 2003-11-18 21:23:43 UTC
Hi,

As you said it's a hack to work in your environment.
Adding and modifying the Tags for SHM just disabled it, and no, we have to 
make it work with shm :)

Disabling shm, you make the ldap cache not working well on threaded mpm. 
For example, with worker mpm, you will have a cache context for all forked 
server, and only thread inside will be able to use the cache, in each server.

Shared memory is providing a common cache data for all threaded and forked 
server.

So yes, you did a hack to make it work, but it's not a solution here :)
What i will do in the next patch is to display in debug mode, which memory 
management it will use, and continue effort to make it stable.

Matthieu

Comment 48 Jeff Trawick 2003-11-21 22:17:30 UTC
enabling the PatchAvailable keyword
updated doc on submitting patches is at http://httpd.apache.org/dev/patches.html
Comment 49 Gottsch 2004-02-16 15:52:45 UTC
Hi all,

my Problem in this Kontext:

if i add the line AuthLDAPURL in httpd.conf i cant start apache without SIGSEGV.

System is:
Solaris 8
gcc 3.1
httpd 2.0.48
openssl 0.9.7c
openldap 2.1.25

my ConfigureScript looks like:
LIBS="-L/opt/openldap/current/lib" \
INCLUDES="-I/opt/openldap/current/include" \
./configure \
--disable-autoindex \
--disable-asis \
--disable-userdir \
--disable-cgid \
--disable-cgi \
--disable-imap \
--enable-info \
--enable-proxy \
--enable-ssl \
--enable-headers \
--enable-ldap \
--enable-auth-ldap \
--with-ssl=/opt/openssl/current \
--with-ldap \
--with-mpm=worker 

httpd.conf:
------------------------------
......
........
LDAPSharedCacheSize 200000
LDAPCacheEntries 1024
LDAPCacheTTL 600
LDAPOpCacheEntries 1024
LDAPOpCacheTTL 600

<VirtualHost  10.1.1.11:443>
    ServerName test
....
...
    <Location /cbt>
#	AuthType Basic
#	AuthName cbt
#	AuthUserFile conf/auth_user_file
#	require valid-user

	AuthLDAPEnabled on
	AuthLDAPAuthoritative on
	AuthLDAPURL "ldap://ldap.net.de/c=DE"
	require valid-user
    </Location>
.........
........
.......
</VirtualHost>
-------------------------------------------

when i uncomment the line:

AuthLDAPURL "ldap://ldap.net.de/c=DE"

i can start Apache.


here ist my Backtrace:
-------------------------------------------
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.8"...
Core was generated by `/opt/webservers/apache/test0/2.0.48/bin/httpd -k st'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /opt/webservers/apache/test0/2.0.48/lib/libaprutil-
0.so.0...done.
Loaded symbols for /opt/webservers/apache/test0/2.0.48/lib/libaprutil-0.so.0
Reading symbols from /usr/local/lib/libldapssl30.so...done.
Loaded symbols for /usr/local/lib/libldapssl30.so
Reading symbols 
from /opt/webservers/apache/test0/2.0.48/lib/libexpat.so.0...done.
Loaded symbols for /opt/webservers/apache/test0/2.0.48/lib/libexpat.so.0
Reading symbols from /usr/local/lib/libiconv.so.2...done.
Loaded symbols for /usr/local/lib/libiconv.so.2
Reading symbols from /opt/webservers/apache/test0/2.0.48/lib/libapr-
0.so.0...done.
Loaded symbols for /opt/webservers/apache/test0/2.0.48/lib/libapr-0.so.0
Reading symbols from /lib/libsendfile.so.1...done.
Loaded symbols for /lib/libsendfile.so.1
Reading symbols from /lib/librt.so.1...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libm.so.1...done.
Loaded symbols for /lib/libm.so.1
Reading symbols from /lib/libsocket.so.1...done.
Loaded symbols for /lib/libsocket.so.1
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libdl.so.1...done.
Loaded symbols for /lib/libdl.so.1
Reading symbols from /lib/libpthread.so.1...done.
Loaded symbols for /lib/libpthread.so.1
Reading symbols from /lib/libc.so.1...done.
Loaded symbols for /lib/libc.so.1
Reading symbols from /lib/libthread.so.1...done.
Loaded symbols for /lib/libthread.so.1
Reading symbols from /lib/libaio.so.1...done.
Loaded symbols for /lib/libaio.so.1
Reading symbols from /lib/libmp.so.2...done.
Loaded symbols for /lib/libmp.so.2
Reading symbols from /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1...done.
Loaded symbols for /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1
#0  0xfee33174 in strlen () from /lib/libc.so.1
(gdb) run
Starting program: /opt/webservers/apache/test0/2.0.48/bin/httpd 
[New LWP 1]
[New LWP 2]
[New LWP 3]
[New LWP 4]

Program received signal SIGSEGV, Segmentation fault.
0xfee33174 in strlen () from /lib/libc.so.1
(gdb) 
-------------------------------------------


So i read all the Reports, is there a Patch for this Problem ?? 
I read something about caching and shm but i dont really know, i think my Bug 
is a little diffrent.

Steve Waltner had the same Problem in 2003 i think.

i'd like to know what is happening with this bug ? its NEW since beginning of 
2003

friendly Regards
Christian
Comment 50 Jess Holle 2004-02-17 16:40:45 UTC
Note: I still get the core dump when I apply the very latest (i.e. latest 
available yesterday) sources from the Apache 2.0 branch.  On a positive note, 
these just compile against 2.0.48 and don't have to be fiddled with (like those 
from Apache 2.1 did to work with 2.0.48).  Unfortunately, the core dump on 
first attempt to authenticate with the cache enabled is still there.

[2.0.48, worker, Solaris 8]
Comment 51 Jess Holle 2004-02-17 16:59:25 UTC
Backtrace (using latest 2.0 branch sources for util_ldap and mod_auth_ldap +
2.0.48 base):

current thread: t@6
=>[1] util_ald_create_cache(0xb7688, 0xfea53cb8, 0xfea53cd0, 0xfea53cf0,
0xfea53e20, 0x148), at 0xfea54850
  [2] util_ald_create_caches(), at 0xfea545e0
  [2] util_ald_create_caches(0xb7688, 0xd81f0, 0x84da0, 0x0, 0xfea33623, 0x6e),
at 0xfea545e0
  [3] util_ldap_cache_checkuserid(r = 0x15b0c8, ldc = 0xfda00, url = 0xd81f0 "ld
ap://jholle03l.ptcnet.ptc.com/ou=people,cn=pdm7,cn=jholle03l,cn=Application%20Se
rvices,o=ptc", basedn = 0xd8270 "ou=people,cn=pdm7,cn=jholle03l,cn=Application S
ervices,o=ptc", scope = 2, attrs = (nil), filter = 0xfd8058f0 "(&(objectclass=*)
(uid=wcadmin))", bindpw = 0x15c5d0 "wcadmin", binddn = 0xfd8058e8, retvals =
0xfd8058e4), line 725 in "util_ldap.c"
  [4] mod_auth_ldap_check_user_id(r = 0x15b0c8), line 327 in "mod_auth_ldap.c"
  [5] ap_run_check_user_id(0x15b0c8, 0x62c00, 0x0, 0x2d, 0x29, 0x15b248), at 0x4c784
  [6] ap_process_request_internal(0x15b0c8, 0x0, 0x4, 0x15b0c8, 0x60000,
0x15bdc8), at 0x4d0d0
  [7] ap_process_request(0x15b0c8, 0xc8, 0x15b0c8, 0x14b178, 0x0, 0x0), at 0x321c0
  [8] ap_process_http_connection(0x14b178, 0x2d55c, 0x79400, 0x79400, 0x0,
0x14b1cd), at 0x2d5a8
  [9] ap_run_process_connection(0x14b178, 0x80000000, 0x14b088, 0x1, 0x14b170,
0x159088), at 0x40eec
  [10] ap_process_connection(0x14b178, 0x14b088, 0x14b088, 0x1, 0x14b170,
0x159088), at 0x411d8
  [11] process_socket(0x14b178, 0x14b088, 0x0, 0x1, 0x159088, 0x0), at 0x335b8
  [12] worker_thread(0x0, 0x1, 0x5c400, 0x5c400, 0x1117e, 0x9d410), at 0x33c98
  [13] dummy_worker(0x9d410, 0xfebd5d10, 0x0, 0x5, 0x1, 0xfe401000), at 0xfef15838
Comment 52 Jess Holle 2004-02-19 02:47:36 UTC
This appears to be triggering a gcc on Sparc bug -- read on...

Note the backtrace given above was hard to obtain, e.g. I could only obtain it 
when *not* using maintainer mode on configure, etc.

Once I put breakpoints in the routine in question in each child process I 
could single step through the assembly (for some reason I did not have source-
level information even when building with maintainer mode enabled and thus -g -
- pointers as to how this might happen would be appreciated) until it blew up.

The offending assembly instruction is 'std' (this is on Sparc Solaris 8) and 
the error is an invalid alignment error.  This smelled of a compiler bug -- 
and sure enough google has lots of claims of various versions of gcc making 8-
byte alignment assumptions when it can't legitimately do so -- and then using 
ldd and std instructions which require such alignment.  Thus seeing this only 
as assembly was not a bad thing -- except that I need to carefully verify 
which struct field its blowing up on...

Does anyone know of a gcc version that is known to have this error fixed?  
Alternatively, does someone know of flags to pass gcc to work around this?  
Note this error appears to be specific to -O2 optimization (which I removed 
from my configure env vars, but I can't seem to get rid of it).  Ideally the 
source for this module or the gcc compilation options for just it (not all of 
Apache) could be adjusted to skirt this issue.

I'll be playing with the possibilities here...

[I'm currently still using the ancient gcc 2.95.2 as it's what's already 
installed on the machine.]
Comment 53 Jess Holle 2004-02-19 03:09:06 UTC
I *believe* that the field causing issues (from the latest Apache 2 branch 
sources) is avg_purgetime.  I'll try replacing it with a float tomorrow as a 
double seems unnecessary (apart from an insignificant purge speed difference).
Comment 54 Jess Holle 2004-02-19 23:38:33 UTC
Okay on a little further examination I am still getting an alignment bus error 
from an std instruction BUT it would appear all the structure offsets are 8-
byte aligned -- which I guess means the structure allocated by APR's rmm is 
not?!?  If so, this would appear *not* to be the gcc bug.

This all seems hard to believe...

[I applied the latest apr_rmm.c to no avail.]

Note that diffing the rudedog.org and latest Apache 2 sources for 
util_ldap_cache_mgr.c seems to indicate that the main switch in the routine 
that's crashing is from MM to APR's rmm....
Comment 55 Jess Holle 2004-02-20 21:29:10 UTC
I have finally cried "uncle" for now (i.e. given up) and am simply replacing 
all "#if APR_HAS_SHARED_MEMORY" occurences with "#if 0" in the mod_ldap .c 
files (I left the headers alone).  This results in 1 LDAP cache per process.

I was already using mod_worker, so now I'm just increasing the number of 
threads per process a bit and thus limiting the number of processes and thus 
limiting the number of redundant LDAP caches and entries.

The result seems to work just fine -- and should be faster than disabling the 
cache entirely.
Comment 56 Joe Orton 2004-02-20 22:56:04 UTC
Has the issue where the apr_rmm_*alloc return values are ignored been fixed?
Comment 57 Michael L. Gantz 2004-02-29 23:03:11 UTC
Has an official fix for this bug been created?  I've been able to work around
this using the disable shared memory hack, but that is not an elegant solution.
 This bug does not appear in the httpd delivered with Fedora Core 1, but I need
to compile my own, and am bouncing into this issue.

Any help would be appreciated.
Comment 58 Jess Holle 2004-03-04 18:23:41 UTC
Note: I got what appears to be the same exact crash with a mod_worker Apache 
2.0.48 + latest LDAP related patches from 2.0 branch (same stuff I tested on 
Solaris) built with iPlanet LDAP SDK.

As soon as I applied the patch to pretend shared memory does not exist in to 
the module sources, it seemed to work fine...

Whatever the problem is, shm, rmm, or mod/util_ldap, a fix would be *very* much 
appreciated!
Comment 59 Jess Holle 2004-03-04 18:24:55 UTC
Ooops.  I forgot to include the most relevant piece of information in my last 
comment.  The Apache I just tested was on AIX 5.1.  Thus this is by no means 
limited to Solaris.
Comment 60 Paul Querna 2004-05-06 23:40:23 UTC
*** Bug 28716 has been marked as a duplicate of this bug. ***
Comment 61 Graham Leggett 2004-05-21 14:05:12 UTC
Can someone confirm whether this bug still bites using the latest LDAP from
v2.1.0-dev? There have been a number of bugfix commits, I would like to know if
this bug has been squashed.
Comment 62 Jess Holle 2004-05-21 14:16:20 UTC
I can confirm that this bug exists in 2.0.49 (with or without Brad Nicholes
latest changes to squash the authenticated LDAP access issues).  I have not
tried 2.1.0 anything.

Also, the cache overflow crash is still present in 2.0.49.  [I forget the bug #,
but when more distinct users authenticate against Apache than what you've sized
the cache for the child process will die.  If this does not happen on cache size
+ 1 users it always happens by cache size + 5 or so users.]

Squashing these 2 issues would do wonders for LDAP authentication via Apache and
would, in my opinion, justify moving this module out of experimental.  Both of
these issues are pretty severe, however.  They don't preclude use of the module
for LDAP authentication, but they require some hefty workarounds (disabling
cache sharing between processes and sizing the LDAP cache to hold your entire
user population -- which may be excessive).
Comment 63 Graham Leggett 2004-05-21 17:24:24 UTC
Note to all: this bug report is discussing many different bugs in the same
place. These include:

- crash inside mod_auth_ldap_parse_url(): #21719
- crash in LDAP cache util_ldap_search_node_copy(): #28250
- crashes when distinct users exceeds LDAPCacheEntries: #24801

I think it would be more helpful to continue the discussion under each specific
report above.
Comment 64 Jess Holle 2004-05-21 17:30:15 UTC
Hmmm...  I guess I don't know where exactly it crashes recently, but at least
one of my previous notes was of it crashing in util_ald_create_cache().

In any event, I consistently have it crash on the very first request requiring
LDAP authentication (with 2.0.49 on Solaris and AIX, but not on Windows)
unless/until I disable sharing of the caches across processes -- at which point
I only have the cache overflow issue, which I agree is a very separate and
distinct bug.
Comment 65 Graham Leggett 2004-05-22 01:34:29 UTC
So if I am understanding right, sharing across processes causes an immediate
crash, while sharing across threads works - until the cache is full, then crash?
Comment 66 Graham Leggett 2004-05-22 02:09:35 UTC
Try this patch attached to bug 24801:
http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=11633
Comment 67 Jess Holle 2004-05-23 19:55:08 UTC
Yep!
Comment 68 Graham Leggett 2004-05-23 20:34:13 UTC
Yup the patch works, or yup that was the problem...? :)
Comment 69 Jess Holle 2004-05-24 13:49:56 UTC
Yup, that was the problem.

I've not had a chance to test the patch yet.

I will try to get to it today.
Comment 70 Graham Leggett 2004-05-25 17:20:04 UTC
Patches for fixing the segfaults have been applied to v2.1.0-dev and v2.0.50-dev.

The underlying brokenness that caused the segfaults remains however, and is
described in bug 29207. I'm marking this bug as a duplicate of that one to
continue getting to the root of the problem.


*** This bug has been marked as a duplicate of 29207 ***