Bug #61929 [NEW]: Possible bug in ts_resource_ex of TSRM.c

From: Date: Thu, 03 May 2012 20:09:55 +0000
Subject: Bug #61929 [NEW]: Possible bug in ts_resource_ex of TSRM.c
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-170134@lists.php.net to get a copy of this message
From:             
Operating system: All
PHP version:      5.4.2
Package:          Scripting Engine problem
Bug Type:         Bug
Bug description:Possible bug in ts_resource_ex of TSRM.c

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 bug report at https://bugs.php.net/bug.php?id=61929&edit=1
-- 
Try a snapshot (PHP 5.4):            https://bugs.php.net/fix.php?id=61929&r=trysnapshot54
Try a snapshot (PHP 5.3):            https://bugs.php.net/fix.php?id=61929&r=trysnapshot53
Try a snapshot (trunk):              https://bugs.php.net/fix.php?id=61929&r=trysnapshottrunk
Fixed in SVN:                        https://bugs.php.net/fix.php?id=61929&r=fixed
Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61929&r=needdocs
Fixed in release:                    https://bugs.php.net/fix.php?id=61929&r=alreadyfixed
Need backtrace:                      https://bugs.php.net/fix.php?id=61929&r=needtrace
Need Reproduce Script:               https://bugs.php.net/fix.php?id=61929&r=needscript
Try newer version:                   https://bugs.php.net/fix.php?id=61929&r=oldversion
Not developer issue:                 https://bugs.php.net/fix.php?id=61929&r=support
Expected behavior:                   https://bugs.php.net/fix.php?id=61929&r=notwrong
Not enough info:                     https://bugs.php.net/fix.php?id=61929&r=notenoughinfo
Submitted twice:                     https://bugs.php.net/fix.php?id=61929&r=submittedtwice
register_globals:                    https://bugs.php.net/fix.php?id=61929&r=globals
PHP 4 support discontinued:          https://bugs.php.net/fix.php?id=61929&r=php4
Daylight Savings:                    https://bugs.php.net/fix.php?id=61929&r=dst
IIS Stability:                       https://bugs.php.net/fix.php?id=61929&r=isapi
Install GNU Sed:                     https://bugs.php.net/fix.php?id=61929&r=gnused
Floating point limitations:          https://bugs.php.net/fix.php?id=61929&r=float
No Zend Extensions:                  https://bugs.php.net/fix.php?id=61929&r=nozend
MySQL Configuration Error:           https://bugs.php.net/fix.php?id=61929&r=mysqlcfg



Thread (3 messages)

« previous php.bugs (#170134) next »