[PHP-BUG] Bug #62599 [NEW]: Some SPL Exceptions do not display any backtrace / error message via mod_php5
From: peter at netkey dot at Operating system: FreeBSD PHP version: 5.4.4 Package: SPL related Bug Type: Bug Bug description:Some SPL Exceptions do not display any backtrace / error message via mod_php5 Description: When called via apache2 (mod_php5), some SPL exception do not display any information: BadFunctionCallException, InvalidArgumentException, OutOfBoundsException, RuntimeException and UnexpectedValueException. When called vi CLI the backtrace and exception message is displayed. All other SPL exceptions display the expected message / backtrace. PHP was installed via the ports system, before the upgrade form 5.3 to 5.4 the mentioned exceptions displayed message and backtrace. Test script: --- Expected result: Fatal error: Uncaught exception 'InvalidArgumentException' with message 'SDF' in /path/to/script.php Actual result: -- Fatal error: in /path/to/script.php -- Edit bug report at https://bugs.php.net/bug.php?id=62599&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62599&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62599&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62599&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62599&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62599&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62599&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62599&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62599&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62599&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62599&r=support Expected behavior: https://bugs.php.net/fix.php?id=62599&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62599&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62599&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62599&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62599&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62599&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62599&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62599&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62599&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62599&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62599&r=mysqlcfg
#31538 [Com]: MySQLi disconnects after termination of child in master
ID: 31538
Comment by: peter at netkey dot at
Reported By: rudy dot metzger at xs4all dot nl
Status: Open
Bug Type: MySQLi related
Operating System: Fedora Core 3
PHP Version: 5.0.3
New Comment:
You need a seperate connection for each child, or MySQL will get
confused.
See http://dev.mysql.com/doc/mysql/en/gone-away.html the comment from
Christophe C.
HTH
Previous Comments:
[2005-01-13 15:45:20] rudy dot metzger at xs4all dot nl
Used DB versions
MySQL-devel-4.1.7-0
MySQL-shared-4.1.7-0
MySQL-server-4.1.7-0
MySQL-client-4.1.7-0
[2005-01-13 15:42:01] rudy dot metzger at xs4all dot nl
Description:
When connecting to a database, then forking off a new child, the
database connection will be terminated (disconnected) when the child
exits.
I have the feeling that at the "cleanup" of the child process the
database connection is closed. This should not be the case because the
master process might still use it.
This is not the case with the mysql extension, only with mysqli. With
the mysql extension, you might be required to give the optional
parameter "open new session" on the connect. at least this is what I
did.
Reproduce code:
---
0 ) {
if ( !pcntl_wifexited($status) )
echo "Collected killed pid $pid\n";
else
echo "Collected pid $pid\n";
}
}
declare(ticks=1);
pcntl_signal( SIGCHLD, 'SigChild' );
$res = mysqli_connect('localhost','zpc','zpc');
ping_db($res,'after connect');
$pid = pcntl_fork();
ping_db($res,'right after fork');
if ( !$pid ) { // --- the slave
echo "child sleep\n";
sleep(5);
echo "child exiting\n";
exit(0);
}
ping_db($res,'after fork');
echo "master sleep\n";
sleep(10);
ping_db($res,'after sleep');
while ( ($pid=pcntl_wait($status)) > 0 ) {
if ( !pcntl_wifexited($status) )
echo "Collected killed pid $pid\n";
else
echo "Collected pid $pid\n";
}
mysqli_close( $res );
?>
Expected result:
The database connection in the master should not have terminated.
Actual result:
--
6311 after connect: still alive
6313 right after fork: still alive
child sleep
6311 right after fork: still alive
6311 after fork: still alive
master sleep
child exiting
Collected pid 6313
6311 after sleep: died
In the last line you can see that the connection died (6311 is master,
6313 is child)
--
Edit this bug report at http://bugs.php.net/?id=31538&edit=1
