#22215 [Fbk->Opn]: PHP dies while loading php.ini
ID: 22215
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 4CVS-2003-02-13 (stable)
New Comment:
I do _not_ have auto_detect_line_endings enabled in my ini file. The
contents of the file are included in my original report. Backtrace
follows - perhaps this should be a 'scripting engine problem' if it is
a PHP problem.
(gdb) run
Starting program: /usr/local/src/php-cvs/php4/sapi/cli/php
Program received signal SIGSEGV, Segmentation fault.
0x404044fc in memcpy () at memcpy:-1
-1 memcpy: No such file or directory.
in memcpy
(gdb) bt
#0 0x404044fc in memcpy () at memcpy:-1
#1 0xdfffdea5 in ?? ()
#2 0x081258e3 in zend_parse_ini_file (fh=0xbfffd9e0,
unbuffered_errors=1,
ini_parser_cb=0x8112948 , arg=0x821f900)
at /usr/local/src/php-cvs/php4/Zend/zend_ini_parser.y:164
#3 0x08112e99 in php_init_config () at
/usr/local/src/php-cvs/php4/main/php_ini.c:386
#4 0x0810ee9f in php_module_startup (sf=0x821c720,
additional_modules=0x0, num_additional_modules=0)
at /usr/local/src/php-cvs/php4/main/main.c:1104
#5 0x081504c1 in main (argc=1, argv=0xbfffdc84) at
/usr/local/src/php-cvs/php4/sapi/cli/php_cli.c:481
#6 0x40397657 in __libc_start_main (main=0x8150398 , argc=1,
ubp_av=0xbfffdc84, init=0x806a8e4 <_init>,
fini=0x81a0760 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>,
stack_end=0xbfffdc7c)
at ../sysdeps/generic/libc-start.c:129
(gdb)
Previous Comments:
[2003-02-13 16:19:05] [EMAIL PROTECTED]
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
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.
Also, do you have the 'auto_detect_line_endings' enabled in your ini
file?
[2003-02-13 16:14:19] [EMAIL PROTECTED]
current (Thu Feb 13 22:00:53 GMT 2003) php-4.3 from CVS compiled as
follows:
./configure --disable-ipv6 --with-config-file-path=/etc/httpd/conf
--enable-memory-limit --disable-display-source --enable-track-var
--with-imap --with-imap-ssl
--with-apxs=/usr/local/apache/current/bin/apxs --with-gd=/usr
--with-jpeg-dir=/usr --with-xpm-dir=/usr/X11R6
--with-mysql=/usr/local/mysql/current --with-curl --enable-ftp
--enable-dbase --enable-xml --with-xml --with-gettext --with-mcrypt
--disable-posix
prevents Apache-1.3.27 from starting (segfault). strace on the CLI
SAPI shows a problem accessing php.ini:
close(3)= 0
brk(0x822c000) = 0x822c000
open("sapi/cli//php-cli.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/httpd/conf/php-cli.ini", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("sapi/cli//php.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/httpd/conf/php.ini", O_RDONLY) = 3
getcwd("/usr/local/src/php-cvs/php4", 4095) = 28
lstat64("/etc", {st_mode=S_IFDIR|0755, st_size=8192, ...}) = 0
lstat64("/etc/httpd", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/etc/httpd/conf", {st_mode=S_IFDIR|0771, st_size=4096, ...}) =
0
lstat64("/etc/httpd/conf/php.ini", {st_mode=S_IFREG|0644, st_size=331,
...}) = 0
brk(0x8231000) = 0x8231000
ioctl(3, 0x5401, 0xbfffca80)= -1 ENOTTY (Inappropriate
ioctl for device)
fstat64(3, {st_mode=S_IFREG|0644, st_size=331, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x40018000
read(3, "register_globals = on\nignore_use"..., 8192) = 331
read(3, "", 4096) = 0
read(3, "", 8192) = 0
ioctl(3, 0x5401, 0xbfffbed0)= -1 ENOTTY (Inappropriate
ioctl for device)
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
The exact same config works fine with plain 4.3 tarball compile.
The system is RedHat 7.2 with autoconf/automake/libtool upgraded to
play nice with PHP/CVS.
The /etc/httpd/conf/php.ini file is as follows:
register_globals = on
ignore_user_abort = on
log_errors = true
#zend_optimizer.optimization_level = 15
#zend_extension = "/usr/local/lib/ZendOptimizer.so"
display_errors = false
memory_limit = 65536
post_max_size = 65536
upload_max_filesize = 32768
upload_tmp_dir = /var/tmp
max_input_time = 60
max_execution_time = 30
If I can help with any further details please let me know.
Thanks
--
Edit this bug report at http://bugs.php.net/?id=22215&edit=
#22220 [NEW]: can't turn open_basedir off anymore since 4.2.3 -> 4.3.0
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.7-STABLE PHP version: 4.3.0 PHP Bug Type: Apache related Bug description: can't turn open_basedir off anymore since 4.2.3 -> 4.3.0 I have this in my php.ini as default: open_basedir = /var/www I have a virtualhost block like this: ServerName "host.example.com" DocumentRoot "/var/www/host.example.com/root" Options Indexes ExecCgi php_admin_value safe_mode 0 php_admin_value open_basedir "/" The goal is to force a default open_basedir of "/var/www" to everything, except the explicitly specified /admin directory and contents (same with safe_mode). First, I read that setting the open_basedir to "/" doesn't work anymore in http://bugs.php.net/bug.php?id=22101. Seems kinda weird as the documentation states: [The restriction specified with open_basedir is actually a prefix, not a directory name. This means that "open_basedir = /dir/incl" also allows access to "/dir/include" and "/dir/incls" if they exist. When you want to restrict access to only the specified directory, end with a slash. For example: "open_basedir = /dir/incl/"] But besides that, specifying 'none' as open basedir in the virtualhost doesn't turn it off, it uses the default of /var/www, and I haven't found a way to set the open_basedir to NULL. So, as I see it either the 'none' setting isn't working correctly and needs to be fixed or the possibility of setting the open_basedir to "/" needs to be put back in. Unless I'm overseeing some very trivial way of turning the open_basedir restriction off of course. Thanks in advance. -- Edit bug report at http://bugs.php.net/?id=0&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=0&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=0&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=0&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=0&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=0&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=0&r=support Expected behavior: http://bugs.php.net/fix.php?id=0&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=0&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=0&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=0&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=0&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=0&r=dst IIS Stability: http://bugs.php.net/fix.php?id=0&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=0&r=gnused
#21886 [NoF->Opn]: parameters sometimes not submitted
ID: 21886
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: No Feedback
+Status: Open
Bug Type: Class/Object related
Operating System: Linux 7.2
PHP Version: 4.3.0
New Comment:
I am sorry, actually I do not have time, I hope I can give you an
example in the next two days - sorry for that (but your first reply
took more than two days :-).
But - it is NOT an misunderstanding how sessions work. I am using
sessions since the beginning of PHP 4 and the same code is running
under 4.2.3 perfect.
Regards,
Sebastian
Previous Comments:
[2003-02-13 12:40:12] [EMAIL PROTECTED]
[EMAIL PROTECTED]: Please open your own report about this,
seems like the original reporter of this bug is not
responding and your problem seems a bit different.
(IMO, neither of these are bugs, just misunderstanding how sessions
work)
[2003-02-13 11:04:18] [EMAIL PROTECTED]
Ooops! I please forgive my mistake, in my last post, switch the call
from:
$bar->myecho("apple, orange");
to:
$bar->myecho("apple", "orange");
[2003-02-13 11:00:57] [EMAIL PROTECTED]
Here is an example.
class foo {
// constructor, etc.
function myecho($string1, $string2) {
echo "String 1: " . $string1 . "\n";
echo "String 2: " . $string2 . "\n";
}
};
$bar = new foo();
$bar->myecho("apple, orange");
Will output one of these 3 possibilities, at random (or so it seems:)
String 1: apple
String 2: orange
String 1: orange
String 2:
String 1:
String 2:
Weird, eh? and rerunning the same code does not always give the same
results.
I guess it's clearer now.
[2003-02-13 02:01:03] [EMAIL PROTECTED]
Please provide a complete but short example
that _clearly_ shows the problem.
[2003-01-31 11:25:29] [EMAIL PROTECTED]
With multiple parameters too, creates trouble. Using 2 parameters,
sometimes only the second one is passed... as the first!
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/21886
--
Edit this bug report at http://bugs.php.net/?id=21886&edit=1
#22220 [Com]: can't turn open_basedir off anymore since 4.2.3 -> 4.3.0
ID: 0 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: FreeBSD 4.7-STABLE PHP Version: 4.3.0 New Comment: Hmm it works for my system open_basedir = '/www'; in php.ini and in apache directive i have php_admin_value open_basedir none which works grand. did you try actually acessing a file outside the docroot? Previous Comments: [2003-02-14 04:03:11] [EMAIL PROTECTED] I have this in my php.ini as default: open_basedir = /var/www I have a virtualhost block like this: ServerName "host.example.com" DocumentRoot "/var/www/host.example.com/root" Options Indexes ExecCgi php_admin_value safe_mode 0 php_admin_value open_basedir "/" The goal is to force a default open_basedir of "/var/www" to everything, except the explicitly specified /admin directory and contents (same with safe_mode). First, I read that setting the open_basedir to "/" doesn't work anymore in http://bugs.php.net/bug.php?id=22101. Seems kinda weird as the documentation states: [The restriction specified with open_basedir is actually a prefix, not a directory name. This means that "open_basedir = /dir/incl" also allows access to "/dir/include" and "/dir/incls" if they exist. When you want to restrict access to only the specified directory, end with a slash. For example: "open_basedir = /dir/incl/"] But besides that, specifying 'none' as open basedir in the virtualhost doesn't turn it off, it uses the default of /var/www, and I haven't found a way to set the open_basedir to NULL. So, as I see it either the 'none' setting isn't working correctly and needs to be fixed or the possibility of setting the open_basedir to "/" needs to be put back in. Unless I'm overseeing some very trivial way of turning the open_basedir restriction off of course. Thanks in advance. -- Edit this bug report at http://bugs.php.net/?id=0&edit=1
#21310 [Fbk->Asn]: no such file (paths)
ID: 21310 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Assigned Bug Type: *Directory/Filesystem functions Operating System: Solaris 8 PHP Version: 4.3.0 -Assigned To: +Assigned To: wez Previous Comments: [2003-02-13 20:01:17] [EMAIL PROTECTED] before I make someone confused, I'm rephrasing my last comment: "...it worked just fine for me..." [2003-02-13 19:59:28] [EMAIL PROTECTED] I applied the patch and it worked just for me... I'm on solaris 9 here [2003-02-13 05:06:49] [EMAIL PROTECTED] Please use the latest stable snapshot from snaps.php.net. [2003-02-13 04:54:59] [EMAIL PROTECTED] Should I apply this patch to the latest "Stable (4.3.x-dev)" version or to 4.3.0 version? [2003-02-13 03:24:25] [EMAIL PROTECTED] Testing the patch should not be a problem if it fixes the problem you already described... Don't forget, you can always run a test server on another port for a short while without affecting your main server. Feedback means that we need to know if the proposed solution fixes it for you. Our access to Solaris is quite limited, so we rely on feedback to tell us if things are working. If you can't provide feedback, and we don't have a way of testing it ourselves, then this report will just get suspended. 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/21310 -- Edit this bug report at http://bugs.php.net/?id=21310&edit=1
#22171 [Fbk->Bgs]: Support of Transaction Control Statements
ID: 22171
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Bogus
Bug Type: MySQL related
Operating System: NT2000
PHP Version: 4.3.0
New Comment:
you have to use mysql_query("begin");
not mysql_query(begin);
Previous Comments:
[2003-02-11 16:55:01] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Could you please provide a short sample of code?!
(only query related part of code)
[2003-02-11 11:40:59] [EMAIL PROTECTED]
I´m using MySQL Version 4.0.8 Gamma Release and PHP 4.3. There is the
transaction control implemented.
Now I tried to use the statements "set autocommit=0, begin, commit or
rollback" within a php-script. At runtime I have got an error: Notice:
Use of undefined constant BEGIN - assumes 'BEGIN' in test.php on line
xx.
The control statements in MySQL are correctly functioning !
I think the transaction control statements aren't supported in PHP
yet.
Are you able to advice me ?
Many Thanks,
Werner Schuermann
--
Edit this bug report at http://bugs.php.net/?id=22171&edit=1
#22177 [Bgs]: Warning: fopen() expects parameter 1 to be string
ID: 22177 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Filesystem function related Operating System: RedHat PHP Version: 4.3.0 New Comment: my 2c on this: yes it worked in 4.2.3 ... but even in 4.2.3 it didn't do what you wanted, instead of creating a temp file with a unique name (or better in addition to it) your fopen statement opens a file by the name of the auto-converted resource number, so if you investigate this you'll find out that your temporary files are actualy namend by small numbers, and if your code always opens the same resources you'll even get temp files of *equal* names by different script runs -> not what you want so 4.3 now warns you about this were 4.3.2 silently accepted it "that same exact code block worked 100% under php 4.2.3." is just not true, as it would create race conditions if run simultaneous multiple times even in 4.2.3 "Thus one last question, looking at the code I initially posted, what would be your suggestion if I may ask specifically tailored to my problem?" you've been told before in this thread: either use temnam() instead of tmpfile(), or use the file handle resource returned by temfile() right away instead of trying to perform unspecified operations on it ... "I don't appreciate the RTFM remark, but I am glad you replied back. I use the php manual extensively but have not seen that particular link." so you use functions without reading their specs and then complain about them not working as you'd expect? strange concept ... Previous Comments: [2003-02-11 18:28:06] [EMAIL PROTECTED] Quote: "Now leave this bug as it should be for our stat system." Now that too is much more of an intelligent remark than "user error". On that note: "Bogus". [2003-02-11 18:25:34] [EMAIL PROTECTED] keep it "bogus" please. [2003-02-11 18:25:02] [EMAIL PROTECTED] Thank you for the thank. Now leave this bug as it should be for our stat system. BOGUS ! [2003-02-11 18:22:38] [EMAIL PROTECTED] Thanks. [2003-02-11 18:22:02] [EMAIL PROTECTED] For support: http://www.php.net/support.php 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/22177 -- Edit this bug report at http://bugs.php.net/?id=22177&edit=1
#22221 [NEW]: bad rows count in the result object for postgresql
From: [EMAIL PROTECTED]
Operating system: Linux morlupo 2.4.18-14 (redhat
PHP version: 4.2.2
PHP Bug Type: DBX related
Bug description: bad rows count in the result object for postgresql
Hello,
I am using the default php modules with postgresql coming with redhat
8.0.
I have a code using the dbx function that work well in mysql.
When changing to postgresql (i.e. changing DBX_MYSQL to DBX_PGSQL in
function dbx_connect()) I get warnings that I don't get with mysql.
Note that those warning are difficult to see: you have to define your own
error_handler to see them!!!
That's what I do usually on my web sites.
In your error handler I have set the following message options:
(E_ERROR,E_WARNING,E_PARSE,E_CORE_ERROR,E_CORE_WARNING,E_USER_ERROR,
E_USER_WARNING)
OK, with that set up
after making a query that return 3 rows I get the message:
---
pg_fetch_array() unable to jump to row 10 on PostgreSQL result index 4
in /somepath/library_connect.php line 68
---
this corresponds to the following loop:
$query="select * from membership";
$result=dbx_query($socket,$query,DBX_RESULT_ASSOC);
$num_rows = $result->rows;
for ($i=0;$i<$num_rows;$i++) {
list(,$row)=each($result->data);
}
This type of code works well with the mysql driver. In postgresq it seems
it looks for indexes for 0 to 10 included!
--
Edit bug report at http://bugs.php.net/?id=1&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=1&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=1&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=1&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=1&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=1&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=1&r=support
Expected behavior: http://bugs.php.net/fix.php?id=1&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=1&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=1&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=1&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=1&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=1&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=1&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=1&r=gnused
#22221 [Opn]: bad rows count in the result object for postgresql
ID: 1
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: DBX related
-Operating System: Linux morlupo 2.4.18-14 (redhat
+Operating System: Linux 2.4.18-14 (redhat
PHP Version: 4.2.2
New Comment:
sorry for the typo:
please read:
after making a query that return *10* rows I get the message:
---
pg_fetch_array() unable to jump to row 10 on PostgreSQL result index 4
in /somepath/library_connect.php line 68
Previous Comments:
[2003-02-14 06:27:27] [EMAIL PROTECTED]
Hello,
I am using the default php modules with postgresql coming with redhat
8.0.
I have a code using the dbx function that work well in mysql.
When changing to postgresql (i.e. changing DBX_MYSQL to DBX_PGSQL in
function dbx_connect()) I get warnings that I don't get with mysql.
Note that those warning are difficult to see: you have to define your
own error_handler to see them!!!
That's what I do usually on my web sites.
In your error handler I have set the following message options:
(E_ERROR,E_WARNING,E_PARSE,E_CORE_ERROR,E_CORE_WARNING,E_USER_ERROR,
E_USER_WARNING)
OK, with that set up
after making a query that return 3 rows I get the message:
---
pg_fetch_array() unable to jump to row 10 on PostgreSQL result index 4
in /somepath/library_connect.php line 68
---
this corresponds to the following loop:
$query="select * from membership";
$result=dbx_query($socket,$query,DBX_RESULT_ASSOC);
$num_rows = $result->rows;
for ($i=0;$i<$num_rows;$i++) {
list(,$row)=each($result->data);
}
This type of code works well with the mysql driver. In postgresq it
seems it looks for indexes for 0 to 10 included!
--
Edit this bug report at http://bugs.php.net/?id=1&edit=1
#22221 [Opn->Fbk]: bad rows count in the result object for postgresql
ID: 1
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: DBX related
Operating System: Linux 2.4.18-14 (redhat
PHP Version: 4.2.2
New Comment:
Internally in the dbx_pgsql driver, the code disables E_WARNING for
pg_fetch_array, fetches rows until no more rows are available (this is
detected by trapping the warning you got), then re-enables the
E_WARNING if it was enabled in the first place.
This is probably why you have to define your own error-handler to see
the warning at all.
Does this happen with any user-defined error-handler or is your setup
very specific? Is there an easy workaround without resorting to
@dbx_qeuery()? Could you post the code for your error-handler
(simplified if possible)?
Thanks, Marc.
Previous Comments:
[2003-02-14 06:32:05] [EMAIL PROTECTED]
sorry for the typo:
please read:
after making a query that return *10* rows I get the message:
---
pg_fetch_array() unable to jump to row 10 on PostgreSQL result index 4
in /somepath/library_connect.php line 68
[2003-02-14 06:27:27] [EMAIL PROTECTED]
Hello,
I am using the default php modules with postgresql coming with redhat
8.0.
I have a code using the dbx function that work well in mysql.
When changing to postgresql (i.e. changing DBX_MYSQL to DBX_PGSQL in
function dbx_connect()) I get warnings that I don't get with mysql.
Note that those warning are difficult to see: you have to define your
own error_handler to see them!!!
That's what I do usually on my web sites.
In your error handler I have set the following message options:
(E_ERROR,E_WARNING,E_PARSE,E_CORE_ERROR,E_CORE_WARNING,E_USER_ERROR,
E_USER_WARNING)
OK, with that set up
after making a query that return 3 rows I get the message:
---
pg_fetch_array() unable to jump to row 10 on PostgreSQL result index 4
in /somepath/library_connect.php line 68
---
this corresponds to the following loop:
$query="select * from membership";
$result=dbx_query($socket,$query,DBX_RESULT_ASSOC);
$num_rows = $result->rows;
for ($i=0;$i<$num_rows;$i++) {
list(,$row)=each($result->data);
}
This type of code works well with the mysql driver. In postgresq it
seems it looks for indexes for 0 to 10 included!
--
Edit this bug report at http://bugs.php.net/?id=1&edit=1
#22222 [NEW]: mod_rewrite variables change between apache and apache2
From: [EMAIL PROTECTED] Operating system: Win32 PHP version: 4.3.0 PHP Bug Type: Apache2 related Bug description: mod_rewrite variables change between apache and apache2 Hello, I have a problem with a different behaviour of Apache / Apache2 Two configuration: - Apache 1.3.27 / PHP 4.3 / Win32 - Apache 2.0.44 / PHP 4.3 / Win32 with more or less the same httpd.conf configuration file (here the part which make troubles): ... DocumentRoot "D:/CVSCheckout/project" ServerName mycomputer.local RewriteEngine On RewriteRule ^/.*\.xml /system/if/xmlfile.if.php Both configuration should rewrite all .xml files to a central file, which load the xml file and output the parsed xml code in a format (i.e. HTML, PDF, Flash, ...). No problem till I update the system to apache 2.0.44. Since then I get a "400 Bad Request" Error (IE, Mozilla). I test a while and solve the problem with this line: RewriteRule ^/.*\.xml /system/if/xmlfile.if.php [PT] but now all script variables like SCRIPT_NAME, etc. changes due to the other way of rewrite. Ok, I could do a nasty workaround, but I hate to do this due to a bug. I know it's perhaps not a php Bug (at least I think so) but it influence the normal php script behaviour a lot. Perhaps one of the PHP and Apache developer could solve the problem cu Thomas Thiery -- Edit bug report at http://bugs.php.net/?id=2&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=2&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=2&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=2&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=2&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=2&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=2&r=support Expected behavior: http://bugs.php.net/fix.php?id=2&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=2&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=2&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=2&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=2&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=2&r=dst IIS Stability: http://bugs.php.net/fix.php?id=2&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=2&r=gnused
#22221 [Fbk->Opn]: bad rows count in the result object for postgresql
ID: 1
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: DBX related
-Operating System: Linux 2.4.18-14 (redhat
+Operating System: Linux morlupo 2.4.18-14 (redhat
PHP Version: 4.2.2
New Comment:
Hello Marc,
Thank you for replying so fast.
I don't think my setup is very specific.
Here is the code of my error handler.
(Note that the work around I have found is to regexp the $errormesg: I
didn't want to leave completely the E_WARNING completely as a SQL
syntax error will be unnoticed by me. Strangely a SQL syntax erro comes
out with the same error code E_WARNING as this postgresql "bug")
I don't know how the default handler do, but it catches the SQL errors
but not this postgresql stuff perhaps does the same thing: parse
for ERROR)
here is the code-
function userErrorHandler ($errno, $errmsg, $filename, $linenum, $vars)
{
# define an assoc array of error string
# in reality the only entries we should
# consider are 2,8,256,512 and 1024
$errortype = array (
1 => "Error",
2 => "Warning",
4 => "Parsing Error",
8 => "Notice",
16 => "Core Error",
32 => "Core Warning",
64 => "Compile Error",
128 => "Compile Warning",
256 => "User Error",
512 => "User Warning",
1024=> "User Notice"
);
# set of errors for which we will die
$die_errors = array(E_USER_ERROR);
# set of errors that will be mailed
$mail_errors =
array(E_ERROR,E_WARNING,E_PARSE,E_CORE_ERROR,E_CORE_WARNING,E_USER_ERROR,
E_USER_WARNING);
$err.=$errortype["$errno"]." (bit $errno)\n$errmsg\nin $filename
line $linenum";
if (in_array($errno, $mail_errors) &&
preg_match("/ERROR/",$errmsg)) {
myerrormail("[EMAIL PROTECTED]",$errortype["$errno"]." (bit
$errno)",$err);
}
#possibly die
if (in_array($errno, $die_errors)){
exit;
}
return 1;
}
Previous Comments:
[2003-02-14 06:44:23] [EMAIL PROTECTED]
Internally in the dbx_pgsql driver, the code disables E_WARNING for
pg_fetch_array, fetches rows until no more rows are available (this is
detected by trapping the warning you got), then re-enables the
E_WARNING if it was enabled in the first place.
This is probably why you have to define your own error-handler to see
the warning at all.
Does this happen with any user-defined error-handler or is your setup
very specific? Is there an easy workaround without resorting to
@dbx_qeuery()? Could you post the code for your error-handler
(simplified if possible)?
Thanks, Marc.
[2003-02-14 06:32:05] [EMAIL PROTECTED]
sorry for the typo:
please read:
after making a query that return *10* rows I get the message:
---
pg_fetch_array() unable to jump to row 10 on PostgreSQL result index 4
in /somepath/library_connect.php line 68
[2003-02-14 06:27:27] [EMAIL PROTECTED]
Hello,
I am using the default php modules with postgresql coming with redhat
8.0.
I have a code using the dbx function that work well in mysql.
When changing to postgresql (i.e. changing DBX_MYSQL to DBX_PGSQL in
function dbx_connect()) I get warnings that I don't get with mysql.
Note that those warning are difficult to see: you have to define your
own error_handler to see them!!!
That's what I do usually on my web sites.
In your error handler I have set the following message options:
(E_ERROR,E_WARNING,E_PARSE,E_CORE_ERROR,E_CORE_WARNING,E_USER_ERROR,
E_USER_WARNING)
OK, with that set up
after making a query that return 3 rows I get the message:
---
pg_fetch_array() unable to jump to row 10 on PostgreSQL result index 4
in /somepath/library_connect.php line 68
---
this corresponds to the following loop:
$query="select * from membership";
$result=dbx_query($socket,$query,DBX_RESULT_ASSOC);
$num_rows = $result->rows;
for ($i=0;$i<$num_rows;$i++) {
list(,$row)=each($result->data);
}
This type of code works well with the mysql driver. In postgresq it
seems it looks for indexes for 0 to 10 included!
--
Edit this bug report at http://bugs.php.net/?id=1&edit=1
#22222 [Opn]: mod_rewrite variables change between apache and apache2
ID: 2 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache2 related Operating System: Win32 PHP Version: 4.3.0 New Comment: I did a little mistake in the description nothing on the topic DocumentRoot "D:/CVSCheckout/project" ServerName mycomputer.local RewriteEngine On RewriteRule ^/.*\.xml /system/if/xmlfile.if.php Previous Comments: [2003-02-14 07:25:51] [EMAIL PROTECTED] Hello, I have a problem with a different behaviour of Apache / Apache2 Two configuration: - Apache 1.3.27 / PHP 4.3 / Win32 - Apache 2.0.44 / PHP 4.3 / Win32 with more or less the same httpd.conf configuration file (here the part which make troubles): ... DocumentRoot "D:/CVSCheckout/project" ServerName mycomputer.local RewriteEngine On RewriteRule ^/.*\.xml /system/if/xmlfile.if.php Both configuration should rewrite all .xml files to a central file, which load the xml file and output the parsed xml code in a format (i.e. HTML, PDF, Flash, ...). No problem till I update the system to apache 2.0.44. Since then I get a "400 Bad Request" Error (IE, Mozilla). I test a while and solve the problem with this line: RewriteRule ^/.*\.xml /system/if/xmlfile.if.php [PT] but now all script variables like SCRIPT_NAME, etc. changes due to the other way of rewrite. Ok, I could do a nasty workaround, but I hate to do this due to a bug. I know it's perhaps not a php Bug (at least I think so) but it influence the normal php script behaviour a lot. Perhaps one of the PHP and Apache developer could solve the problem cu Thomas Thiery -- Edit this bug report at http://bugs.php.net/?id=2&edit=1
#22223 [NEW]: Register Globals config in php.ini get ignored
From: [EMAIL PROTECTED] Operating system: Slackware Linux 7.1 PHP version: 4.3.0 PHP Bug Type: *General Issues Bug description: Register Globals config in php.ini get ignored In my /etc/php.ini of 4.3.0, register_globals = On In , it said, register_globals = Off Off I am using the followings options in complie: './configure' '--with-mysql' '--with-apache=../ apache_1.3.27' '--with-config-file-path=/etc --disable-cli' -- Edit bug report at http://bugs.php.net/?id=3&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=3&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=3&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=3&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=3&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=3&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=3&r=support Expected behavior: http://bugs.php.net/fix.php?id=3&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=3&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=3&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=3&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=3&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=3&r=dst IIS Stability: http://bugs.php.net/fix.php?id=3&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=3&r=gnused
#22218 [Opn->Fbk]: COM function causes PHP crash
ID: 22218
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
-Bug Type: Reproducible crash
+Bug Type: COM related
Operating System: Windows 2000
PHP Version: 4.3.0
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Previous Comments:
[2003-02-14 00:36:24] [EMAIL PROTECTED]
One more bit of information... I found this in the event log:
The exception generated was c005 at address 10030727
(php_COM_release)
[2003-02-14 00:31:02] [EMAIL PROTECTED]
I have installed PHP 4.3.0 (as a CGI module) and Apache 2.0.43 in a
Windows 2000 machine. I am updating code that works on an earlier
install and I am able to get most things working.
However, I get a php crash ("php.exe has generated errors and will be
closed by Windows") when I run scripts that use COM do MSXML
validations of an XML document against a schema.
The code works on previous PHP versions set up similarly, but not on
this version.
My code looks like this:
$validate = new COM("Msxml2.DOMDocument.4.0");
$validate->async = "false";
$validate->validateOnParse = "true";
$validate->load($xmldeliveryfile);
$code = $validate->parseError->errorCode;
$reason = $validate->parseError->reason;
It seems to be returning correct values for the error code and reason
before the PHP crash, but then everything goes south. And it seems to
be crashing earlier in the process if I deliberately create an XML
validation error.
And, yes, I do have MSXML4 installed.
Any ideas?
Thanks
--
Edit this bug report at http://bugs.php.net/?id=22218&edit=1
#22213 [Fbk->Opn]: Apache mod_ssl + PHP + cURL SSL segfault
ID: 22213 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: cURL related Operating System: FreeBSD 4.6-STABLE PHP Version: 4CVS-2003-02-13 (stable) New Comment: The configure command: ./configure --with-apache=/usr/pair/sw/apachessl_1.3.27 --with-config-file-path=/usr/local/etc --enable-magic-quotes --enable-bcmath --without-cdb --with-zlib-dir=/usr/local --with-gd --without-ttf --without-msql --with-mysql=/usr/local --with-iodbc --with-pdflib --enable-inline-optimization --disable-memory-limit --with-db --without-gdbm --with-ndbm --without-db2 --without-dbm --with-gettext --without-readline --with-recode --with-openssl=/usr/local/ssl --with-mcrypt --without-db3 --enable-dba --with-curl=/usr/local/lib --with-png-dir=/usr/local/lib Compiling without "--with-curl" fixes the bug. Compiling curl "--without-ssl" also does the trick. Previous Comments: [2003-02-13 19:22:22] [EMAIL PROTECTED] And the full configure line used to configure php was..? [2003-02-13 16:17:05] [EMAIL PROTECTED] This bug could be related to bug #22112. [2003-02-13 15:56:40] [EMAIL PROTECTED] I've reproduced this bug with PHP versions 4.2.2, and the STABLE PHP dated Feb 13, 2003. FreeBSD 4.6-stable PHP 4.2.2 --with-curl curl --with-ssl, versions 7.9.8 and 7.10.3 Apache 1.3.27 mod_ssl OpenSSL 0.9.7, and a variety of flavors of 0.9.6. To reproduce the bug: * start apache * send a HUP signal to apache's parent process (to restart it) The server needn't serve any pages (php or otherwise) before the HUP is sent. Apache crashes, I believe while trying to reinitialize the mod_ssl module. Running the same version of everything, but curl compiled --without-ssl makes it work correctly: the apache parent kills off its children and spawns new ones without the parent segfaulting. It seems to be dying inside SSL_CTX_ctrl (via SSL_CTX_set_options) when called from apache's ssl_init_ConfigureServer, at this line: SSL_CTX_set_options(ctx, SSL_OP_ALL); Unfortunately, by the time it segfaults, the stack has been corrupted, and it gets really difficult to debug. Alan -- Edit this bug report at http://bugs.php.net/?id=22213&edit=1
#21884 [Opn->Csd]: enable-force-cgi-redirect doesnot work
ID: 21884 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Apache related Operating System: BSD/OS PHP Version: 4.3.0 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-01-26 02:37:32] [EMAIL PROTECTED] I use PHP as CGI with Apache 1.3.27. I compiled PHP with --safe-mode and --enable-force-cgi-redirect (minimal config to verify the problem). When I access php like http://domain.com/cgi-bin/php the "enable-force-cgi-redirect" works fine BUT when I aceess http://domain.com/test.php and test.php does NOT exist I get "No input file specified" and of course you may then pass parameters and the rest is known. ie http://www.domain.com/test.php?/etc/passwd returns the password file. In exactly the same setups I never had problems with prior versions of PHP. Also in the virual hosts in apache conf I have: ScriptAlias /cgi-bin/ /home/domain/cgi-bin/ but this was always like this. The same compilation with PHP 4.3 RC2 and before and there was no problem Thank you in advance Kosmas Skiadopoulos -- Edit this bug report at http://bugs.php.net/?id=21884&edit=1
#22220 [Opn->Bgs]: can't turn open_basedir off anymore since 4.2.3 -> 4.3.0
ID: 0 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache related Operating System: FreeBSD 4.7-STABLE PHP Version: 4.3.0 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. First of all open_basedir of '/' is rather meaningless since it allows opening of every file anyway. Secondly the open_basedir problems especially in FreeBSD enviroment should be convered in bug report #19292. Previous Comments: [2003-02-14 04:26:02] [EMAIL PROTECTED] Hmm it works for my system open_basedir = '/www'; in php.ini and in apache directive i have php_admin_value open_basedir none which works grand. did you try actually acessing a file outside the docroot? [2003-02-14 04:03:11] [EMAIL PROTECTED] I have this in my php.ini as default: open_basedir = /var/www I have a virtualhost block like this: ServerName "host.example.com" DocumentRoot "/var/www/host.example.com/root" Options Indexes ExecCgi php_admin_value safe_mode 0 php_admin_value open_basedir "/" The goal is to force a default open_basedir of "/var/www" to everything, except the explicitly specified /admin directory and contents (same with safe_mode). First, I read that setting the open_basedir to "/" doesn't work anymore in http://bugs.php.net/bug.php?id=22101. Seems kinda weird as the documentation states: [The restriction specified with open_basedir is actually a prefix, not a directory name. This means that "open_basedir = /dir/incl" also allows access to "/dir/include" and "/dir/incls" if they exist. When you want to restrict access to only the specified directory, end with a slash. For example: "open_basedir = /dir/incl/"] But besides that, specifying 'none' as open basedir in the virtualhost doesn't turn it off, it uses the default of /var/www, and I haven't found a way to set the open_basedir to NULL. So, as I see it either the 'none' setting isn't working correctly and needs to be fixed or the possibility of setting the open_basedir to "/" needs to be put back in. Unless I'm overseeing some very trivial way of turning the open_basedir restriction off of course. Thanks in advance. -- Edit this bug report at http://bugs.php.net/?id=0&edit=1
#22213 [Opn]: Apache mod_ssl + PHP + cURL SSL segfault
ID: 22213
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: cURL related
Operating System: FreeBSD 4.6-STABLE
PHP Version: 4CVS-2003-02-13 (stable)
New Comment:
Regarding notes/issues raised on bug #22112:
I made sure that apache is linking against only one copy of libssl and
libcrypto.
We have a global ErrorLog directive in the httpd.conf we're testing
with, but no VirtualHost blocks at all: it's a base conf file, and the
server doesn't even need to serve any pages for this to be a problem
for us.
Our httpd.conf conditionally turns on SSL only when the "-DSSL" flag is
present. When apache is run without that flag, it works without any
problems. It crashes only when SSL is running.
("SSLEngine on" only happens with -DSSL)
Thanks.
Previous Comments:
[2003-02-14 08:33:47] [EMAIL PROTECTED]
The configure command:
./configure --with-apache=/usr/pair/sw/apachessl_1.3.27
--with-config-file-path=/usr/local/etc --enable-magic-quotes
--enable-bcmath --without-cdb --with-zlib-dir=/usr/local --with-gd
--without-ttf --without-msql --with-mysql=/usr/local --with-iodbc
--with-pdflib --enable-inline-optimization --disable-memory-limit
--with-db --without-gdbm --with-ndbm --without-db2 --without-dbm
--with-gettext --without-readline --with-recode
--with-openssl=/usr/local/ssl --with-mcrypt --without-db3 --enable-dba
--with-curl=/usr/local/lib --with-png-dir=/usr/local/lib
Compiling without "--with-curl" fixes the bug. Compiling curl
"--without-ssl" also does the trick.
[2003-02-13 19:22:22] [EMAIL PROTECTED]
And the full configure line used to configure php was..?
[2003-02-13 16:17:05] [EMAIL PROTECTED]
This bug could be related to bug #22112.
[2003-02-13 15:56:40] [EMAIL PROTECTED]
I've reproduced this bug with PHP versions 4.2.2, and the STABLE PHP
dated Feb 13, 2003.
FreeBSD 4.6-stable
PHP 4.2.2 --with-curl
curl --with-ssl, versions 7.9.8 and 7.10.3
Apache 1.3.27 mod_ssl
OpenSSL 0.9.7, and a variety of flavors of 0.9.6.
To reproduce the bug:
* start apache
* send a HUP signal to apache's parent process (to restart it)
The server needn't serve any pages (php or otherwise) before the HUP is
sent. Apache crashes, I believe while trying to reinitialize the
mod_ssl module.
Running the same version of everything, but curl compiled
--without-ssl
makes it work correctly: the apache parent kills off its children and
spawns new ones without the parent segfaulting.
It seems to be dying inside SSL_CTX_ctrl (via SSL_CTX_set_options) when
called from apache's ssl_init_ConfigureServer, at this line:
SSL_CTX_set_options(ctx, SSL_OP_ALL);
Unfortunately, by the time it segfaults, the stack has been corrupted,
and it gets really difficult to debug.
Alan
--
Edit this bug report at http://bugs.php.net/?id=22213&edit=1
#22222 [Opn->Bgs]: mod_rewrite variables change between apache and apache2
ID: 2 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Win32 PHP Version: 4.3.0 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. This is mod_rewrite issue and not a PHP one, your bug report would be better served on the Apache 2 buglist then here. One tip that I can give you is to enable the most verbose logging of the rewrting logic, which may allow you to see why your previously working rewrite rule is failing. Previous Comments: [2003-02-14 07:28:04] [EMAIL PROTECTED] I did a little mistake in the description nothing on the topic DocumentRoot "D:/CVSCheckout/project" ServerName mycomputer.local RewriteEngine On RewriteRule ^/.*\.xml /system/if/xmlfile.if.php [2003-02-14 07:25:51] [EMAIL PROTECTED] Hello, I have a problem with a different behaviour of Apache / Apache2 Two configuration: - Apache 1.3.27 / PHP 4.3 / Win32 - Apache 2.0.44 / PHP 4.3 / Win32 with more or less the same httpd.conf configuration file (here the part which make troubles): ... DocumentRoot "D:/CVSCheckout/project" ServerName mycomputer.local RewriteEngine On RewriteRule ^/.*\.xml /system/if/xmlfile.if.php Both configuration should rewrite all .xml files to a central file, which load the xml file and output the parsed xml code in a format (i.e. HTML, PDF, Flash, ...). No problem till I update the system to apache 2.0.44. Since then I get a "400 Bad Request" Error (IE, Mozilla). I test a while and solve the problem with this line: RewriteRule ^/.*\.xml /system/if/xmlfile.if.php [PT] but now all script variables like SCRIPT_NAME, etc. changes due to the other way of rewrite. Ok, I could do a nasty workaround, but I hate to do this due to a bug. I know it's perhaps not a php Bug (at least I think so) but it influence the normal php script behaviour a lot. Perhaps one of the PHP and Apache developer could solve the problem cu Thomas Thiery -- Edit this bug report at http://bugs.php.net/?id=2&edit=1
#22221 [Opn->Fbk]: bad rows count in the result object for postgresql
ID: 1
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: DBX related
Operating System: Linux morlupo 2.4.18-14 (redhat
PHP Version: 4.2.2
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Previous Comments:
[2003-02-14 07:26:47] [EMAIL PROTECTED]
Hello Marc,
Thank you for replying so fast.
I don't think my setup is very specific.
Here is the code of my error handler.
(Note that the work around I have found is to regexp the $errormesg: I
didn't want to leave completely the E_WARNING completely as a SQL
syntax error will be unnoticed by me. Strangely a SQL syntax erro comes
out with the same error code E_WARNING as this postgresql "bug")
I don't know how the default handler do, but it catches the SQL errors
but not this postgresql stuff perhaps does the same thing: parse
for ERROR)
here is the code-
function userErrorHandler ($errno, $errmsg, $filename, $linenum, $vars)
{
# define an assoc array of error string
# in reality the only entries we should
# consider are 2,8,256,512 and 1024
$errortype = array (
1 => "Error",
2 => "Warning",
4 => "Parsing Error",
8 => "Notice",
16 => "Core Error",
32 => "Core Warning",
64 => "Compile Error",
128 => "Compile Warning",
256 => "User Error",
512 => "User Warning",
1024=> "User Notice"
);
# set of errors for which we will die
$die_errors = array(E_USER_ERROR);
# set of errors that will be mailed
$mail_errors =
array(E_ERROR,E_WARNING,E_PARSE,E_CORE_ERROR,E_CORE_WARNING,E_USER_ERROR,
E_USER_WARNING);
$err.=$errortype["$errno"]." (bit $errno)\n$errmsg\nin $filename
line $linenum";
if (in_array($errno, $mail_errors) &&
preg_match("/ERROR/",$errmsg)) {
myerrormail("[EMAIL PROTECTED]",$errortype["$errno"]." (bit
$errno)",$err);
}
#possibly die
if (in_array($errno, $die_errors)){
exit;
}
return 1;
}
[2003-02-14 06:44:23] [EMAIL PROTECTED]
Internally in the dbx_pgsql driver, the code disables E_WARNING for
pg_fetch_array, fetches rows until no more rows are available (this is
detected by trapping the warning you got), then re-enables the
E_WARNING if it was enabled in the first place.
This is probably why you have to define your own error-handler to see
the warning at all.
Does this happen with any user-defined error-handler or is your setup
very specific? Is there an easy workaround without resorting to
@dbx_qeuery()? Could you post the code for your error-handler
(simplified if possible)?
Thanks, Marc.
[2003-02-14 06:32:05] [EMAIL PROTECTED]
sorry for the typo:
please read:
after making a query that return *10* rows I get the message:
---
pg_fetch_array() unable to jump to row 10 on PostgreSQL result index 4
in /somepath/library_connect.php line 68
[2003-02-14 06:27:27] [EMAIL PROTECTED]
Hello,
I am using the default php modules with postgresql coming with redhat
8.0.
I have a code using the dbx function that work well in mysql.
When changing to postgresql (i.e. changing DBX_MYSQL to DBX_PGSQL in
function dbx_connect()) I get warnings that I don't get with mysql.
Note that those warning are difficult to see: you have to define your
own error_handler to see them!!!
That's what I do usually on my web sites.
In your error handler I have set the following message options:
(E_ERROR,E_WARNING,E_PARSE,E_CORE_ERROR,E_CORE_WARNING,E_USER_ERROR,
E_USER_WARNING)
OK, with that set up
after making a query that return 3 rows I get the message:
---
pg_fetch_array() unable to jump to row 10 on PostgreSQL result index 4
in /somepath/library_connect.php line 68
---
this corresponds to the following loop:
$query="select * from membership";
$result=dbx_query($socket,$query,DBX_RESULT_ASSOC);
$num_rows = $result->rows;
for ($i=0;$i<$num_rows;$i++) {
list(,$row)=each($result->data);
}
This type of code works well with the mysql driver. In postgresq it
seems it looks for indexes for 0 to 10 included!
--
Edit this bug report at http://bugs
#22223 [Opn->Fbk]: Register Globals config in php.ini get ignored
ID: 3 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *General Issues Operating System: Slackware Linux 7.1 PHP Version: 4.3.0 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip If the problem persists include the output of strace sapi/cli/php -h 2>&1 | grep "open(.*\.ini" in your reply. Previous Comments: [2003-02-14 07:30:05] [EMAIL PROTECTED] In my /etc/php.ini of 4.3.0, register_globals = On In , it said, register_globals = Off Off I am using the followings options in complie: './configure' '--with-mysql' '--with-apache=../ apache_1.3.27' '--with-config-file-path=/etc --disable-cli' -- Edit this bug report at http://bugs.php.net/?id=3&edit=1
#22221 [Fbk->Opn]: bad rows count in the result object for postgresql
ID: 1
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: DBX related
Operating System: Linux morlupo 2.4.18-14 (redhat
PHP Version: 4.2.2
New Comment:
Hi Iliia,
Marc sent me a patch that solved the problem.
Previous Comments:
[2003-02-14 08:58:43] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-02-14 07:26:47] [EMAIL PROTECTED]
Hello Marc,
Thank you for replying so fast.
I don't think my setup is very specific.
Here is the code of my error handler.
(Note that the work around I have found is to regexp the $errormesg: I
didn't want to leave completely the E_WARNING completely as a SQL
syntax error will be unnoticed by me. Strangely a SQL syntax erro comes
out with the same error code E_WARNING as this postgresql "bug")
I don't know how the default handler do, but it catches the SQL errors
but not this postgresql stuff perhaps does the same thing: parse
for ERROR)
here is the code-
function userErrorHandler ($errno, $errmsg, $filename, $linenum, $vars)
{
# define an assoc array of error string
# in reality the only entries we should
# consider are 2,8,256,512 and 1024
$errortype = array (
1 => "Error",
2 => "Warning",
4 => "Parsing Error",
8 => "Notice",
16 => "Core Error",
32 => "Core Warning",
64 => "Compile Error",
128 => "Compile Warning",
256 => "User Error",
512 => "User Warning",
1024=> "User Notice"
);
# set of errors for which we will die
$die_errors = array(E_USER_ERROR);
# set of errors that will be mailed
$mail_errors =
array(E_ERROR,E_WARNING,E_PARSE,E_CORE_ERROR,E_CORE_WARNING,E_USER_ERROR,
E_USER_WARNING);
$err.=$errortype["$errno"]." (bit $errno)\n$errmsg\nin $filename
line $linenum";
if (in_array($errno, $mail_errors) &&
preg_match("/ERROR/",$errmsg)) {
myerrormail("[EMAIL PROTECTED]",$errortype["$errno"]." (bit
$errno)",$err);
}
#possibly die
if (in_array($errno, $die_errors)){
exit;
}
return 1;
}
[2003-02-14 06:44:23] [EMAIL PROTECTED]
Internally in the dbx_pgsql driver, the code disables E_WARNING for
pg_fetch_array, fetches rows until no more rows are available (this is
detected by trapping the warning you got), then re-enables the
E_WARNING if it was enabled in the first place.
This is probably why you have to define your own error-handler to see
the warning at all.
Does this happen with any user-defined error-handler or is your setup
very specific? Is there an easy workaround without resorting to
@dbx_qeuery()? Could you post the code for your error-handler
(simplified if possible)?
Thanks, Marc.
[2003-02-14 06:32:05] [EMAIL PROTECTED]
sorry for the typo:
please read:
after making a query that return *10* rows I get the message:
---
pg_fetch_array() unable to jump to row 10 on PostgreSQL result index 4
in /somepath/library_connect.php line 68
[2003-02-14 06:27:27] [EMAIL PROTECTED]
Hello,
I am using the default php modules with postgresql coming with redhat
8.0.
I have a code using the dbx function that work well in mysql.
When changing to postgresql (i.e. changing DBX_MYSQL to DBX_PGSQL in
function dbx_connect()) I get warnings that I don't get with mysql.
Note that those warning are difficult to see: you have to define your
own error_handler to see them!!!
That's what I do usually on my web sites.
In your error handler I have set the following message options:
(E_ERROR,E_WARNING,E_PARSE,E_CORE_ERROR,E_CORE_WARNING,E_USER_ERROR,
E_USER_WARNING)
OK, with that set up
after making a query that return 3 rows I get the message:
---
pg_fetch_array() unable to jump to row 10 on PostgreSQL result index 4
in /somepath/library_connect.php line 68
---
this corresponds to the following loop:
$query="select * from membership";
$result=dbx_query($socket,$query,DBX_RESULT_ASSOC);
$num_rows = $result->rows;
for ($i=0;$i<$num_rows;$i++) {
list(,$row)=each($result->data);
}
This type of code works well with the mysql driver. In postgr
#22221 [Opn->Ver]: bad rows count in the result object for postgresql
ID: 1
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Verified
Bug Type: DBX related
Operating System: Linux morlupo 2.4.18-14 (redhat
PHP Version: 4.2.2
-Assigned To:
+Assigned To: mboeren
New Comment:
The same error would have occurrred in the latest version too. The
patch I sent solves the problem, and should have no side-effects. I
would like to run the dbx-tests before I commit the patch to cvs
though.
Previous Comments:
[2003-02-14 09:07:45] [EMAIL PROTECTED]
Hi Iliia,
Marc sent me a patch that solved the problem.
[2003-02-14 08:58:43] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-02-14 07:26:47] [EMAIL PROTECTED]
Hello Marc,
Thank you for replying so fast.
I don't think my setup is very specific.
Here is the code of my error handler.
(Note that the work around I have found is to regexp the $errormesg: I
didn't want to leave completely the E_WARNING completely as a SQL
syntax error will be unnoticed by me. Strangely a SQL syntax erro comes
out with the same error code E_WARNING as this postgresql "bug")
I don't know how the default handler do, but it catches the SQL errors
but not this postgresql stuff perhaps does the same thing: parse
for ERROR)
here is the code-
function userErrorHandler ($errno, $errmsg, $filename, $linenum, $vars)
{
# define an assoc array of error string
# in reality the only entries we should
# consider are 2,8,256,512 and 1024
$errortype = array (
1 => "Error",
2 => "Warning",
4 => "Parsing Error",
8 => "Notice",
16 => "Core Error",
32 => "Core Warning",
64 => "Compile Error",
128 => "Compile Warning",
256 => "User Error",
512 => "User Warning",
1024=> "User Notice"
);
# set of errors for which we will die
$die_errors = array(E_USER_ERROR);
# set of errors that will be mailed
$mail_errors =
array(E_ERROR,E_WARNING,E_PARSE,E_CORE_ERROR,E_CORE_WARNING,E_USER_ERROR,
E_USER_WARNING);
$err.=$errortype["$errno"]." (bit $errno)\n$errmsg\nin $filename
line $linenum";
if (in_array($errno, $mail_errors) &&
preg_match("/ERROR/",$errmsg)) {
myerrormail("[EMAIL PROTECTED]",$errortype["$errno"]." (bit
$errno)",$err);
}
#possibly die
if (in_array($errno, $die_errors)){
exit;
}
return 1;
}
[2003-02-14 06:44:23] [EMAIL PROTECTED]
Internally in the dbx_pgsql driver, the code disables E_WARNING for
pg_fetch_array, fetches rows until no more rows are available (this is
detected by trapping the warning you got), then re-enables the
E_WARNING if it was enabled in the first place.
This is probably why you have to define your own error-handler to see
the warning at all.
Does this happen with any user-defined error-handler or is your setup
very specific? Is there an easy workaround without resorting to
@dbx_qeuery()? Could you post the code for your error-handler
(simplified if possible)?
Thanks, Marc.
[2003-02-14 06:32:05] [EMAIL PROTECTED]
sorry for the typo:
please read:
after making a query that return *10* rows I get the message:
---
pg_fetch_array() unable to jump to row 10 on PostgreSQL result index 4
in /somepath/library_connect.php line 68
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/1
--
Edit this bug report at http://bugs.php.net/?id=1&edit=1
#22221 [Ver]: bad rows count in the result object for postgresql
ID: 1
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Verified
Bug Type: DBX related
Operating System: Linux morlupo 2.4.18-14 (redhat
PHP Version: 4.2.2
Assigned To: mboeren
New Comment:
Marc:
I am trying to run the tests (compile the cgi version).
I'll tell you the results of the tests if any.
Alex
Previous Comments:
[2003-02-14 09:16:36] [EMAIL PROTECTED]
The same error would have occurrred in the latest version too. The
patch I sent solves the problem, and should have no side-effects. I
would like to run the dbx-tests before I commit the patch to cvs
though.
[2003-02-14 09:07:45] [EMAIL PROTECTED]
Hi Iliia,
Marc sent me a patch that solved the problem.
[2003-02-14 08:58:43] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-02-14 07:26:47] [EMAIL PROTECTED]
Hello Marc,
Thank you for replying so fast.
I don't think my setup is very specific.
Here is the code of my error handler.
(Note that the work around I have found is to regexp the $errormesg: I
didn't want to leave completely the E_WARNING completely as a SQL
syntax error will be unnoticed by me. Strangely a SQL syntax erro comes
out with the same error code E_WARNING as this postgresql "bug")
I don't know how the default handler do, but it catches the SQL errors
but not this postgresql stuff perhaps does the same thing: parse
for ERROR)
here is the code-
function userErrorHandler ($errno, $errmsg, $filename, $linenum, $vars)
{
# define an assoc array of error string
# in reality the only entries we should
# consider are 2,8,256,512 and 1024
$errortype = array (
1 => "Error",
2 => "Warning",
4 => "Parsing Error",
8 => "Notice",
16 => "Core Error",
32 => "Core Warning",
64 => "Compile Error",
128 => "Compile Warning",
256 => "User Error",
512 => "User Warning",
1024=> "User Notice"
);
# set of errors for which we will die
$die_errors = array(E_USER_ERROR);
# set of errors that will be mailed
$mail_errors =
array(E_ERROR,E_WARNING,E_PARSE,E_CORE_ERROR,E_CORE_WARNING,E_USER_ERROR,
E_USER_WARNING);
$err.=$errortype["$errno"]." (bit $errno)\n$errmsg\nin $filename
line $linenum";
if (in_array($errno, $mail_errors) &&
preg_match("/ERROR/",$errmsg)) {
myerrormail("[EMAIL PROTECTED]",$errortype["$errno"]." (bit
$errno)",$err);
}
#possibly die
if (in_array($errno, $die_errors)){
exit;
}
return 1;
}
[2003-02-14 06:44:23] [EMAIL PROTECTED]
Internally in the dbx_pgsql driver, the code disables E_WARNING for
pg_fetch_array, fetches rows until no more rows are available (this is
detected by trapping the warning you got), then re-enables the
E_WARNING if it was enabled in the first place.
This is probably why you have to define your own error-handler to see
the warning at all.
Does this happen with any user-defined error-handler or is your setup
very specific? Is there an easy workaround without resorting to
@dbx_qeuery()? Could you post the code for your error-handler
(simplified if possible)?
Thanks, Marc.
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/1
--
Edit this bug report at http://bugs.php.net/?id=1&edit=1
#22221 [Ver->Asn]: bad rows count in the result object for postgresql
ID: 1
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Verified
+Status: Assigned
Bug Type: DBX related
Operating System: Linux morlupo 2.4.18-14 (redhat
PHP Version: 4.2.2
Assigned To: mboeren
Previous Comments:
[2003-02-14 09:47:29] [EMAIL PROTECTED]
Marc:
I am trying to run the tests (compile the cgi version).
I'll tell you the results of the tests if any.
Alex
[2003-02-14 09:16:36] [EMAIL PROTECTED]
The same error would have occurrred in the latest version too. The
patch I sent solves the problem, and should have no side-effects. I
would like to run the dbx-tests before I commit the patch to cvs
though.
[2003-02-14 09:07:45] [EMAIL PROTECTED]
Hi Iliia,
Marc sent me a patch that solved the problem.
[2003-02-14 08:58:43] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-02-14 07:26:47] [EMAIL PROTECTED]
Hello Marc,
Thank you for replying so fast.
I don't think my setup is very specific.
Here is the code of my error handler.
(Note that the work around I have found is to regexp the $errormesg: I
didn't want to leave completely the E_WARNING completely as a SQL
syntax error will be unnoticed by me. Strangely a SQL syntax erro comes
out with the same error code E_WARNING as this postgresql "bug")
I don't know how the default handler do, but it catches the SQL errors
but not this postgresql stuff perhaps does the same thing: parse
for ERROR)
here is the code-
function userErrorHandler ($errno, $errmsg, $filename, $linenum, $vars)
{
# define an assoc array of error string
# in reality the only entries we should
# consider are 2,8,256,512 and 1024
$errortype = array (
1 => "Error",
2 => "Warning",
4 => "Parsing Error",
8 => "Notice",
16 => "Core Error",
32 => "Core Warning",
64 => "Compile Error",
128 => "Compile Warning",
256 => "User Error",
512 => "User Warning",
1024=> "User Notice"
);
# set of errors for which we will die
$die_errors = array(E_USER_ERROR);
# set of errors that will be mailed
$mail_errors =
array(E_ERROR,E_WARNING,E_PARSE,E_CORE_ERROR,E_CORE_WARNING,E_USER_ERROR,
E_USER_WARNING);
$err.=$errortype["$errno"]." (bit $errno)\n$errmsg\nin $filename
line $linenum";
if (in_array($errno, $mail_errors) &&
preg_match("/ERROR/",$errmsg)) {
myerrormail("[EMAIL PROTECTED]",$errortype["$errno"]." (bit
$errno)",$err);
}
#possibly die
if (in_array($errno, $die_errors)){
exit;
}
return 1;
}
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/1
--
Edit this bug report at http://bugs.php.net/?id=1&edit=1
#22052 [Asn]: Ftp ftp_rawlist,ftp_nlist broken
ID: 22052 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: FTP related Operating System: FreeBSD 5.0-RELEASE #0 PHP Version: 4.3.1-dev Assigned To: pollita New Comment: still broken using php4-STABLE-200302141630.tar.bz2 (the latest snap). Previous Comments: [2003-02-13 20:11:07] [EMAIL PROTECTED] excellent, expect some results by 9:00am PMT. [2003-02-13 20:09:16] [EMAIL PROTECTED] Okay, great... I believe I've got the problem nailed down, I just need the results of using that updated snapshot to be 100% certain. In the meantime I'll start putting together the patch and with luck this should be working by this time tomorrow. [2003-02-13 18:54:22] [EMAIL PROTECTED] the tmpfile(); test works without flaw. [2003-02-13 17:33:48] [EMAIL PROTECTED] I have a feeling, at this point, that while the new snapshot will stop your segfault, it'll still not behave in the way you expect it to. Try this seemingly unrelated script via your httpd server: Ideally you should see "This is a test" in your browser... if notwell... does it show an error? [2003-02-13 17:20:36] [EMAIL PROTECTED] pollita, This script only breaks in http method, as the cli returns the desired output(snafu). The Httpd child dies with a segfault. This appears to only occur on the OS's listed on the main 4.3 distro of PHP as well as alot of the snaps I've tried. currently running FreeBSD 4.7-RELEASE #0: Wed Feb 12 19:59:59 GMT 2003 with php4.3.0 release (very stable). thanks for your time, as I will try the current snap tomorrow. 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/22052 -- Edit this bug report at http://bugs.php.net/?id=22052&edit=1
#22177 [Bgs]: Warning: fopen() expects parameter 1 to be string
ID: 22177 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Filesystem function related Operating System: RedHat PHP Version: 4.3.0 New Comment: Thanks for the reply. I ran a search on the functions you listed and couldn't find them: a) temfile http://www.php.net/manual-lookup.php?pattern=temfile&lang=en b) temname http://www.php.net/manual-lookup.php?pattern=temname&lang=en Why are they not listed in the manual? "so you use functions without reading their specs and then complain about them not working as you'd expect? strange concept ..." I don't believe in this bug report I ever said the script was written by me. You see the script that I "have" was released GNU GPL to the public and I was conducting tests on it in two difference versions of PHP. Because it doesn't function under 4.3 I was trying to be kind in debugging it and releases the "bug fix" to the community-at-large. This is precisely why I am not 100% familiar with the code because I didn't write it. This has all been about the gesture of goodwill. Previous Comments: [2003-02-14 05:29:43] [EMAIL PROTECTED] my 2c on this: yes it worked in 4.2.3 ... but even in 4.2.3 it didn't do what you wanted, instead of creating a temp file with a unique name (or better in addition to it) your fopen statement opens a file by the name of the auto-converted resource number, so if you investigate this you'll find out that your temporary files are actualy namend by small numbers, and if your code always opens the same resources you'll even get temp files of *equal* names by different script runs -> not what you want so 4.3 now warns you about this were 4.3.2 silently accepted it "that same exact code block worked 100% under php 4.2.3." is just not true, as it would create race conditions if run simultaneous multiple times even in 4.2.3 "Thus one last question, looking at the code I initially posted, what would be your suggestion if I may ask specifically tailored to my problem?" you've been told before in this thread: either use temnam() instead of tmpfile(), or use the file handle resource returned by temfile() right away instead of trying to perform unspecified operations on it ... "I don't appreciate the RTFM remark, but I am glad you replied back. I use the php manual extensively but have not seen that particular link." so you use functions without reading their specs and then complain about them not working as you'd expect? strange concept ... [2003-02-11 18:22:38] [EMAIL PROTECTED] Thanks. [2003-02-11 18:22:02] [EMAIL PROTECTED] For support: http://www.php.net/support.php [2003-02-11 18:19:33] [EMAIL PROTECTED] Quote: "The fact that this "worked" for you in 4.2.3 indicates a bug in 4.2.3 that has been fixed in 4.3." Now that is an idea that didn't occur to me. And since php 4.2.3 may have been buggy then obviously the fix is to upgrade to 4.3 and rewrite it the way you folks suggest. Thanks for that answer, a much more mature one than RTFM. Hence this isn't bogus but an actual bug that was in 4.2.3. And the patch is to make sure the code is written correctly. Thus one last question, looking at the code I initially posted, what would be your suggestion if I may ask specifically tailored to my problem? [2003-02-11 18:15:22] [EMAIL PROTECTED] "Warning: fopen() expects parameter 1 to be string" Now read the manual for fopen -> parameter 1 needs to be a string. You are passing a resource. The fact that this "worked" for you in 4.2.3 indicates a bug in 4.2.3 that has been fixed in 4.3. Your supposed temporary file name would be a string "Resource id #4", which isn't a very good temporary file name. You describe the expected behaviour of PHP, your script is broken, therefore this is a user error, and thus a bogus report. Now, please leave us in peace to fix real bugs. 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/22177 -- Edit this bug report at http://bugs.php.net/?id=22177&edit=1
#21479 [Opn->Fbk]: Crashes with 6 slashes in URL and non-existant file
ID: 21479 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: GetImageSize related Operating System: Win 2000 IIS (CGI) PHP Version: 4.3.0 New Comment: And did you replace all files in your system or system32 directory ? Previous Comments: [2003-02-14 00:59:53] [EMAIL PROTECTED] yes i renamed c:\php to something else, and unzipped the snapshot into a new c:\php, then rebooted - still crashing as described above. [2003-02-12 22:00:52] [EMAIL PROTECTED] Please make sure you've really replaced ALL the old dlls with the new ones from the snapshot package! Especially the php4ts.dll file. Easiest way to make sure you do this is to delete all the old files first. And sometimes a reboot is needed too..(reported by others) [2003-02-12 11:44:07] [EMAIL PROTECTED] it still crashes, the only difference is - with php 4.3.1 the php.exe application error message i get is: The instruction at "0x77fcb9f8" referenced memory at "0x00e4803a". The memory could not be "written". with php 4.3.0 the php.exe application error message i get is: The instruction at "0x77fcb9f8" referenced memory at "0x00e2703a". The memory could not be "written". [2003-02-10 19:26:11] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip I cannot replicate the bug using Windows XP + PHP 4.3.1-dev. [2003-01-25 12:30:11] [EMAIL PROTECTED] I cannot reproduce this with 4.4: [c:\dokumente und einstellungen\marcus]c:\Programme\PHP4\php.exe http://economads.com/libaware/_font/title/image.gif')); ?> ^Z Content-type: text/html X-Powered-By: PHP/4.4.0-dev Warning: getimagesize(http://economads.com/libaware/_font/title/image.gif) [function.getimagesize]: failed to create stream: HTTP request failed! HTTP/1.1 404 Object Not Found in C:\Dokumente und Einstellungen\marcus\- on line 2 [c:\dokumente und einstellungen\marcus]php -v PHP 4.4.0-dev (cgi-fcgi), Copyright (c) 1997-2003 The PHP Group Zend Engine v1.4.0, Copyright (c) 1998-2003 Zend Technologies 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/21479 -- Edit this bug report at http://bugs.php.net/?id=21479&edit=1
#22224 [NEW]: implode changes object references in array
From: [EMAIL PROTECTED] Operating system: WIN 2K PHP version: 4.3.0 PHP Bug Type: *General Issues Bug description: implode changes object references in array implode seems to change object references in the given array to strings. try this: b(); // ERROR! ?> -- Edit bug report at http://bugs.php.net/?id=4&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=4&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=4&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=4&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=4&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=4&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=4&r=support Expected behavior: http://bugs.php.net/fix.php?id=4&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=4&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=4&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=4&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=4&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=4&r=dst IIS Stability: http://bugs.php.net/fix.php?id=4&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=4&r=gnused
#22224 [Opn->Asn]: implode changes object references in array
ID: 4 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: *General Issues Operating System: WIN 2K PHP Version: 4.3.0 -Assigned To: +Assigned To: moriyoshi New Comment: Verified & assigned to me. This seems to be my fault. Previous Comments: [2003-02-14 11:47:00] [EMAIL PROTECTED] implode seems to change object references in the given array to strings. try this: b(); // ERROR! ?> -- Edit this bug report at http://bugs.php.net/?id=4&edit=1
#21926 [Com]: Apache process hangs
ID: 21926 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Java related Operating System: Red Hat Linux 7.1 PHP Version: 4CVS-2003-01-28 (stable) New Comment: I would like to ammend this report by saying I am seeing something similar... using Lucene... Now... here's some more information. Using the CLI... my PHP script works just fine. It instantiates my java object and executes perfectly and returns results as I would expect... so it appears to be definitely something with the libphp4.so module. I have rebuilt it many many times. I should also say that running on RedHat 8.0 everything works perfectly... its just on RedHat 7.x appears to be a problem. I am using Sun JDK 1.3.1_07 for Linux Apache 1.24 Previous Comments: [2003-01-28 13:16:59] [EMAIL PROTECTED] Hi. I'm using the PHP Java extension to run Jakarta Lucene to power my internal site search. Whenever I call a Java object, Apache starts between 1 to 5 new httpd processes and it keeps growing with each subsequent call to the object. After some time (and after more than 50 httpd processes are started) the web site stops respondig for some clients. For others it continues running as usual. This happens with PHP 4.3.0 and the latest CVS (2003-01-28) My configure line is as follows: './configure' '--with-mysql' '--with-imap' '--with-imap-ssl' '--with-kerberos' '--with-apxs=/var/www/bin/apxs' '--enable-xslt' '--with-xslt-sablot' '--with-xml' '--with-iconv' '--with-pgsql' '--with-dom' '--with-zlib' '--with-gd' '--with-java=/usr/java/j2sdk1.4.1_01' Java Version: Sun J2SE 1.4.1 Apache Version 1.3.24 This also seems to be the same bug as #20270, that is closed. -- Edit this bug report at http://bugs.php.net/?id=21926&edit=1
#22224 [Asn]: implode changes object references in array
ID: 4 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: *General Issues Operating System: WIN 2K PHP Version: 4.3.0 Assigned To: moriyoshi New Comment: Oh it turned out not to be my fault :) Anyway, I'm going to fix this bug then. Previous Comments: [2003-02-14 12:01:11] [EMAIL PROTECTED] Verified & assigned to me. This seems to be my fault. [2003-02-14 11:47:00] [EMAIL PROTECTED] implode seems to change object references in the given array to strings. try this: b(); // ERROR! ?> -- Edit this bug report at http://bugs.php.net/?id=4&edit=1
#22224 [Asn->Csd]: implode changes object references in array
ID: 4 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: *General Issues Operating System: WIN 2K PHP Version: 4.3.0 Assigned To: moriyoshi New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-02-14 12:06:27] [EMAIL PROTECTED] Oh it turned out not to be my fault :) Anyway, I'm going to fix this bug then. [2003-02-14 12:01:11] [EMAIL PROTECTED] Verified & assigned to me. This seems to be my fault. [2003-02-14 11:47:00] [EMAIL PROTECTED] implode seems to change object references in the given array to strings. try this: b(); // ERROR! ?> -- Edit this bug report at http://bugs.php.net/?id=4&edit=1
#22225 [NEW]: Foreach statement allows for unexpected ';' without throwing error.
From: [EMAIL PROTECTED]
Operating system: Redhat 7.1
PHP version: 4.3.0
PHP Bug Type: Regexps related
Bug description: Foreach statement allows for unexpected ';' without throwing error.
foreach($someArray AS $index => $key);
{
...instructions
}
Assuming that $someArray has a length greater than 1; The semi-colon at
the end of the foreach() statement does not throw a syntax error and it
also does not loop through the instructions, rather it runs the
instructions once with what would be the 'last' set of $key
--
Edit bug report at http://bugs.php.net/?id=5&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=5&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=5&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=5&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=5&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=5&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=5&r=support
Expected behavior: http://bugs.php.net/fix.php?id=5&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=5&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=5&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=5&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=5&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=5&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=5&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=5&r=gnused
#22225 [Opn->Bgs]: Foreach statement allows for unexpected ';' without throwing error.
ID: 5
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Regexps related
Operating System: Redhat 7.1
PHP Version: 4.3.0
New Comment:
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
Imagine the following case:
if (true); // if statement is terminated by a semicolon.
/* blah */
{
// this block has nothing to do with the above statement
}
Previous Comments:
[2003-02-14 13:16:30] [EMAIL PROTECTED]
foreach($someArray AS $index => $key);
{
...instructions
}
Assuming that $someArray has a length greater than 1; The semi-colon
at the end of the foreach() statement does not throw a syntax error and
it also does not loop through the instructions, rather it runs the
instructions once with what would be the 'last' set of $key
--
Edit this bug report at http://bugs.php.net/?id=5&edit=1
#22215 [Opn->Ver]: PHP dies while loading php.ini
ID: 22215
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Verified
Bug Type: Reproducible crash
Operating System: Linux
-PHP Version: 4CVS-2003-02-13 (stable)
+PHP Version: 4CVS-2003-02-13 (stable) / 5CVS-2003-02-14 (dev)
New Comment:
This bug appears to be yet another bison oddity.
I managed to reproduce with bison 1.875a
Which version of bison are you using?
$ bison --version
Previous Comments:
[2003-02-14 02:08:58] [EMAIL PROTECTED]
I do _not_ have auto_detect_line_endings enabled in my ini file. The
contents of the file are included in my original report. Backtrace
follows - perhaps this should be a 'scripting engine problem' if it is
a PHP problem.
(gdb) run
Starting program: /usr/local/src/php-cvs/php4/sapi/cli/php
Program received signal SIGSEGV, Segmentation fault.
0x404044fc in memcpy () at memcpy:-1
-1 memcpy: No such file or directory.
in memcpy
(gdb) bt
#0 0x404044fc in memcpy () at memcpy:-1
#1 0xdfffdea5 in ?? ()
#2 0x081258e3 in zend_parse_ini_file (fh=0xbfffd9e0,
unbuffered_errors=1,
ini_parser_cb=0x8112948 , arg=0x821f900)
at /usr/local/src/php-cvs/php4/Zend/zend_ini_parser.y:164
#3 0x08112e99 in php_init_config () at
/usr/local/src/php-cvs/php4/main/php_ini.c:386
#4 0x0810ee9f in php_module_startup (sf=0x821c720,
additional_modules=0x0, num_additional_modules=0)
at /usr/local/src/php-cvs/php4/main/main.c:1104
#5 0x081504c1 in main (argc=1, argv=0xbfffdc84) at
/usr/local/src/php-cvs/php4/sapi/cli/php_cli.c:481
#6 0x40397657 in __libc_start_main (main=0x8150398 , argc=1,
ubp_av=0xbfffdc84, init=0x806a8e4 <_init>,
fini=0x81a0760 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>,
stack_end=0xbfffdc7c)
at ../sysdeps/generic/libc-start.c:129
(gdb)
[2003-02-13 16:19:05] [EMAIL PROTECTED]
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
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.
Also, do you have the 'auto_detect_line_endings' enabled in your ini
file?
[2003-02-13 16:14:19] [EMAIL PROTECTED]
current (Thu Feb 13 22:00:53 GMT 2003) php-4.3 from CVS compiled as
follows:
./configure --disable-ipv6 --with-config-file-path=/etc/httpd/conf
--enable-memory-limit --disable-display-source --enable-track-var
--with-imap --with-imap-ssl
--with-apxs=/usr/local/apache/current/bin/apxs --with-gd=/usr
--with-jpeg-dir=/usr --with-xpm-dir=/usr/X11R6
--with-mysql=/usr/local/mysql/current --with-curl --enable-ftp
--enable-dbase --enable-xml --with-xml --with-gettext --with-mcrypt
--disable-posix
prevents Apache-1.3.27 from starting (segfault). strace on the CLI
SAPI shows a problem accessing php.ini:
close(3)= 0
brk(0x822c000) = 0x822c000
open("sapi/cli//php-cli.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/httpd/conf/php-cli.ini", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("sapi/cli//php.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/httpd/conf/php.ini", O_RDONLY) = 3
getcwd("/usr/local/src/php-cvs/php4", 4095) = 28
lstat64("/etc", {st_mode=S_IFDIR|0755, st_size=8192, ...}) = 0
lstat64("/etc/httpd", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/etc/httpd/conf", {st_mode=S_IFDIR|0771, st_size=4096, ...}) =
0
lstat64("/etc/httpd/conf/php.ini", {st_mode=S_IFREG|0644, st_size=331,
...}) = 0
brk(0x8231000) = 0x8231000
ioctl(3, 0x5401, 0xbfffca80)= -1 ENOTTY (Inappropriate
ioctl for device)
fstat64(3, {st_mode=S_IFREG|0644, st_size=331, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x40018000
read(3, "register_globals = on\nignore_use"..., 8192) = 331
read(3, "", 4096) = 0
read(3, "", 8192) = 0
ioctl(3, 0x5401, 0xbfffbed0)= -1 ENOTTY (Inappropriate
ioctl for device)
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
The exact same config works fine with plain 4.3 tarball compile.
The system is RedHat 7.2 with autoconf/automake/libtool upgraded to
play nice with PHP/CVS.
The /etc/httpd/conf/php.ini file is as follows:
register_globals = on
ignore_user_abort = on
log_errors = true
#zend_optimizer.optimization_level = 15
#zend_extension = "/usr/local/lib/ZendOptimizer.so"
display_errors = false
memory_limit = 65536
post_
#22215 [Ver->Fbk]: PHP dies while loading php.ini
ID: 22215
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Verified
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 4CVS-2003-02-13 (stable) / 5CVS-2003-02-14 (dev)
Previous Comments:
[2003-02-14 13:27:21] [EMAIL PROTECTED]
This bug appears to be yet another bison oddity.
I managed to reproduce with bison 1.875a
Which version of bison are you using?
$ bison --version
[2003-02-14 02:08:58] [EMAIL PROTECTED]
I do _not_ have auto_detect_line_endings enabled in my ini file. The
contents of the file are included in my original report. Backtrace
follows - perhaps this should be a 'scripting engine problem' if it is
a PHP problem.
(gdb) run
Starting program: /usr/local/src/php-cvs/php4/sapi/cli/php
Program received signal SIGSEGV, Segmentation fault.
0x404044fc in memcpy () at memcpy:-1
-1 memcpy: No such file or directory.
in memcpy
(gdb) bt
#0 0x404044fc in memcpy () at memcpy:-1
#1 0xdfffdea5 in ?? ()
#2 0x081258e3 in zend_parse_ini_file (fh=0xbfffd9e0,
unbuffered_errors=1,
ini_parser_cb=0x8112948 , arg=0x821f900)
at /usr/local/src/php-cvs/php4/Zend/zend_ini_parser.y:164
#3 0x08112e99 in php_init_config () at
/usr/local/src/php-cvs/php4/main/php_ini.c:386
#4 0x0810ee9f in php_module_startup (sf=0x821c720,
additional_modules=0x0, num_additional_modules=0)
at /usr/local/src/php-cvs/php4/main/main.c:1104
#5 0x081504c1 in main (argc=1, argv=0xbfffdc84) at
/usr/local/src/php-cvs/php4/sapi/cli/php_cli.c:481
#6 0x40397657 in __libc_start_main (main=0x8150398 , argc=1,
ubp_av=0xbfffdc84, init=0x806a8e4 <_init>,
fini=0x81a0760 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>,
stack_end=0xbfffdc7c)
at ../sysdeps/generic/libc-start.c:129
(gdb)
[2003-02-13 16:19:05] [EMAIL PROTECTED]
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
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.
Also, do you have the 'auto_detect_line_endings' enabled in your ini
file?
[2003-02-13 16:14:19] [EMAIL PROTECTED]
current (Thu Feb 13 22:00:53 GMT 2003) php-4.3 from CVS compiled as
follows:
./configure --disable-ipv6 --with-config-file-path=/etc/httpd/conf
--enable-memory-limit --disable-display-source --enable-track-var
--with-imap --with-imap-ssl
--with-apxs=/usr/local/apache/current/bin/apxs --with-gd=/usr
--with-jpeg-dir=/usr --with-xpm-dir=/usr/X11R6
--with-mysql=/usr/local/mysql/current --with-curl --enable-ftp
--enable-dbase --enable-xml --with-xml --with-gettext --with-mcrypt
--disable-posix
prevents Apache-1.3.27 from starting (segfault). strace on the CLI
SAPI shows a problem accessing php.ini:
close(3)= 0
brk(0x822c000) = 0x822c000
open("sapi/cli//php-cli.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/httpd/conf/php-cli.ini", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("sapi/cli//php.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/httpd/conf/php.ini", O_RDONLY) = 3
getcwd("/usr/local/src/php-cvs/php4", 4095) = 28
lstat64("/etc", {st_mode=S_IFDIR|0755, st_size=8192, ...}) = 0
lstat64("/etc/httpd", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/etc/httpd/conf", {st_mode=S_IFDIR|0771, st_size=4096, ...}) =
0
lstat64("/etc/httpd/conf/php.ini", {st_mode=S_IFREG|0644, st_size=331,
...}) = 0
brk(0x8231000) = 0x8231000
ioctl(3, 0x5401, 0xbfffca80)= -1 ENOTTY (Inappropriate
ioctl for device)
fstat64(3, {st_mode=S_IFREG|0644, st_size=331, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x40018000
read(3, "register_globals = on\nignore_use"..., 8192) = 331
read(3, "", 4096) = 0
read(3, "", 8192) = 0
ioctl(3, 0x5401, 0xbfffbed0)= -1 ENOTTY (Inappropriate
ioctl for device)
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
The exact same config works fine with plain 4.3 tarball compile.
The system is RedHat 7.2 with autoconf/automake/libtool upgraded to
play nice with PHP/CVS.
The /etc/httpd/conf/php.ini file is as follows:
register_globals = on
ignore_user_abort = on
log_errors = true
#zend_optimizer.optimization_level = 15
#zend_extension = "/usr/local/lib/ZendOptimizer
#22215 [Fbk]: PHP dies while loading php.ini
ID: 22215
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Reproducible crash
Operating System: Linux
-PHP Version: 4CVS-2003-02-13 (stable) / 5CVS-2003-02-14 (dev)
+PHP Version: 4CVS-2003-02-13 (stable) / 5CVS-2003-02-13 (dev)
New Comment:
Sorry, I forgot that I live in a far east area.
Correcting version info.
Previous Comments:
[2003-02-14 13:27:21] [EMAIL PROTECTED]
This bug appears to be yet another bison oddity.
I managed to reproduce with bison 1.875a
Which version of bison are you using?
$ bison --version
[2003-02-14 02:08:58] [EMAIL PROTECTED]
I do _not_ have auto_detect_line_endings enabled in my ini file. The
contents of the file are included in my original report. Backtrace
follows - perhaps this should be a 'scripting engine problem' if it is
a PHP problem.
(gdb) run
Starting program: /usr/local/src/php-cvs/php4/sapi/cli/php
Program received signal SIGSEGV, Segmentation fault.
0x404044fc in memcpy () at memcpy:-1
-1 memcpy: No such file or directory.
in memcpy
(gdb) bt
#0 0x404044fc in memcpy () at memcpy:-1
#1 0xdfffdea5 in ?? ()
#2 0x081258e3 in zend_parse_ini_file (fh=0xbfffd9e0,
unbuffered_errors=1,
ini_parser_cb=0x8112948 , arg=0x821f900)
at /usr/local/src/php-cvs/php4/Zend/zend_ini_parser.y:164
#3 0x08112e99 in php_init_config () at
/usr/local/src/php-cvs/php4/main/php_ini.c:386
#4 0x0810ee9f in php_module_startup (sf=0x821c720,
additional_modules=0x0, num_additional_modules=0)
at /usr/local/src/php-cvs/php4/main/main.c:1104
#5 0x081504c1 in main (argc=1, argv=0xbfffdc84) at
/usr/local/src/php-cvs/php4/sapi/cli/php_cli.c:481
#6 0x40397657 in __libc_start_main (main=0x8150398 , argc=1,
ubp_av=0xbfffdc84, init=0x806a8e4 <_init>,
fini=0x81a0760 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>,
stack_end=0xbfffdc7c)
at ../sysdeps/generic/libc-start.c:129
(gdb)
[2003-02-13 16:19:05] [EMAIL PROTECTED]
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
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.
Also, do you have the 'auto_detect_line_endings' enabled in your ini
file?
[2003-02-13 16:14:19] [EMAIL PROTECTED]
current (Thu Feb 13 22:00:53 GMT 2003) php-4.3 from CVS compiled as
follows:
./configure --disable-ipv6 --with-config-file-path=/etc/httpd/conf
--enable-memory-limit --disable-display-source --enable-track-var
--with-imap --with-imap-ssl
--with-apxs=/usr/local/apache/current/bin/apxs --with-gd=/usr
--with-jpeg-dir=/usr --with-xpm-dir=/usr/X11R6
--with-mysql=/usr/local/mysql/current --with-curl --enable-ftp
--enable-dbase --enable-xml --with-xml --with-gettext --with-mcrypt
--disable-posix
prevents Apache-1.3.27 from starting (segfault). strace on the CLI
SAPI shows a problem accessing php.ini:
close(3)= 0
brk(0x822c000) = 0x822c000
open("sapi/cli//php-cli.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/httpd/conf/php-cli.ini", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("sapi/cli//php.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/httpd/conf/php.ini", O_RDONLY) = 3
getcwd("/usr/local/src/php-cvs/php4", 4095) = 28
lstat64("/etc", {st_mode=S_IFDIR|0755, st_size=8192, ...}) = 0
lstat64("/etc/httpd", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/etc/httpd/conf", {st_mode=S_IFDIR|0771, st_size=4096, ...}) =
0
lstat64("/etc/httpd/conf/php.ini", {st_mode=S_IFREG|0644, st_size=331,
...}) = 0
brk(0x8231000) = 0x8231000
ioctl(3, 0x5401, 0xbfffca80)= -1 ENOTTY (Inappropriate
ioctl for device)
fstat64(3, {st_mode=S_IFREG|0644, st_size=331, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x40018000
read(3, "register_globals = on\nignore_use"..., 8192) = 331
read(3, "", 4096) = 0
read(3, "", 8192) = 0
ioctl(3, 0x5401, 0xbfffbed0)= -1 ENOTTY (Inappropriate
ioctl for device)
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
The exact same config works fine with plain 4.3 tarball compile.
The system is RedHat 7.2 with autoconf/automake/libtool upgraded to
play nice with PHP/CVS.
The /etc/httpd/conf/php.ini file is as follows:
register_globals = on
#22215 [Fbk->Opn]: PHP dies while loading php.ini
ID: 22215
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 4CVS-2003-02-13 (stable) / 5CVS-2003-02-13 (dev)
New Comment:
not quite 1.875a, but close
$ bison --version
bison (GNU Bison) 1.875
Previous Comments:
[2003-02-14 13:31:37] [EMAIL PROTECTED]
Sorry, I forgot that I live in a far east area.
Correcting version info.
[2003-02-14 13:27:21] [EMAIL PROTECTED]
This bug appears to be yet another bison oddity.
I managed to reproduce with bison 1.875a
Which version of bison are you using?
$ bison --version
[2003-02-14 02:08:58] [EMAIL PROTECTED]
I do _not_ have auto_detect_line_endings enabled in my ini file. The
contents of the file are included in my original report. Backtrace
follows - perhaps this should be a 'scripting engine problem' if it is
a PHP problem.
(gdb) run
Starting program: /usr/local/src/php-cvs/php4/sapi/cli/php
Program received signal SIGSEGV, Segmentation fault.
0x404044fc in memcpy () at memcpy:-1
-1 memcpy: No such file or directory.
in memcpy
(gdb) bt
#0 0x404044fc in memcpy () at memcpy:-1
#1 0xdfffdea5 in ?? ()
#2 0x081258e3 in zend_parse_ini_file (fh=0xbfffd9e0,
unbuffered_errors=1,
ini_parser_cb=0x8112948 , arg=0x821f900)
at /usr/local/src/php-cvs/php4/Zend/zend_ini_parser.y:164
#3 0x08112e99 in php_init_config () at
/usr/local/src/php-cvs/php4/main/php_ini.c:386
#4 0x0810ee9f in php_module_startup (sf=0x821c720,
additional_modules=0x0, num_additional_modules=0)
at /usr/local/src/php-cvs/php4/main/main.c:1104
#5 0x081504c1 in main (argc=1, argv=0xbfffdc84) at
/usr/local/src/php-cvs/php4/sapi/cli/php_cli.c:481
#6 0x40397657 in __libc_start_main (main=0x8150398 , argc=1,
ubp_av=0xbfffdc84, init=0x806a8e4 <_init>,
fini=0x81a0760 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>,
stack_end=0xbfffdc7c)
at ../sysdeps/generic/libc-start.c:129
(gdb)
[2003-02-13 16:19:05] [EMAIL PROTECTED]
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
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.
Also, do you have the 'auto_detect_line_endings' enabled in your ini
file?
[2003-02-13 16:14:19] [EMAIL PROTECTED]
current (Thu Feb 13 22:00:53 GMT 2003) php-4.3 from CVS compiled as
follows:
./configure --disable-ipv6 --with-config-file-path=/etc/httpd/conf
--enable-memory-limit --disable-display-source --enable-track-var
--with-imap --with-imap-ssl
--with-apxs=/usr/local/apache/current/bin/apxs --with-gd=/usr
--with-jpeg-dir=/usr --with-xpm-dir=/usr/X11R6
--with-mysql=/usr/local/mysql/current --with-curl --enable-ftp
--enable-dbase --enable-xml --with-xml --with-gettext --with-mcrypt
--disable-posix
prevents Apache-1.3.27 from starting (segfault). strace on the CLI
SAPI shows a problem accessing php.ini:
close(3)= 0
brk(0x822c000) = 0x822c000
open("sapi/cli//php-cli.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/httpd/conf/php-cli.ini", O_RDONLY) = -1 ENOENT (No such file
or directory)
open("sapi/cli//php.ini", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/etc/httpd/conf/php.ini", O_RDONLY) = 3
getcwd("/usr/local/src/php-cvs/php4", 4095) = 28
lstat64("/etc", {st_mode=S_IFDIR|0755, st_size=8192, ...}) = 0
lstat64("/etc/httpd", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/etc/httpd/conf", {st_mode=S_IFDIR|0771, st_size=4096, ...}) =
0
lstat64("/etc/httpd/conf/php.ini", {st_mode=S_IFREG|0644, st_size=331,
...}) = 0
brk(0x8231000) = 0x8231000
ioctl(3, 0x5401, 0xbfffca80)= -1 ENOTTY (Inappropriate
ioctl for device)
fstat64(3, {st_mode=S_IFREG|0644, st_size=331, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x40018000
read(3, "register_globals = on\nignore_use"..., 8192) = 331
read(3, "", 4096) = 0
read(3, "", 8192) = 0
ioctl(3, 0x5401, 0xbfffbed0)= -1 ENOTTY (Inappropriate
ioctl for device)
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
The exact sa
#21809 [Com]: fclose() of socket never returns
ID: 21809
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Sockets related
Operating System: RedHat 7.3
PHP Version: 4CVS-2003-01-22 (stable)
Assigned To: wez
New Comment:
I submitted bug #22099. If it's just a duplicate of this, I'm assuming
you think it's fixed. It's not. Here's a backtrace and I did the same
thing you asked the last guy
to do by printing the contets of frame 2. Got a really
odd result.
#0 0x401c641e in select () from /lib/libc.so.6
#1 0x0819ae24 in __DTOR_END__ ()
#2 0x08122691 in _php_stream_free (stream=0x81ead5c, close_options=3)
at /home/install/php4-STABLE-200302141830/main/streams.c:327
#3 0x080ad213 in zif_fclose (ht=1, return_value=0x81e7a7c,
this_ptr=0x0,
return_value_used=0)
at /home/install/php4-STABLE-200302141830/ext/standard/file.c:1120
#4 0x0815b850 in execute (op_array=0x81da304)
at /home/install/php4-STABLE-200302141830/Zend/zend_execute.c:1596
#5 0x08145b8c in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/install/php4-STABLE-200302141830/Zend/zend.c:864
#6 0x08118f3d in php_execute_script (primary_file=0xba30)
at /home/install/php4-STABLE-200302141830/main/main.c:1582
#7 0x08164700 in main (argc=2, argv=0xbad4)
at /home/install/php4-STABLE-200302141830/sapi/cli/php_cli.c:753
#8 0x401071c4 in __libc_start_main () from /lib/libc.so.6
(gdb) frame 2
#2 0x08122691 in _php_stream_free (stream=0x81ead5c, close_options=3)
at /home/install/php4-STABLE-200302141830/main/streams.c:327
327 ret = stream->ops->close(stream,
preserve_handle ? 0 : 1 TSRMLS_CC);
(gdb) print *stream
Cannot access memory at address 0x0
Previous Comments:
[2003-02-13 20:47:41] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-02-13 08:22:41] [EMAIL PROTECTED]
The select call that ensures all data is flushed to the remote server
never times out.
#22099 is a dup of this bug.
[2003-01-23 12:38:55] [EMAIL PROTECTED]
(gdb) frame 2
#2 0x08147689 in _php_stream_free (stream=0x82598fc, close_options=3)
at /usr/local/src/php4-STABLE-200301220030/main/streams.c:327
327 ret = stream->ops->close(stream,
preserve_handle ? 0 : 1 TSRMLS_CC);
(gdb) print *stream
$2 = {ops = 0x81ee5c0, abstract = 0x824f46c, filterhead = 0x0,
filtertail = 0x0, wrapper = 0x0, wrapperthis = 0x0, wrapperdata =
0x0,
fgetss_state = 0, is_persistent = 0, mode = "r+", '\0' ,
rsrc_id = 4, in_free = 1, fclose_stdiocast = 0, stdiocast = 0x0,
__exposed = 1, __orig_path = 0x0, context = 0x0, flags = 16, position
= 0,
readbuf = 0x8254b9c "", readbuflen = 8192, readpos = 0, writepos =
0,
chunk_size = 8192, eof = 1}
[2003-01-23 03:45:38] [EMAIL PROTECTED]
Could you do that again, but this time type the following after you
type "bt" (also in gdb):
frame 2
print *stream
[2003-01-21 19:01:41] [EMAIL PROTECTED]
I was using 4.3.0 on the machine running the "server" test script (but
since that script is merely to aid in testing the bug in the "client"
script, I didnt think it mattered). The machine running the "client"
script - the one experiencing the bug - was running a stable snapshot
compiled last night. Nontheless, I just re-compiled with the latest
stable today, ran again, and managed to generate a bt in the process:
#0 0x420e19ee in select () from /lib/i686/libc.so.6
#1 0x08204844 in __DTOR_END__ ()
#2 0x08147689 in _php_stream_free (stream=0x82598fc, close_options=3)
at /usr/local/src/php4-STABLE-200301220030/main/streams.c:327
#3 0x080c4f85 in zif_fclose (ht=1, return_value=0x8256f2c,
this_ptr=0x0,
return_value_used=0)
at
/usr/local/src/php4-STABLE-200301220030/ext/standard/file.c:1120
#4 0x08185c8b in execute (op_array=0x8254ac4)
at
/usr/local/src/php4-STABLE-200301220030/Zend/zend_execute.c:1596
#5 0x08173dcc in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/local/src/php4-STABLE-200301220030/Zend/zend.c:864
#6 0x0813c983 in php_execute_script (primary_file=0xbb10)
at /usr/local/src/php4-STABLE-200301220030/main/main.c:1573
#7 0x0818c0a2 in main (argc=2, argv=0xbbb4)
at /usr/local/src/php4-STABLE-200301220030/sapi/cli/php_cli.c:753
#8 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
Hope it helps :)
The
#22218 [Fbk->Csd]: COM function causes PHP crash
ID: 22218
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Closed
Bug Type: COM related
Operating System: Windows 2000
PHP Version: 4.3.0
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
there were sooo many reports regarding this, did you ever consider
reading the bugreports before filing your own ?
Previous Comments:
[2003-02-14 08:30:46] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-02-14 00:36:24] [EMAIL PROTECTED]
One more bit of information... I found this in the event log:
The exception generated was c005 at address 10030727
(php_COM_release)
[2003-02-14 00:31:02] [EMAIL PROTECTED]
I have installed PHP 4.3.0 (as a CGI module) and Apache 2.0.43 in a
Windows 2000 machine. I am updating code that works on an earlier
install and I am able to get most things working.
However, I get a php crash ("php.exe has generated errors and will be
closed by Windows") when I run scripts that use COM do MSXML
validations of an XML document against a schema.
The code works on previous PHP versions set up similarly, but not on
this version.
My code looks like this:
$validate = new COM("Msxml2.DOMDocument.4.0");
$validate->async = "false";
$validate->validateOnParse = "true";
$validate->load($xmldeliveryfile);
$code = $validate->parseError->errorCode;
$reason = $validate->parseError->reason;
It seems to be returning correct values for the error code and reason
before the PHP crash, but then everything goes south. And it seems to
be crashing earlier in the process if I deliberately create an XML
validation error.
And, yes, I do have MSXML4 installed.
Any ideas?
Thanks
--
Edit this bug report at http://bugs.php.net/?id=22218&edit=1
#22226 [NEW]: explode misbehaves exploding empty strings
From: [EMAIL PROTECTED]
Operating system: Win32
PHP version: 4.2.1
PHP Bug Type: Scripting Engine problem
Bug description: explode misbehaves exploding empty strings
This was reported before (bug #8883) as
count(explode("|", "")) == 1
but was stated bogus for some unexplained reason.
The problem is: exploding an empty string returns an array with one empty
element, but should return an empty array instead.
I found this bug to be closed for PHP 3.0.3 (bug #699) with no comment,
but it seems it isn't fixed really?
--
Edit bug report at http://bugs.php.net/?id=6&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=6&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=6&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=6&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=6&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=6&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=6&r=support
Expected behavior: http://bugs.php.net/fix.php?id=6&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=6&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=6&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=6&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=6&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=6&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=6&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=6&r=gnused
#22215 [Opn]: PHP dies while loading php.ini
ID: 22215 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: Linux PHP Version: 4CVS-2003-02-13 (stable) / 5CVS-2003-02-13 (dev) New Comment: That version is know to cause the crash in PHP. Please downgrade to 1.75 or all the way down to 1.28. Previous Comments: [2003-02-14 14:50:23] [EMAIL PROTECTED] not quite 1.875a, but close $ bison --version bison (GNU Bison) 1.875 [2003-02-14 13:31:37] [EMAIL PROTECTED] Sorry, I forgot that I live in a far east area. Correcting version info. [2003-02-14 13:27:21] [EMAIL PROTECTED] This bug appears to be yet another bison oddity. I managed to reproduce with bison 1.875a Which version of bison are you using? $ bison --version [2003-02-14 02:08:58] [EMAIL PROTECTED] I do _not_ have auto_detect_line_endings enabled in my ini file. The contents of the file are included in my original report. Backtrace follows - perhaps this should be a 'scripting engine problem' if it is a PHP problem. (gdb) run Starting program: /usr/local/src/php-cvs/php4/sapi/cli/php Program received signal SIGSEGV, Segmentation fault. 0x404044fc in memcpy () at memcpy:-1 -1 memcpy: No such file or directory. in memcpy (gdb) bt #0 0x404044fc in memcpy () at memcpy:-1 #1 0xdfffdea5 in ?? () #2 0x081258e3 in zend_parse_ini_file (fh=0xbfffd9e0, unbuffered_errors=1, ini_parser_cb=0x8112948 , arg=0x821f900) at /usr/local/src/php-cvs/php4/Zend/zend_ini_parser.y:164 #3 0x08112e99 in php_init_config () at /usr/local/src/php-cvs/php4/main/php_ini.c:386 #4 0x0810ee9f in php_module_startup (sf=0x821c720, additional_modules=0x0, num_additional_modules=0) at /usr/local/src/php-cvs/php4/main/main.c:1104 #5 0x081504c1 in main (argc=1, argv=0xbfffdc84) at /usr/local/src/php-cvs/php4/sapi/cli/php_cli.c:481 #6 0x40397657 in __libc_start_main (main=0x8150398 , argc=1, ubp_av=0xbfffdc84, init=0x806a8e4 <_init>, fini=0x81a0760 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbfffdc7c) at ../sysdeps/generic/libc-start.c:129 (gdb) [2003-02-13 16:19:05] [EMAIL PROTECTED] 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 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. Also, do you have the 'auto_detect_line_endings' enabled in your ini file? 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/22215 -- Edit this bug report at http://bugs.php.net/?id=22215&edit=1
#22215 [Opn]: PHP dies while loading php.ini
ID: 22215 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: Linux PHP Version: 4CVS-2003-02-13 (stable) / 5CVS-2003-02-13 (dev) New Comment: This should make it into http://www.php.net/anoncvs.php for others to know, unless the PHP/Zend team is planning a workaround. The page now says "bison (1.28+)" Thanks Previous Comments: [2003-02-14 16:47:34] [EMAIL PROTECTED] That version is know to cause the crash in PHP. Please downgrade to 1.75 or all the way down to 1.28. [2003-02-14 14:50:23] [EMAIL PROTECTED] not quite 1.875a, but close $ bison --version bison (GNU Bison) 1.875 [2003-02-14 13:31:37] [EMAIL PROTECTED] Sorry, I forgot that I live in a far east area. Correcting version info. [2003-02-14 13:27:21] [EMAIL PROTECTED] This bug appears to be yet another bison oddity. I managed to reproduce with bison 1.875a Which version of bison are you using? $ bison --version [2003-02-14 02:08:58] [EMAIL PROTECTED] I do _not_ have auto_detect_line_endings enabled in my ini file. The contents of the file are included in my original report. Backtrace follows - perhaps this should be a 'scripting engine problem' if it is a PHP problem. (gdb) run Starting program: /usr/local/src/php-cvs/php4/sapi/cli/php Program received signal SIGSEGV, Segmentation fault. 0x404044fc in memcpy () at memcpy:-1 -1 memcpy: No such file or directory. in memcpy (gdb) bt #0 0x404044fc in memcpy () at memcpy:-1 #1 0xdfffdea5 in ?? () #2 0x081258e3 in zend_parse_ini_file (fh=0xbfffd9e0, unbuffered_errors=1, ini_parser_cb=0x8112948 , arg=0x821f900) at /usr/local/src/php-cvs/php4/Zend/zend_ini_parser.y:164 #3 0x08112e99 in php_init_config () at /usr/local/src/php-cvs/php4/main/php_ini.c:386 #4 0x0810ee9f in php_module_startup (sf=0x821c720, additional_modules=0x0, num_additional_modules=0) at /usr/local/src/php-cvs/php4/main/main.c:1104 #5 0x081504c1 in main (argc=1, argv=0xbfffdc84) at /usr/local/src/php-cvs/php4/sapi/cli/php_cli.c:481 #6 0x40397657 in __libc_start_main (main=0x8150398 , argc=1, ubp_av=0xbfffdc84, init=0x806a8e4 <_init>, fini=0x81a0760 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbfffdc7c) at ../sysdeps/generic/libc-start.c:129 (gdb) 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/22215 -- Edit this bug report at http://bugs.php.net/?id=22215&edit=1
#20616 [Com]: 4.3.0RC1-Win32 cannot find files found by 4.2.3
ID: 20616
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Scripting Engine problem
Operating System: Win 2k server
PHP Version: 4.3.0RC1
New Comment:
while testing a third party script that does:
require_once("db/foo.php");
i got an error reporting 'No such file or directory'.
Being under Win OS, i checked to see if
require_once("db\\foo.php");
would work. And it DOES!
Previous Comments:
[2002-12-09 07:50:01] [EMAIL PROTECTED]
I juste tested the latest stable snapshot
(http://snaps.php.net/win32/php4-win32-STABLE-latest.zip) and could not
reproduce the problem using CLI or Apache modules. If the problem
existed it was fixed since RC1.
[2002-12-09 05:31:49] [EMAIL PROTECTED]
Black,
I'm simply calling ../application.php from admin/index.php, there's
nothing else involved. This particular piece of code works fine in
4.2.3
[2002-12-09 05:14:15] [EMAIL PROTECTED]
could you list the directory structure of "used" files..
im mainly interested in the main script, admin/index.php and
application.php.
if the main script is in the same dir as application.php and includes
admin/index.php, then the problem most probablly lies there, since the
include path doesnt change from the main script to its includes..
other than that try downgrading to 4.2.3 just to see if the problem
remains - if yes, then its a script error in your code and not in
php4.3RC2 itself.
[2002-12-09 02:10:12] [EMAIL PROTECTED]
Nope. application.php is in the parent directory, or:
C:\Xitami\webpages\Commerce\mymarket1\application.php
[2002-12-08 22:37:24] [EMAIL PROTECTED]
Some clarification needed..the error you got:
"No such file or directory in
C:\Xitami\webpages\Commerce\mymarket1\admin\index.php on line 8
Warning: Failed opening '../application.php' for inclusion"
In index.php you have 'include("../application.php");' ?
Is the path to "application.php":
C:\Xitami\webpages\Commerce\mymarket1\admin\application.php ???
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/20616
--
Edit this bug report at http://bugs.php.net/?id=20616&edit=1
#20548 [Com]: Decrement ("$x[$y]--") doesn't work on uninitiated variable
ID: 20548 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Verified Bug Type: Scripting Engine problem Operating System: Linux 2.4 PHP Version: 4.3.0RC1 New Comment: I just stumbled across this bug recently with an older version (4.1.1) of PHP on Win32 -- verified that it still exists in 4.3.0. This one had me going in circles trying to debug. Work-arounds: $score[$num] -= 1; or $score[$num] = $score[$num] - 1; Previous Comments: [2002-11-21 12:42:11] [EMAIL PROTECTED] The following: $score[$num]--; does not affect $score[$num] if $score[$num] is uninitiated. Using $score[$num]++ does work, however. This is inconsistent. -- Edit this bug report at http://bugs.php.net/?id=20548&edit=1
#22213 [Com]: Apache mod_ssl + PHP + cURL SSL segfault
ID: 22213
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: cURL related
Operating System: FreeBSD 4.6-STABLE
PHP Version: 4CVS-2003-02-13 (stable)
New Comment:
How about providing a stack trace or something that shows us what was
going on when it crashed?
For information, libcurl calls only two functions to initialize the
OpenSSL library:
SSL_load_error_strings();
SSLeay_add_ssl_algorithms(); (a define for SSL_library_init)
(The rest is done when some action is called for, and this report says
that isn't required for this problem to occur.)
I honestly can't see how this can be wrong from a libcurl point of
view.
Previous Comments:
[2003-02-14 08:41:39] [EMAIL PROTECTED]
Regarding notes/issues raised on bug #22112:
I made sure that apache is linking against only one copy of libssl and
libcrypto.
We have a global ErrorLog directive in the httpd.conf we're testing
with, but no VirtualHost blocks at all: it's a base conf file, and the
server doesn't even need to serve any pages for this to be a problem
for us.
Our httpd.conf conditionally turns on SSL only when the "-DSSL" flag is
present. When apache is run without that flag, it works without any
problems. It crashes only when SSL is running.
("SSLEngine on" only happens with -DSSL)
Thanks.
[2003-02-14 08:33:47] [EMAIL PROTECTED]
The configure command:
./configure --with-apache=/usr/pair/sw/apachessl_1.3.27
--with-config-file-path=/usr/local/etc --enable-magic-quotes
--enable-bcmath --without-cdb --with-zlib-dir=/usr/local --with-gd
--without-ttf --without-msql --with-mysql=/usr/local --with-iodbc
--with-pdflib --enable-inline-optimization --disable-memory-limit
--with-db --without-gdbm --with-ndbm --without-db2 --without-dbm
--with-gettext --without-readline --with-recode
--with-openssl=/usr/local/ssl --with-mcrypt --without-db3 --enable-dba
--with-curl=/usr/local/lib --with-png-dir=/usr/local/lib
Compiling without "--with-curl" fixes the bug. Compiling curl
"--without-ssl" also does the trick.
[2003-02-13 19:22:22] [EMAIL PROTECTED]
And the full configure line used to configure php was..?
[2003-02-13 16:17:05] [EMAIL PROTECTED]
This bug could be related to bug #22112.
[2003-02-13 15:56:40] [EMAIL PROTECTED]
I've reproduced this bug with PHP versions 4.2.2, and the STABLE PHP
dated Feb 13, 2003.
FreeBSD 4.6-stable
PHP 4.2.2 --with-curl
curl --with-ssl, versions 7.9.8 and 7.10.3
Apache 1.3.27 mod_ssl
OpenSSL 0.9.7, and a variety of flavors of 0.9.6.
To reproduce the bug:
* start apache
* send a HUP signal to apache's parent process (to restart it)
The server needn't serve any pages (php or otherwise) before the HUP is
sent. Apache crashes, I believe while trying to reinitialize the
mod_ssl module.
Running the same version of everything, but curl compiled
--without-ssl
makes it work correctly: the apache parent kills off its children and
spawns new ones without the parent segfaulting.
It seems to be dying inside SSL_CTX_ctrl (via SSL_CTX_set_options) when
called from apache's ssl_init_ConfigureServer, at this line:
SSL_CTX_set_options(ctx, SSL_OP_ALL);
Unfortunately, by the time it segfaults, the stack has been corrupted,
and it gets really difficult to debug.
Alan
--
Edit this bug report at http://bugs.php.net/?id=22213&edit=1
#21809 [Fbk->Opn]: fclose() of socket never returns
ID: 21809
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Sockets related
Operating System: RedHat 7.3
-PHP Version: 4CVS-2003-01-22 (stable)
+PHP Version: 4CVS-2003-02-14 (stable)
Assigned To: wez
New Comment:
My script still stalls. Here's a new bt:
#0 0x420d3b2e in select () from /lib/i686/libc.so.6
#1 0x081a077c in __JCR_LIST__ ()
#2 0x0811482b in _php_stream_free (stream=0xbfffb940,
close_options=3)
at /usr/local/src/php4-STABLE-200302141830/main/streams.c:327
#3 0x080b95ee in zif_fclose (ht=1, return_value=0x81f4514,
this_ptr=0x0,
return_value_used=0)
at
/usr/local/src/php4-STABLE-200302141830/ext/standard/file.c:1120
#4 0x0813dc5a in execute (op_array=0x81ef52c)
at
/usr/local/src/php4-STABLE-200302141830/Zend/zend_execute.c:1596
#5 0x08131595 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/local/src/php4-STABLE-200302141830/Zend/zend.c:864
#6 0x0810c79c in php_execute_script (primary_file=0xbfffe1f0)
at /usr/local/src/php4-STABLE-200302141830/main/main.c:1582
#7 0x0814255f in main (argc=2, argv=0xbfffe274)
at /usr/local/src/php4-STABLE-200302141830/sapi/cli/php_cli.c:753
#8 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) frame 2
#2 0x0811482b in _php_stream_free (stream=0xbfffb940,
close_options=3)
at /usr/local/src/php4-STABLE-200302141830/main/streams.c:327
327 ret = stream->ops->close(stream,
preserve_handle ? 0 : 1 TSRMLS_CC);
(gdb) print *stream
$1 = {ops = 0x10, abstract = 0x0, filterhead = 0x0, filtertail = 0x0,
wrapper = 0x0, wrapperthis = 0x0, wrapperdata = 0x0, fgetss_state =
0,
is_persistent = 0, mode = '\0' , rsrc_id = 0,
in_free = 0,
fclose_stdiocast = 0, stdiocast = 0x0, context = 0x0, flags = 0,
position = 0, readbuf = 0x0, readbuflen = 0, readpos = 0, writepos =
0,
chunk_size = 0, eof = 0}
Previous Comments:
[2003-02-14 15:12:02] [EMAIL PROTECTED]
I submitted bug #22099. If it's just a duplicate of this, I'm assuming
you think it's fixed. It's not. Here's a backtrace and I did the same
thing you asked the last guy
to do by printing the contets of frame 2. Got a really
odd result.
#0 0x401c641e in select () from /lib/libc.so.6
#1 0x0819ae24 in __DTOR_END__ ()
#2 0x08122691 in _php_stream_free (stream=0x81ead5c, close_options=3)
at /home/install/php4-STABLE-200302141830/main/streams.c:327
#3 0x080ad213 in zif_fclose (ht=1, return_value=0x81e7a7c,
this_ptr=0x0,
return_value_used=0)
at /home/install/php4-STABLE-200302141830/ext/standard/file.c:1120
#4 0x0815b850 in execute (op_array=0x81da304)
at /home/install/php4-STABLE-200302141830/Zend/zend_execute.c:1596
#5 0x08145b8c in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/install/php4-STABLE-200302141830/Zend/zend.c:864
#6 0x08118f3d in php_execute_script (primary_file=0xba30)
at /home/install/php4-STABLE-200302141830/main/main.c:1582
#7 0x08164700 in main (argc=2, argv=0xbad4)
at /home/install/php4-STABLE-200302141830/sapi/cli/php_cli.c:753
#8 0x401071c4 in __libc_start_main () from /lib/libc.so.6
(gdb) frame 2
#2 0x08122691 in _php_stream_free (stream=0x81ead5c, close_options=3)
at /home/install/php4-STABLE-200302141830/main/streams.c:327
327 ret = stream->ops->close(stream,
preserve_handle ? 0 : 1 TSRMLS_CC);
(gdb) print *stream
Cannot access memory at address 0x0
[2003-02-13 20:47:41] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-02-13 08:22:41] [EMAIL PROTECTED]
The select call that ensures all data is flushed to the remote server
never times out.
#22099 is a dup of this bug.
[2003-01-23 12:38:55] [EMAIL PROTECTED]
(gdb) frame 2
#2 0x08147689 in _php_stream_free (stream=0x82598fc, close_options=3)
at /usr/local/src/php4-STABLE-200301220030/main/streams.c:327
327 ret = stream->ops->close(stream,
preserve_handle ? 0 : 1 TSRMLS_CC);
(gdb) print *stream
$2 = {ops = 0x81ee5c0, abstract = 0x824f46c, filterhead = 0x0,
filtertail = 0x0, wrapper = 0x0, wrapperthis = 0x0, wrapperdata =
0x0,
fgetss_state = 0, is_persistent = 0, mode = "r+", '\0' ,
rsrc_id = 4, in_free = 1, fclose_stdiocast = 0, stdiocast = 0x0,
__exposed = 1, __orig_path = 0x0, context = 0x0, flags = 16, position
= 0,
readbuf = 0x8254b9c "", readbuflen = 8192, readpos = 0, writepos =
0,
chunk_size = 8192, eof
#21479 [Fbk->Opn]: Crashes with 6 slashes in URL and non-existant file
ID: 21479 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: GetImageSize related Operating System: Win 2000 IIS (CGI) PHP Version: 4.3.0 New Comment: non of the dlls in the c:\php\dlls\ directory exists in win\system32 or win\system so there is nothing to overwrite - it is always using the dlls in c:\php\dlls. is there any other file(s) i have to overwrite? i never had to do this when installing php, and i can't find anything about this (besides the above dlls) in install.txt in the snapshot zip file. Previous Comments: [2003-02-14 11:33:08] [EMAIL PROTECTED] And did you replace all files in your system or system32 directory ? [2003-02-14 00:59:53] [EMAIL PROTECTED] yes i renamed c:\php to something else, and unzipped the snapshot into a new c:\php, then rebooted - still crashing as described above. [2003-02-12 22:00:52] [EMAIL PROTECTED] Please make sure you've really replaced ALL the old dlls with the new ones from the snapshot package! Especially the php4ts.dll file. Easiest way to make sure you do this is to delete all the old files first. And sometimes a reboot is needed too..(reported by others) [2003-02-12 11:44:07] [EMAIL PROTECTED] it still crashes, the only difference is - with php 4.3.1 the php.exe application error message i get is: The instruction at "0x77fcb9f8" referenced memory at "0x00e4803a". The memory could not be "written". with php 4.3.0 the php.exe application error message i get is: The instruction at "0x77fcb9f8" referenced memory at "0x00e2703a". The memory could not be "written". [2003-02-10 19:26:11] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip I cannot replicate the bug using Windows XP + PHP 4.3.1-dev. 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/21479 -- Edit this bug report at http://bugs.php.net/?id=21479&edit=1
#22227 [NEW]: printf() field limiters broke between 4.2.3 and 4.3.0
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.3.0
PHP Bug Type: Output Control
Bug description: printf() field limiters broke between 4.2.3 and 4.3.0
Witness the following code:
printf( "PHP Version=%s\n", phpversion() );
print "Output should be [abc] in all cases\n";
$masks = Array( "%-3.3s", "%.3s", "%-.3s" );
$str = "abcdefg";
foreach ( $masks as $mask ) {
printf( "[$mask] <-- %s\n", $str, $mask );
}
Under 4.2.3 we get:
PHP Version=4.2.3
Output should be [abc] in all cases
[abc] <-- %-3.3s
[abc] <-- %.3s
[abc] <-- %-.3s
Under 4.3.0 we get:
PHP Version=4.3.0
Output should be [abc] in all cases
[abcdefg] <-- %-3.3s
[abc] <-- %.3s
[abc] <-- %-.3s
This breaks a TON of column-formatting code for our application. We're
reverting to 4.2.3 until this is fixed.
The test suite in ext/standard/tests/general_functions/001.phpt does not
test that specific combination of width & precision.
--
Edit bug report at http://bugs.php.net/?id=7&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=7&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=7&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=7&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=7&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=7&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=7&r=support
Expected behavior: http://bugs.php.net/fix.php?id=7&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=7&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=7&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=7&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=7&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=7&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=7&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=7&r=gnused
#22228 [NEW]: ob_get_status with bool_argument crashes with Apache 1.3.22
From: [EMAIL PROTECTED] Operating system: Win2K SP3 PHP version: 4.2.3 PHP Bug Type: Reproducible crash Bug description: ob_get_status with bool_argument crashes with Apache 1.3.22 ob_get_status() works but ob_get_status(true) crashes with Apache on Win2K SP3 -- Edit bug report at http://bugs.php.net/?id=8&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=8&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=8&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=8&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=8&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=8&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=8&r=support Expected behavior: http://bugs.php.net/fix.php?id=8&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=8&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=8&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=8&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=8&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=8&r=dst IIS Stability: http://bugs.php.net/fix.php?id=8&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=8&r=gnused
#22052 [Com]: Ftp ftp_rawlist,ftp_nlist broken
ID: 22052 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: FTP related Operating System: FreeBSD 5.0-RELEASE #0 PHP Version: 4.3.1-dev Assigned To: pollita New Comment: pollita, I patched the file and recompiled. The simple script you gave me returned 0 results in web mode.(via httpd).A more complex script in Cli mode actually produced the best results (lengthy): http://www.kelvinbeats.com/pollita/ Previous Comments: [2003-02-14 11:27:24] [EMAIL PROTECTED] still broken using php4-STABLE-200302141630.tar.bz2 (the latest snap). [2003-02-13 20:11:07] [EMAIL PROTECTED] excellent, expect some results by 9:00am PMT. [2003-02-13 20:09:16] [EMAIL PROTECTED] Okay, great... I believe I've got the problem nailed down, I just need the results of using that updated snapshot to be 100% certain. In the meantime I'll start putting together the patch and with luck this should be working by this time tomorrow. [2003-02-13 18:54:22] [EMAIL PROTECTED] the tmpfile(); test works without flaw. [2003-02-13 17:33:48] [EMAIL PROTECTED] I have a feeling, at this point, that while the new snapshot will stop your segfault, it'll still not behave in the way you expect it to. Try this seemingly unrelated script via your httpd server: Ideally you should see "This is a test" in your browser... if notwell... does it show an error? 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/22052 -- Edit this bug report at http://bugs.php.net/?id=22052&edit=1
#22229 [NEW]: binding (-b) fastcgi produces a segfault
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.7-RELEASE-p1 PHP version: 4CVS-2003-02-14 (stable) PHP Bug Type: Other web server Bug description: binding (-b) fastcgi produces a segfault CFLAGS=-g ./configure --enable-fastcgi make cd sapi/cgi ./php -b 1234 zsh: 35201 segmentation fault (core dumped) ./php -b 1234 this shouldn't be. gdb ./php GNU gdb 4.18 (FreeBSD) Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 2627 in elfstab_build_psymtabs Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 933 in fill_symbuf (gdb) run -b 1234 Starting program: /usr/home/greg/sources/apache/php4-STABLE-200302150030/sapi/cgi/./php -b 1234 Program received signal SIGSEGV, Segmentation fault. 0x2823f5b0 in strdup () from /usr/lib/libc.so.4 (gdb) bt #0 0x2823f5b0 in strdup () from /usr/lib/libc.so.4 #1 0x8159f40 in main (argc=3, argv=0xbfbffb0c) at /usr/home/greg/sources/apache/php4-STABLE-200302150030/sapi/cgi/cgi_main.c:976 #2 0x8060c51 in _start () (gdb) line 976 says: if (!fastcgi) bindpath= strdup(ap_php_optarg); with my poor c knowledge I don't know what wrong. But some lines above is a similar construct: cgi_sapi_module.php_ini_path_override = strdup(ap_php_optarg); HTH greg -- Edit bug report at http://bugs.php.net/?id=9&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=9&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=9&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=9&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=9&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=9&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=9&r=support Expected behavior: http://bugs.php.net/fix.php?id=9&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=9&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=9&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=9&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=9&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=9&r=dst IIS Stability: http://bugs.php.net/fix.php?id=9&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=9&r=gnused
#22052 [Asn]: Ftp ftp_rawlist,ftp_nlist broken
ID: 22052 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: FTP related Operating System: FreeBSD 5.0-RELEASE #0 PHP Version: 4.3.1-dev Assigned To: pollita New Comment: So after browsing via httpd there was absolutely nothing in /etc/22052.log ? And only after running via CLI did items appear? The log results I'm seeing suggest there was a segfault (or other failure to complete) during the second call (the NLST command was sent but no successful response was received) and several immediate failures at the end. I think in order to fully diagnose this I'll have to install FreeBSD 5.0 locally so that I can run deeper tests myself. This means the fix won't make it into 4.3.1, but it should be ready well before 4.3.2 and you can pick it up in a snapshot at any time after I find and fix the problem. Previous Comments: [2003-02-14 20:16:53] [EMAIL PROTECTED] pollita, I patched the file and recompiled. The simple script you gave me returned 0 results in web mode.(via httpd).A more complex script in Cli mode actually produced the best results (lengthy): http://www.kelvinbeats.com/pollita/ [2003-02-14 11:27:24] [EMAIL PROTECTED] still broken using php4-STABLE-200302141630.tar.bz2 (the latest snap). [2003-02-13 20:11:07] [EMAIL PROTECTED] excellent, expect some results by 9:00am PMT. [2003-02-13 20:09:16] [EMAIL PROTECTED] Okay, great... I believe I've got the problem nailed down, I just need the results of using that updated snapshot to be 100% certain. In the meantime I'll start putting together the patch and with luck this should be working by this time tomorrow. [2003-02-13 18:54:22] [EMAIL PROTECTED] the tmpfile(); test works without flaw. 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/22052 -- Edit this bug report at http://bugs.php.net/?id=22052&edit=1
#22230 [NEW]: libtool linking fails
From: [EMAIL PROTECTED] Operating system: Solaris 8 PHP version: 4.3.0 PHP Bug Type: Compile Failure Bug description: libtool linking fails Compiling PHP as a static apache module with the following command: ./configure --with-apache=../apache_1.3.27 --with-pgsql=/data/postgres Configure runs fine, and the build runs fine up until the final link where it calls libtool with an insane number of link objects. The link fails because it looks like the command line is too long for libtool to handle, giving the error: gcc: main/all: No such file or directory make: *** [sapi/cli/php] Error 1 main/all is actually a fragment of the libtool command line, several thousand characters into the command line, which leads me to suspect the libtool command line is far too long. The libtool line that fails is this: /bin/sh libtool --silent --mode=link gcc -export-dynamic -g -O2 -L/usr/ucblib L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2.2 -L/data/postgres/lib -R /us /ucblib -R /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2.2 -R /data/postgres/ ib ext/ctype/ctype.lo ext/mysql/php_mysql.lo ext/mysql/libmysql/libmysql.lo ext mysql/libmysql/errmsg.lo ext/mysql/libmysql/net.lo ext/mysql/libmysql/violite.l ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_init.lo ext/mysql/libmysq /my_lib.lo ext/mysql/libmysql/my_static.lo ext/mysql/libmysql/my_malloc.lo ext/ ysql/libmysql/my_realloc.lo ext/mysql/libmysql/my_create.lo ext/mysql/libmysql/ y_delete.lo ext/mysql/libmysql/my_tempnam.lo ext/mysql/libmysql/my_open.lo ext/ ysql/libmysql/mf_casecnv.lo ext/mysql/libmysql/my_read.lo ext/mysql/libmysql/my write.lo ext/mysql/libmysql/errors.lo ext/mysql/libmysql/my_error.lo ext/mysql/ ibmysql/my_getwd.lo ext/mysql/libmysql/my_div.lo ext/mysql/libmysql/mf_pack.lo xt/mysql/libmysql/my_messnc.lo ext/mysql/libmysql/mf_dirname.lo ext/mysql/libmy ql/mf_fn_ext.lo ext/mysql/libmysql/mf_wcomp.lo ext/mysql/libmysql/typelib.lo ex /mysql/libmysql/safemalloc.lo ext/mysql/libmysql/my_alloc.lo ext/mysql/libmysql mf_format.lo ext/mysql/libmysql/mf_path.lo ext/mysql/libmysql/mf_unixpath.lo ex /mysql/libmysql/my_fopen.lo ext/mysql/libmysql/mf_loadpath.lo ext/mysql/libmysq /my_pthread.lo ext/mysql/libmysql/my_thr_init.lo ext/mysql/libmysql/thr_mutex.l ext/mysql/libmysql/mulalloc.lo ext/mysql/libmysql/string.lo ext/mysql/libmysql default.lo ext/mysql/libmysql/my_compress.lo ext/mysql/libmysql/array.lo ext/my ql/libmysql/my_once.lo ext/mysql/libmysql/list.lo ext/mysql/libmysql/my_net.lo xt/mysql/libmysql/dbug.lo ext/mysql/libmysql/strmov.lo ext/mysql/libmysql/strxm v.lo ext/mysql/libmysql/strnmov.lo ext/mysql/libmysql/strmake.lo ext/mysql/libm sql/strend.lo ext/mysql/libmysql/strfill.lo ext/mysql/libmysql/is_prefix.lo ext mysql/libmysql/int2str.lo ext/mysql/libmysql/str2int.lo ext/mysql/libmysql/stri str.lo ext/mysql/libmysql/strcont.lo ext/mysql/libmysql/strcend.lo ext/mysql/li mysql/bchange.lo ext/mysql/libmysql/bmove.lo ext/mysql/libmysql/bmove_upp.lo ex /mysql/libmysql/longlong2str.lo ext/mysql/libmysql/strtoull.lo ext/mysql/libmys l/strtoll.lo ext/mysql/libmysql/charset.lo ext/mysql/libmysql/ctype.lo ext/over oad/overload.lo ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo ext/pcre pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo ext/pgsql/pgsql. o ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo ext/sessio /mod_mm.lo ext/session/mod_user.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo xt/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/s andard/dir.lo ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/s andard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo ext/standa d/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo ext/standard/ht l.lo ext/standard/image.lo ext/standard/info.lo ext/standard/iptc.lo ext/standa d/lcg.lo ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo ext/sta dard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo ext/standard/pa k.lo ext/standard/pageinfo.lo ext/standard/parsedate.lo ext/standard/quot_print lo ext/standard/rand.lo ext/standard/reg.lo ext/standard/soundex.lo ext/standar /string.lo ext/standard/scanf.lo ext/standard/syslog.lo ext/standard/type.lo ex /standard/uniqid.lo ext/standard/url.lo ext/standard/url_scanner.lo ext/standar /var.lo ext/standard/versioning.lo ext/standard/assert.lo ext/standard/strnatcm .lo ext/standard/levenshtein.lo ext/standard/incomplete_class.lo ext/standard/u l_scanner_ex.lo ext/standard/ftp_fopen_wrapper.lo ext/standard/http_fopen_wrapp r.lo ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo ext/standard/css lo ext/standard/var_unserializer.lo ext/standard/ftok.lo ext/standard/aggregati n.lo ext/standard/sha1.lo ext/tokenizer/tokenizer.lo ext/xml/xml.lo ext/xml/exp t/xmlparse.lo ext/xml
#22228 [Opn->Ver]: ob_get_status with bool_argument crashes with Apache 1.3.22
ID: 8 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Verified Bug Type: Reproducible crash -Operating System: Win2K SP3 +Operating System: Win2K SP3 / Linux -PHP Version: 4.2.3 +PHP Version: 4CVS-2003-02-14 (stable) / 5cvs-2003-02-14 (dev) New Comment: verified Previous Comments: [2003-02-14 19:19:05] [EMAIL PROTECTED] ob_get_status() works but ob_get_status(true) crashes with Apache on Win2K SP3 -- Edit this bug report at http://bugs.php.net/?id=8&edit=1
