#32292 [Com]: XML parser script crashes PHP5ts.dll in Apache 2
ID: 32292 Comment by: dwivedi dot vibhor at gmail dot com Reported By: admin at skynetlabs dot org Status: No Feedback Bug Type: XML related Operating System: Windows XP (SP2) PHP Version: 5.0.4 RC1 New Comment: i just installed apache and php in my windows xp apache is running nicely when i am not loading php module but when i changed configuration file as add ing this two lines LoadModule php5_module "c:/PHP/php5ts.dll" AddType application/x-httpd-php .php but now if i restart the server it is giving error i don't know what t o do next plese try with php5 and apache latest version. Previous Comments: [2006-02-04 08:22:34] dwivedi dot vibhor at gmail dot com i just installed apache server and php. i add these 3 lines in config file. LoadModule php5_module c:/PHP/php5ts.dll AddType application/x-httpd-php .php [2005-11-28 17:47:41] vicoasis at gmail dot com At me the same mistake when I use plus still MySQL szAppName : Apache.exe szAppVer : 2.0.55.0 szModName : php5ts.dll szModVer : 5.0.5.5 offset : 7da9 Any body know to what it is caused : [2005-06-27 04:00:25] rick dot martinez at gmail dot com The crash is reproduced on my system. I have the same problem on other scripts as well. All those scripts use DOM. Here is the Windows error signature for the error produced by the submitted script: szAppName : Apache.exe szAppVer : 2.0.54.0 szModName : php5ts.dll szModVer : 5.0.4.4 offset : 7798 Files created by Windows related to the error are available here: http://www.digxworld.com/files/phpXmlErrors/Apache.exe.mdmp http://www.digxworld.com/files/phpXmlErrors/appcompat.txt If you need any more info, just let me know. Hope this helps! (especially since this error is really annoying me :P) [2005-03-25 01:49:42] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2005-03-18 19:55:56] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip It does not crash for me.. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/32292 -- Edit this bug report at http://bugs.php.net/?id=32292&edit=1
#32292 [Com]: XML parser script crashes PHP5ts.dll in Apache 2
ID: 32292 Comment by: dwivedi dot vibhor at gmail dot com Reported By: admin at skynetlabs dot org Status: No Feedback Bug Type: XML related Operating System: Windows XP (SP2) PHP Version: 5.0.4 RC1 New Comment: i just installed apache server and php. i add these 3 lines in config file. LoadModule php5_module c:/PHP/php5ts.dll AddType application/x-httpd-php .php Previous Comments: [2005-11-28 17:47:41] vicoasis at gmail dot com At me the same mistake when I use plus still MySQL szAppName : Apache.exe szAppVer : 2.0.55.0 szModName : php5ts.dll szModVer : 5.0.5.5 offset : 7da9 Any body know to what it is caused : [2005-06-27 04:00:25] rick dot martinez at gmail dot com The crash is reproduced on my system. I have the same problem on other scripts as well. All those scripts use DOM. Here is the Windows error signature for the error produced by the submitted script: szAppName : Apache.exe szAppVer : 2.0.54.0 szModName : php5ts.dll szModVer : 5.0.4.4 offset : 7798 Files created by Windows related to the error are available here: http://www.digxworld.com/files/phpXmlErrors/Apache.exe.mdmp http://www.digxworld.com/files/phpXmlErrors/appcompat.txt If you need any more info, just let me know. Hope this helps! (especially since this error is really annoying me :P) [2005-03-25 01:49:42] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2005-03-18 19:55:56] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip It does not crash for me.. [2005-03-15 11:11:01] admin at skynetlabs dot org I have just tested the same file on 5.0.4 RC1 (latest snapshot) with the same results. Whoever runs the script crashes Apache. The XML used by the script can be found here: http://www.skynetlabs.org/torrents/azureus_stats.xml the script running as it should (PHP 5.0.2): http://www.skynetlabs.org/torrents/crashserver.php download of the script: http://www.skynetlabs.org/torrents/crashserver.txt (be aware that server has been busy, so please be patient in receiving the results from the php script) Don't know exactly what the procedure is that crashes php >=5.0.3... going to examine the script better this afternoon. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/32292 -- Edit this bug report at http://bugs.php.net/?id=32292&edit=1
#36281 [NEW]: bindParam not working with LIKE '%:foo%'
From: vendor at visv dot net
Operating system: Linux
PHP version: 5.1.2
PHP Bug Type: PDO related
Bug description: bindParam not working with LIKE '%:foo%'
Description:
$q = "SELECT id, name FROM test WHERE name like '%:foo%';
$s = "carrot";
$dbh = new PDO('mysql:...', $user, $pass);
$sth = $dbh->prepare($q);
$sth->bindParam(':foo', $s);
$sth->execute()
while ($r = $sth->fetch()) {
print_r($r);
}
the above does not work. Adding PDO::PARAM_STR, and the
length argument do not help matters.
simply embedding $s in place of :foo does work. It also
works fine if I leave off the "'%" and "%'" parts
and $s == the column value. It just seems bindParam()
cannot cope with the '% %' parts in the query.
I do not find similar in your bugtracking system, nor
in user supplied notes (currently there are none).
Thanks.
Reproduce code:
---
See description.
--
Edit bug report at http://bugs.php.net/?id=36281&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36281&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36281&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36281&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36281&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36281&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36281&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36281&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36281&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36281&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36281&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36281&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36281&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36281&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36281&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36281&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36281&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36281&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36281&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36281&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36281&r=mysqlcfg
#36280 [NEW]: Character increment - problems with non-english chars
From: dekelb at gmail dot com Operating system: PHP version: 4.4.2 PHP Bug Type: *General Issues Bug description: Character increment - problems with non-english chars Description: I've search for similar bug, but nothing found. If I missed it please ignore this post :) The manual mentioned the character increment, but there is no reference for English characters only. When I'm trying character increment on Hebrew chars (and I guess with any non-english chars it will be the same) the output of the script is just the same as the original char: The expected result is the following char (which is "á"), but the result is the same char. Notice that ++ on "à9" results with 9 changes to 0, but the Hebrew char isn't incremented. (The encoding I used for this post is windows-1255/iso-8859-8-i). -- Edit bug report at http://bugs.php.net/?id=36280&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36280&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36280&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36280&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36280&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36280&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36280&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36280&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36280&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36280&r=support Expected behavior:http://bugs.php.net/fix.php?id=36280&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36280&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36280&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36280&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36280&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36280&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36280&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36280&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36280&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36280&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36280&r=mysqlcfg
#35737 [Com]: undefined symbol: sqlite3SelectDelete
ID: 35737 Comment by: fuchsd at gmail dot com Reported By: jphml at videotron dot ca Status: No Feedback Bug Type: SQLite related Operating System: Linux PHP Version: 5.1.1 New Comment: Same problem: php 5.1.2, apache 2.2.0, mysql 5.0.18, Ubuntu Breezy Previous Comments: [2006-02-01 19:33:15] kpankratz at gmail dot com installing Tcl-devel package did not solve the problem. Using --with-zlib removed the sqlite errors. The next module in the list now produces the error. ldd -d libphp5.so shows most of the modules as an undefined symbol. PHP 5.1.2 source files, Apache 2.2.0 source files, OS = SLES 9 SP3 [2006-01-28 23:08:34] vano at kolumbus dot fi Try to install Tcl-devel package, because sqlite needs it. Then recompile php. OR Re-configure pdo_sqlite/sqlite with "--disable-tcl" option (because it is actually not needed for building the lirary). Then recompile php. [2006-01-11 03:54:23] george at gmarcotte dot com http://snaps.php.net/php5.1-latest.tar.gz has no effect still get the error: httpd: Syntax error on line 53 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/libphp5.so into server: /usr/local/apache2/modules/libphp5.so: undefined symbol: sqlite3SelectDelete when I try to start the webserver. What is sqlite3SelectDelete? is there some header files missing? [2006-01-05 11:23:24] james at e0ts dot com Same with Debian 3.1 [2006-01-04 19:23:21] esesen at o2 dot pl exactly the same problem under slackware 10.2 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/35737 -- Edit this bug report at http://bugs.php.net/?id=35737&edit=1
#36214 [Asn]: Conditional operator fails to work properly when both __set and __get are set
ID: 36214
User updated by: pexu at lyseo dot edu dot ouka dot fi
Reported By: pexu at lyseo dot edu dot ouka dot fi
Status: Assigned
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.1.2
Assigned To: dmitry
New Comment:
I quickly tried the newest snapshot (20060203, 5.1.3-dev) but neither
error messages were generated nor results were any different from
5.1.2. (Error_reporting was set to E_ALL | E_STRICT and display_errors
was turned on. I tried both conditional operator and normal if
clause.)
But I guess I can utilize ArrayObject etc. to get the expected result I
wanted.
Previous Comments:
[2006-02-02 16:04:32] [EMAIL PROTECTED]
That it works in the latter case is just a side affect which falls
under "undefined behaviour".
You should actually see an error telling you that __get() can't return
a reference or that array_push() wants a reference.
IIRC it's fixed in current CVS, could you please try?
Where "fixed" means that an error is generated.
Thanks.
[2006-02-02 14:08:59] pexu at lyseo dot edu dot ouka dot fi
Even overload::$array is defined as public variable, actual result
remains the same. But if I change conditional operator to normal if ..
else clause, problem disappers!
So:
function __get ($key)
{
if (isset($this->array[$key]))
return $this->array[$key];
else
return null;
}
works just fine. So the actual problem can't be a private property
which is accessed outside the class, right?
[2006-01-30 19:43:18] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You're trying to acces a private property (arr) from
outside the class.
[2006-01-30 19:34:55] pexu at lyseo dot edu dot ouka dot fi
Description:
When both __set and __get are set, conditional operator "?" fails to
work when used to return variables from __get when working with
arrays.
A normal if .. else clause however works fine. With non-array variables
there's no problem, either.
If __set is not used, this bug doesn't seem to appear.
Reproduce code:
---
class overload
{
private $array = array();
public function __set($key, $value)
{
$this->array[$key] = $value;
}
public function __get($key)
{
return isset($this->array[$key])
? $this->array[$key]
: null;
}
}
$ol = new overload; $ol->arr = array();
array_push($ol->arr, "element");
var_dump($ol->arr);
Expected result:
array(1) {
[0]=>
string(7) "element"
}
Actual result:
--
array(0) {
}
--
Edit this bug report at http://bugs.php.net/?id=36214&edit=1
#36278 [Opn->Bgs]: extremely slow bytea extraction from pgsql
ID: 36278 Updated by: [EMAIL PROTECTED] Reported By: support at kalador dot com -Status: Open +Status: Bogus Bug Type: Performance problem Operating System: redhat linux PHP Version: 5.1.2 New Comment: With libpq > 7.3 pg_unescape_bytea() is just a wrapper for PQunescapeBytea(). If this function is slow - sorry, we can do nothing about it. Please report it to PG developers. Previous Comments: [2006-02-03 22:38:18] support at kalador dot com libpq is 3.2 Using postgresql 8.0.1 btw [2006-02-03 22:17:26] [EMAIL PROTECTED] What version of libpq are you using? [2006-02-03 21:34:53] support at kalador dot com Description: I tried 3 ways to store big images (500K) in database and display in browser. lo works fast, as does using a "text" column and converting the image to base64 (and back for display). However, using bytea with escaping is very slow. Adding to the database is fine (it is fast), retrieving is the problem. Reproduce code: --- This code consumed my CPU and took 77 seconds to run for a 400K image: Expected result: This should take less than 1 second. Using a text column and base64 escaping rather than a bytea column and pg_unescape_bytea takes less than 1 second on the same data. Actual result: -- Actually result - 77 seconds. -- Edit this bug report at http://bugs.php.net/?id=36278&edit=1
#36214 [Opn->Asn]: Conditional operator fails to work properly when both __set and __get are set
ID: 36214
Updated by: [EMAIL PROTECTED]
Reported By: pexu at lyseo dot edu dot ouka dot fi
-Status: Open
+Status: Assigned
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.1.2
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2006-02-02 16:04:32] [EMAIL PROTECTED]
That it works in the latter case is just a side affect which falls
under "undefined behaviour".
You should actually see an error telling you that __get() can't return
a reference or that array_push() wants a reference.
IIRC it's fixed in current CVS, could you please try?
Where "fixed" means that an error is generated.
Thanks.
[2006-02-02 14:08:59] pexu at lyseo dot edu dot ouka dot fi
Even overload::$array is defined as public variable, actual result
remains the same. But if I change conditional operator to normal if ..
else clause, problem disappers!
So:
function __get ($key)
{
if (isset($this->array[$key]))
return $this->array[$key];
else
return null;
}
works just fine. So the actual problem can't be a private property
which is accessed outside the class, right?
[2006-01-30 19:43:18] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You're trying to acces a private property (arr) from
outside the class.
[2006-01-30 19:34:55] pexu at lyseo dot edu dot ouka dot fi
Description:
When both __set and __get are set, conditional operator "?" fails to
work when used to return variables from __get when working with
arrays.
A normal if .. else clause however works fine. With non-array variables
there's no problem, either.
If __set is not used, this bug doesn't seem to appear.
Reproduce code:
---
class overload
{
private $array = array();
public function __set($key, $value)
{
$this->array[$key] = $value;
}
public function __get($key)
{
return isset($this->array[$key])
? $this->array[$key]
: null;
}
}
$ol = new overload; $ol->arr = array();
array_push($ol->arr, "element");
var_dump($ol->arr);
Expected result:
array(1) {
[0]=>
string(7) "element"
}
Actual result:
--
array(0) {
}
--
Edit this bug report at http://bugs.php.net/?id=36214&edit=1
#36278 [Fbk->Opn]: extremely slow bytea extraction from pgsql
ID: 36278 User updated by: support at kalador dot com Reported By: support at kalador dot com -Status: Feedback +Status: Open Bug Type: Performance problem Operating System: redhat linux PHP Version: 5.1.2 New Comment: libpq is 3.2 Using postgresql 8.0.1 btw Previous Comments: [2006-02-03 22:17:26] [EMAIL PROTECTED] What version of libpq are you using? [2006-02-03 21:34:53] support at kalador dot com Description: I tried 3 ways to store big images (500K) in database and display in browser. lo works fast, as does using a "text" column and converting the image to base64 (and back for display). However, using bytea with escaping is very slow. Adding to the database is fine (it is fast), retrieving is the problem. Reproduce code: --- This code consumed my CPU and took 77 seconds to run for a 400K image: Expected result: This should take less than 1 second. Using a text column and base64 escaping rather than a bytea column and pg_unescape_bytea takes less than 1 second on the same data. Actual result: -- Actually result - 77 seconds. -- Edit this bug report at http://bugs.php.net/?id=36278&edit=1
#36278 [Opn->Fbk]: extremely slow bytea extraction from pgsql
ID: 36278 Updated by: [EMAIL PROTECTED] Reported By: support at kalador dot com -Status: Open +Status: Feedback Bug Type: Performance problem Operating System: redhat linux PHP Version: 5.1.2 New Comment: What version of libpq are you using? Previous Comments: [2006-02-03 21:34:53] support at kalador dot com Description: I tried 3 ways to store big images (500K) in database and display in browser. lo works fast, as does using a "text" column and converting the image to base64 (and back for display). However, using bytea with escaping is very slow. Adding to the database is fine (it is fast), retrieving is the problem. Reproduce code: --- This code consumed my CPU and took 77 seconds to run for a 400K image: Expected result: This should take less than 1 second. Using a text column and base64 escaping rather than a bytea column and pg_unescape_bytea takes less than 1 second on the same data. Actual result: -- Actually result - 77 seconds. -- Edit this bug report at http://bugs.php.net/?id=36278&edit=1
#27009 [Com]: mcrypt now crashes apache
ID: 27009
Comment by: keymone at gmail dot com
Reported By: ronan at ronanmcnulty dot co dot uk
Status: No Feedback
Bug Type: mcrypt related
Operating System: winxp
PHP Version: 4.3.4
New Comment:
Windows 2003 Server SP1
PHP 4.3.2
this line crashes Apache/1.3.24
$bar = mcrypt_ecb(MCRYPT_RIJNDAEL_128 , 'foo', $bar, MCRYPT_DECRYPT);
Previous Comments:
[2004-07-08 21:54:33] danielpm8 at hotmail dot com
Hi,
I am experiencing this problem also. When I run mcrypt_decrypt it
causes apache to crash. However, mcrypt_encrypt is working fine.
I have Mcrypt module loaded as a dynamic module on apache. I am using
Windows XP professional, apache 1.3 and php 4.3.4 . The mcrypt dll
library is a "libmcrypt + php 4.3.x on windows".
The following is the example code I used, which causes apache to
crash.
If you any questions or suggestions please do not hesitate to contact
me. Thanks in advance.
Cheers,
Daniel
==
Example code
example6_encrypt();
function example6_encrypt(){
$iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
$key = "This is a very secret key";
$text = "Meet me at 11 o'clock behind the monument.";
//echo strlen($text) . "\n";
$crypttext = mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $key, $text,
MCRYPT_MODE_ECB, $iv);
//echo strlen($crypttext) . "\n";
echo "encrypted string: $crypttext";
example6_decrypt($crypttext);
}
/*
string mcrypt_decrypt ( string cipher, string key, string data, string
mode [, string iv])
*/
function example6_decrypt($text){
$iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
$key = "This is a very secret key";
$decrypt_text = mcrypt_decrypt(MCRYPT_RIJNDAEL_256, $key, $text,
MCRYPT_MODE_ECB, $iv);
echo "decrypted string: $decrypt_text";
}
[2004-01-31 23:15:59] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2004-01-22 14:03:46] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
[2004-01-22 13:47:30] ronan at ronanmcnulty dot co dot uk
Description:
When I use the example:
mcrypt_ecb (MCRYPT_3DES, $key, $input, MCRYPT_ENCRYPT);
Apache crashes:
szAppName : Apache.exe szAppVer : 0.0.0.0 szModName :
libmcrypt.dll
szModVer : 0.0.0.0 offset : 00022685
Reproduce code:
---
mcrypt_ecb (MCRYPT_3DES, $key, $input, MCRYPT_ENCRYPT);
Expected result:
I expect apache NOT to crash!
Actual result:
--
Apache actually crashes
--
Edit this bug report at http://bugs.php.net/?id=27009&edit=1
#36278 [NEW]: extremely slow bytea extraction from pgsql
From: support at kalador dot com Operating system: redhat linux PHP version: 5.1.2 PHP Bug Type: Performance problem Bug description: extremely slow bytea extraction from pgsql Description: I tried 3 ways to store big images (500K) in database and display in browser. lo works fast, as does using a "text" column and converting the image to base64 (and back for display). However, using bytea with escaping is very slow. Adding to the database is fine (it is fast), retrieving is the problem. Reproduce code: --- This code consumed my CPU and took 77 seconds to run for a 400K image: Expected result: This should take less than 1 second. Using a text column and base64 escaping rather than a bytea column and pg_unescape_bytea takes less than 1 second on the same data. Actual result: -- Actually result - 77 seconds. -- Edit bug report at http://bugs.php.net/?id=36278&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36278&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36278&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36278&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36278&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36278&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36278&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36278&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36278&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36278&r=support Expected behavior:http://bugs.php.net/fix.php?id=36278&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36278&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36278&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36278&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36278&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36278&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36278&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36278&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36278&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36278&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36278&r=mysqlcfg
#36276 [NEW]: Tiger hash fails regression test
From: shiloh dot heurich at newvillagemedia dot com Operating system: Mac OS X 10.4.4 PHP version: 5CVS-2006-02-03 (snap) PHP Bug Type: *Encryption and hash functions Bug description: Tiger hash fails regression test Description: When running regression tests on PHP 5.1.2 and 200602031530 snapshots, tiger hash function fails: FAIL tiger [ext/hash/tests/tiger.phpt] t] uname: Darwin 8.4.0 Darwin Kernel Version 8.4.0: Tue Jan 3 18:22:10 PST 2006; root:xnu-792.6.56.obj~1/RELEASE_PPC Power Macintosh powerpc gcc: gcc version 4.0.1 (Apple Computer, Inc. build 5250) configuration: CFLAGS='-g -O2 -arch ppc -mcpu=970' ./ configure --prefix=/usr/local/php5 --mandir=/usr/local/ php5/share/man --infodir=/usr/local/php5/share/info -- sysconfdir=/usr/local/etc/php5 --x-includes=/usr/X11R6/ include --x-libraries=/usr/X11R6/lib --with-apxs=/usr/sbin/ apxs --enable-cli --enable-cgi --with-layout=PHP --with- config-file-path=/usr/local/etc/php5 --enable-ipv6 -- disable-all --enable-libxml --with-libxml-dir=/usr --with- openssl=/usr --with-kerberos=/usr --with-pcre-regex=/usr/ local/pcre --with-zlib=/usr --with-zlib-dir=/usr --enable- bcmath --with-bz2=/usr --enable-calendar --enable-ctype -- with-curl=/usr --enable-dba --with-cdb --with-inifile -- with-flatfile --enable-dom --enable-exif --enable-ftp -- with-openssl-dir=/usr --with-gd --with-jpeg-dir=/usr/local/ libjpeg --with-png-dir=/usr/local/libpng --with-xpm-dir=/ usr/X11R6 --with-freetype-dir=/usr/X11R6 --with-t1lib=/usr/ local/t1lib --enable-gd-native-ttf --enable-hash --with- imap=/usr/local/imap-2004g --with-imap-ssl=/usr --with- ldap=/usr --enable-mbstring --enable-mbregex --with-mcrypt=/ usr/local/libmcrypt --with-mssql=/usr/local/freetds --with- mysql=/usr --with-mysql-sock=/var/mysql/mysql.sock --with- mysqli=/usr/bin/mysql_config --with-ncurses=/usr --with- iodbc=/usr --enable-pdo --with-pdo-dblib=/usr/local/freetds --with-pdo-mysql=/usr --enable-posix --with-pspell=/usr/ local/aspell --enable-reflection --enable-session --enable- shmop --enable-simplexml --with-snmp=/usr --enable-soap -- enable-sockets --enable-spl --with-sqlite --enable-sqlite- utf8 --enable-sysvmsg --enable-sysvsem --enable-sysvshm -- with-tidy=/usr/local/tidy --enable-tokenizer --enable-wddx --enable-xml --enable-xmlreader --with-xmlrpc --with-iconv=/ usr/local/libiconv --with-iconv-dir=/usr/local/libiconv -- enable-xmlwriter --with-xsl=/usr --with-pear --enable- memory-limit Reproduce code: --- tiger.php: Expected result: tiger.log: EXPECTED OUTPUT 24f0130c63ac933216166e76b1bb925ff373de2d49584e7a f258c1e88414ab2a527ab541ffc5b8bf935f7b951c132951 8ee409a14e6066933b63d5b2abca63d71a78f55e29eb4649 2586156d16bf9ab1e6e48bdf5e038f8053c30e071db3bcb0 3ee8a9405396ddba1bc038508af4164ac1fe59ef58916a85 Actual result: -- tiger.log: ACTUAL OUTPUT 60ef6c0dbc077b9c175ffb7771008c253bacea024c9d01ab c79e799e14b53e7df935d83477fa4df939d18c44f76b73cd 0cbefecf310004da41a290cfeef81e918ea533f130c2b9ba 11fe76694d6a116bd7af6eeded0ef4d147e43ee107abda06 397fb45a4406fd2046c9ad070907ac574d004836c89553a2 -- Edit bug report at http://bugs.php.net/?id=36276&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36276&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36276&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36276&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36276&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36276&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36276&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36276&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36276&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36276&r=support Expected behavior:http://bugs.php.net/fix.php?id=36276&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36276&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36276&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36276&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36276&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36276&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36276&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36276&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36276&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36276&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36276&r=mysqlcfg
#36275 [NEW]: Regression of bug #30638
From: shiloh dot heurich at newvillagemedia dot com Operating system: Mac OS X 10.4.4 PHP version: 5CVS-2006-02-03 (snap) PHP Bug Type: Scripting Engine problem Bug description: Regression of bug #30638 Description: This bug has resurfaced when building PHP 5.1.1, 5.1.2 and 200602031530 snapshot on Darwin 8.4.0 (Mac OS X 10.4.4) ppc platform. make test: FAIL Bug #30638 (localeconv returns wrong LC_NUMERIC settings) [tests/lang/bug30638.phpt] uname: Darwin 8.4.0 Darwin Kernel Version 8.4.0: Tue Jan 3 18:22:10 PST 2006; root:xnu-792.6.56.obj~1/RELEASE_PPC Power Macintosh powerpc gcc: gcc version 4.0.1 (Apple Computer, Inc. build 5250) configuration: CFLAGS='-g -O2 -arch ppc -mcpu=970' ./ configure --prefix=/usr/local/php5 --mandir=/usr/local/ php5/share/man --infodir=/usr/local/php5/share/info -- sysconfdir=/usr/local/etc/php5 --x-includes=/usr/X11R6/ include --x-libraries=/usr/X11R6/lib --with-apxs=/usr/sbin/ apxs --enable-cli --enable-cgi --with-layout=PHP --with- config-file-path=/usr/local/etc/php5 --enable-ipv6 -- disable-all --enable-libxml --with-libxml-dir=/usr --with- openssl=/usr --with-kerberos=/usr --with-pcre-regex=/usr/ local/pcre --with-zlib=/usr --with-zlib-dir=/usr --enable- bcmath --with-bz2=/usr --enable-calendar --enable-ctype -- with-curl=/usr --enable-dba --with-cdb --with-inifile -- with-flatfile --enable-dom --enable-exif --enable-ftp -- with-openssl-dir=/usr --with-gd --with-jpeg-dir=/usr/local/ libjpeg --with-png-dir=/usr/local/libpng --with-xpm-dir=/ usr/X11R6 --with-freetype-dir=/usr/X11R6 --with-t1lib=/usr/ local/t1lib --enable-gd-native-ttf --enable-hash --with- imap=/usr/local/imap-2004g --with-imap-ssl=/usr --with- ldap=/usr --enable-mbstring --enable-mbregex --with-mcrypt=/ usr/local/libmcrypt --with-mssql=/usr/local/freetds --with- mysql=/usr --with-mysql-sock=/var/mysql/mysql.sock --with- mysqli=/usr/bin/mysql_config --with-ncurses=/usr --with- iodbc=/usr --enable-pdo --with-pdo-dblib=/usr/local/freetds --with-pdo-mysql=/usr --enable-posix --with-pspell=/usr/ local/aspell --enable-reflection --enable-session --enable- shmop --enable-simplexml --with-snmp=/usr --enable-soap -- enable-sockets --enable-spl --with-sqlite --enable-sqlite- utf8 --enable-sysvmsg --enable-sysvsem --enable-sysvshm -- with-tidy=/usr/local/tidy --enable-tokenizer --enable-wddx --enable-xml --enable-xmlreader --with-xmlrpc --with-iconv=/ usr/local/libiconv --with-iconv-dir=/usr/local/libiconv -- enable-xmlwriter --with-xsl=/usr --with-pear --enable- memory-limit Reproduce code: --- bug30638.php: Expected result: bug30638.log: EXPECTED OUTPUT decimal_point: , thousands_sep: . Actual result: -- bug30638.log: ACTUAL OUTPUT decimal_point: , thousands_sep: -- Edit bug report at http://bugs.php.net/?id=36275&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36275&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36275&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36275&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36275&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36275&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36275&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36275&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36275&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36275&r=support Expected behavior:http://bugs.php.net/fix.php?id=36275&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36275&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36275&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36275&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36275&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36275&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36275&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36275&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36275&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36275&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36275&r=mysqlcfg
#36158 [Asn->Csd]: SIGTERM is not handled correctly when running as a FastCGI server
ID: 36158 Updated by: [EMAIL PROTECTED] Reported By: chris at mysociety dot org -Status: Assigned +Status: Closed Bug Type: CGI related Operating System: * PHP Version: 5.1.2, 4.4.2 Assigned To: dmitry New Comment: The bug is fixed in CVS HEAD and PHP_5_1 with libfcgi replacement, however mod_fcgi can lose some requsts during graceful restart itself. Previous Comments: [2006-02-02 00:48:49] chris at mysociety dot org Yeah, that's a fair point. Matters would be improved by adding the FCGI_FAIL_ON_INTR flag to the call to FCGX_InitRequest; that's not a complete solution, since that might cause the server process to quit on receipt of another signal in the call to FCGX_Accept_r, but that's not a very serious problem. Here's a patch that includes that change: http://bitter.ukcod.org.uk/~chris/tmp/20060201/php-4.3.10-fastcgi-sigterm-fix.patch [2006-02-01 18:20:43] stefan at luli dot de Hi there, I am struggeling with the described problem for quite some time now. I have traced the problem now in the code back to the SIGTERM play between fcgi_pm and php. The question is if fcgi_pm should send a SIGTERM to the script even though it processes a request at this momment. One would think that fcgi_pm should be smart enough to deal with this situation (wait until request is done/send no more requests/send SIGTERM). But apparently it isn't. The patch seams to do the trick, but is also prevents php to terminate in case it's just idel. So php will sit there until the next request comes in and terminate once the request is done before waiting for the next request to come in. This should be solved. [2006-01-26 08:58:25] [EMAIL PROTECTED] Dmitry, does the new code fix this problem..? [2006-01-26 01:55:15] chris at mysociety dot org That snapshot (a) doesn't fix the problem -- the FastCGI code is essentially unchanged since 4.x, though with a bunch of whitespace noise; and (b) wouldn't help us in any case since it's PHP5 and our applications are written for PHP4. [2006-01-25 23:51:05] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/36158 -- Edit this bug report at http://bugs.php.net/?id=36158&edit=1
#36274 [NEW]: Incorrect handling of multi-dimensional array increments
From: micheal dot winger at gmail dot com Operating system: Windows XP Home PHP version: 5.1.2 PHP Bug Type: Feature/Change Request Bug description: Incorrect handling of multi-dimensional array increments Description: When working with multi-dimensional arrays without keys.. it ignores the 2-nd dimension and only increments the first. Reproduce code: --- $array[][]="blah"; $array[][]="2nd"; print_r($array); Expected result: I expect to see this on the website: Array ( [0] => Array ( [0] => blah ) [0] => Array ( [1] => 2nd ) ) Actual result: -- Array ( [0] => Array ( [0] => blah ) [1] => Array ( [0] => 2nd ) ) Notice that it is only incrementing the first array. I feel this is a problem since you can do $array[][] in the code, but then it renders useless if you want to have more than one value in the 2nd array, making it impossible to use this method. If possible, make it work like the expected result, and then add a small function just to jump the first array up.. but give support for higher than 2d arrays, allowing the user to specify which layer the user wants to increment. -- Edit bug report at http://bugs.php.net/?id=36274&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36274&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36274&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36274&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36274&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36274&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36274&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36274&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36274&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36274&r=support Expected behavior:http://bugs.php.net/fix.php?id=36274&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36274&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36274&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36274&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36274&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36274&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36274&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36274&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36274&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36274&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36274&r=mysqlcfg
#28321 [Com]: Duplicate Tags in SOAP message parsed incorrectly.
ID: 28321
Comment by: PiRanha_777 at yahoo dot fr
Reported By: ronunism at hotmail dot com
Status: No Feedback
Bug Type: SOAP related
Operating System: Fedora Core 1
PHP Version: 5CVS-2004-05-07 (dev)
Assigned To: dmitry
New Comment:
I have the same problem.
I think the problem comes from the fact that, as the SOAP response is
stored in associative arrays, when there are 2 (or more) tags with the
same name the value of the second tag replace the value of first one.
Previous Comments:
[2006-01-16 01:22:43] marc dot greenstock at gmail dot com
I am experiencing the same problem with the MSN Search API. More
specifically on the SourceRequest objects, where there are 4 tags of
the same name.
[2004-05-21 17:03:47] [EMAIL PROTECTED]
May be the problem in WSDL file?
Can you put here WSDL file, SOAP request (XML) and SOAP response?
[2004-05-07 20:36:10] ronunism at hotmail dot com
Description:
Using PHP5's SoapClient to recieve a SOAP envelope that contains
multiple instances of the same tag, the resulting object retains only
the last item of the given tag name.
E.G. Receiving a SOAP message containing:
Scooby
Lassie
Benji
Results in an object containing:
[dogs] => stdClass Object
(
[dog] => Benji
)
I'm using a perl SOAP::Lite script for the server, and php5's SOAP for
the client. When the tags are changed to be unique (e.g. ,
, ) all three examples are returned as expected.
Reproduce code:
---
[ TestFunction is a simple function that returns a SOAP envelope
containing:
Scooby
Lassie
Benji
$client is the PHP5 SoapClient variable. ]
$test = $client->__call('TestFunction', array($a));
echo '';
print_r($test);
echo '';
Expected result:
stdClass Object
(
[dogs] => array
(
[0] => Scooby
[1] => Lassie
[2] => Benji
)
)
Actual result:
--
stdClass Object
(
[dogs] => stdClass Object
(
[dog] => Benji
)
--
Edit this bug report at http://bugs.php.net/?id=28321&edit=1
#36010 [Asn->Csd]: Crash when executing SQL statment with lob parameter after another SQL statment
ID: 36010
Updated by: [EMAIL PROTECTED]
Reported By: spatar at mail dot nnov dot ru
-Status: Assigned
+Status: Closed
Bug Type: OCI8 related
Operating System: SuSE Linux 9.2 (i586)
PHP Version: 5.1.2
Assigned To: tony2001
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Thanks for the last comment, it was _very_ helpful.
Previous Comments:
[2006-02-03 12:42:43] robertg2 at hope dot ac dot uk
I have the same problem.
Apache/2.0.54
Oracle InstantClient 10.2.0.1
PHP 5.0.4
oci8 from cvs (1.292 at 2006-02-03)
Suse Linux 10.0 (2.6.13-15-default)
Reverted back to oci8 pecl beta release 1.1.1 which doesn't suffer
from the issue.
[2006-01-14 15:48:49] [EMAIL PROTECTED]
Assigned to the maintainer.
[2006-01-14 15:38:32] spatar at mail dot nnov dot ru
Description:
OCI8 crashes in call "oci_execute" when executing some SQL statment
with binded lob parameter after another SQL statment.
Previous version (PHP 5.1.1) doesn't produce this bug.
More details:
OS: SuSE Linux 9.2 (i586)
uname -a: Linux www 2.6.8-24-smp #1 SMP Wed Oct 6 09:16:23 UTC 2004
i686 i686 i386 GNU/Linux
Apache 2.2.0
Oracle 10.1.0.3.0
PHP 5.1.2
Reproduce code:
---
load(), "\n";
}
$clob->free();
oci_free_statement($stid);
}
$conn = oci_connect("voip_dev", "9", "RS21");
f($conn);
f($conn);
oci_close($conn);
?>
Expected result:
lob string
lob string
Actual result:
--
#0 0xb6cfdc73 in kpufGetRcvInfo () from
/u01/app/oracle/OraHome2/lib/libclntsh.so.10.1
#1 0xb6f489b5 in ttcacr () from
/u01/app/oracle/OraHome2/lib/libclntsh.so.10.1
#2 0xb6f4a807 in ttcdrv () from
/u01/app/oracle/OraHome2/lib/libclntsh.so.10.1
#3 0xb6dec4ad in nioqwa () from
/u01/app/oracle/OraHome2/lib/libclntsh.so.10.1
#4 0xb6c5e07e in upirtrc () from
/u01/app/oracle/OraHome2/lib/libclntsh.so.10.1
#5 0xb6bf4d35 in kpurcsc () from
/u01/app/oracle/OraHome2/lib/libclntsh.so.10.1
#6 0xb6bb1831 in kpuexecv8 () from
/u01/app/oracle/OraHome2/lib/libclntsh.so.10.1
#7 0xb6bb33ac in kpuexec () from
/u01/app/oracle/OraHome2/lib/libclntsh.so.10.1
#8 0xb6c27b86 in OCIStmtExecute () from
/u01/app/oracle/OraHome2/lib/libclntsh.so.10.1
#9 0xb788ba64 in php_oci_statement_execute (statement=0x82f6c84,
mode=137325732)
at /home/spatar/mvtm-www/php-5.1.2/ext/oci8/oci8_statement.c:321
#10 0xb788fa7a in zif_oci_execute (ht=2, return_value=0xb640b02c,
return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1) at
/home/spatar/mvtm-www/php-5.1.2/ext/oci8/oci8_interface.c:1276
#11 0xb7a07d7b in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffc240) at zend_vm_execute.h:192
#12 0xb7a56fbd in execute (op_array=0x82a6330) at zend_vm_execute.h:92
#13 0xb7a07836 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffc390) at zend_vm_execute.h:226
#14 0xb7a56fbd in execute (op_array=0x829df04) at zend_vm_execute.h:92
#15 0xb79eaf8f in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/spatar/mvtm-www/php-5.1.2/Zend/zend.c:1101
#16 0xb79b01ae in php_execute_script (primary_file=0xbfffe6e0) at
/home/spatar/mvtm-www/php-5.1.2/main/main.c:1720
#17 0xb7a57ac1 in php_handler (r=0x82799d0) at
/home/spatar/mvtm-www/php-5.1.2/sapi/apache2handler/sapi_apache2.c:584
#18 0x0807756b in ap_run_handler ()
...
--
Edit this bug report at http://bugs.php.net/?id=36010&edit=1
#36273 [Opn->Fbk]: pspell_suggest on certain string causes segfault
ID: 36273 Updated by: [EMAIL PROTECTED] Reported By: mnc at firmseek dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Linux PHP Version: 4.4.2 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Previous Comments: [2006-02-03 14:11:42] mnc at firmseek dot com Description: The code below generates a reproducible segmentation fault on every server I've tried it on. Reproduce code: --- Expected result: Null array, or an error code, but not a dead Apache. -- Edit this bug report at http://bugs.php.net/?id=36273&edit=1
#36273 [NEW]: pspell_suggest on certain string causes segfault
From: mnc at firmseek dot com Operating system: Linux PHP version: 4.4.2 PHP Bug Type: Reproducible crash Bug description: pspell_suggest on certain string causes segfault Description: The code below generates a reproducible segmentation fault on every server I've tried it on. Reproduce code: --- Expected result: Null array, or an error code, but not a dead Apache. -- Edit bug report at http://bugs.php.net/?id=36273&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36273&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36273&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36273&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36273&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36273&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36273&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36273&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36273&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36273&r=support Expected behavior:http://bugs.php.net/fix.php?id=36273&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36273&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36273&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36273&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36273&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36273&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36273&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36273&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36273&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36273&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36273&r=mysqlcfg
#36010 [Com]: Crash when executing SQL statment with lob parameter after another SQL statment
ID: 36010
Comment by: robertg2 at hope dot ac dot uk
Reported By: spatar at mail dot nnov dot ru
Status: Assigned
Bug Type: OCI8 related
Operating System: SuSE Linux 9.2 (i586)
PHP Version: 5.1.2
Assigned To: tony2001
New Comment:
I have the same problem.
Apache/2.0.54
Oracle InstantClient 10.2.0.1
PHP 5.0.4
oci8 from cvs (1.292 at 2006-02-03)
Suse Linux 10.0 (2.6.13-15-default)
Reverted back to oci8 pecl beta release 1.1.1 which doesn't suffer
from the issue.
Previous Comments:
[2006-01-14 15:48:49] [EMAIL PROTECTED]
Assigned to the maintainer.
[2006-01-14 15:38:32] spatar at mail dot nnov dot ru
Description:
OCI8 crashes in call "oci_execute" when executing some SQL statment
with binded lob parameter after another SQL statment.
Previous version (PHP 5.1.1) doesn't produce this bug.
More details:
OS: SuSE Linux 9.2 (i586)
uname -a: Linux www 2.6.8-24-smp #1 SMP Wed Oct 6 09:16:23 UTC 2004
i686 i686 i386 GNU/Linux
Apache 2.2.0
Oracle 10.1.0.3.0
PHP 5.1.2
Reproduce code:
---
load(), "\n";
}
$clob->free();
oci_free_statement($stid);
}
$conn = oci_connect("voip_dev", "9", "RS21");
f($conn);
f($conn);
oci_close($conn);
?>
Expected result:
lob string
lob string
Actual result:
--
#0 0xb6cfdc73 in kpufGetRcvInfo () from
/u01/app/oracle/OraHome2/lib/libclntsh.so.10.1
#1 0xb6f489b5 in ttcacr () from
/u01/app/oracle/OraHome2/lib/libclntsh.so.10.1
#2 0xb6f4a807 in ttcdrv () from
/u01/app/oracle/OraHome2/lib/libclntsh.so.10.1
#3 0xb6dec4ad in nioqwa () from
/u01/app/oracle/OraHome2/lib/libclntsh.so.10.1
#4 0xb6c5e07e in upirtrc () from
/u01/app/oracle/OraHome2/lib/libclntsh.so.10.1
#5 0xb6bf4d35 in kpurcsc () from
/u01/app/oracle/OraHome2/lib/libclntsh.so.10.1
#6 0xb6bb1831 in kpuexecv8 () from
/u01/app/oracle/OraHome2/lib/libclntsh.so.10.1
#7 0xb6bb33ac in kpuexec () from
/u01/app/oracle/OraHome2/lib/libclntsh.so.10.1
#8 0xb6c27b86 in OCIStmtExecute () from
/u01/app/oracle/OraHome2/lib/libclntsh.so.10.1
#9 0xb788ba64 in php_oci_statement_execute (statement=0x82f6c84,
mode=137325732)
at /home/spatar/mvtm-www/php-5.1.2/ext/oci8/oci8_statement.c:321
#10 0xb788fa7a in zif_oci_execute (ht=2, return_value=0xb640b02c,
return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1) at
/home/spatar/mvtm-www/php-5.1.2/ext/oci8/oci8_interface.c:1276
#11 0xb7a07d7b in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffc240) at zend_vm_execute.h:192
#12 0xb7a56fbd in execute (op_array=0x82a6330) at zend_vm_execute.h:92
#13 0xb7a07836 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffc390) at zend_vm_execute.h:226
#14 0xb7a56fbd in execute (op_array=0x829df04) at zend_vm_execute.h:92
#15 0xb79eaf8f in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/spatar/mvtm-www/php-5.1.2/Zend/zend.c:1101
#16 0xb79b01ae in php_execute_script (primary_file=0xbfffe6e0) at
/home/spatar/mvtm-www/php-5.1.2/main/main.c:1720
#17 0xb7a57ac1 in php_handler (r=0x82799d0) at
/home/spatar/mvtm-www/php-5.1.2/sapi/apache2handler/sapi_apache2.c:584
#18 0x0807756b in ap_run_handler ()
...
--
Edit this bug report at http://bugs.php.net/?id=36010&edit=1
#36084 [Com]: apache2 segfaults on phpinfo()
ID: 36084 Comment by: mail at skraemer dot net Reported By: clive at darkarts dot co dot za Status: No Feedback Bug Type: Reproducible crash Operating System: FreeBSD PHP Version: 5.1.2 New Comment: This might help you: I ran into the same problem, and the error dissapeared when i commented out the "ImageMagick"-extension in my "exentsions.ini" (FreeBSD-system). If you need detailed informations about the cofiguration- / compiling-process, please send me an e-mail. Previous Comments: [2006-01-28 01:00:05] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2006-01-27 01:06:31] engin at turk-php dot com i was having the same issue on same os and same php version but i didnt try to re-compile with different configure options coz in the previous php-5.0.5 with ZEND Debugger i faced with similar bug , seg fault, when i removed the Zend Debugger module it was working fine, ( on FreeBSD 4.11 - apache 1.3 ) recently i upgrade my os to FreeBSD-6.0 - apache 2.2 - php 5.1.2 with trial and error method i found imagick and recode modules cause issue [Thu Jan 27 02:04:12 2006] [notice] child pid 5968 exit signal Abort trap (6) httpd in free(): error: junk pointer, too high to make sense [2006-01-20 09:51:30] [EMAIL PROTECTED] Then you need to add rest of your options one by one to see which one is causing the problem for you. [2006-01-20 09:47:12] clive at darkarts dot co dot za commandline for both versions (again): rm config.cache ; ./configure --disable-all --disable-cgi --enable-maintainer-zts --with-apxs2=/usr/local/sbin/apxs && make clean && make && sapi/cli/php -r 'phpinfo();' no segfaulting, runs fine. [2006-01-20 09:22:41] [EMAIL PROTECTED] Now try the same but add --with-apxs2=/usr/local/sbin/apxs to the configure options. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/36084 -- Edit this bug report at http://bugs.php.net/?id=36084&edit=1
#36268 [Asn->Csd]: Object destructors called even after fatal errors
ID: 36268
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 5.1.2
Assigned To: dmitry
New Comment:
Fixed in CVS HEAD and PHP_5_1.
Previous Comments:
[2006-02-02 21:44:19] [EMAIL PROTECTED]
Description:
I just ran into this in CodeGen_PECL, wondering why the script
terminated half-way without giving any message, a stripped down
reproducing example is added below.
Basicly the problem was that a fatal error occuerd (which can't
be caught by an error handler) but my output buffer redirection
code still kicked in, so swallowing the error message from the
still active output buffer
its rather strange that i could implement an error handler
for E_FATAL errors using destructors whereas error_handler()
and register_shutdown_function() can't be used for this
Reproduce code:
---
filename = $filename;
ob_start();
}
function __destruct()
{
file_put_contents($this->filename, ob_get_clean());
}
}
$ob = new ob("ob.txt");
foo::bar();
?>
Expected result:
the error message
"Fatal error: Class 'foo' not found in /home/hartmut/new/ob.php on
line 22"
shown on the console after calling the script
Actual result:
--
the error message
"Fatal error: Class 'foo' not found in /home/hartmut/new/ob.php on
line 22"
goes to the "ob.txt" file, not the console, when calling this using
CLI,
the destructor is obviously executed *after* error handling
--
Edit this bug report at http://bugs.php.net/?id=36268&edit=1
