Edit report at https://bugs.php.net/bug.php?id=61929&edit=1
ID: 61929
Updated by: larue...@php.net
Reported by: drueter at assyst dot com
Summary: Possible bug in ts_resource_ex of TSRM.c
Status: Open
Type: Bug
Package: Scripting Engine problem
Operating System: All
PHP Version: 5.4.2
Block user comment: N
Private report: N
New Comment:
the mutex also be unlocked in allocate_new_resource. however I am not sure
whether
I got your idea..
Previous Comments:
------------------------------------------------------------------------
[2012-05-03 20:09:55] drueter at assyst dot com
Description:
------------
While reviewing source code for both 5.4.2 and 5.3.12 I noticed what looks like
a bug in the implementation of ts_resource_ex in TSRM.c
I have not experienced a problem, but from the code it looks like there is a
condition in which a mutex will be locked and never unlocked.
In TSRM.c within the implementation of ts_resource_ex, starting about line 345
I see the following:
tsrm_mutex_lock(tsmm_mutex);
...
else {
allocate_new_resource(&thread_resources->next, thread_id);
return ts_resource_ex(id, &thread_id);
/*
* thread_resources = thread_resources->next;
* break;
*/
... }
tsrm_mutex_unlock(tsmm_mutex);
I think the "break" in the old code that has been commented out is correct, and
the "return" in the new code is uncorrect. I think that in the event this
branch of execution be taken, the tsmm_mutex will be locked but will never be
unlocked.
Alternatively, if the thinking was that the recursive call to ts_resource_ex
would unlock the mutex, I think there is still a problem because in this case
the mutex would be locked twice, but unlocked only once.
Finally, if somehow the code is correct as it stands, it is sufficiently
confusing that a comment should be added.
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=61929&edit=1
