Can apache's PHP module affect C++ exceptions mechanism in other modules? - php

Setup:
Apache
php CLI
php_module.so for Apache
custom.so - my php extension with the following code (C++):
try {
throw MyException("Bla-Bla");
} catch(const MyException& e) {
LOG("got " << e.what());
}
The CLI version of PHP shows me "got Bla-Bla" where i expect it to (custom logger). But apache's PHP module run the same code and crash with uncaught exception:
terminate called after throwing an instance of 'MyException'
what(): Bla-Bla
[Wed Oct 07 14:12:41 2015] [notice] child pid 12614 exit signal Abort trap (6)
The php_module.so is build from the same sources as PHP CLI, but GCC flags used to compile php_module.so is unknown to me. Could some set of gcc flags (used for php_module.so compilation) affect custom.so exceptions behavior?
UPDATE
Seems to be GCC bug, because using clang solves the problem.

Related

dyld: lazy symbol binding failed: Symbol not found: _clock_gettime - in mongodb laravel

I am using Laravel 5.4 version to implement mongodb CRUD operation using link. I am using Mac OS El Captain 10.11. I have installed mongodb.so extension with php version 7.1.16
While i am trying getting eloquent connection it throws me ERR_EMPTY_RESPONSE
I have digg in details an found following error log in Apache during restart the MAMP server
Mon Aug 28 10:22:14 2017] [notice] Graceful restart requested, doing restart
[Mon Aug 28 10:22:15 2017] [notice] Digest: generating secret for digest authentication ...
[Mon Aug 28 10:22:15 2017] [notice] Digest: done
[Mon Aug 28 10:22:15 2017] [notice] Apache/2.2.31 (Unix) mod_wsgi/3.5
Python/2.7.13 PHP/7.1.1 mod_ssl/2.2.31 OpenSSL/1.0.2j DAV/2
mod_fastcgi/2.4.6 mod_perl/2.0.9 Perl/v5.24.0 configured -- resuming normal operations
[Mon Aug 28 10:22:15 2017] [notice] FastCGI: process manager initialized (pid 4233)
dyld: lazy symbol binding failed: Symbol not found: _clock_gettime
Referenced from:
/Applications/MAMP/bin/php/php7.1.1/lib/php/extensions/no-debug-non-zts-20160303/mongodb.so
Expected in: /usr/lib/libSystem.B.dylib
dyld: Symbol not found: _clock_gettime
Referenced from:
/Applications/MAMP/bin/php/php7.1.1/lib/php/extensions/no-debug-non-zts-20160303/mongodb.so
Expected in: /usr/lib/libSystem.B.dylib
dyld: lazy symbol binding failed: Symbol not found: _clock_gettime
Referenced from:
/Applications/MAMP/bin/php/php7.1.1/lib/php/extensions/no-debug-non-zts-20160303/mongodb.so
Expected in: /usr/lib/libSystem.B.dylib
dyld: Symbol not found: _clock_gettime
Referenced from:
/Applications/MAMP/bin/php/php7.1.1/lib/php/extensions/no-debug-non-zts-20160303/mongodb.so
Expected in: /usr/lib/libSystem.B.dylib
This screenshot shows the details of mongodb extension
I have searched online for error dyld: lazy symbol binding failed: Symbol not found: _clock_gettime and found this answer. I have applied all steps which i mentioned, but unable to fix the issue.
Please someone help me to get rid of this.
First of you need to update your os to macOS Sierra, (I am using version 10.12)
clock_gettime was not provided in El Capitain,
Apple has (finally) introduced the clock_gettime posix API in Sierra. Our configure script detects this and enable usage of it. Since the binary isn't executed on Sierra, but instead on El Capitain where this functionality doesn't exist, the linking in runtime fails. Using the workaround you suggest is not a good solution. This might seemingly work, but it is not impossible that you get strange failures at a later time since the binary isn't compiled for the system it is executing on.
Reference From : https://bugs.erlang.org/browse/ERL-256
Latest versions of php{XX}-mongodb installed from homebrew rely on the use of a OS X 10.12 specific Symbol called _clock_gettime, which did not exists in OS X < 10.12.
Upgrading your system will solve this problem, but you might have some valid reasons to not wish to upgrade it.
There is a pull-request currently being Work-In-Progress to preserve the OS X 10.11 compatibility :
https://github.com/Homebrew/homebrew-php/issues/3737
https://github.com/Homebrew/homebrew-php/pull/3890
While this is not accepted, you can hack the phpXX-mongodb formula yourself, as nicely suggested by #adocwang here :
(Be sure to install xcode-select tools first)
sudo xcode-select --install
# Or if you already installed it
softwareinstall --install -a
Then edit the php{XX}-mongodb formula (that'll be php71-mongogb, php56-mongodb, or whatever PHP version you're using)
brew edit php{XX}-mongodb
Find the line of "def install", and replace
def install
Dir.chdir "mongodb-#{version}" unless build.head?
By
def install
Dir.chdir "mongodb-#{version}" unless build.head?
if MacOS.version == "10.11" && MacOS::Xcode.installed? && MacOS::Xcode.version >= "8.0"
inreplace %w[src/libbson/src/bson/bson-clock.c], "HAVE_CLOCK_GETTIME", "UNDEFINED_GIBBERISH"`
end
Then force the reinstallation of this formula from source
brew reinstall -s php{XX}-mongodb

Error loading oci8.so with Ubuntu server 17.04 php 7 and apache2

I have gone through the whole process of downloading Oracle instant client, SDK, etc. in a Ubuntu Server 17.04. Then converted rpm packages to deb with alien, installed, set the paths, downloaded pecl oci8, compiled and installed (w/o errors), etc. and then added the line:
extension=/usr/lib/php/20151012/oci8.so
And restarted. When I check the /var/log/apache2/error.log I see:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20151012/oci8.so' - libmql1.so: cannot open shared object file: No such file or directory in Unknown on line 0
[Thu Jul 20 10:46:44.352631 2017] [mpm_prefork:notice] [pid 23450] AH00163: Apache/2.4.25 (Ubuntu) configured -- resuming normal operations
[Thu Jul 20 10:46:44.352717 2017] [core:notice] [pid 23450] AH00094: Command line: '/usr/sbin/apache2'
Does any one know what I could do to make it work?
I guess I have not selinux enabled or maybe it is a permissions problem?
Thanks
The solution is to put the ORACLE global variables NOT in /etc/environment but in the /etc/apache2/envvars
So, I've added these 2 lines at the end of /etc/apache2/envvars
export LD_LIBRARY_PATH=/usr/lib/oracle/12.2/client64/lib
export ORACLE_HOME=/usr/lib/oracle/12.2/client64
And all working great
As you still will have the same problem with php cli with the above solution, it would be better to add a new file /etc/ld.so.conf.d/oracle.conf with this content:
/usr/lib/oracle/12.2/client64/lib
Then run
sudo ldconfig
This way it works for apache and php cli and you do not need to change /etc/apache2/envvars
With Linux Ubuntu 18, if you're getting the same message, but its command line version:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20170718/oci8' when using php cli (= command line, as opposed to php as an apache module), all you need to do is to set LD_LIBRARY_PATH (not ORACLE_HOME), inside of /etc/environment, as shown below:
export LD_LIBRARY_PATH=/opt/oracle/instantclient_12_2
Next time you open a shell, the environment will declare this variable.
Note that the variable value needs to point to the folder that contains the lib*.so files.
Verification:
open a new console, and run
php -m | grep oci8

Phalcon Installation on Ubuntu 13.10, PHP 5.5 - invalid opcode

I have installed Phalcon using the instructions in the download page on a brand new server with Ubuntu 13.10, Apache 2.4 and PHP 5.5
When I try to run the test/default application I am seeing this in the Apache logs:
[Wed Apr 02 18:46:14.381872 2014] [core:notice] [pid 7634] AH00052: child pid 7639 exit signal Illegal instruction (4)
Additional hunting and tracking I ran across this in dmesg
[1156560.603934] traps: php[5067] trap invalid opcode ip:7fa191d7ddc8 sp:7fffa291e4c0 error:0 in phalcon.so[7fa191c18000+28d000] [1157014.697160] traps: php[6185] trap invalid opcode ip:7ff2b48f5dc8 sp:7fff678e6f00 error:0 in phalcon.so[7ff2b4790000+28d000]
[1157054.064211] traps: php[6205] trap invalid opcode ip:7ff3f4deddc8 sp:7fff6d8f26c0 error:0 in phalcon.so[7ff3f4c88000+28d000] [1157071.808218] traps: php[6256] trap invalid opcode ip:7faee68eddc8 sp:7fffa58c37b0 error:0 in phalcon.so[7faee6788000+28d000]
Any help appreciated.
Try compiling Phalcon this way:
cd cphalcon/build/safe
export CFLAGS="-O2 -fvisibility=hidden"
phpize
./configure --enable-phalcon
make
sudo make install

Why php fails to report syntax error and Apache crashes with segmentation fault?

I have a class file which has some buggy code e.g
else{
$stp->Object($a);
$abbr = $a->abbr;
}
asdf
}
My understanding is that php should properly display an error message e.g saying sth that "asdf" is not a class or constant etc . But as I see this peice of code crashes the server with segmentation fault , as my error log file says:
[Fri Mar 08 17:21:37 2013] [notice] child pid 8615 exit signal Segmentation fault (11)
Is it possible to configure php/apache to properly handle these errors ?
Why php is failing to report the error some understandable way . I only see "The connection was reset"
message in browser.
Specification:
XAMPP (php 5.3.1)
MAC OS 10.6
Xdebuger installed
Apparently something is going wrong into Apache, so it can't be properly displayed because the Apache child exit.
I had some similar error once because the PHP error made a redirection to a PHP error file (ex: ErrorDocument 500), which contained the same error, so it redirect to the PHP error page and so on... making a redirection loop.
Apache kill itself to avoid the machine to go down.
You have to diagnose what is making Apache die.
To do this, install "strace", eg. on debian :
apt-get install strace
Then stop your Apache, and start it through strace :
strace -f /usr/sbin/apache2ctl
Reproduce your problem until your Apache child crash, and try to look into the strace log to find out what happened.
Hope this helped.

Pervasive SQL Driver

UPDATE: should be on serverfault as suggested. New post here: https://serverfault.com/questions/451220/psql-64bit-driver-error
I am having a hard time getting PHP to connect with ODBC using a Pervasive SQL driver.
I have an Ubuntu Server 12.04 and have installed the 64bit PSQL Client drivers from here:
http://www.pervasivedb.com/psqlv11/Pages/PSQL-v11-Linux-Downloads.aspx
I have setup my ODBC.ini with the DSN to my database, and I can happily connect and then run queries:
isql Exchequer
When I use PHP, odbc_connect looks OK and gives me a resource, but odbc_exec (the point at which the driver is called) then totally fails (SEG fault):
[Fri Aug 10 11:05:50 2012] [notice] child pid 13770 exit signal Segmentation fault (11)
What am I doing wrong?
UPDATE:
Here is the output from gdb
(gdb) run /var/www/default/scripts/stock/index.php
Starting program: /usr/bin/php5 /var/www/default/scripts/stock/index.php
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffecc89700 (LWP 14514)]
[Thread 0x7fffecc89700 (LWP 14514) exited]
Halt[Inferior 1 (process 14513) exited normally]
(gdb) bt
No stack.
And the PHP error.log entry
[Fri Aug 10 15:24:53 2012] [notice] child pid 14510 exit signal Segmentation fault (11)
I also added in the Trace/TraceFile but I don't seem to get any output saved to the log file.
Update 2:
This is the simplified script I am running:
if(!$odbc = odbc_connect("exchequer","username","password")) {
die("Connection to Exchequer failed");
}
$rows = odbc_exec($odbc,'SELECT sl.slStockCode, sl.slQtyInStock, sl.slQtyAllocated , sl.slLocCode FROM StockLocation sl WHERE sl.slLocCode IN (\'DIG\',\'WOO\',\'MEN\')');
echo "".print_r($rows,true)."";
The odbc_connect works (doesn't die) but I keep seeing error 342 in my browser, and "exit signal Segmentation fault" in the apache log files.
It could just be a bug in one of the components you are using but my best guess it is a mismatch in your components for the size of SQLLEN/SQLULEN when they were compiled. You can enable logging in unixODBC and it may give us a hint. Edit your odbcinst.ini file and add the following to the top:
[ODBC]
Trace=yes
TraceFile=/tmp/unixodbc.log
If you don't know which odbcinst.ini file you need to edit run odbcinst -j and it will tell you. Now run your PHP script and the file above should contain the log.
Or, you could run php under the debugger (gdb) and see where it falls over. For this you'll need to find where your php executable is and run something like:
gdb /path/to/php
then type "run /path/to/my/php/script" and when it falls over type "bt" to get a back trace which will tell us where it fell over.
However, if it is a SQLLEN/SQLULEN mismatch corruption is probably going on and that can mean it seg faults somewhere totally different from where the problem is. You need to verify that PHP's ODBC module, unixODBC and your ODBC driver were all built with SQLLEN and SQLULEN the same size. I'm guessing if you installed unixODBC and PHP from Ubuntu then they will match and so the odd one out will be the Pervasive driver for which you'll need to ask them.
odbcinst -j outputs the size of SQLLEN/SQLULEN that unixODBC was built using.
You can find a lot more about this at 64-bit ODBC

Categories