You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2025/10/05 08:39:23 UTC
[Bug 69841] New: "double free or corruption" with mod_socache_dbm (socache_dbm_retrieve() + database_cleanup())
https://bz.apache.org/bugzilla/show_bug.cgi?id=69841
Bug ID: 69841
Summary: "double free or corruption" with mod_socache_dbm
(socache_dbm_retrieve() + database_cleanup())
Product: Apache httpd-2
Version: 2.4.65
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: mod_socache_(dbm|dc|memcache|shmcb)
Assignee: bugs@httpd.apache.org
Reporter: akos+asf-bz@szots.dev
Target Milestone: ---
Created attachment 40113
--> https://bz.apache.org/bugzilla/attachment.cgi?id=40113&action=edit
"bt full" of one of the crashing processes
I have MariaDB DBD lookup configured for authentication. Whenever Apache tries
to retrieve a successful authentication result from socache, the affected
processes crash (usually three at a time).
Config:
AuthnCacheSOCache dbm:/run/apache2/socache/socache-dbm-authn-socache
DBDriver mysql
DBDParams
sock=/run/mysql/test/mysql.sock,dbname=mydbname,user=myuser,pass=mypassword
<Location ~ "^/mail/">
AuthType Basic
AuthName "Email"
AuthBasicProvider socache dbd
AuthnCacheProvideFor dbd
AuthnCacheContext mydbname
AuthDBDUserPWQuery 'SELECT REGEXP_REPLACE(password, "{.+}", "") FROM
mailbox WHERE username = %s'
Require valid-user
</Location>
Apache acts as a reverse proxy here, but in this case I don't think it's
important.
Errors in the log:
double free or corruption (out)
double free or corruption (out)
[core:notice] [pid 1:tid 1] AH00052: child pid 7 exit signal Abort (6)
[core:notice] [pid 1:tid 1] AH00052: child pid 8 exit signal Abort (6)
[core:notice] [pid 1:tid 1] AH00052: child pid 9 exit signal Segmentation fault
(11)
[mpm_event:warn] [pid 1:tid 1] AH10392: children are killed successively!
Backtrace:
#0 __pthread_kill_implementation (threadid=<optimized out>,
signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x00007f2d23fbbe33 in __pthread_kill_internal (threadid=<optimized out>,
signo=6) at pthread_kill.c:89
#2 0x00007f2d23f607b6 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
#3 0x00007f2d23f4734b in __GI_abort () at abort.c:77
#4 0x00007f2d23f483ad in __libc_message_impl (fmt=fmt@entry=0x7f2d240dc35d
"%s\n") at ../sysdeps/posix/libc_fatal.c:138
#5 0x00007f2d23fc6b77 in malloc_printerr (str=str@entry=0x7f2d240df538 "double
free or corruption (!prev)") at malloc.c:5879
#6 0x00007f2d23fc8bdc in _int_free_merge_chunk (av=av@entry=0x7f2c8c000030,
p=p@entry=0x7f2c8c005cf0, size=size@entry=5232) at malloc.c:4767
#7 0x00007f2d23fc8f60 in _int_free_chunk (av=0x7f2c8c000030, p=0x7f2c8c005cf0,
size=5232, have_lock=<optimized out>, have_lock@entry=0) at malloc.c:4714
#8 0x00007f2d23fcbee4 in __GI___libc_free (mem=<optimized out>) at
malloc.c:3556
#9 0x00007f2d2417d704 in database_cleanup (data=0x7f2c8c005d00) at
dbm/sdbm/sdbm.c:81
#10 0x00007f2d23453f30 in socache_dbm_retrieve (ctx=0x5586aca01c80,
s=0x5586aca5d8f0, id=0x7f2c88012210 "mydatabase:my@email.eu", idlen=22,
dest=0x7f2d1eb1c940 "\350U\235\254\206U",
destlen=0x7f2d1eb1c93c, p=0x7f2c8801bea8) at
/usr/src/debug/httpd-2.4.65/modules/cache/mod_socache_dbm.c:361
#11 0x00007f2d2345b1aa in check_password (r=0x7f2c8801bf20, user=0x7f2c88012200
"my@email.eu", password=0x7f2c880121e7 "mypassword")
at /usr/src/debug/httpd-2.4.65/modules/aaa/mod_authn_socache.c:377
#12 0x00007f2d2346c955 in authenticate_basic_user (r=0x7f2c8801bf20) at
/usr/src/debug/httpd-2.4.65/modules/aaa/mod_auth_basic.c:375
#13 0x00005586a6be19b0 in ap_run_check_user_id (r=r@entry=0x7f2c8801bf20) at
server/request.c:84
#14 0x00005586a6beb838 in ap_process_request_internal (r=0x7f2c8801bf20) at
server/request.c:342
#15 0x00005586a6c100b8 in ap_process_async_request (r=0x7f2c8801bf20) at
modules/http/http_request.c:450
#16 0x00005586a6c1027c in ap_process_request (r=<optimized out>) at
modules/http/http_request.c:487
#17 0x00007f2d234b68e8 in c2_process (conn_ctx=0x7f2c880050f0,
c=0x7f2c88004d70) at /usr/src/debug/httpd-2.4.65/modules/http2/h2_c2.c:790
#18 h2_c2_hook_process (c=0x7f2c88004d70) at
/usr/src/debug/httpd-2.4.65/modules/http2/h2_c2.c:907
#19 0x00005586a6beecd0 in ap_run_process_connection (c=c@entry=0x7f2c88004d70)
at server/connection.c:42
#20 0x00007f2d234cbd6f in h2_c2_process (c2=0x7f2c88004d70,
thread=0x5586acd1e100, worker_id=<optimized out>) at
/usr/src/debug/httpd-2.4.65/modules/http2/h2_c2.c:715
#21 slot_run (thread=0x5586acd1e100, wctx=0x5586accf7898) at
/usr/src/debug/httpd-2.4.65/modules/http2/h2_workers.c:294
#22 0x00007f2d23fb9df1 in start_thread (arg=<optimized out>) at
pthread_create.c:448
#23 0x00007f2d2403ec8c in __GI___clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
The backtraces of other threads look very similar, except in one case there's a
run_cleanups() call between socache_dbm_retrieve() and database_cleanup():
#10 0x00007f2d24150a4e in run_cleanups (cref=<optimized out>) at
memory/unix/apr_pools.c:2666
#11 apr_pool_clear (pool=0x5586aca03818) at memory/unix/apr_pools.c:938
Full backtrace attached.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 69841] "double free or corruption" with mod_socache_dbm (socache_dbm_retrieve() + database_cleanup())
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69841
Ruediger Pluem <rp...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #40115|0 |1
is obsolete| |
Attachment #40116|0 |1
is obsolete| |
--- Comment #6 from Ruediger Pluem <rp...@apache.org> ---
Created attachment 40121
--> https://bz.apache.org/bugzilla/attachment.cgi?id=40121&action=edit
Version 3 of patch
Thanks for the extensive testing. Can you please try this one? I shortened the
time the lock is held. Especially the time consuming password_validate call now
happens outside the lock. Again this patch is against trunk. Hence the stuff I
mentioned before is valid for this patch as well.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 69841] "double free or corruption" with mod_socache_dbm (socache_dbm_retrieve() + database_cleanup())
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69841
--- Comment #1 from Ruediger Pluem <rp...@apache.org> ---
Created attachment 40114
--> https://bz.apache.org/bugzilla/attachment.cgi?id=40114&action=edit
Patch to fix issue
Can you please try the attached patch and check if it fixes your issue?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 69841] "double free or corruption" with mod_socache_dbm (socache_dbm_retrieve() + database_cleanup())
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69841
--- Comment #8 from Ákos Szőts <ak...@szots.dev> ---
A gentle ping on this issue.
Even if you cannot cache the encrypted password as part of this change, may I
ask you to merge the immediate fix, so that Apache won't crash when DBD caching
is used?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
Re: Fwd: [Bug 69841] New: "double free or corruption" with mod_socache_dbm (socache_dbm_retrieve() + database_cleanup())
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Oct 07, 2025 at 09:24:29PM +0200, Ruediger Pluem wrote:
>
>
> On 10/7/25 6:04 PM, Joe Orton wrote:
> > On Tue, Oct 07, 2025 at 03:54:29PM +0200, Ruediger Pluem wrote:
> >>
> >>
> >> On 10/7/25 11:50 AM, Joe Orton wrote:
> >>> On Tue, Oct 07, 2025 at 10:45:27AM +0100, Joe Orton wrote:
> >>>> There should already be a global lock held by API consumer, since the
> >>>> socache provider is marked with AP_SOCACHE_FLAG_NOTMPSAFE. It looks like
> >>>> mod_authn_socache is protecting entry to the socache provider inside a
> >>>> global mutex without checking that flag - overkill but should be safe.
> >>>
> >>> Ah, not true, it only does it for ->store(). The ->retrieve() calls are
> >>> then unsafe and racy, that's definitely a bug.
> >>
> >> Your proposal would be to setup check_password in mod_authn_socache in a similar way
> >> to ap_authn_cache_store?
> >> Hence wrapping the ->retrieve in a apr_global_mutex_trylock / apr_global_mutex_unlock.
> >
> > Yes, that is definitely necessary to use the socache API (and it's
> > documented that way).
>
> I did create such a patch and asked the reporter to confirm.
Thank you! LGTM.
> > I think the use of ctx->pool in mod_socache_dbm can be safely switched
> > to the passed-in pool (r->pool in this case) in the
> > store/retrieve/remove/status entry points too.
>
> Do you see any reason why we constantly need to get the driver via
> apr_dbm_get_driver in case of a later apr-util and constantly need to
> apr_dbm_open(2) / apr_dbm_close the DB? Can't we just open that once
> in the beginning and keep it open thru the lifecycle of the server? Or
> can only one thread have the DB open due to possible races / locking
> issues?
My experience from stress testing on mod_dav_fs was exactly that - using
a global mutex and opening the apr_dbm_t in only one thread at a time
was the only safe way to use that API.
Storing the apr_dbm_driver_t in the instance_t struct might be safe, but
unless you stress test it/read all the driver code I wouldn't change
that part at all tbh.
(I think Greg said when we talked about this, a better to answer to most
of these questions is dropping apr_dbm in httpd and switching to sqlite
instead, that definitely applies here too. It is crazy to lack safe
concurrent read-only database access)
Regards, Joe
Re: Fwd: [Bug 69841] New: "double free or corruption" with mod_socache_dbm (socache_dbm_retrieve() + database_cleanup())
Posted by Ruediger Pluem <rp...@apache.org>.
On 10/7/25 6:04 PM, Joe Orton wrote:
> On Tue, Oct 07, 2025 at 03:54:29PM +0200, Ruediger Pluem wrote:
>>
>>
>> On 10/7/25 11:50 AM, Joe Orton wrote:
>>> On Tue, Oct 07, 2025 at 10:45:27AM +0100, Joe Orton wrote:
>>>> There should already be a global lock held by API consumer, since the
>>>> socache provider is marked with AP_SOCACHE_FLAG_NOTMPSAFE. It looks like
>>>> mod_authn_socache is protecting entry to the socache provider inside a
>>>> global mutex without checking that flag - overkill but should be safe.
>>>
>>> Ah, not true, it only does it for ->store(). The ->retrieve() calls are
>>> then unsafe and racy, that's definitely a bug.
>>
>> Your proposal would be to setup check_password in mod_authn_socache in a similar way
>> to ap_authn_cache_store?
>> Hence wrapping the ->retrieve in a apr_global_mutex_trylock / apr_global_mutex_unlock.
>
> Yes, that is definitely necessary to use the socache API (and it's
> documented that way).
I did create such a patch and asked the reporter to confirm.
>
> I think the use of ctx->pool in mod_socache_dbm can be safely switched
> to the passed-in pool (r->pool in this case) in the
> store/retrieve/remove/status entry points too.
Do you see any reason why we constantly need to get the driver via apr_dbm_get_driver in case of a later apr-util
and constantly need to apr_dbm_open(2) / apr_dbm_close the DB? Can't we just open that once in the beginning
and keep it open thru the lifecycle of the server? Or can only one thread have the DB open due to possible races /
locking issues?
Regards
Rüdiger
Re: Fwd: [Bug 69841] New: "double free or corruption" with mod_socache_dbm (socache_dbm_retrieve() + database_cleanup())
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Oct 07, 2025 at 03:54:29PM +0200, Ruediger Pluem wrote:
>
>
> On 10/7/25 11:50 AM, Joe Orton wrote:
> > On Tue, Oct 07, 2025 at 10:45:27AM +0100, Joe Orton wrote:
> >> There should already be a global lock held by API consumer, since the
> >> socache provider is marked with AP_SOCACHE_FLAG_NOTMPSAFE. It looks like
> >> mod_authn_socache is protecting entry to the socache provider inside a
> >> global mutex without checking that flag - overkill but should be safe.
> >
> > Ah, not true, it only does it for ->store(). The ->retrieve() calls are
> > then unsafe and racy, that's definitely a bug.
>
> Your proposal would be to setup check_password in mod_authn_socache in a similar way
> to ap_authn_cache_store?
> Hence wrapping the ->retrieve in a apr_global_mutex_trylock / apr_global_mutex_unlock.
Yes, that is definitely necessary to use the socache API (and it's
documented that way).
I think the use of ctx->pool in mod_socache_dbm can be safely switched
to the passed-in pool (r->pool in this case) in the
store/retrieve/remove/status entry points too.
> I guess we can still use apr_global_mutex_trylock and return AUTH_USER_NOT_FOUND in case
> we do not get the lock?
Seems reasonable to me, yup.
Re: Fwd: [Bug 69841] New: "double free or corruption" with mod_socache_dbm (socache_dbm_retrieve() + database_cleanup())
Posted by Ruediger Pluem <rp...@apache.org>.
On 10/7/25 11:50 AM, Joe Orton wrote:
> On Tue, Oct 07, 2025 at 10:45:27AM +0100, Joe Orton wrote:
>> There should already be a global lock held by API consumer, since the
>> socache provider is marked with AP_SOCACHE_FLAG_NOTMPSAFE. It looks like
>> mod_authn_socache is protecting entry to the socache provider inside a
>> global mutex without checking that flag - overkill but should be safe.
>
> Ah, not true, it only does it for ->store(). The ->retrieve() calls are
> then unsafe and racy, that's definitely a bug.
Your proposal would be to setup check_password in mod_authn_socache in a similar way
to ap_authn_cache_store?
Hence wrapping the ->retrieve in a apr_global_mutex_trylock / apr_global_mutex_unlock.
I guess we can still use apr_global_mutex_trylock and return AUTH_USER_NOT_FOUND in case
we do not get the lock?
Regards
Rüdiger
Re: Fwd: [Bug 69841] New: "double free or corruption" with mod_socache_dbm (socache_dbm_retrieve() + database_cleanup())
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Oct 07, 2025 at 10:45:27AM +0100, Joe Orton wrote:
> There should already be a global lock held by API consumer, since the
> socache provider is marked with AP_SOCACHE_FLAG_NOTMPSAFE. It looks like
> mod_authn_socache is protecting entry to the socache provider inside a
> global mutex without checking that flag - overkill but should be safe.
Ah, not true, it only does it for ->store(). The ->retrieve() calls are
then unsafe and racy, that's definitely a bug.
Re: Fwd: [Bug 69841] New: "double free or corruption" with mod_socache_dbm (socache_dbm_retrieve() + database_cleanup())
Posted by Joe Orton <jo...@redhat.com>.
On Sun, Oct 05, 2025 at 12:42:42PM +0200, Ruediger Pluem wrote:
> I think we have a design issue below. mod_socache_dbm uses ctx->pool for many operations (retrieve, store, expire, etc.), but
> ctx->pool is a child of the pconf pool and the same pool for all threads. I see two possible ways forward:
>
> Either create a subpool each time or use a another external thread specific pool like r->pool.
> A subpool might be more memory efficient but comes with the penalty of a process lock for creation and destroying
> while something like r->pool might consume more memory but does not require additional locking.
> Any opinions?
Why isn't it using the pool passed to retrieve()/store() etc? That pool
is explicitly documented as "Pool for temporary allocations"?
There should already be a global lock held by API consumer, since the
socache provider is marked with AP_SOCACHE_FLAG_NOTMPSAFE. It looks like
mod_authn_socache is protecting entry to the socache provider inside a
global mutex without checking that flag - overkill but should be safe.
Regards, Joe
>
> Regards
>
> Rüdiger
>
>
> -------- Forwarded Message --------
> Subject: [Bug 69841] New: "double free or corruption" with mod_socache_dbm (socache_dbm_retrieve() + database_cleanup())
> Date: Sun, 05 Oct 2025 08:39:23 +0000
> From: bugzilla@apache.org
> Reply-To: Apache HTTPD Bugs Notification List <bu...@httpd.apache.org>
> To: bugs@httpd.apache.org
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=69841
>
> Bug ID: 69841
> Summary: "double free or corruption" with mod_socache_dbm
> (socache_dbm_retrieve() + database_cleanup())
> Product: Apache httpd-2
> Version: 2.4.65
> Hardware: PC
> OS: Linux
> Status: NEW
> Severity: normal
> Priority: P2
> Component: mod_socache_(dbm|dc|memcache|shmcb)
> Assignee: bugs@httpd.apache.org
> Reporter: akos+asf-bz@szots.dev
> Target Milestone: ---
>
>
>
Fwd: [Bug 69841] New: "double free or corruption" with mod_socache_dbm (socache_dbm_retrieve() + database_cleanup())
Posted by Ruediger Pluem <rp...@apache.org>.
I think we have a design issue below. mod_socache_dbm uses ctx->pool for many operations (retrieve, store, expire, etc.), but
ctx->pool is a child of the pconf pool and the same pool for all threads. I see two possible ways forward:
Either create a subpool each time or use a another external thread specific pool like r->pool.
A subpool might be more memory efficient but comes with the penalty of a process lock for creation and destroying
while something like r->pool might consume more memory but does not require additional locking.
Any opinions?
Regards
Rüdiger
-------- Forwarded Message --------
Subject: [Bug 69841] New: "double free or corruption" with mod_socache_dbm (socache_dbm_retrieve() + database_cleanup())
Date: Sun, 05 Oct 2025 08:39:23 +0000
From: bugzilla@apache.org
Reply-To: Apache HTTPD Bugs Notification List <bu...@httpd.apache.org>
To: bugs@httpd.apache.org
https://bz.apache.org/bugzilla/show_bug.cgi?id=69841
Bug ID: 69841
Summary: "double free or corruption" with mod_socache_dbm
(socache_dbm_retrieve() + database_cleanup())
Product: Apache httpd-2
Version: 2.4.65
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: mod_socache_(dbm|dc|memcache|shmcb)
Assignee: bugs@httpd.apache.org
Reporter: akos+asf-bz@szots.dev
Target Milestone: ---
[Bug 69841] "double free or corruption" with mod_socache_dbm (socache_dbm_retrieve() + database_cleanup())
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69841
--- Comment #5 from Ákos Szőts <ak...@szots.dev> ---
I did four modifications within the patch:
1. #define LOCK_TIMEOUT 5000000
2. Left diff line 24 at "mutex busy"
3. Changed diff line 40 to "mutex busy-2"
4. Changed diff line 105 to "mutex busy-3"
This way I could differentiate where it gets stalled.
I used "strings" to verify that the deployed .so file contains all three
variants.
With 2 seconds timeout in the debug log I see 6 "mutex busy-2" logs. With 5
seconds timeout this is reduced to 3.
The page loads reduced to a crawl with these timeouts. The best are when it's
zero. However, I believe 0 being the fastest should be considered incorrect
behaviour.
My thoughts about the timeout and caching:
1. I think, theoretically, the LOCK_TIMEOUT can be an arbitrarily big value (~
<5 seconds). Because:
- If the initial computation or data retrieval takes /less/ time than that,
LOCK_TIMEOUT is never reached.
- If the initial computation or data retrieval takes /more/ time than that,
LOCK_TIMEOUT will be reached, but the computation still needs more time, so
LOCK_TIMEOUT won't be a limiting factor. In fact, defining a too small but
nonzero value hurts because the thread will be idling first, and only then
starts a longer computation. It's better to wait for others to finish first.
- The only problem happens if there's an error in the /less/ case, and
LOCK_TIMEOUT prevents an error like a deadlock. That should be very rare.
2. There should be two sides of caching: (I don't know if it's the case today)
- Caching of the clear text password encryption. The provided clear text
password goes through the crypt() call, and that should take ~0.5 second,
regardless of the current hardware. Better hardware, migrate to more difficult
encryption. This is against brute force on a modern machine.
This is where the slowness in my case comes currently. Apache is (probably)
running crypt separately for all 70 requests.
You can try it without DBD, just paste the output of this snippet in a
.htpasswd file:
python3 -c "from passlib.hash import sha512_crypt; import getpass;
print(sha512_crypt.hash(getpass.getpass('Enter password'), rounds=1000000))"
- The other side of caching is the "compare-to", encrypted password that
currently resides in the DB in my case (or in .htpasswd in other cases). This
retrieval is usually fast enough.
In my case there shouldn't be any mutex-busy-2 logs because both the crypt()
operation and the DB retrieval is maximum 0.5 second, way less than 5 seconds.
And while the mutexes wait for the very first request to compute crypt() and
call for the DB, all subsequent requests should use the cached version (where
the retrieval is again < 5 seconds).
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 69841] "double free or corruption" with mod_socache_dbm (socache_dbm_retrieve() + database_cleanup())
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69841
--- Comment #2 from akos+asf-bz@szots.dev ---
Created attachment 40115
--> https://bz.apache.org/bugzilla/attachment.cgi?id=40115&action=edit
Patch diff
Thank you, it was quick!
In 2.4.65 still "apr_password_validate" is used instead of
"ap_password_validate", so I had to modify the patch (attaching the diff), but
otherwise it applied and I recompiled exactly how my distro compiled, then
replaced the mod_authn_socache.so file.
Observations:
The error is gone, the page loads without any error messages or crashes.
However, caching is effectively not done. With trace4, for a single page load,
for every request I see multiple "mutex busy" messages. Altogether 104 for 75
requests.
1. Encryption standards require an algorithm with high computation power, so I
use SHA512-CRYPT with many rounds. As I see, Apache is trying to crypt the
password for every request and compare it with the DB result, which prolongs
the web page loading time from a few hundred ms to 5 seconds.
2. I still see many (20+) connections reaching the DB. I'd think that with
caching that's reduced.
I use Apache in "event" worker mode.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 69841] "double free or corruption" with mod_socache_dbm (socache_dbm_retrieve() + database_cleanup())
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69841
--- Comment #7 from Ákos Szőts <ak...@szots.dev> ---
This new version is definitely a step in the right direction: with timeout
value of 5 seconds, there're no more "mutex busy" prints.
With 0 timeout, the mutex busy prints are still there, so caching is
effectively not done, but the crash is avoided. It's also a bit slower than
with a reasonable timeout.
What I think is still missing is the caching of the encrypted password. How I
_think_ requests are done now is like:
1. Receive a request from the UA with clear text password
2. Apache runs the password through crypt() that takes a considerable amount of
time for modern encryption. No caching is done at this step.
3. The now-encrypted password is checked against the cached value from the DB
(that stores the password already encrypted).
4. Request is served after a successful encrypted==encrypted comparison
The slowness comes in at step 2.
Apache runs crypt() on every single request without caching it and crypt() is
(and should be) slow.
I recorded a short screen capture to visualise that it takes 5 seconds for a
local website to serve 1.1 MB of data via 77 requests.
Bugzilla didn't allow me to upload this file, so I placed it here:
https://mega.nz/file/pcgGhCLK#RhtpQPohoxPRctrfpx4Zjkrp4ClXo0zMgJuJzQVAjBA
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 69841] "double free or corruption" with mod_socache_dbm (socache_dbm_retrieve() + database_cleanup())
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69841
--- Comment #3 from Ruediger Pluem <rp...@apache.org> ---
(In reply to Ákos Szőts from comment #2)
> Created attachment 40115 [details]
> Patch diff
>
> Thank you, it was quick!
>
> In 2.4.65 still "apr_password_validate" is used instead of
> "ap_password_validate", so I had to modify the patch (attaching the diff),
> but otherwise it applied and I recompiled exactly how my distro compiled,
> then replaced the mod_authn_socache.so file.
This is because the patch was created for trunk and not for 2.4.x. Sorry for
not mentioning this.
>
> Observations:
Thanks for reporting back.
>
> The error is gone, the page loads without any error messages or crashes.
>
> However, caching is effectively not done. With trace4, for a single page
> load, for every request I see multiple "mutex busy" messages. Altogether 104
> for 75 requests.
I decided to follow a similar pattern in the existing code to avoid too much
lock contentions, by just not using the cache if we cannot get the needed lock.
This is possibly the wrong decision and waiting for the lock might give a
better overall result. I will attach a new version of the patch (again against
trunk, hence have a look for the apr_password_validate difference). The patch
as provided does the same as the previous one, but you can play around a bit
with a hardcoded timeout value: LOCK_TIMEOUT is in microseconds and tells the
code how long to wait for a lock before giving up and not using the cache. A
good value here might give a fair balance between a good caching and avoiding
too much lock contention. Let me know your experience.
>
> 1. Encryption standards require an algorithm with high computation power, so
> I use SHA512-CRYPT with many rounds. As I see, Apache is trying to crypt the
> password for every request and compare it with the DB result, which prolongs
> the web page loading time from a few hundred ms to 5 seconds.
ap_password_validate in trunk optimizes this, but it was never backported to
2.4.x:
See
https://github.com/apache/httpd/commit/40431c8d757f8bdaf0c1be4203ea5f79224e31de
>
> 2. I still see many (20+) connections reaching the DB. I'd think that with
> caching that's reduced.
I am not sure if the number of connections matter as I don't know if they are
kept open, but I guess the points above are more important.
>
> I use Apache in "event" worker mode.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 69841] "double free or corruption" with mod_socache_dbm (socache_dbm_retrieve() + database_cleanup())
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69841
--- Comment #4 from Ruediger Pluem <rp...@apache.org> ---
Created attachment 40116
--> https://bz.apache.org/bugzilla/attachment.cgi?id=40116&action=edit
Version 2 of the patch
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org