[PHP-DEV] Bug #14886: Access Violation in error handler with PEAR DB (ISAPI)
From: [EMAIL PROTECTED]
Operating system: Win2000
PHP version: 4.1.1
PHP Bug Type: IIS related
Bug description: Access Violation in error handler with PEAR DB (ISAPI)
I ran ApacheBench on a PEAR DB script (see below), and IIS (ISAPI mode)
will die eventually. It is so bad that often iisreset is unable to
restart IIS.
The ab command I used:
ab -n1 -c10 url
with the following results:
This is ApacheBench, Version 1.3c $Revision: 1.45 $ apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-2000 The Apache Group, http://www.apache.org/
Server Software:Microsoft-IIS/5.0
Server Hostname:jaguar
Server Port:80
Document Path: /lens/adodb/peartest.php
Document Length:142 bytes
Concurrency Level: 10
Time taken for tests: 269.158 seconds
Complete requests: 1
Failed requests:5272
(Connect: 0, Length: 5272, Exceptions: 0)
Non-2xx responses: 1868
Total transferred: 1891906 bytes
HTML transferred: 769177 bytes
Requests per second:37.15
Transfer rate: 7.03 kb/s received
Connnection Times (ms)
min avg max
Connect:0 0 5
Processing: 2 268 2771
Total: 2 268 2776
The interesting thing is that the crash only happens when an invalid SQL
statement is entered in the script below(notice the column badcolumn
which does not exist). If a valid SQL statement is entered (badcolumn is
removed), no crash occurs, and ApacheBench runs fine.
So I guess it is some problem with PHP's error-handler or MySQL extension
not being thread safe. No dll extensions were installed. Standard
pre-compiled PHP downloaded from php.net was used.
John Lim
=== THE SCRIPT ===
?php
include DB.php;
$DBNAME = 'PEAR DB';
$dsn = mysql://root:@localhost/northwind;
$db = DB::Connect($dsn);
$rs = $db-query('select
badcolumn,productid,productname,unitsinstock,unitprice from products');
while (DB_OK === $rs-fetchInto($fields)) {
$id=$fields[0];
$name=$fields[1];
$unitsinstock=$fields[2];
$unitprice=$fields[3];
print $id, $name, $unitsinstock, $unitpricebr;
}
$rs-free();
?
--
Edit bug report at: http://bugs.php.net/?id=14886edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14780 Updated: Segmentation fault with mm,PHP works fine with files
ID: 14780
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Assigned
Bug Type: Session related
Operating System: RH 7.2
PHP Version: 4.1.1
Old Assigned To: yohgaki
Assigned To:
New Comment:
Hi,
Here is my configure statement. Notice there's no pgsql:
./configure --with-mm --enable-inline-optimization --with-zlib
--with-oci8=/u01/app/or
acle/product/8.1.7 --disable-onstatement --enable-ftp --with-apxs
--enable-shmop --en
able-sysvsem --with-gd
John Lim
Previous Comments:
[2002-01-02 17:08:20] [EMAIL PROTECTED]
I noticed this problem before your report :) It's not a mm, but pgsql
save handler though. Root of the problem is the same, I guess.
I'm not 100% sure, yet, but multiple close calls may be the cause.
[2001-12-31 02:12:09] [EMAIL PROTECTED]
A simple script that reproduces the problem with mm. Works fine for a
while until mm breaks under stress:
?php
error_reporting(E_ALL);
$abc1 = '';
for ($i=0;$i20;$i++)
session_register('abc'.$i);
@$_SESSION['abc1'] += 2;
print pre$abc1\n\n;
?
[2001-12-31 01:55:44] [EMAIL PROTECTED]
When stress testing my web server with
ab -n5000 -c10 url
after about 1000-1500 requests the child processes start to fail.
In my apache error_log I see many entries like the following:
[Fri Dec 28 19:50:06 2001] [notice] child pid 14215 exit signal
Segmentation fault (11)
If I repeat the ab test several times, eventually Apache will hang and
I have to restart the web server. Here are the results:
This is ApacheBench, Version 1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-1999 The Apache Group, http://www.apache.org/
Benchmarking semut (be patient)...
Server Software:Apache/1.3.20
Server Hostname:semut
Server Port:80
Document Path: /juris/case.php
fbba51299f
Document Length:85383 bytes
Concurrency Level: 10
Time taken for tests: 1638.945 seconds
Complete requests: 5000
Failed requests:3446
(Connect: 0, Length: 3446, Exceptions: 0)
Total transferred: 429091301 bytes
HTML transferred: 427029653 bytes
Requests per second:3.05
Transfer rate: 261.81 kb/s received
Connnection Times (ms)
min avg max
Connect:0 9 197
Processing: 1692 3263 11353
Total: 1692 3272 11550
When I switch from mm to files everything works fine. I have a
suspicion that the bug is related to the fact that I am running on an
SMP processor.
Edit this bug report at http://bugs.php.net/?id=14780edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14886 Updated: Access Violation in error handler with MySQL (ISAPI)
ID: 14886
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Summary: Access Violation in error handler with PEAR DB (ISAPI)
Status: Open
Bug Type: IIS related
Operating System: Win2000
PHP Version: 4.1.1
New Comment:
I have simplified the crash to the following script (note that $obj is
null). The bug does not happen when $testmysql = false.
?php
error_reporting(E_ALL);
$testmysql = true;
print brtest start;
if ($testmysql) {
$conn = mysql_connect('localhost','root');
}
$obj-run();
print brtest end;
?
I had to run ab -n2 -c10 url several times before problems
started to occur on a W2k IIS server receiving no other visitors and had
just been restarted.
This is ApacheBench, Version 1.3c $Revision: 1.45 $ apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-2000 The Apache Group, http://www.apache.org/
Server Software:Microsoft-IIS/5.0
Server Hostname:jaguar
Server Port:80
Document Path: /php/err.php
Document Length:145 bytes
Concurrency Level: 10
Time taken for tests: 184.950 seconds
Complete requests: 2
Failed requests:556
(Connect: 0, Length: 556, Exceptions: 0)
Non-2xx responses: 555
Total transferred: 5504927 bytes
HTML transferred: 2847858 bytes
Requests per second:108.14
Transfer rate: 29.76 kb/s received
Connnection Times (ms)
min avg max
Connect:0 022
Processing: 490 466
Total: 490 488
Previous Comments:
[2002-01-06 06:15:53] [EMAIL PROTECTED]
I ran ApacheBench on a PEAR DB script (see below), and IIS (ISAPI mode)
will die eventually. It is so bad that often iisreset is unable to
restart IIS.
The ab command I used:
ab -n1 -c10 url
with the following results:
This is ApacheBench, Version 1.3c $Revision: 1.45 $ apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-2000 The Apache Group, http://www.apache.org/
Server Software:Microsoft-IIS/5.0
Server Hostname:jaguar
Server Port:80
Document Path: /lens/adodb/peartest.php
Document Length:142 bytes
Concurrency Level: 10
Time taken for tests: 269.158 seconds
Complete requests: 1
Failed requests:5272
(Connect: 0, Length: 5272, Exceptions: 0)
Non-2xx responses: 1868
Total transferred: 1891906 bytes
HTML transferred: 769177 bytes
Requests per second:37.15
Transfer rate: 7.03 kb/s received
Connnection Times (ms)
min avg max
Connect:0 0 5
Processing: 2 268 2771
Total: 2 268 2776
The interesting thing is that the crash only happens when an invalid SQL
statement is entered in the script below(notice the column badcolumn
which does not exist). If a valid SQL statement is entered (badcolumn
is removed), no crash occurs, and ApacheBench runs fine.
So I guess it is some problem with PHP's error-handler or MySQL
extension not being thread safe. No dll extensions were installed.
Standard pre-compiled PHP downloaded from php.net was used.
John Lim
=== THE SCRIPT ===
?php
include DB.php;
$DBNAME = 'PEAR DB';
$dsn = mysql://root:@localhost/northwind;
$db = DB::Connect($dsn);
$rs = $db-query('select
badcolumn,productid,productname,unitsinstock,unitprice from
products');
while (DB_OK === $rs-fetchInto($fields)) {
$id=$fields[0];
$name=$fields[1];
$unitsinstock=$fields[2];
$unitprice=$fields[3];
print $id, $name, $unitsinstock, $unitpricebr;
}
$rs-free();
?
Edit this bug report at http://bugs.php.net/?id=14886edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14780: Segmentation fault with mm,PHP works fine with files
From: [EMAIL PROTECTED] Operating system: RH 7.2 PHP version: 4.1.1 PHP Bug Type: Session related Bug description: Segmentation fault with mm,PHP works fine with files When stress testing my web server with ab -n5000 -c10 url after about 1000-1500 requests the child processes start to fail. In my apache error_log I see many entries like the following: [Fri Dec 28 19:50:06 2001] [notice] child pid 14215 exit signal Segmentation fault (11) If I repeat the ab test several times, eventually Apache will hang and I have to restart the web server. Here are the results: This is ApacheBench, Version 1.3 Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Copyright (c) 1998-1999 The Apache Group, http://www.apache.org/ Benchmarking semut (be patient)... Server Software:Apache/1.3.20 Server Hostname:semut Server Port:80 Document Path: /juris/case.php fbba51299f Document Length:85383 bytes Concurrency Level: 10 Time taken for tests: 1638.945 seconds Complete requests: 5000 Failed requests:3446 (Connect: 0, Length: 3446, Exceptions: 0) Total transferred: 429091301 bytes HTML transferred: 427029653 bytes Requests per second:3.05 Transfer rate: 261.81 kb/s received Connnection Times (ms) min avg max Connect:0 9 197 Processing: 1692 3263 11353 Total: 1692 3272 11550 When I switch from mm to files everything works fine. I have a suspicion that the bug is related to the fact that I am running on an SMP processor. -- Edit bug report at: http://bugs.php.net/?id=14780edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14780 Updated: Segmentation fault with mm,PHP works fine with files
ID: 14780
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: RH 7.2
PHP Version: 4.1.1
New Comment:
A simple script that reproduces the problem with mm. Works fine for a while until
mm breaks under stress:
?php
error_reporting(E_ALL);
$abc1 = '';
for ($i=0;$i20;$i++)
session_register('abc'.$i);
@$_SESSION['abc1'] += 2;
print pre$abc1\n\n;
?
Previous Comments:
[2001-12-31 01:55:44] [EMAIL PROTECTED]
When stress testing my web server with
ab -n5000 -c10 url
after about 1000-1500 requests the child processes start to fail.
In my apache error_log I see many entries like the following:
[Fri Dec 28 19:50:06 2001] [notice] child pid 14215 exit signal Segmentation fault
(11)
If I repeat the ab test several times, eventually Apache will hang and I have to
restart the web server. Here are the results:
This is ApacheBench, Version 1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-1999 The Apache Group, http://www.apache.org/
Benchmarking semut (be patient)...
Server Software:Apache/1.3.20
Server Hostname:semut
Server Port:80
Document Path: /juris/case.php
fbba51299f
Document Length:85383 bytes
Concurrency Level: 10
Time taken for tests: 1638.945 seconds
Complete requests: 5000
Failed requests:3446
(Connect: 0, Length: 3446, Exceptions: 0)
Total transferred: 429091301 bytes
HTML transferred: 427029653 bytes
Requests per second:3.05
Transfer rate: 261.81 kb/s received
Connnection Times (ms)
min avg max
Connect:0 9 197
Processing: 1692 3263 11353
Total: 1692 3272 11550
When I switch from mm to files everything works fine. I have a suspicion that the
bug is related to the fact that I am running on an SMP processor.
Edit this bug report at http://bugs.php.net/?id=14780edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14451: Unknown persistent list entry type in shutdown in IIS CGI
From: [EMAIL PROTECTED] Operating system: Win2000 PHP version: 4.1.0 PHP Bug Type: IIS related Bug description: Unknown persistent list entry type in shutdown in IIS CGI The following code running in IIS CGI mode generates a warning: Warning: Unknown persistent list entry type in module shutdown (11) in Unknown on line 0 ?php $db = mysql_pconnect(mangrove, , ); die(); ? In ISAPI mode the error does not occur. The following code does not cause any problems in CGI. ?php $db = mysql_connect(mangrove, , );die(); ? -- Edit bug report at: http://bugs.php.net/?id=14451edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14445: undefined function not trapped by user defined error handler
From: [EMAIL PROTECTED]
Operating system: Win2000
PHP version: 4.0.6
PHP Bug Type: *General Issues
Bug description: undefined function not trapped by user defined error handler
The following code is used to catch errors and mail them to the
webmaster:
?php
/* decide what errors to report */
error_reporting (E_ALL);
/* error handler function */
function MailErrorHandler($errno, $errstr, $errfile='?', $errline= '?')
{
print Errno=$errno Errorstring=$errstr;
/* code deleted - mails error to webmaster */
}
set_error_handler('MailErrorHandler');
$undefined_var();
When the code above is run, I see in the browser window:
Errno=8 Errorstring=Undefined variable: undefined_var
Fatal error: Call to undefined function: () in
d:\inetpub\wwwroot\php\err.php on line 14
In other words, the Fatal error is never caught by the error handler, and
our webmaster never detects that it is actually a very serious error, and
not just an undefined var E_NOTICE.
Thank you, John Lim
?
--
Edit bug report at: http://bugs.php.net/?id=14445edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #6275 Updated: ODBC_Prepare/ODBC_Execute fails with parameters
I agree with kowalsky, it is probably a limitation in the access odbc driver. Sorry
for
confusing everyone (including myself!).
Regards, John
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=6275edit=2
ID: 6275
Updated by: sander
Reported By: [EMAIL PROTECTED]
Old Status: Analyzed
Status: Feedback
Bug Type: ODBC related
Operating System: Windows 98
PHP Version: 4.0.1pl2
Assigned To: kalowsky
New Comment:
Does this problem still occur with 4.0.6, the latest RC
(http://download.php.net/~zeev/php-4.1.0RC3.tar.gz) or the latest CVS?
Previous Comments:
[2001-04-01 19:36:34] [EMAIL PROTECTED]
further poking tonight revealed the following...
in the odbc_execute function, when doing a SQLDesrcibe on
the value pulled out of the array function the following
message was produced by PHP/ODBC:
SQL error: [Microsoft][ODBC Driver Manager\ Driver does not
support this function, SQL state IM001 in SQLBindParamater
insert script name here.
Could it be that MS Access doesn't support this
functionality? Is there any way to (dis)prove this theory?
[2001-03-23 17:01:42] [EMAIL PROTECTED]
Tried updating to the latest MDAC (2.6) and this provided no change in the
given example. It did fix one or two issues, but in generally hasn't helped
any.
[2001-03-11 20:59:58] [EMAIL PROTECTED]
it seems the sample script provided is failing in the
SQLBindParameter call. Why? The SQLError call tells us
it's trying to bind a parameter of the wrong type.
I've sent out an email on the PHP-DB list asking if anyone
could try a small variation of this script, and only one
person responded. It seems to be a Microsoft Access
specific issue only, but my only other comparision at this
time is SQL Server...draw your own conclusions.
[2001-02-14 08:20:41] [EMAIL PROTECTED]
starting to look into windows problems, only problem is I have only win98,
so the winNT and 2k won't likely happen...
[2000-08-21 09:16:20] [EMAIL PROTECTED]
Hello,
My problem is odbc_execute fails with the following error message:
Warning: SQL error: [Microsoft][ODBC Microsoft Access Driver]COUNT field
incorrect , SQL state 07001 in SQLExecute in
d:\Inetpub\wwwroot\php\adodb\index.php on line 77
The odbc_exec INSERT works fine. I am using a plain vanilla NorthWind MS
Access database and am using the ISAPI version of PHP, with ODBC built in.
Sample code:
$conn = odbc_connect(nwind,,);
odbc_exec($conn,drop table ADOXYZ);
odbc_exec($conn,create table ADOXYZ (id int, firstname char(24), lastname
char(24))); odbc_exec($conn,insert into ADOXYZ (id,firstname,lastname)
values (0,'Zend','PHP')); $stmt = odbc_prepare($conn,insert into ADOXYZ
(id,firstname,lastname) values (?,?,?)); if ($stmt) {
print Trying executebr;
$stmt = odbc_execute($stmt,array(1,John,Lim));
}
---
Stressed spelled backwards is desserts.
[EMAIL PROTECTED] NATSOFT MALAYSIA (60)3-7806 1216
My personal PHP website: http://php.weblogs.com/
My company's PHP website: http://phplens.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12166 Updated: SQL_CUR_DEFAULT constant not defined in php_odbc.dll
ID: 12166 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Closed Status: Open Bug Type: ODBC related Operating System: Windows ME PHP Version: 4.0.6 New Comment: I meant the PHP Manual entry for odbc_connect(). Previous Comments: [2001-08-20 12:03:35] [EMAIL PROTECTED] no feedback. [2001-07-17 08:42:13] [EMAIL PROTECTED] Which docs are you referring to? The ODBC docs for PHP? The ODBC v3 docs? The ODBC v3.5 docs? please note that my name is kalowsky, not kowalsky. [2001-07-16 22:32:16] [EMAIL PROTECTED] Hi Kowalsky If you check in microsoft's sqlext.h you will see that SQL_CUR_DEFAULT is set to SQL_CUR_USE_DRIVER so it is a constant. Also if you check the odbc_connect( ) docs, it says that SQL_CUR_DEFAULT is an acceptable parameter to pass into odbc_connect(). So it should be defined, or the documentation be corrected. Regards, John [2001-07-16 08:31:20] [EMAIL PROTECTED] this is supposed to be defined by your ODBC driver, not by PHP... after all, how is PHP to know what your DB's default cursor is? [2001-07-14 11:14:19] [EMAIL PROTECTED] SQL_CUR_DEFAULT, which is a constant that can be passed into odbc_connect, is not defined in the odbc extension. I get a warning that it an undefined constant when I use it. A quick check in the source code confirmed it. Edit this bug report at http://bugs.php.net/?id=12166edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #12166 Updated: SQL_CUR_DEFAULT constant not defined in php_odbc.dll
ID: 12166 Updated by: kalowsky Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: ODBC related Operating System: Windows ME PHP Version: 4.0.6 New Comment: Which docs are you referring to? The ODBC docs for PHP? The ODBC v3 docs? The ODBC v3.5 docs? Whoops, sorry for the name change. Silly me. I meant the ODBC docs in the PHP manual. - John please note that my name is kalowsky, not kowalsky. Previous Comments: [2001-07-16 22:32:16] [EMAIL PROTECTED] Hi Kowalsky If you check in microsoft's sqlext.h you will see that SQL_CUR_DEFAULT is set to SQL_CUR_USE_DRIVER so it is a constant. Also if you check the odbc_connect( ) docs, it says that SQL_CUR_DEFAULT is an acceptable parameter to pass into odbc_connect(). So it should be defined, or the documentation be corrected. Regards, John [2001-07-16 08:31:20] [EMAIL PROTECTED] this is supposed to be defined by your ODBC driver, not by PHP... after all, how is PHP to know what your DB's default cursor is? [2001-07-14 11:14:19] [EMAIL PROTECTED] SQL_CUR_DEFAULT, which is a constant that can be passed into odbc_connect, is not defined in the odbc extension. I get a warning that it an undefined constant when I use it. A quick check in the source code confirmed it. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=12166edit=2 --- Stressed spelled backwards is desserts. [EMAIL PROTECTED] NATSOFT MALAYSIA (60)3-706 1216 Visit this web site for Asian and local Internet news http://webfeet.editthispage.com/ My PHP website: http://php.weblogs.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12166 Updated: SQL_CUR_DEFAULT constant not defined in php_odbc.dll
ID: 12166 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Closed Status: Open Bug Type: ODBC related Operating System: Windows ME PHP Version: 4.0.6 New Comment: Hi Kowalsky If you check in microsoft's sqlext.h you will see that SQL_CUR_DEFAULT is set to SQL_CUR_USE_DRIVER so it is a constant. Also if you check the odbc_connect( ) docs, it says that SQL_CUR_DEFAULT is an acceptable parameter to pass into odbc_connect(). So it should be defined, or the documentation be corrected. Regards, John Previous Comments: [2001-07-16 08:31:20] [EMAIL PROTECTED] this is supposed to be defined by your ODBC driver, not by PHP... after all, how is PHP to know what your DB's default cursor is? [2001-07-14 11:14:19] [EMAIL PROTECTED] SQL_CUR_DEFAULT, which is a constant that can be passed into odbc_connect, is not defined in the odbc extension. I get a warning that it an undefined constant when I use it. A quick check in the source code confirmed it. Edit this bug report at http://bugs.php.net/?id=12166edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12166: SQL_CUR_DEFAULT constant not defined in php_odbc.dll
From: [EMAIL PROTECTED] Operating system: Windows ME PHP version: 4.0.6 PHP Bug Type: ODBC related Bug description: SQL_CUR_DEFAULT constant not defined in php_odbc.dll SQL_CUR_DEFAULT, which is a constant that can be passed into odbc_connect, is not defined in the odbc extension. I get a warning that it an undefined constant when I use it. A quick check in the source code confirmed it. -- Edit bug report at: http://bugs.php.net/?id=12166edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11644: Interbase dll causes PWS ISAPI to die
From: [EMAIL PROTECTED] Operating system: Windows ME PHP version: 4.0.6 PHP Bug Type: InterBase related Bug description: Interbase dll causes PWS ISAPI to die Upgraded from PHP 4.0.4pl1 to PHP 4.0.6. Did not modify my php.ini. After the upgrade, I ran a test script with phpinfo() to see if the upgrade worked, and PWS died immediately. By commenting out my extensions one by one, I discovered the culprit was php_interbase.dll. With only that extension removed, everything works fine using ISAPI. When I use CGI with interbase, everything works fine. Perhaps the interbase dll is not 100% thread safe? Thanks for reading this, John -- Edit Bug report at: http://bugs.php.net/?id=11644edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11645: tempnam( ) does not use TMP environment variable
From: [EMAIL PROTECTED]
Operating system: Windows ME
PHP version: 4.0.6
PHP Bug Type: Filesystem function related
Bug description: tempnam( ) does not use TMP environment variable
The PHP manual states:
The behaviour of the tempnam() function is system dependent. On Windows the TMP
environment variable will override the dir parameter.
However testing the following when my TMP env variable is set to \WINDOWS\TMP:
print tempnam('/','z')
the result is:
C:\zB312.TMP
This used to work fine in PHP 4.0.4pl1.
Thanks again, John
--
Edit Bug report at: http://bugs.php.net/?id=11645edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11644 Updated: Interbase dll causes PWS ISAPI to die
ID: 11644 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: InterBase related Operating system: Windows ME PHP Version: 4.0.6 Description: Interbase dll causes PWS ISAPI to die Did you update your extensions from the new release? Yes I did. I renamed my old php directory to php404 and recreated the php directory from scracth. I copied all the dlls in the dll folder to my windows\system directory and rebooted also. -- John Previous Comments: --- [2001-06-24 17:49:27] [EMAIL PROTECTED] Did you update your extensions from the new release? --- [2001-06-24 14:05:30] [EMAIL PROTECTED] Upgraded from PHP 4.0.4pl1 to PHP 4.0.6. Did not modify my php.ini. After the upgrade, I ran a test script with phpinfo() to see if the upgrade worked, and PWS died immediately. By commenting out my extensions one by one, I discovered the culprit was php_interbase.dll. With only that extension removed, everything works fine using ISAPI. When I use CGI with interbase, everything works fine. Perhaps the interbase dll is not 100% thread safe? Thanks for reading this, John --- Full Bug description available at: http://bugs.php.net/?id=11644 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
