View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001360 | Xdebug | Uncategorized | public | 2016-11-03 14:35 | 2017-01-13 16:51 |
| Reporter | Blizz | Assigned To | |||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | resolved | Resolution | no change required | ||
| Platform | Docker | OS | Debian | OS Version | Jessie |
| Product Version | 2.4.1 | ||||
| Summary | 0001360: Xdebug enabled causes Segfaults | ||||
| Description | I'm experiencing a problem similar to the one described in ticket 0001339, but I decided to open a separate ticket in case you want to threat it as a different one. While unit testing code developed against Laravel 5.3.22 Xdebug seems to cause a crash when trying to execute a statement that results in a "QueryException". With xdebug disabled, the code "correctly" finishes, displaying the exception results. | ||||
| Steps To Reproduce | Attempt a save operation with a record not having a specific field on a table not having a default value for that field. Normal result: Illuminate\Database\QueryException: SQLSTATE[HY000]: General error: 1364 Field 'parent_id' doesn't have a default value (SQL: insert into /app/vendor/laravel/framework/src/Illuminate/Database/Connection.php:769 Caused by /app/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:93 Caused by /app/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:91 With xdebug: segfault. | ||||
| Additional Information | Attached is the full backtrace, this is the regular one: #0 0x00007f004f7e1d8b in xdebug_objdebug_pp (zval_pp=0x7ffca9b864c8, is_tmp=0x7ffca9b86414) at /tmp/pear/temp/xdebug/xdebug_var.c:57 I'll add my phpinfo as a note | ||||
| Tags | No tags attached. | ||||
| Operating System | |||||
| PHP Version | 7.0.10-7.0.14 | ||||
|
|
php info added as 2nd attachment instead. |
|
|
I'm pretty sure I've fixed this in Git already. Could you try the latest master branch from github.com/xdebug/xdebug please? I'm near releasing 2.5.0alpha1 with this fix too. |
|
|
This program makes use of the Zend Scripting Language Engine: PHPUnit 5.6.2 by Sebastian Bergmann and contributors. Segmentation fault (core dumped) It seems not in this case. I'll attach an update full backtrace but it looks pretty much the same as my initial one. |
|
|
Okay - thanks for trying. Can you provide me with all the steps that I need to (try) to reproduce this please? |
|
|
Took me a while, but I succeeded. I've managed to reproduce this on a vanilla install of Laravel 5.3 with the following code: No special dependencies included in composer.json, just laravel/framework (5.3.*) <?php class Category extends \Illuminate\Database\Eloquent\Model } $category = new Category(); Observation: It does not matter that the underlying table doesn't exist, the segmentation fault basically occurs on any exception being thrown. After some further testing it turns out that the fault is only raised if a read and an assignment operation follow each other. I've tried the following things (keeping the function and the "return $this"-statement): $this->{static::CREATED_AT} = $value; if ($this->timestamps !== true) if ($this->timestamps !== true) if (is_array($this->timestamps)) $this->timestamps !== true; is_array($this->timestamps); |
|
|
It gets even weirder: Apparently there needs to be a static read access as well... $this->timestamps !== true; static::CREATED_AT; $this->timestamps !== true; Order in which they occur doesn't seem to matter: static::CREATED_AT; $this->created_at = $value; |
|
|
I don't know Laravel. Can you give me a list of the exact things to run in a newly created directory? |
|
|
Create a boilerplate project by running: composer create-project --prefer-dist laravel/laravel testproject Then open the .env file in there, modify the DB_ constants. |
|
|
I can reproduce this with your test case, but also managed to get a smaller one: <?php } $f = new Foo; |
|
|
Small question: Now that you can reproduce it, is there a possible option for XDebug that I can switch off to not encounter that Segfault while keeping debugging functionality? I'm doing a lot of debugging lately and I keep running into the crash. Thanks. |
|
|
Sorry - I can't think of any, except for perhaps setting xdebug.collect_params=0. |
|
|
FYI: I set collect_params from 4 to 0 and that seems to have resolved it for now (at least regarding phpunit and phpspec, haven't had the chance to test the web-side of the code yet) |
|
|
I am pretty sure that I have fixed the crash related to objdebug_pp, as shown in your backtrace. Could you please try the latest version from GIT again? |
|
|
Tried it and it still segfaulted on my unit tests. Here is the head of it: Program terminated with signal SIGSEGV, Segmentation fault. Let me know if you need more info, or if I need to check something else. |
|
|
Ow, perhaps important: As you can probably see in the paths, this is 7.1.0 instead of 7.0.12, if I should test with a 7.0 release instead, let me know. |
|
|
This latest crash, with which reproduce case are you generating this? |
|
|
Ping? |
|
|
Sorry, haven't been able to spend the time on it earlier. |
|
|
Okay - thanks! |
