View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000480XdebugUsage problems (Wrong Results)public2009-10-29 10:572010-04-03 14:38
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
PlatformOSOS Version
Product Version 
Target Version2.1.0RC1Fixed in Version 
Summary0000480: Issues with the reserved resource in multi threaded environments
DescriptionFrom: "Grolemund, Francis" <>
To: Derick Rethans <>
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.


--- 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
+ there. */
+ zend_global_offset = zend_get_resource_handle(&dummy_ext);

        /* Overload the "exit" opcode */
TagsNo tags attached.
Operating System
PHP Version5.3.0
Attached Files

- Relationships

-  Notes
magreenblatt (reporter)
2009-11-05 16:58

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 (administrator)
2010-04-03 14:38

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 14:38 derick Note Added: 0001425
2010-04-03 14:38 derick Status new => closed
2010-04-03 14:38 derick Resolution open => fixed
2016-07-31 13:36 derick Category Usage problems => Usage problems (Crashes)
2016-07-31 13:38 derick Category Usage problems (Crashes) => Usage problems (Wrong Results)

Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker