View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001221 | Xdebug | Usage problems (Wrong Results) | public | 2015-12-02 04:15 | 2015-12-12 20:56 |
Reporter | techkey | Assigned To | derick | ||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Product Version | |||||
Target Version | Fixed in Version | 2.4.0rc3 | |||
Summary | 0001221: long should be zend_long | ||||
Description | In X64 zend_parse_parameters(..."l"...&options) tries to put 64bit into 32bit, which of course goes wrong because of 'long options'. I've changed long into zend_long on numerous places nearby zend_parse_parameters and the segfaults disappeared. This is on PHP7-RC8 X64 Windows 10 | ||||
Tags | No tags attached. | ||||
Operating System | |||||
PHP Version | 7.0.0rc7 | ||||
|
Is this just for zend_parse_parameters, or did you have to change it in other places too? |
|
Hi, I've just discovered by debugging failing tests that it's in other places too. The 'long' that are used in PHP_INI_BEGIN()... and ZEND_BEGIN_MODULE_GLOBALS()... must be also 'zend_long' otherwise it messes up other nearby variables because there too the API uses 64bit in X64. I think that all 'long' that has to do with the API should be 'zend_long'. I let you know when I discover some more X64 issues. |
|
I have a branch at https://github.com/derickr/xdebug/tree/issue1221-long-vs-zend_long to track this. I will likely merge the current thing and release RC2 tonight, so not everything makes it in. |
|
I've just merged the first PR for this, but leaving the issue open in case you find more issues. |
|
I've just downloaded the master, compiled it and be busy debugging. The command 'property_get' has a problem. I've compiled the debugclient also to manually instruct xdebug. I've also compiled PHP-7.0.0 with debug, all is running in the MSVC2015 IDE. In the file 'xdebug_var_c' on line 437 is: 437: ulong hash_value = zend_inline_hash_func(element, element_length); And you can guess what happens! That API call (in zend_string.h) returns a zend_ulong: 326: register zend_ulong hash = Z_UL(5381); ... 353: return hash | Z_UL(0x8000000000000000); On a handfull tests I get also NFC's, maybe that's related. I'm planning to check that soon also. |
|
Ok, the ulong --> zend_ulong in xdebug_var_c on line 437 fixed most of the test. 327 tests passed and 10 failed so far. |
|
Found a new one, negative array indices goes wrong. In xdebug_var_c line 502: if (ht && ((retval_p = zend_hash_index_find(ht, strtoul(element, NULL, 10))) != NULL)) { zend_hash_c line on line 1964: ZEND_API zval* ZEND_FASTCALL zend_hash_index_find(const HashTable *ht, zend_ulong h) Meaning that -1 (0xFFFFFFFF) becomes 0x00000000FFFFFFFF. strtoul should be strtoull. |
|
8 Failed tests to go: bug00623-php7 // No response for command: property_get -i 5 -n :: bug00627 // The <response> tag turned into a <stream> tag bug00678 // No response for command: eval -i 4 -- bmV3IE5vbkV4aXN0c0NsYXNz bug00688 // No response for command: stack_get -i 4 bug00689 // No response for command: eval -i 4 -- JGEtPmZvbygpOw== bug00690-2 // The string 'DONE' on line 2 is missing bug00763-php7 // No response for command: step_over -i 4 bug00886-php7 // No response for command: step_into -i 9 I look at that in the weekend. Maybe you have some ideas. |
|
Reason for failing 5 tests was typo's in the tests, namely differences in linux/windows paths. 3 Failed tests to go: bug00627 // The <response> tag turned into a <stream> tag bug00690-2 // The string 'DONE' on line 2 is missing bug00886-php7 // No response for command: step_into -i 9 (probably doesn't set breakpoint inside a PHAR or doesn't break inside a PHAR) |
|
Fixed bug00627, I needed to create the symlink. Remaining 2: bug00690-2 // Can't find where 'DONE' should come from, I've searched the source and can't find it in there. bug00886-php7 // Uses a PHAR, I'm investigating it. |
|
Hey - thanks for checking all of these. It would *extremely* helpful if you could make a patch for all the changes that you have done, so I won't have to hunt down and track every issue again. A Pull Request would be even nicer :-) |
|
Hi, since the last few days I'm using xdebug master (with the changes) extensively on projects based on Symfony 3 and new projects that uses almost all capabilities of PHP 7 with NO bugs or weird things related to xdebug! :) Just a reminder of my setup: Windows 10 Pro X64 (with the major update of last week) PHP 7.0.0 X64 TS the official release and the compiled debug. XDebug master with the changes compiled and tested (run) in the IDE Visual Studio 2015 (up to date) and run standalone as debug and release. I'm no wizard when it comes to GitHub (and Git) but I think that I can manage to clone the current master and put in the few changes. I let you know when I run into trouble with that if that's ok with you. |
|
I've fixed all the issues you found, and also spend all they making *all* the Windows tests work with PHP 7.0. I will be releasing RC3 very soon with these fixes. |
Date Modified | Username | Field | Change |
---|---|---|---|
2015-12-02 04:15 | techkey | New Issue | |
2015-12-02 10:22 | derick | Note Added: 0003276 | |
2015-12-02 10:22 | derick | Assigned To | => derick |
2015-12-02 10:22 | derick | Status | new => feedback |
2015-12-02 13:09 | techkey | Note Added: 0003278 | |
2015-12-02 13:09 | techkey | Status | feedback => assigned |
2015-12-02 18:54 | derick | Note Added: 0003279 | |
2015-12-02 22:29 | derick | Note Added: 0003280 | |
2015-12-04 14:05 | techkey | Note Added: 0003284 | |
2015-12-04 19:04 | techkey | Note Added: 0003285 | |
2015-12-04 20:28 | techkey | Note Added: 0003286 | |
2015-12-04 20:56 | techkey | Note Added: 0003287 | |
2015-12-05 08:08 | techkey | Note Added: 0003288 | |
2015-12-05 08:18 | techkey | Note Edited: 0003288 | View Revisions |
2015-12-05 08:43 | techkey | Note Added: 0003289 | |
2015-12-07 10:21 | derick | Note Added: 0003290 | |
2015-12-07 10:35 | techkey | Note Added: 0003293 | |
2015-12-12 20:41 | derick | Note Added: 0003326 | |
2015-12-12 20:41 | derick | Status | assigned => closed |
2015-12-12 20:41 | derick | Resolution | open => fixed |
2015-12-12 20:41 | derick | Fixed in Version | => 2.4.0 |
2015-12-12 20:56 | derick | Fixed in Version | 2.4.0 => 2.4.0rc3 |
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) |