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 &quot;exit&quot; 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.)

Issue History

Date Modified Username Field Change
2009-10-29 10:57 derick New Issue
2009-10-29 10:57 derick PHP Version => 5.3.0
2009-10-29 10:57 derick Xdebug Version => 2.0.5
2009-11-05 16:58 magreenblatt Note Added: 0001121
2010-03-20 23:50 derick Target Version => 2.1.0RC1
2010-04-03 13:38 derick Note Added: 0001425
2010-04-03 13:38 derick Status new => closed
2010-04-03 13:38 derick Resolution open => fixed
2016-07-31 12:36 derick Category Usage problems => Usage problems (Crashes)
2016-07-31 12:38 derick Category Usage problems (Crashes) => Usage problems (Wrong Results)
2020-03-12 16:35 derick Category Usage problems (Wrong Results) => Variable Display
2020-03-12 16:38 derick Category Variable Display => Uncategorized