DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22955>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22955 unix based lock creation routines have a possible race issue Summary: unix based lock creation routines have a possible race issue Product: Apache httpd-2.0 Version: 2.0.47 Platform: Sun OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Platform AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] In the code below, theres a small race window between when we do a semget and when we try and set the mutex value to 1. Its possible for a different process to prematurely call and succeed in the _acquire() in this window.. static apr_status_t proc_mutex_sysv_create(apr_proc_mutex_t *new_mutex, const char *fname) { union semun ick; apr_status_t rv; new_mutex->interproc = apr_palloc(new_mutex->pool, sizeof(*new_mutex- >interproc)); new_mutex->interproc->filedes = semget(IPC_PRIVATE, 1, IPC_CREAT | 0600); if (new_mutex->interproc->filedes < 0) { rv = errno; proc_mutex_sysv_cleanup(new_mutex); return rv; } ick.val = 1; if (semctl(new_mutex->interproc->filedes, 0, SETVAL, ick) < 0) { rv = errno; proc_mutex_sysv_cleanup(new_mutex); return rv; } new_mutex->curr_locked = 0; apr_pool_cleanup_register(new_mutex->pool, (void *)new_mutex, apr_proc_mutex_cleanup, apr_pool_cleanup_null); return APR_SUCCESS; } --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
