PHP call_user_func_array doesn't catch database error - php

I am currently building a database handler. Running on PHP 5.4.16 on top of a Firebird database.
When I have made a prepared statement, I need to execute the SQL with the arguments. I made this function:
private function assignParameters($args)
{
return call_user_func_array('ibase_execute',$args);
}
The problem is when I make an error in the args (not giving it the values that are expected), I expect the return to give false(error). ibase_execute normally returns false when an error has occurred.
But right now my PHP installation(XAMPP) simply crashes and restarts. I have tried using a try/catch without any luck. The call_user_func_array doesn't fail but I would expect it to return the result from the ibase_execute. I'm confused.
I should mention that there are no entries in PHP/Apache error logs. The only entry is that the Apache2 server have restarted.
The interbase configuration from phpinfo();
Firebird/InterBase Support dynamic
Compile-time Client Library Version Firebird API version 25
Run-time Client Library Version WI-V6.3.2.26539 Firebird 2.5
Any ideas - is this the driver crashing?
EDIT:
As requested from Mariuz here is what I got from the debug at crash time. The crash creates two dump report from the http process witch is running the PHP code.
They both contain a lot of information. To much to dump here but here's the excetions.
Dump 1
Exception Information
In httpd__PID__10168__Date__02_21_2014__Time_03_40_11PM__949__Second_Chance_Exception_C0000008.dmp the assembly instruction at 0x76ed12c7 which does not correspond to any known native module in the process has caused an unknown exception (0xc0000008) on thread 0
Dump 2
Exception Information
MSVCR80!UNWINDUPVEC+50In httpd__PID__10064__Date__02_21_2014__Time_03_40_05PM__321__Second_Chance_Exception_C0000005.dmp the assembly instruction at msvcr80!UnwindUpVec+50 in C:\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.6195_none_d09154e044272b9a\msvcr80.dll from Microsoft Corporation has caused an access violation exception (0xC0000005) when trying to read from memory location 0x00000000 on thread 5

This seems to be a segfault in php please provide the script and a backtrace to it
https://bugs.php.net/bugs-generating-backtrace-win32.php

Related

Error calling Php code from Xcode 12.2 dlopen libquic failed

I recently updated to Xcode 12.2. Now my php code (called from Xcode) to access and modify the local SQL database is broken.
Tried this solution:
https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_disable-library-validation
by enabling hardened runtime and then adding the runtime exception to disable library validation. Now the app crashes on startup. The original error code (in Xcode) when trying to access the database (via php) was: nw_protocol_get_quic_image_block_invoke dlopen libquic failed
that led me to the supposed fix above. DB is unreachable from the app.
Now I'm not sure how to proceed. Can someone please advise.
Additionally the responseString just looks like this: responseString = Optional(<?php (php code) ?>) .. not running the php code at all
Another thing, I'm getting Status Code: 412 or Precondition Failed when trying to run php scripts from Xcode
Thread with similar issue:
https://developer.apple.com/forums/thread/666538

ssh2_connect(): Error starting up SSH connection(-43): Failed getting banner

Have a docker container build using php-ssh2. php version 7.2 When trying to use
$con = ssh2_connect('hostname');
I am getting Error starting up SSH connection(-43): Failed getting banner . Interesting thing is 43 here. Whats the significance of 43. What does that mean? Also any idea how to fix this? There is no heavy load, running connection manually.
Deepdive into libssh2
This number -43 is an error code that comes directly from libssh2, specifically LIBSSH2_ERROR_SOCKET_RECV. The Failed getting banner message is the dynamic error message that accompanies the error code. These two pieces of information give the location where this error is thrown, namely in the receive_banner.
Underlying problem
It was the result of the socket throwing a receive error when libssh2 tried to read from it as part of initialising your SSH session. Either the server is misconfigured and is not sending a banner or the underlying connection disconnected for some reason.
Solution
The best course of action seems to have adequate retrying in place for these kinds of errors. You are connecting to a network which is an action that can fail. As the number of servers you are connecting to increases, you are going to run into errors that are a result of the underlying network. Adequate error handling is your best course of action.
You can find how to set exception handlers from the PHP docs.

PHP odbc_exec Segmentation Fault after successful odbc_connect to Teradata 14.0

I am using PHP 5.3.3 on RHEL 5. I have installed all the necessary drivers and add-ons for ODBC connections to Teradata. I wrote a simple script to test it:
$con_string = "DRIVER={Teradata};DBCName=**HOST**; DATABASE=**database**;";
$con = odbc_pconnect( $con_string , "user", "pass" );
var_dump($con);
echo 'here';
$res = odbc_exec($con, "SELECT id FROM database.table");
echo 'there';
var_dump($res);
The output is as follows:
resource(5) of type (odbc link persistent)
hereSegmentation fault
Obviously the connection works. I have also tried other commands, some work, some don't. odbc_tables() and odbc_procedures() return the correct information without problem. However, anything related to a SQL query gets a seg fault. I have not been able to get trace/debug to turn on for ODBC.
Any help would be greatly appreciated!
I experienced this problem with using a resultset twice for two different odbc_exec's. It was resolved doing unset($res) before each odbc_exec so the odbc_exec always starts using a clean variable.
I don't yet have a good explanation 'why' (probably previous resultset variables require correct 'closes'...?), but this prevents my segmentation faults
Three things you can do. First, (assuming you are using unixODBC) find your odbcinst.ini file and add:
[ODBC]
Trace=yes
TraceFile=/tmp/unixodbc.log
Run your PHP script from the command line and you should get a log. If it is segfaulting in unixODBC or your ODBC driver the last line should show an entry into an ODBC API but no exit. However, that will only give you a clue as to where it is failing.
Second thing you can do is find where your php executable is and run it under the debugger:
gdb /path/to/php
When you get the prompt do:
r /path/to/my/php_script
When it seg faults use the back trace (bt) command to show where it blew up.
Lastly, you could have a teradata ODBC driver which was not built with the same ODBC headers or defines as PHP and unixODBC. This is very tricky to discover but if you are on a 64 bit machine it is a possibility. You can use unixODBC's odbc_config command to find out how unixODBC was built. In particular odbc_config --ulen and --cflags. Unfortunately most debian based distributions don't include odbc_config yet - may be you'll be luckier on redhat. The thing you are looking for is teradata being built with SQLULEN 32 bits and unixODBC/PHP with it 64 bits - if you've got this situation you'll definitely get segfaults. If this is your issue you need to get the correct build from teradata or switch everything to 32 bit binaries.
Armed with this info you might be able to find out what is going wrong. You can always post the gdb back trace or the end of the unixODBC log file and I may be able to help.
I have seen this issue previously (specifically with Teradata ODBC connectivity) and remember having to patch and build a custom PHP executable in order to get it to work. I'm light on the details as it was some time ago but remember its due to a problem with PHP's ODBC_pconnect and the TD drivers. It seems that PHP's odbc_connect also uses odbc_pconnect so never worked - once odbc_connect was patched to remove odbc_pconnect I could use PHP as expected.
Sorry if that's a rambling mess, hopefully it will give you some pointers...

Patch PHP 5.3.10 to support sybase_next_result()

The database management system Sybase ASE supports multiple result sets, however the implementation of Sybase in PHP doesn't. There is a bug reported on this issue and there is also a patch supplied in that report (https://bugs.php.net/bug.php?id=48675). The patch is for version 5.2.9 and I've tried to add it to version 5.3.10. The source builds without warnings or errors, and testing the new function 'sybase_next_result()' does not yield a fatal error "Call to undefined function". This would suggest that the function is implemented, but not working as expected.
Configuration is:
configure --disable-isapi --enable-debug-pack --without-mssql --without-pdo-mssql --without-pi3web --with-mcrypt=static --disable-static-analyze --enable-cli --with-sybase-ct=%SYBASE%\%SYBASE_OCS%
There is a notice on 'sybase_query()' when there are multiple result sets saying "Sybase: Unexpected results, cancelling current in...". The first result set is retrieved. And this notice is returned even without the patch.
The number of stored procedures in the database that return multiple result sets is vast, and a 'sybase_next_result()' would be the best solution. In short, I looking for an equivalent to 'mssql_next_result()' (http://se2.php.net/manual/en/function.mssql-execute.php) for Sybase in PHP 5.3.10.
Worth noting is that the other parts of the Sybase implementation is in place and seems work as expected.
My testing environment is a WAMP server (Windows 7, Apache 2.21, MySQL 5.5.20, PHP 5.3.10) and Sybase ASE is version 15.7.0.
Is there anyone out there that has "solved" this?
With regards
//Jonas
Update:
A colleague gave me the instructions to use 'OutputDebugString()' (http://msdn.microsoft.com/en-us/library/windows/desktop/aa363362(v=vs.85).aspx) and catch that with DebugView (http://technet.microsoft.com/en-us/sysinternals/bb896647).
From this I can say that 'sybase_next_result()' is called but the block
if (sybase_ptr->active_result_index) {
...
}
is not run. This is probably correct (as I see it).
The row
retcode = ct_results(sybase_ptr->cmd, &restype);
is always setting 'retcode' to 'CS_FAIL'. This is perhaps because the earlier
ZEND_FETCH_RESOURCE2(sybase_ptr, sybase_link *, sybase_link_index, id, "Sybase-Link", le_link, le_plink);
sets 'sybase_ptr' in sutch fashion that 'retcode' becomes 'CS_FAIL'.

Using SQL Server in Cake PHP: PHP SQL Server interface is not installed

I inherited an old Cakephp site that was using adodb as a driver to connect to an MSSQL database and it turns out this is no longer supported in the new version of cake (1.3, we are in 1.2) so I'm trying to change the driver so I can upgrade. We're using IIS and a sql server 2005 database on a different server, php 5.2.17. However using driver "mssql" gives me the following errors:
PHP SQL Server interface is not installed. For troubleshooting information, see http://php.net/mssql/
Call to undefined function mssql_min_message_severity()
The top error leads me to a page regarding the old php_mssql.dll, which according to this question: ( CakePHP: error when trying to use mssql datasource ) will become a problem when I switch to PHP 5.3 so I'm trying to use the php_sqlsrv*.dll for my php version but I still get the error. Could never get the mssql.dll one to work either. I do however see "sqlsrv support enable" in phpinfo.php and the whole sqlsrv section is intact there.
In cake php I'm using "driver => 'mssql'", is this the correct driver for the new sqlsrv dll? Is there something I'm missing? For kicks I tried 'driver' => 'sqlsrv', that fixes the php SQL Server interface error but I still get
"Fatal error: Call to undefined function sqlsrv_min_message_severity() in C:\Inetpub\wwwroot\riverstone-dev\www\cake\libs\model\datasources\dbo\dbo_sqlsrv.php on line 107"
Installing the latest SQL Native Client set from Microsoft and reenabling the extension in PHP has worked, albeit on a different server. Please try the drivers below if having a similar problem:
http://www.microsoft.com/download/en/details.aspx?id=20098

Categories