View Issue Details

IDProjectCategoryView StatusLast Update
0001483XdebugUsage problems (Wrong Results)public2019-09-09 08:24
Reporterclaude.bingAssigned Toderick 
Status feedbackResolutionreopened 
PlatformLinuxOSUbuntuOS Version16.04.3 LTS
Product Version2.5.5 
Target VersionFixed in Version 
Summary0001483: Some function calls return NULL only when XDebug is enabled
DescriptionWhen I have XDebug enabled, a function call that is meant to return an array of objects will instead return NULL. If I disable XDebug, var_dump($variable); will return the correct information. The gist link in "Additional information" has two comments with output of var_dump() both with and without XDebug enabled.
Additional Information

It is not selectable in the list, but I am using PHP 7.1.10
TagsNo tags attached.
Operating SystemUbuntu 16.04.3 LTS
PHP Version7.3.5-7.3.9



2017-10-26 10:15

administrator   ~0004445

Please attach the code as a file here, so I can have a look when I'm offline too.


2018-01-29 21:48

administrator   ~0004579

Can't reproduce this, and no feedback provided.

2019-08-03 19:17

reporter   ~0005101

Sorry I abandoned this issue, I got sidetracked with a lot of things.

I have reproduced this issue with the same project, but with a different OS version, PHP version, and Xdebug version. Similar to the original issue, the function returns an array of items, and adding a breakpoint in the function causes it to return null. If I do not add a breakpoint, it works fine.

Can you give me a list of things that would be most useful to you in order to debug the issue? Some sort of log from Xdebug, package versions, etc.

2019-08-03 20:23


trace.container.with-stmt-close (1,647,538 bytes)

2019-08-03 20:23


trace.container.without-stmt-close (2,593,500 bytes)
trace.manual.with-stmt-close (2,593,603 bytes)

2019-08-03 20:23

reporter   ~0005103

I have (possibly) narrowed it down to closing a mysqli prepared statement before returning a value from the function. If I add a breakpoint after $stmt->close(), the function will return null. If I remove my container from the script, it produces a different problem entirely:

PHP Warning: get_prospects(): Property access is not allowed yet in /home/vhosts/dla-dev/app/tools/test-xdebug.php on line 104
PHP Stack trace:
PHP 1. {main}() /home/vhosts/dla-dev/app/tools/test-xdebug.php:0
PHP 2. get_prospects($db = class mysqli { public $affected_rows = NULL; public $client_info = NULL; public $client_version = NULL; public $connect_errno = NULL; public $connect_error = NULL; public $errno = NULL; public $error = NULL; public $error_list = NULL; public $field_count = NULL; public $host_info = NULL; public $info = NULL; public $insert_id = NULL; public $server_info = NULL; public $server_version = NULL; public $stat = NULL; public $sqlstate = NULL; public $protocol_version = NULL; public $thread_id = NULL; public $warning_count = NULL }) /home/vhosts/dla-dev/app/tools/test-xdebug.php:113

Value of the $stmt variable in PhpStorm:
   'affected_rows' => NULL,
   'insert_id' => NULL,
   'num_rows' => NULL,
   'param_count' => NULL,
   'field_count' => NULL,
   'errno' => NULL,
   'error' => NULL,
   'error_list' => NULL,
   'sqlstate' => NULL,
   'id' => NULL,

trace.manual.without-stmt-close (2,593,500 bytes)
sample_script.php (2,764 bytes)

2019-08-03 20:26

reporter   ~0005104

1. trace.container.with-stmt-close: DI Container + $stmt->close() before function return
2. trace.container.without-stmt-close: DI Container, no $stmt->close()
3. trace.manual.with-stmt-close: new mysqli object + $stmt->close() before function return
4. trace.manual.without-stmt-close: new mysqli object, no $stmt->close()

2019-08-03 20:40


trace.manual.with-stmt-close.with-error-handler (1,659,128 bytes)

2019-08-03 20:40

reporter   ~0005105

The last thing I think is relevant is that the problem can be reproduced without the container if I register a custom error handler:

function exceptionErrorHandler($severity, $message, $file, $line)
    if (!(error_reporting() & $severity)) {
        // This error code is not included in error_reporting
    throw new ErrorException($message, 0, $severity, $file, $line);


2019-09-09 08:24

administrator   ~0005139

I believe it is this **PHP** bug that causes the issue: — this got fixed in for PHP 7.4. As this is technically a BC break, it was not merge back to older PHP versions.

If you could try the latest 7.4.0RC1 version to test whether it solved this problem, that'd be great! If not, then I suggest we close the issue as I'm relatively sure, this is the cause of your issue.

Issue History

Date Modified Username Field Change
2017-10-26 02:44 New Issue
2017-10-26 10:15 derick Note Added: 0004445
2017-10-26 10:15 derick Assigned To => derick
2017-10-26 10:15 derick Status new => feedback
2018-01-29 21:48 derick Note Added: 0004579
2018-01-29 21:48 derick Status feedback => resolved
2018-01-29 21:48 derick Resolution open => unable to reproduce
2019-08-03 19:17 Note Added: 0005101
2019-08-03 19:18 Status resolved => new
2019-08-03 19:18 Resolution unable to reproduce => reopened
2019-08-03 19:18 PHP Version 7.1.5-7.1.9 => 7.3.5-7.3.9
2019-08-03 20:23 File Added: trace.container.with-stmt-close
2019-08-03 20:23 File Added: trace.container.without-stmt-close
2019-08-03 20:23 File Added: trace.manual.with-stmt-close
2019-08-03 20:23 File Added: trace.manual.without-stmt-close
2019-08-03 20:23 File Added: sample_script.php
2019-08-03 20:23 Note Added: 0005103
2019-08-03 20:26 Note Added: 0005104
2019-08-03 20:40 File Added: trace.manual.with-stmt-close.with-error-handler
2019-08-03 20:40 Note Added: 0005105
2019-09-09 08:24 derick Status new => feedback
2019-09-09 08:24 derick Note Added: 0005139