Bugzilla – Full Text Bug Listing
| Summary: | Reading system-wide php.ini by PHP execs leads to segfaults | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Jacek Pospychala <jacek.pospychala> | ||||||
| Component: | PDT | Assignee: | PHP Debug <php.debug-inbox> | ||||||
| Status: | CLOSED FIXED | QA Contact: | Ilina Stefanova <ilina.s> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | carpentier.martin, ganoro, kalin.a, kubo, mpav, qiangsheng.w, zhaozhongwei | ||||||
| Version: | unspecified | Flags: | ganoro:
review+
jacek.pospychala: review? zhaozhongwei: review+ |
||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Jacek Pospychala
Created attachment 177822 [details]
patch
use -n in all invokations of php execs
Comment on attachment 177822 [details]
patch
after further discussion with Roy, this solution turns incorrect. It would end up not reading any php.ini, whereas we want only ours php.ini to be read. But for some reason some other config is also loaded #$#(*( :-)
Created attachment 178045 [details]
patch v2
after even more discussions, it appears that -n is a correct argument.
To sum up:
php-cgi -c /dir/to/my/php.ini -n - reads only /dir/to/my/php.ini config
php-cgi -c /dir/to/my/php.ini - reads both my php.ini and system wide cfg
php-cgi -n - reads no any config
php-cgi - reads system wide cfg
system wide cfg may be <somewhere>/etc/php.ini as well as <somewhere/etc/conf.d/*
fixed in head and branch I recently had to update my Eclipse PDT to the latest milestone (because of the "broken file compare" bug) and found out that I couldn't run nor debug PHP script anymore because only the main php.ini file is loaded. All the extra configurations defined in /etc/php5/cli/conf.d/*.ini are ignored. After many searches for a solution I stumbled upon this bug report and was a bit mystified by the fix used. I can see how it's not a problem on a windows platform where all the php configuration is usually defined in one single ini file but on a Linux platform, modules configuration are set in external ini files (which aren't loaded anymore when debugging). I tried merging all the configurations in one single file and set the PHP executable to use it (in Preferences -> PHP -> PHP Executables) but it doesn't work. The php.ini file in /tmp/zend_debug/session*.tmp is always ends up as a copy of the original /etc/php5/cli/php.ini file. Are you sure this is the proper and only solution for the segfault problem? I have the same issue as comment #5. On Linux (Ubuntu) specifically, PHP uses a conf.d directory where all of the extension ini files are managed (things like mysql, xdebug, ...). The fix in this bug disables the ability to scan a dir for additional .ini files. hi, the point of this bug was that sometimes users have more than version of php executable which are incompatbile with each other. So now when one version of php exe was reading system-wide preferences of another executable, it was trying to load incompatible modules and was crashing with segfault. When configuring php executable in preferences, can you specify the optional php.ini file? It is not a single optional php.ini file. There is the standard php.ini file that we all know and love, then there is a conf.d directory that contains config info for all the optional PHP modules. Martin described this in comment #5. The point is that when you specify the -c or -n args to PHP, it does not read from the conf.d directory, even if you have set the PHP_INI_SCAN_DIR env var. The workaround that I'm using is to concatenate all the .ini files in the conf.d and append them to the root php.ini file. ok, so we probably should add an option (a checkbox?) like "Use system default php.ini configuration". So you could allow or deny reading php.ini and conf.d from Exes preferences. Alternatively we could expose ability to customize command line parameters. So you'd manually add/remove "-n -c" Would that work for you? I would love the "Use system default php.ini configuration" option. opened new bug #339547 for fixing this. Thanks for rising this issue guys! Closing... |