msr_global_mutex_lock: handle errors from apr_global_mutex_lock#3257
Conversation
|
#3255 acknowledged to be solved by the PR |
|
Before we merge, I want to check why the lock acquire was failed (see #3255 - the user reported that this issue came with the new version where we introduced this method). |
|
The problem was already happening in the previous versions. Looks to me linked to concurrency. |
Co-authored-by: Max Leske <[email protected]>
Co-authored-by: Max Leske <[email protected]>
May be - but now the audit.log is empty (with this patch too). I think we should investigate this issue. I already installed FreeBSD and could reproduce the behavior, so I'm on it. |
|
the audit.log is empty, but you should have an entry in the error log (about the problem at creation time) |
Indeed, but I think we should investigate the issue. |
|
|
|
I propose to accept this PR first, then create one that doesn't use the temp filename, as it's not the right way to create a mutx, see https://lists.apache.org/thread/ykb26kg4lgcqnldvxwd9p6hv16fy4z9l |
Okay, I approved this PR and resolved all conversation. You can merge this PR now. |
marcstern
dismissed
theseion’s stale review
Implemented all requested changes but a comment
4 participants
apr_global_mutex_lockis sometimes called with a lock that wasn't created (for any reason).In this case, the pointer is null and
apr_global_mutex_lockdereferences a null pointer, leading to a crash.This PR creates a wrapper around
apr_global_mutex_lockto handle checking that and correct logging.Same for
msr_global_mutex_unlock.