Re: [PATCH] allow implicit ServerRoot via apxs
Geoffrey Young wrote:
+if ($base = $self-{inherit_config}-{ServerRoot}) {
+debug using inherited ServerRoot $base to resolve $file;
+}
+elsif ($base = $self-apxs('PREFIX')) {
+warning using apxs-derived ServerRoot $base to resolve $file;
+}
+elsif (file_name_is_absolute($file)) {
+debug $file is already absolute;
+return $file
+}
+else {
+error unable to resolve $file - please specify a ,
+ 'ServerRoot in your httpd.conf or use apxs';
+die '';
+}
}
rel2abs $file, $base;
Shouldn't the file_name_is_absolute case be first?
--
Mike Cramer
http://www.webkist.com/ | AIM: MikeWebkist
Re: [PATCH] allow implicit ServerRoot via apxs
+elsif (file_name_is_absolute($file)) {
Shouldn't the file_name_is_absolute case be first?
indeed - I only noticed that case after I had coded the others.
clearly not enough coffee yet :)
--Geoff
Redo of: Diff for flood_net_ssl.c [Ref A1]
See below for explanation of change; attached diff now correct.
-Norman Tuttle, OpenDemand Systems Developer [EMAIL PROTECTED]
On Mon, 13 Oct 2003, Norman Tuttle wrote:
To Apache Flood development team:
Other than some small touch-ups, these changes to flood_net_ssl.c involve
1) taking recursive function code out of socket read/write functions,
(replacing with do .. while loop) resulting in
a) more robust code, with less possibility of stack-related issues.
b) errors returned in recursively-called code were not being propagated.
c) with iterative code it is easier to set limits on the amount of
iteration, if necessary. I have not changed the logic here (yet).
and
2) the addition of certain cases which should cause a continuation of
reading.
--- \flood-1.1\flood_net_ssl.c 2003-10-08 19:25:02.0 -0400
+++ flood_net_ssl.c 2003-11-04 12:06:16.0 -0500
@@ -281,37 +281,41 @@
int sslError;
apr_int32_t socketsRead;
-/* Wait until there is something to read. */
-if (SSL_pending(s-ssl_connection) *buflen) {
+do
+{
+
+ /* Wait until there is something to read. */
+ if (SSL_pending(s-ssl_connection) *buflen) {
e = apr_poll(s-socket-read_pollset, 1, socketsRead,
LOCAL_SOCKET_TIMEOUT);
if (socketsRead != 1)
return APR_TIMEUP;
-}
+ }
-e = SSL_read(s-ssl_connection, buf, *buflen);
-sslError = SSL_get_error(s-ssl_connection, e);
+ e = SSL_read(s-ssl_connection, buf, *buflen);
+ sslError = SSL_get_error(s-ssl_connection, e);
-switch (sslError)
-{
-case SSL_ERROR_NONE:
-*buflen = e;
-break;
-case SSL_ERROR_WANT_READ:
-ssl_read_socket(s, buf, buflen);
-break;
-case SSL_ERROR_ZERO_RETURN: /* Peer closed connection. */
-return APR_EOF;
-case SSL_ERROR_SYSCALL: /* Look at errno. */
-if (errno == 0)
+ switch (sslError)
+ {
+case SSL_ERROR_NONE:
+ *buflen = e;
+ break;
+case SSL_ERROR_WANT_READ:
+case SSL_ERROR_WANT_WRITE:
+case SSL_ERROR_WANT_X509_LOOKUP:
+ break;
+case SSL_ERROR_ZERO_RETURN: /* Peer closed connection. */
+ return APR_EOF;
+case SSL_ERROR_SYSCALL: /* Look at errno. */
+ if (errno == 0)
return APR_EOF;
-/* Continue through with the error case. */
-case SSL_ERROR_WANT_WRITE: /* Technically, not an error. */
-default:
-ERR_print_errors_fp(stderr);
-return APR_EGENERAL;
-}
+ /* else Continue through with the error case. */
+default:
+ ERR_print_errors_fp(stderr);
+ return APR_EGENERAL;
+ }
+} while (sslError != SSL_ERROR_NONE); /* to exit loop: need no error */
return APR_SUCCESS;
}
@@ -334,24 +338,27 @@
apr_status_t e;
int sslError;
+do
+{
/* Returns an error. */
-e = SSL_write(s-ssl_connection, r-rbuf, r-rbufsize);
+ e = SSL_write(s-ssl_connection, r-rbuf, r-rbufsize);
-sslError = SSL_get_error(s-ssl_connection, e);
-switch (sslError)
-{
-case SSL_ERROR_NONE:
-break;
-case SSL_ERROR_WANT_READ:
-ssl_read_socket_handshake(s);
-ssl_write_socket(s, r);
-break;
-case SSL_ERROR_WANT_WRITE:
-break;
-default:
-ERR_print_errors_fp(stderr);
-return APR_EGENERAL;
-}
+ sslError = SSL_get_error(s-ssl_connection, e);
+ switch (sslError)
+ {
+case SSL_ERROR_NONE:
+case SSL_ERROR_WANT_WRITE:
+ break;
+case SSL_ERROR_WANT_READ:
+ ssl_read_socket_handshake(s);
+ break;
+default:
+ ERR_print_errors_fp(stderr);
+ return APR_EGENERAL;
+ }
+} while (sslError == SSL_ERROR_WANT_READ);
+/* to get out of this loop, need no errors!
+ (WANT_WRITE not considered error) */
return APR_SUCCESS;
}
Re: [PATCH] allow implicit ServerRoot via apxs
Geoffrey Young wrote:
[...]
+elsif ($base = $self-apxs('PREFIX')) {
+warning using apxs-derived ServerRoot $base to resolve $file;
May be better to say it all?
warning since ServerRoot is not defined, .
using apxs-derived PREFIX $base to resolve $file;
While you are at it, I'd also add a check that $base exists and it's a
directory before you call rel2abs, because it can be a broken value. And also
check that rel2abs gives us a an existing filename and it's an absolute_path.
or die otherwise.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] allow implicit ServerRoot via apxs
Stas Bekman wrote:
Geoffrey Young wrote:
[...]
+elsif ($base = $self-apxs('PREFIX')) {
+warning using apxs-derived ServerRoot $base to resolve
$file;
May be better to say it all?
warning since ServerRoot is not defined, .
using apxs-derived PREFIX $base to resolve $file;
I suppose the wording could be reworked.
While you are at it, I'd also add a check that $base exists and it's a
directory before you call rel2abs, because it can be a broken value.
I think it's safe to assume if you pass in $base you know what you're doing
(especially since nobody appears to be passing in $base :)
as for checking the resulting ServerRoot, yeah, I thought about that. I
suppose it can't hurt.
And
also check that rel2abs gives us a an existing filename
this function is starting to explode a bit...
and it's an
absolute_path.
no sense checking that - rel2abs returns an absolute path by definition.
or die otherwise.
I don't think we should die here - it's not fatal to the build process if
'perl Makefile.PL' can't resolve testing files.
--Geoff
Re: [PATCH] allow implicit ServerRoot via apxs
Geoffrey Young wrote:
Stas Bekman wrote:
Geoffrey Young wrote:
[...]
+elsif ($base = $self-apxs('PREFIX')) {
+warning using apxs-derived ServerRoot $base to resolve
$file;
May be better to say it all?
warning since ServerRoot is not defined, .
using apxs-derived PREFIX $base to resolve $file;
I suppose the wording could be reworked.
sure ;)
While you are at it, I'd also add a check that $base exists and it's a
directory before you call rel2abs, because it can be a broken value.
I think it's safe to assume if you pass in $base you know what you're
doing (especially since nobody appears to be passing in $base :)
yes, but you attempt to do:
$base = $self-apxs('PREFIX')
what if it returns a non-existing dir? apxs may be not adjusted to the
movement of the files post-install. It doesn't hurt to check.
as for checking the resulting ServerRoot, yeah, I thought about that. I
suppose it can't hurt.
And also check that rel2abs gives us a an existing filename
this function is starting to explode a bit...
So what, it's just a function. Why not making it foolproof why we are spending
time at it.
and it's an absolute_path.
no sense checking that - rel2abs returns an absolute path by definition.
what if it fails?
or die otherwise.
I don't think we should die here - it's not fatal to the build process
if 'perl Makefile.PL' can't resolve testing files.
Hmm, look at your patch, you die if there is no base. I was just following
your idea ;)
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] allow implicit ServerRoot via apxs
and it's an absolute_path. no sense checking that - rel2abs returns an absolute path by definition. what if it fails? the call to rel2abs? since it does no check of the underlying filesystem I doubt that's realistic. I'm definitely a fan of error checking where it makes sense, but I also think it's safe to rely on APIs to do what they say. we don't go checking calls to catfile to make sure the result has slashes in them :) or die otherwise. I don't think we should die here - it's not fatal to the build process if 'perl Makefile.PL' can't resolve testing files. Hmm, look at your patch, you die if there is no base. I was just following your idea ;) oops, I meant to take that out - as you can see, though, I was thinking about whether it was ok to die here ;) it seem, though, that everyone is kinda happy with putting the logic change here, so I'll work these changes up and submit something new soonish. --Geoff
Re: [PATCH] allow implicit ServerRoot via apxs
the call to rel2abs? since it does no check of the underlying filesystem I doubt that's realistic. you are right, I've confused with the opposite operation abs2rel, which may fail if the base doesn't fit. In any case it's a good idea to check that rel2abs gives you a path that exists, no? yeah, I had planned on that. I'm off to ny.pm tomorrow, so I'll probably get back around to this on thursday. --Geoff
should input filter return the exact amount of bytes asked for?
I'm trying to get rid of ap_get_client_block(), but I don't understand a few things. ap_get_client_block() asks for readbytes from the upstream filter. What happens if the filter returns less bytes (while there is still more data coming?) What happens if the filter returns more bytes than requested (e.g. because it uncompressed some data). After all the incoming filters all propogate a request for N bytes read to the core_in filter, which returns that exact number if it can. Now as the data flows up the filter chain its length may change. Does it mean that if the filter didn't return the exact amount asked for it's broken? Is that the case when it returns less data than requested? Or when it returns more data? I'm trying to deal with the case where a user call wants N bytes and I've to give that exact number in a single call. I'm not sure whether I should buffer things if I've got too much data or on the opposite ask for more bbs if I don't have enough data. Are there any modules I can look at to learn from? The doc for ap_get_brigade doesn't say anything about ap_get_brigade satisfying 'readbytes' argument. /** * Get the current bucket brigade from the next filter on the filter * stack. The filter returns an apr_status_t value. If the bottom-most * filter doesn't read from the network, then ::AP_NOBODY_READ is returned. * The bucket brigade will be empty when there is nothing left to get. * @param filter The next filter in the chain * @param bucket The current bucket brigade. The original brigade passed * to ap_get_brigade() must be empty. * @param mode The way in which the data should be read * @param block How the operations should be performed * ::APR_BLOCK_READ, ::APR_NONBLOCK_READ * @param readbytes How many bytes to read from the next filter. */ AP_DECLARE(apr_status_t) ap_get_brigade(ap_filter_t *filter, apr_bucket_brigade *bucket, ap_input_mode_t mode, apr_read_type_e block, apr_off_t readbytes); __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: mod_ldap SEGV while caching on FreeBSD 4.8-STABLE
Hi Matthieu, We are also seeing the same problem on HP-UX running 2.0.47 with mod_ldap enabled. We have done some analysis and we think we might have found the problem. The cache memory is shared by all processes(one process creates it and other processes just attaches to it). After a process attached to the shared memory, it calls apr_rmm_init to create a rmm handler to the shared memory. The following code in apr_rmm_init looks suspicious: (*rmm)-base-abssize = size; (*rmm)-base-firstused = 0; (*rmm)-base-firstfree = sizeof(rmm_hdr_block_t); base points to the header block of the shared memory which contains abssize, firstused and firstfree for managing the shared memory. These code will reset the size, the free and allocated trees in the shared memory. Imagine what may happen if the memory was already allocated and the new process re-initializes these values again. The previous contents will be lost. The header block should be initialized only once and access to the header block needs to be synchronized among all processes. Right now, it is only synchronized using process specific rwlock. They should be replaced by system-wide rwlock. Chou -Original Message- From: Matthieu Estrade [mailto:[EMAIL PROTECTED] Sent: Monday, November 03, 2003 12:37 AM To: [EMAIL PROTECTED] Subject: Re: mod_ldap SEGV while caching on FreeBSD 4.8-STABLE Hi Albert, Could you try this little patch posted on bugzilla: http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=8185 It works under linux but still not work with solaris... i never tested it on FreeBSD. You can also find information about the bug which is #18756. Albert Chin wrote: I have an Intel S875WP1-E with FreeBSD 4.8-STABLE running Apache 2.0.48 prefork with mod_ldap enabled, built against OpenLDAP 2.1.23. I'm getting a SEGV when I have ldap caching enabled. It seems the contents of the global util_ldap_cache is being corrupted. If I set a breakpoint at util_ald_cache_insert, I see this right before the SEGV: #0 util_ald_cache_insert (cache=0x30048018, payload=0x80c3540) at util_ldap_cache_mgr.c:390 #1 0x2841260d in util_ald_create_caches (st=0x80dad98, url=0x8153600 [AuthLDAPUrl argument]) at util_ldap_cache_mgr.c:275 #2 0x28410952 in util_ldap_cache_checkuserid (r=0x814d050, ldc=0x80c3248, url=0x8153600 [AuthLDAPUrl argument], basedn=0x81536b0 [LDAP BASE DN], scope=1, attrs=0x81536d8, filter=0xbfbfd768 [LDAP QUERY STRING], bindpw=0x8153b56 [PASSWORD], binddn=0xbfbfd754, retvals=0xbfbff768) at util_ldap.c:765 #3 0x28417bf5 in mod_auth_ldap_check_user_id (r=0x814d050) at mod_auth_ldap.c:366 ... gdb print util_ldap_cache $37 = (util_ald_cache_t *) 0x30048018 gdb print util_ldap_cache-maxentries $38 = 675356296 The 675356296 should be 50 (from util_ldap_cache_init in util_ldap_cache.c). The SEGV comes from: gdb print util_ldap_cache-hash $39 = (long unsigned int (*)()) 0 What can I do to track this down?
Re: piped log files
Bastiaan van der Put wrote: CustomLog |/usr/local/apache2/bin/logresolve /home/accounts/x/x/logs/access_log combined unless somebody speaks up soon, I'll commit the patch to Apache 2.1-dev Works now, When stopping apache i still get piped log program '/usr/local/apache2/bin/logresolve /home/accounts/x/xx/logs/access_log' failed unexpectedly right, due to unrelated problem
Re: mod_ldap SEGV while caching on FreeBSD 4.8-STABLE
Hi Chou, I dunno if you looked into the patch i pointed in my last mail, but this is what the patch is doing: SHM is now initialised in post_config hook, so apr_shm_create and apr_rmm_init are just called one time when apache is startup. Then, all the lock are now using the module structure to lock data, and no more a global variable. Could you tell me if you speak about my patch or about the actual code of util_ldap and mod_ldap ? I know the patch works with linux and it's broken with solaris, but i don't have more feedback. Matthieu CHOU,TAIR-SHIAN (HP-Cupertino,ex1) wrote: Hi Matthieu, We are also seeing the same problem on HP-UX running 2.0.47 with mod_ldap enabled. We have done some analysis and we think we might have found the problem. The cache memory is shared by all processes(one process creates it and other processes just attaches to it). After a process attached to the shared memory, it calls apr_rmm_init to create a rmm handler to the shared memory. The following code in apr_rmm_init looks suspicious: (*rmm)-base-abssize = size; (*rmm)-base-firstused = 0; (*rmm)-base-firstfree = sizeof(rmm_hdr_block_t); base points to the header block of the shared memory which contains abssize, firstused and firstfree for managing the shared memory. These code will reset the size, the free and allocated trees in the shared memory. Imagine what may happen if the memory was already allocated and the new process re-initializes these values again. The previous contents will be lost. The header block should be initialized only once and access to the header block needs to be synchronized among all processes. Right now, it is only synchronized using process specific rwlock. They should be replaced by system-wide rwlock. Chou -Original Message- From: Matthieu Estrade [mailto:[EMAIL PROTECTED] Sent: Monday, November 03, 2003 12:37 AM To: [EMAIL PROTECTED] Subject: Re: mod_ldap SEGV while caching on FreeBSD 4.8-STABLE Hi Albert, Could you try this little patch posted on bugzilla: http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=8185 It works under linux but still not work with solaris... i never tested it on FreeBSD. You can also find information about the bug which is #18756. Albert Chin wrote: I have an Intel S875WP1-E with FreeBSD 4.8-STABLE running Apache 2.0.48 prefork with mod_ldap enabled, built against OpenLDAP 2.1.23. I'm getting a SEGV when I have ldap caching enabled. It seems the contents of the global util_ldap_cache is being corrupted. If I set a breakpoint at util_ald_cache_insert, I see this right before the SEGV: #0 util_ald_cache_insert (cache=0x30048018, payload=0x80c3540) at util_ldap_cache_mgr.c:390 #1 0x2841260d in util_ald_create_caches (st=0x80dad98, url=0x8153600 [AuthLDAPUrl argument]) at util_ldap_cache_mgr.c:275 #2 0x28410952 in util_ldap_cache_checkuserid (r=0x814d050, ldc=0x80c3248, url=0x8153600 [AuthLDAPUrl argument], basedn=0x81536b0 [LDAP BASE DN], scope=1, attrs=0x81536d8, filter=0xbfbfd768 [LDAP QUERY STRING], bindpw=0x8153b56 [PASSWORD], binddn=0xbfbfd754, retvals=0xbfbff768) at util_ldap.c:765 #3 0x28417bf5 in mod_auth_ldap_check_user_id (r=0x814d050) at mod_auth_ldap.c:366 ... gdb print util_ldap_cache $37 = (util_ald_cache_t *) 0x30048018 gdb print util_ldap_cache-maxentries $38 = 675356296 The 675356296 should be 50 (from util_ldap_cache_init in util_ldap_cache.c). The SEGV comes from: gdb print util_ldap_cache-hash $39 = (long unsigned int (*)()) 0 What can I do to track this down?
Re: Submitting module
Jeff Trawick wrote: Piras Velandai Thiyagarajan wrote: To better serve the Apache user community for easy integration, it would be nice if during configure compilation option, --with-mod-sun-plugin, that way just be simple effect of compilation, the customers get what they want. I'd expect that many of your customers would not be building Apache but instead would be using a build prepared by their vendor. Also, we don't want to add a module to the Apache distribution which has such a limited purpose. Of course, if we had an implementation of the identity server it might be a different matter. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
can someone confirm or deny my interpretation of global mutices?
when i first started using 2.0.47, i was concerned that mod_rewrite no longer wrote a visible lockfile when using RewriteLock with an external map program. i realize there was some type of bug related to this in 2.0.39 ( 9534 -- http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9534 ), which is marked as having been fixed in 2.0.41. i still saw no lockfile being created, so i looked around in the source code to see what's happening. i'm not a great C programmer, but i think i understand, from the comments on the method which creates the mutex, that an actual file is used only if the operating system needs it to implement the locking. might there be someone on this list more familiar with the linux locking systems and the source code to confirm that this is how things are working? jon from 'apr_global_mutex.h': /* * Create and initialize a mutex that can be used to synchronize both * processes and threads. Note: There is considerable overhead in * using this API if only cross-process or cross-thread mutual * exclusion is required. See apr_proc_mutex.h and apr_thread_mutex.h * for more specialized lock routines. * @param mutex the memory address where the newly created mutex * will be stored. * @param fname A file name to use if the lock mechanism * requires one. This argument should always be provided. The lock * code itself will determine if it should be used. * @param mech The mechanism to use for the interprocess * lock, if any; one of * PRE *APR_LOCK_FCNTL *APR_LOCK_FLOCK *APR_LOCK_SYSVSEM *APR_LOCK_POSIXSEM *APR_LOCK_PROC_PTHREAD *APR_LOCK_DEFAULT pick the default *mechanism for the platform * /PRE * @param pool the pool from which to allocate the * mutex. * @warning Check APR_HAS_foo_SERIALIZE defines to * see if the platform supports APR_LOCK_foo. Only APR_LOCK_DEFAULT * is portable. */ APR_DECLARE(apr_status_t) apr_global_mutex_create( apr_global_mutex_t **mutex, const char *fname, apr_lockmech_e mech, apr_pool_t *pool);
Re: htdocs in 1.3 CVS tree?
hi again I'm still seeing this error on my local system. since those who tried were not able to reproduce, I decided to try on cvs.apache.org hostname minotaur.apache.org mkdir src cd src cvs -z9 -d:pserver:[EMAIL PROTECTED]:/home/cvspublic checkout apache-1.3 cvs server: Updating apache-1.3 ... U apache-1.3/src/test/vhtest/logs/.cvsignore cvs server: existing repository /home/cvspublic/apache-1.3/htdocs does not match /home/cvspublic/httpd-docs-1.3/htdocs cvs server: ignoring module htdocs-1.3 ll apache-1.3/htdocs/manual/mod total 2 drwxr-xr-x 2 geoff geoff 512 Nov 4 10:57 CVS sorry if I seem like a nag, but it just doesn't seem right... --Geoff Geoffrey Young wrote: hi all when I do a fresh checkout of apache-1.3 $ cvs -z9 -d:pserver:[EMAIL PROTECTED]:/home/cvspublic checkout apache-1.3 I see this error cvs server: existing repository /home/cvspublic/apache-1.3/htdocs does not match /home/cvspublic/httpd-docs-1.3/htdocs and htdocs is free of content. from modules, it looks like apache-1.3 should be both apache-1.3 apache-1.3 htdocs-1.3 so I should be getting the docs too. is something amuck? it's been a while since I've looked at 1.3 cvs... --Geoff
Re: can someone confirm or deny my interpretation of global mutices?
Jonathan Gold wrote: i'm not a great C programmer, but i think i understand, from the comments on the method which creates the mutex, that an actual file is used only if the operating system needs it to implement the locking. correct your Linux build is probably defaulting to SysV semaphores*, and mod_rewrite uses the default mutex type; thus, there is no file associated with that mod_rewrite mutex *verify by seeing if apachectl -V displays -D APR_USE_SYSVSEM_SERIALIZE
RE: mod_ldap SEGV while caching on FreeBSD 4.8-STABLE
Hi Matthieu, I was speaking about the actual code we saw in 2.0.47. I will try your patch and see what happens. Thanks, Chou -Original Message- From: Matthieu Estrade [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 04, 2003 4:29 AM To: [EMAIL PROTECTED] Subject: Re: mod_ldap SEGV while caching on FreeBSD 4.8-STABLE Hi Chou, I dunno if you looked into the patch i pointed in my last mail, but this is what the patch is doing: SHM is now initialised in post_config hook, so apr_shm_create and apr_rmm_init are just called one time when apache is startup. Then, all the lock are now using the module structure to lock data, and no more a global variable. Could you tell me if you speak about my patch or about the actual code of util_ldap and mod_ldap ? I know the patch works with linux and it's broken with solaris, but i don't have more feedback. Matthieu CHOU,TAIR-SHIAN (HP-Cupertino,ex1) wrote: Hi Matthieu, We are also seeing the same problem on HP-UX running 2.0.47 with mod_ldap enabled. We have done some analysis and we think we might have found the problem. The cache memory is shared by all processes(one process creates it and other processes just attaches to it). After a process attached to the shared memory, it calls apr_rmm_init to create a rmm handler to the shared memory. The following code in apr_rmm_init looks suspicious: (*rmm)-base-abssize = size; (*rmm)-base-firstused = 0; (*rmm)-base-firstfree = sizeof(rmm_hdr_block_t); base points to the header block of the shared memory which contains abssize, firstused and firstfree for managing the shared memory. These code will reset the size, the free and allocated trees in the shared memory. Imagine what may happen if the memory was already allocated and the new process re-initializes these values again. The previous contents will be lost. The header block should be initialized only once and access to the header block needs to be synchronized among all processes. Right now, it is only synchronized using process specific rwlock. They should be replaced by system-wide rwlock. Chou -Original Message- From: Matthieu Estrade [mailto:[EMAIL PROTECTED] Sent: Monday, November 03, 2003 12:37 AM To: [EMAIL PROTECTED] Subject: Re: mod_ldap SEGV while caching on FreeBSD 4.8-STABLE Hi Albert, Could you try this little patch posted on bugzilla: http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=8185 It works under linux but still not work with solaris... i never tested it on FreeBSD. You can also find information about the bug which is #18756. Albert Chin wrote: I have an Intel S875WP1-E with FreeBSD 4.8-STABLE running Apache 2.0.48 prefork with mod_ldap enabled, built against OpenLDAP 2.1.23. I'm getting a SEGV when I have ldap caching enabled. It seems the contents of the global util_ldap_cache is being corrupted. If I set a breakpoint at util_ald_cache_insert, I see this right before the SEGV: #0 util_ald_cache_insert (cache=0x30048018, payload=0x80c3540) at util_ldap_cache_mgr.c:390 #1 0x2841260d in util_ald_create_caches (st=0x80dad98, url=0x8153600 [AuthLDAPUrl argument]) at util_ldap_cache_mgr.c:275 #2 0x28410952 in util_ldap_cache_checkuserid (r=0x814d050, ldc=0x80c3248, url=0x8153600 [AuthLDAPUrl argument], basedn=0x81536b0 [LDAP BASE DN], scope=1, attrs=0x81536d8, filter=0xbfbfd768 [LDAP QUERY STRING], bindpw=0x8153b56 [PASSWORD], binddn=0xbfbfd754, retvals=0xbfbff768) at util_ldap.c:765 #3 0x28417bf5 in mod_auth_ldap_check_user_id (r=0x814d050) at mod_auth_ldap.c:366 ... gdb print util_ldap_cache $37 = (util_ald_cache_t *) 0x30048018 gdb print util_ldap_cache-maxentries $38 = 675356296 The 675356296 should be 50 (from util_ldap_cache_init in util_ldap_cache.c). The SEGV comes from: gdb print util_ldap_cache-hash $39 = (long unsigned int (*)()) 0 What can I do to track this down?
Re: can someone confirm or deny my interpretation of global mutices?
indeed it does use APR_USE_SYSVSEM_SERIALIZE. thanks for looking. jon On Tue, 4 Nov 2003, Jeff Trawick wrote: Jonathan Gold wrote: i'm not a great C programmer, but i think i understand, from the comments on the method which creates the mutex, that an actual file is used only if the operating system needs it to implement the locking. correct your Linux build is probably defaulting to SysV semaphores*, and mod_rewrite uses the default mutex type; thus, there is no file associated with that mod_rewrite mutex *verify by seeing if apachectl -V displays -D APR_USE_SYSVSEM_SERIALIZE
