-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Latest build of Phalcon 1.3.0 is crashing PHPEd #1714
Comments
Could you please generate the backtrace? gdb /path/to/php-fpm /path/to/core/dump and then at gdb prompt run
|
I was finishing editing my post when you wrote that. Please read the edits. Where do I find "/path/to/core/dump" ? |
"/var/crash/_var_web_php_sbin_php-fpm.33.crash" is not a core dump: File format not recognized |
Are you using Ubuntu? |
yes |
Run this as root: cd /var/crash
apport-unpack _var_web_php_sbin_php-fpm.33.crash /var/crash/unpacked
chmod a+rX -R /var/crash/unpacked then (i think this can be run as the ordinary user): gdb /var/web/php/sbin/php-fpm /var/crash/unpacked/CoreDump |
bt full:
|
Does it run fine without the debugger? |
Yes. |
OK, could you please build Phalcon from ext/ in debug mode and try again? This should produce more meaningful backtrace. cd ext
phpize
./configure CFLAGS="-O0 -g3"
make -j4
sudo make install |
bt full:
|
Gotta step out.. Will be available next morning. Please let me know if you figure anything out. Clearly, something in that commit broke the debugger. Thanks! |
I'm back... Any thoughts? This is an absolute nightmare scenario for me. I'm too far into my project to start again. And no debugger is a disaster... |
This backtrace looks totally different — though it is possible that the crash happened in the same place as before, it was triggered by a different code path. The first crash happened when Phalcon\Validation\Message\Group::valid() was called, the second one happened when Phalcon\Dispatcher::dispatch() called the controller/action handler. Is there any source code for dbg-php-5.5.so or is it proprietary? Also is there a way to run php under valgrind? |
I am running the tests under valgrind: https://travis-ci.org/sjinks/cphalcon/builds/15769025 to see if it detects anything wrong. |
dbg-php-5.5.so is proprietary. I am at a workstation now with different environment, I am going to see if the same problem occurs here. |
yea, exactly the same thing. slightly different Ubuntu configuration, but identical result. but what was in the commit
that may have introduced the problem? what if you start looking there? |
"Regenerated build" commits contain several weeks of works — these commits merge all files from ext/ into one and put it into build/. To find out what commit introduced the bug you need to check all commits and build phalcon from ext/, this is probably the only way. |
ok, I have no problem doing that. Can you give me any idea of the time range I should be looking at? |
BTW, did you build PHP yourself? |
to do that I have to do php gen-build.php? |
yes, I compiled PHP myself. |
I would try bisection — try the commit that lays in the middle between the latest and the last one you built Phalcon from. If it fails, go towards the last successful build, if succeeds, go towards the latest commit. |
No. cd ext
git checkout <commit hash goes here>
phpize
./configure CFLAGS="-O0 -g3"
make -j4
sudo make install To speed up build you can use a higher number after |
For debugging I usually use PHP built with |
thanks, I started looking for a breaking change. |
There is another option: you can contact NuSphere support and refer them to this issue. Because everything runs fine without the debugger and the crash happens inside |
If they need a test server, I can provide it. |
you know, it is extremely difficult to communicate with NuSphere. they never admit to existence of bugs in their software, and their standard response is "can't reproduce". I'd rather exhaust all other options first. |
Question: does Phalcon loads before or after dbg-php-5.5? If before, please try to load it (Phalcon) very last. |
Phalcon is loaded AFTER dbg module. |
alright, I have found the problem commit. It is: c4351e6feb3e5138f3026e9e790b9fdf2b47fb25 30/10/13 Phalcon
Merge pull request #1473 from sjinks/fastdi
Faster version of Phalcon\DI using object handlers The one before it handles PHPEd breakpoints just fine: 30/10/13
Merge pull request #1477 from dreamsxin/request_file
Use FILEINFO_MIME_TYPE for \Pahlcon\Request\File::getRealType Anything else I can do? |
This is very sad :-( OK, could you please comment out line 489 in ext/di.c: phalcon_di_object_handlers.get_properties = phalcon_di_get_properties; and try again? |
commit Id c4351e6feb3e5138f3026e9e790b9fdf2b47fb25 line 489 of ext/di.c is: phalcon_fetch_params_ex(2, 1, &name, &definition, &shared); your code is at line number 454. Commenting your code out at line 454 fixed the problem. PHPEd's debugbreaks don't crash anymore. |
OK, I thought so. Could you please do the same for the latest 1.3.0 and see if it works? |
Also if you run |
[Zend Modules]
DBG |
OK, please let me know if commenting out |
would a workaround mean that whoever's using PHPEd would miss out on some DI-related (new & great) features? |
With that workaround you won't be able to see the internal properties of DI which is still better than the crash :-) All other features remain intact. And if possible, please show NuSphere this thread — hopefully they will be able to fix the debugger. |
ok, commenting out that code in latest commit does fix the issue. everything is working. regarding NuSphere - I could try filing a bug. what low-level details might help them identify the problem? |
They will definitely ask you for the code that reproduces the bug. Please tell them the commit ID of 1.3.0 where the bug happens. This is the handler that returns all internal properties of DI: https://github.com/phalcon/cphalcon/blob/1.3.0/ext/di.c#L379 If they need any other info, either you ask me or ask them to leave a comment here. Thanks! |
ok, I appreciate your time. would you please update the thread once you put in the promised workaround in. |
Once this build succeeds, I will submit a PR. |
Could you please check that PhpEd can handle this code: <?php
$a = array();
$a['a'] = &$a;
$a['b'] = 123;
$c = new \Phalcon\Config($a);
$c['a']['c'] = $c;
print_r($c);
?> There will be a warning, "Warning: Phalcon\Config::__construct(): Recursion detected", this is OK |
With the latest code and with your DI code commented out:
<br />
<b>Warning</b>: Phalcon\Config::__construct(): Recursion detected in <b>/var/web/nginx/html/krfs/public/z.php</b> on line <b>5</b><br />
Phalcon\Config Object
(
[a] => Phalcon\Config Object
(
[b] => 123
[c] => Phalcon\Config Object
*RECURSION*
)
[b] => 123
)
|
PR submitted. |
Merged :-) |
You rock! Thanks a lot. Any chance for you to take another look at #1624 ? I know that me & my PHPEd are a real pain in the ass :-) |
Fixed in 1.3.0 |
I had not updated 1.3.0 in about 6-7 weeks. Did that just a moment ago and my PHPEd debugger started crashing when breakpoint is triggered.
I cloned/compiled 1.2.4 - no problem there.
The message:
Fatal error while fetching local variables. Debug session has been terminated.
The following is being added to /var/log/kern.log:
Also, there's a huge dump file created: /var/crash/_var_web_php_sbin_php-fpm.33.crash.
I started checking out commits by ID in reverse chronological order and found that problems started with commit ID
The one before it works fine.
Please help! :-)
Thanks!
The text was updated successfully, but these errors were encountered: