View Issue Details

IDProjectCategoryView StatusLast Update
0000480XdebugUncategorizedpublic2010-04-03 13:38
Reporterderick Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Target Version2.1.0RC1 
Summary0000480: Issues with the reserved resource in multi threaded environments
Description

From: "Grolemund, Francis" Francis.Grolemund@netapp.com
To: Derick Rethans derick@xdebug.org
X-Bogosity: Unsure, tests=bogofilter, spamicity=0.500000, version=1.2.1
Subject: RE: question about your use of zend_get_resource_handle()

After I sent the e-mail, it was still bugging me how this type of defect
could exist in your code since you clearly took the time to make the
multi-threaded build work here. My new theory is that it would only
appear in situations where memory is not zeroed after initialization or
when you are sharing the process space with another extension, like APC,
that uses this trick. I grepped the extension tree under PHP and didn't
find any others that use this zend_get_resource_handle, so this approach
is fairly arcane. If your extension starts up and is the first one to
request a resource handle and your global structure happens to get its
reserved_offset set to zero on each thread because of the way the heap
allocation works on Linux, for instance, it wouldn't appear. That could
account for a lot of the posssible installation scenarios.

For what it's worth, I'm shocked that PHP doesn't ship with your
extension. It clearly fills a gap in their architecture.

Anyway, here's the patch. Let me know what you think.

Fran

--- xdebug-orig/xdebug.c 2009-09-30 15:46:35.903278000 -0400
+++ xdebug-2.0.5/xdebug.c 2009-09-30 15:49:58.232958000 -0400
@@ -105,6 +105,7 @@
static char return_trace_stack_retval(function_stack_entry i, zval*
retval TSRMLS_DC);

int zend_xdebug_initialised = 0;
+int zend_global_offset = -1;

function_entry xdebug_functions[] = {
PHP_FE(xdebug_get_stack_depth, NULL)
@@ -338,6 +339,7 @@
xg->do_code_coverage = 0;
xg->breakpoint_count = 0;
xg->ide_key = NULL;

  • xg->reserved_offset = zend_global_offset;

    xdebug_llist_init(&xg->server, xdebug_superglobals_dump_dtor);
    xdebug_llist_init(&xg->get, xdebug_superglobals_dump_dtor);

    @@ -575,7 +577,10 @@

    #ifdef ZEND_ENGINE_2
    / Get reserved offset /

  • XG(reserved_offset) = zend_get_resource_handle(&dummy_ext);
  • /* NOTE: this patch makes the global offset thread-safe, whereas
  • it was being used by other threads, when it wasn't
    propagated
  • there. */
  • zend_global_offset = zend_get_resource_handle(&dummy_ext);

    /* Overload the "exit" opcode */
    XDEBUG_SET_OPCODE_OVERRIDE(exit, ZEND_EXIT); 
TagsNo tags attached.
Operating System
PHP Version5.3.0

Activities

magreenblatt

2009-11-05 16:58

reporter   ~0001121

Reproduced with Xdebug 2.0.5 and PHP 5.2.4 using VS6 debug build on Windows XP. When PHP code is executed on a thread other than the main application thread a crash occurs in xdebug_init_oparray() due to XG(reserved_offset) containing a garbage value. The above patch fixes the issue for me.

derick

2010-04-03 13:38

administrator   ~0001425

This patch is now in SVN (Rev. 3244.)