#20209 [NEW]: appending text nodes leads to segfaults sometimes
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4CVS-2002-11-01 PHP Bug Type: DOM XML related Bug description: appending text nodes leads to segfaults sometimes if a text_node is appended to a node, then it can lead to segfaults if the last child of the node is also a text-node. this is because libxml2 frees then the node. (from their docu: Add a new node to parent, at the end of the child (or property) list merging adjacent TEXT nodes (in which case cur is freed) If the new node was already inserted in a document it is first unlinked from its existing context. If the new node is ATTRIBUTE, it is added into properties instead of children. If there is an attribute with equal name, it is first destroyed.) and we don't... I'll try to find a solution chregu -- Edit bug report at http://bugs.php.net/?id=20209edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20209r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20209r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20209r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20209r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20209r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20209r=support Expected behavior: http://bugs.php.net/fix.php?id=20209r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20209r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20209r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20209r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20209r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20209r=dst IIS Stability: http://bugs.php.net/fix.php?id=20209r=isapi
#20209 [Opn-Ana]: appending text nodes leads to segfaults sometimes
ID: 20209 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed Bug Type: DOM XML related Operating System: linux PHP Version: 4CVS-2002-11-01 -Assigned To: +Assigned To: chregu Previous Comments: [2002-11-01 03:31:36] [EMAIL PROTECTED] if a text_node is appended to a node, then it can lead to segfaults if the last child of the node is also a text-node. this is because libxml2 frees then the node. (from their docu: Add a new node to parent, at the end of the child (or property) list merging adjacent TEXT nodes (in which case cur is freed) If the new node was already inserted in a document it is first unlinked from its existing context. If the new node is ATTRIBUTE, it is added into properties instead of children. If there is an attribute with equal name, it is first destroyed.) and we don't... I'll try to find a solution chregu -- Edit this bug report at http://bugs.php.net/?id=20209edit=1
#20206 [Opn-Bgs]: escape the escape char in preg_replace
ID: 20206 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *Regular Expressions Operating System: win2k sp3 PHP Version: 4.2.2 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 Check your regex pattern again. Two leading backslashes will escape *. Previous Comments: [2002-11-01 01:46:39] [EMAIL PROTECTED] line 3 also missed a '/' :( $_SESSION[l] = 'c/c++'; $_SESSION[l] = preg_replace(/\\*\//,\/,$_SESSION[l]); $_SESSION[l] = preg_replace(/\\*\+/,\+,$_SESSION[l]); [2002-11-01 01:43:41] [EMAIL PROTECTED] sorry, a typo in the second line of code $_SESSION[l] = preg_replace(/\\*\//,\/,$_SESSION[l]); i missed a '/'. [2002-10-31 21:38:57] [EMAIL PROTECTED] let say: $_SESSION[l] = 'c/c++'; $_SESSION[l] = preg_replace(/\\*\/,\/,$_SESSION[l]); $_SESSION[l] = preg_replace(/\\*\+,\+,$_SESSION[l]); what i expect is no matter how the user reload the page $_SESSION[l] should be 'c\/c\+\+' i used the reg exp in perl and tried it out, seems logically correct, but it cause an error in my php page. thx for your attention -- Edit this bug report at http://bugs.php.net/?id=20206edit=1
#20209 [Ana-Csd]: appending text nodes leads to segfaults sometimes
ID: 20209 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Analyzed +Status: Closed Bug Type: DOM XML related Operating System: linux PHP Version: 4CVS-2002-11-01 Assigned To: chregu 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: [2002-11-01 03:31:36] [EMAIL PROTECTED] if a text_node is appended to a node, then it can lead to segfaults if the last child of the node is also a text-node. this is because libxml2 frees then the node. (from their docu: Add a new node to parent, at the end of the child (or property) list merging adjacent TEXT nodes (in which case cur is freed) If the new node was already inserted in a document it is first unlinked from its existing context. If the new node is ATTRIBUTE, it is added into properties instead of children. If there is an attribute with equal name, it is first destroyed.) and we don't... I'll try to find a solution chregu -- Edit this bug report at http://bugs.php.net/?id=20209edit=1
#19404 [Com]: phpMyAdmin does not work properly anymore
ID: 19404 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: mbstring related Operating System: SuSE Linux 8.0 PHP Version: 4.2.3 New Comment: Is it fixed in STABLE CVS or LATEST CVS? Also how come there are comments here like in other languages and OT comments like i want to make a good forum for my homepage Previous Comments: [2002-10-31 20:13:55] [EMAIL PROTECTED] Úíæä ÇáßæíÊ [2002-10-31 13:16:43] [EMAIL PROTECTED] 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. [2002-10-31 12:07:09] [EMAIL PROTECTED] This bug was fixed long time ago in CVS. Stop posting any more comments here. Thank you. [2002-10-31 10:10:37] [EMAIL PROTECTED] Got the same error (first four characters left off strings) using another (not phpMyAdmin) script on: FreeBSD with PHP (4.2.3) and MySQL (3.23.52) Looks like a PHP/MySQL bug, not phpMyAdmin. [2002-10-27 23:32:45] [EMAIL PROTECTED] Hi Fernando.. do you have the problem yet? if you like, write me to my email and i can help you... (i´m in Colombia too, i´m writing in english for the forum) :) Byron H. [EMAIL PROTECTED] 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/19404 -- Edit this bug report at http://bugs.php.net/?id=19404edit=1
#20200 [Bgs]: configure of apache fails after php-compilation
ID: 20200 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *Compile Issues Operating System: SuSE 8,0 or RedHat 7.3 PHP Version: 4.2.1 New Comment: For me I do not nned Support! I got today such a mail from php-support. I know how to fix this bug every time for my self. But perhaps the configure or the make of php can fix this, so that the nex php-version is able to configure and compile in apache without editing the source of the php-mudule by hand. Previous Comments: [2002-10-31 21:32:59] [EMAIL PROTECTED] 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. [2002-10-31 13:57:44] [EMAIL PROTECTED] Hi, I do the following: I extract apache 1.3.26, an make a configure with default seiings an a make, then I apply mod-ssl and mod_perl. Then i configure and make php 4.2.1 with these options: ./configure \ --prefix=/usr/local/php4/4.2.1/ \ --with-apache=/usr/local/src/lamp/apache_1.3.26 \ --enable-force-cgi-redirect \ --disable-debug \ --enable-dbg=shared \ --with-dbg-profiler \ --enable-pic \ --disable-rpath \ --enable-inline-optimization \ --with-bz2 \ --with-db3 \ --with-curl \ --with-dom=/usr \ --with-freetype-dir=/usr \ --with-png-dir=/usr \ --with-gd \ --enable-gd-native-ttf \ --with-ttf \ --with-gdbm \ --with-gettext \ --with-ncurses \ --with-gmp \ --with-iconv \ --with-jpeg-dir=/usr \ --with-mm \ --with-openssl \ --with-png \ --with-pspell \ --with-regex=system \ --with-xml \ --with-expat-dir=/usr \ --with-zlib \ --with-layout=GNU \ --enable-bcmath \ --enable-debugger \ --enable-exif \ --enable-ftp \ --enable-magic-quotes \ --enable-safe-mode \ --enable-sockets \ --enable-sysvsem \ --enable-sysvshm \ --enable-discard-path \ --enable-track-vars \ --enable-trans-sid \ --enable-yp \ --enable-wddx \ --without-oci8 \ --with-imap=shared \ --with-imap-ssl \ --with-kerberos=/usr/kerberos \ --with-mysql=shared,/usr/local/mysql/current/ \ --with-snmp=shared,/usr \ --with-snmp=shared \ --enable-ucd-snmp-hack \ --with-unixODBC=shared \ --enable-memory-limit \ --enable-bcmath \ --enable-shmop \ --enable-versioning \ --enable-calendar \ --enable-dbx \ --enable-dio \ --enable-mcal \ --enable-mbstring \ --enable-mbstr-enc-trans \ --with-recode=/usr \ --with-xpm-dir=/usr/X11R6 \ --with-zip this works on comfigure and on make apter that I start a configure of the apache with this: EAPI_MM=SYSTEM SSL_BASE=/usr ./configure \ --activate-module=src/modules/perl/libperl.a \ --activate-module=src/modules/php4/libphp4.a \ --prefix=/home/boerns/usr/local/apache/ \ --enable-module=rewrite \ --enable-module=unique_id \ --enable-module=speling \ --enable-module=expires \ --enable-module=info \ --enable-module=log_agent \ --enable-module=log_referer \ --enable-module=usertrack \ --enable-module=userdir \ --enable-module=so \ --enable-shared=ssl \ --enable-module=ssl while running configure i get this: Configuring for Apache, Version 1.3.26 + using installation path layout: Apache (config.layout) + activated perl module (modules/perl/libperl.a) + activated php4 module (modules/php4/libphp4.a) Creating Makefile Creating Configuration.apaci in src Creating Makefile in src + configured for Linux platform + setting C compiler to gcc + setting C pre-processor to gcc -E + checking for system header files + adding selected modules o rewrite_module uses ConfigStart/End + using -lndbm for DBM support enabling DBM support for mod_rewrite o ssl_module uses ConfigStart/End + SSL interface: mod_ssl/2.8.9 + SSL interface build type: DSO + SSL interface compatibility: enabled + SSL interface experimental code: disabled + SSL interface conservative code: disabled + SSL interface vendor extensions: disabled + SSL interface plugin: Built-in SDBM + SSL library path: /usr + SSL library version: OpenSSL 0.9.6c [engine] 21 dec 2001 + SSL library type: installed package (stand-alone) o php4_module uses ConfigStart/End + enabling Extended API (EAPI) using MM library for EAPI: (system-wide) + using system Expat + using -ldl for vendor DSO support + checking sizeof various data types + doing sanity check on compiler and options ** A test compilation with your Makefile configuration ** failed. The below error output from the compilation ** test will give you an idea what is failing. Note that ** Apache requires an ANSI C Compiler, such as gcc.
#20202 [Opn-Bgs]: Form elements id Attrbute Ignored
ID: 20202 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: WinXP SP1 PHP Version: 4.2.2 New Comment: Okay then, not a error/problem in PHP so we mark this as bogus. Derick Previous Comments: [2002-10-31 18:50:55] [EMAIL PROTECTED] OK so, I trace Moziila 1.1beta Win32 with HTTPTrace 2.0 and indeed you were right , when only the id attribe is set mozilla does not send the content of the element. Unfortunately the program did not work with the other browser but I suspet the same issue is involved. For information I tested : Moziila 1.1b, Opera 6.01, Amaya 6.4 and Internet Explorer 6.0 SP1 on Win32 and Mozilla 1.0, Lynx and Links, Konqueror on Linux. Every browser reported the error but acted differently some time . IE6 for exmple did not even report the PHP error message as Mozilla did. The XHTML 1.0/1.1 still accept the name attribute as does XHTML Basic but I do believe that UA developpers should correct this issue for the future [2002-10-31 14:48:55] [EMAIL PROTECTED] This is up to the browser to do. Did you verify with a line sniffer / network tracer to see what happened? My bet is that the browser didn't send the data correctly, and of course PHP doesn't record it then. Derick [2002-10-31 14:46:26] [EMAIL PROTECTED] W3C Specs page about id attribute in XHTML 1.0 is at http://www.w3.org/TR/xhtml1/#h-4.10 [2002-10-31 14:36:20] [EMAIL PROTECTED] PHP seems to ignore the id attribute given to form elements. It just consider the name attribute So while a element like input type=text name=first_name / will create a $_post[first_name] variable if submitted, for exemple, the similar tag input type=text id=first_name / will not create any variable. The problem is that in the XHTML 1.0 W3C specs the name attribute is depreached in favor of id. This could cause problems in the near future where XHTML whill be more widespread. It would be appreciated if the id attribute handling is added to future PHP releases. Info: I installed PHP on my WinXP SP1 for use with IIS using the included installer and use all the default choices. My inst -- Edit this bug report at http://bugs.php.net/?id=20202edit=1
#20210 [NEW]: Hash in urldata
From: [EMAIL PROTECTED] Operating system: Red Hat linux 7.3 PHP version: 4.2.0 PHP Bug Type: *General Issues Bug description: Hash in urldata http://localhost/editaccount.php?UID=1Email=##;localhost http://localhost/editaccount.php?UID=1Email=%23%23;localhost These two urls points to the same thing. The first one is generated by mozilla (uri's are normally escaped by the browser if nescesarry). The variabel Email appears emtpy, and the my script then fails and shit :-/ If I escape the url manually to the second one, php is happy and the Email variabel is set to a value :-) In both cases, isset($Email) and is_string($Email) returned true. I also tested this: http://localhost/editaccount.php?UID=1Email=test##;localhost and Email was set to test Stian -- Edit bug report at http://bugs.php.net/?id=20210edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20210r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20210r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20210r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20210r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20210r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20210r=support Expected behavior: http://bugs.php.net/fix.php?id=20210r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20210r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20210r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20210r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20210r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20210r=dst IIS Stability: http://bugs.php.net/fix.php?id=20210r=isapi
#20210 [Opn-Bgs]: Hash in urldata
ID: 20210 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: Red Hat linux 7.3 PHP Version: 4.2.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. Previous Comments: [2002-11-01 05:23:24] [EMAIL PROTECTED] http://localhost/editaccount.php?UID=1Email=##;localhost http://localhost/editaccount.php?UID=1Email=%23%23;localhost These two urls points to the same thing. The first one is generated by mozilla (uri's are normally escaped by the browser if nescesarry). The variabel Email appears emtpy, and the my script then fails and shit :-/ If I escape the url manually to the second one, php is happy and the Email variabel is set to a value :-) In both cases, isset($Email) and is_string($Email) returned true. I also tested this: http://localhost/editaccount.php?UID=1Email=test##;localhost and Email was set to test Stian -- Edit this bug report at http://bugs.php.net/?id=20210edit=1
#20184 [Csd-Opn]: Add the build date to the output from php -v
ID: 20184 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: Feature/Change Request Operating System: All PHP Version: 4CVS-2002-10-31 New Comment: reopened this feature request phpinfo() is not enough as the output of phpinfo cannot easily be analyzed. if not adding this to other functions something like php_buildate or even better php_package_date (the date when the archive was packed and uploaded to the server) would be great. see also http://lists.php.net/article.php?group=php.qaarticle=6527 Previous Comments: [2002-10-31 11:34:58] [EMAIL PROTECTED] Added. phpinfo() already has this information and adding it to any other place is waste of time. (but propably someone will add a function for this too..*sigh*) [2002-10-31 04:28:12] [EMAIL PROTECTED] aolme too/aol ;) [2002-10-31 04:24:39] [EMAIL PROTECTED] I would appreciate this change, it would make everything much easier. This output should also be added to phpinfo(), phpversion() and anything else where a version information is returned by PHP. [2002-10-31 03:20:13] [EMAIL PROTECTED] When testing CVS versions of PHP it is occasionally easy to lose track of which date's version you're running, whether you forgot to compile after the last CVS update etc. Other than burrowing for the executables and reading modification dates, there doesn't seem to be an simple way of finding the build date. It would seem like a reasonable idea to add the build date to the output from php -v. so it reads something like: php -v PHP 4.3.0-dev (cli) (built: Oct 29 12:04), Copyright (c) 1997-2002 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies -- Edit this bug report at http://bugs.php.net/?id=20184edit=1
#20211 [NEW]: Segfault in sapi_apache_header_handler
From: [EMAIL PROTECTED]
Operating system: FreeBSD
PHP version: 4CVS-2002-11-01
PHP Bug Type: Zlib Related
Bug description: Segfault in sapi_apache_header_handler
#0 0x2836810e in sapi_apache_header_handler (sapi_header=0xbfbff5e4,
sapi_headers=0x2853c790) at mod_php4.c:259
259 table_set(r-headers_out, header_name,
header_content);
(gdb) bt
#0 0x2836810e in sapi_apache_header_handler (sapi_header=0xbfbff5e4,
sapi_headers=0x2853c790) at mod_php4.c:259
#1 0x28370f79 in sapi_add_header_ex (header_line=0x8be0a0c
Content-Encoding, header_line_len=22, duplicate=1 '\001',
replace=1 '\001') at SAPI.c:557
#2 0x283828ac in zif_ob_gzhandler (ht=2, return_value=0x8bdb86c,
this_ptr=0x0, return_value_used=1) at zlib.c:1273
#3 0x2835178e in call_user_function_ex (function_table=0x80de080,
object_pp=0x0, function_name=0x8d7718c,
retval_ptr_ptr=0xbfbff7a8, param_count=2, params=0xbfbff75c,
no_separation=1, symbol_table=0x0)
at zend_execute_API.c:532
#4 0x28376197 in php_end_ob_buffer (send_buffer=1 '\001', just_flush=0
'\000') at output.c:177
#5 0x2837652f in php_end_ob_buffers (send_buffer=1 '\001') at
output.c:267
#6 0x2836b907 in php_request_shutdown (dummy=0x0) at main.c:775
#7 0x28368442 in php_apache_request_shutdown (dummy=0x0) at
mod_php4.c:390
#8 0x80514f2 in run_cleanups ()
#9 0x805cd15 in make_child ()
Cannot access memory at address 0x3dc26069.
#0 0x2836810e in sapi_apache_header_handler (sapi_header=0xbfbff5e4,
sapi_headers=0x2853c790) at mod_php4.c:259
259 table_set(r-headers_out, header_name,
header_content);
(gdb) list
254 if (!strcasecmp(header_name, Content-Type)) {
255 r-content_type = pstrdup(r-pool,
header_content);
256 } else if (!strcasecmp(header_name, Set-Cookie)) {
257 table_add(r-headers_out, header_name,
header_content);
258 } else {
259 table_set(r-headers_out, header_name,
header_content);
260 }
261
262 *p = ':'; /* a well behaved header handler shouldn't
change its original arguments */
263
(gdb) p r-headers_out
Cannot access memory at address 0x84.
--
Edit bug report at http://bugs.php.net/?id=20211edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20211r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20211r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20211r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20211r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20211r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20211r=support
Expected behavior: http://bugs.php.net/fix.php?id=20211r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20211r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20211r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20211r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20211r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20211r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20211r=isapi
#20211 [Com]: Segfault in sapi_apache_header_handler
ID: 20211
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Zlib Related
Operating System: FreeBSD
PHP Version: 4CVS-2002-11-01
New Comment:
Looks like this one is related to:
#19919
Previous Comments:
[2002-11-01 05:34:33] [EMAIL PROTECTED]
#0 0x2836810e in sapi_apache_header_handler (sapi_header=0xbfbff5e4,
sapi_headers=0x2853c790) at mod_php4.c:259
259 table_set(r-headers_out, header_name,
header_content);
(gdb) bt
#0 0x2836810e in sapi_apache_header_handler (sapi_header=0xbfbff5e4,
sapi_headers=0x2853c790) at mod_php4.c:259
#1 0x28370f79 in sapi_add_header_ex (header_line=0x8be0a0c
Content-Encoding, header_line_len=22, duplicate=1 '\001',
replace=1 '\001') at SAPI.c:557
#2 0x283828ac in zif_ob_gzhandler (ht=2, return_value=0x8bdb86c,
this_ptr=0x0, return_value_used=1) at zlib.c:1273
#3 0x2835178e in call_user_function_ex (function_table=0x80de080,
object_pp=0x0, function_name=0x8d7718c,
retval_ptr_ptr=0xbfbff7a8, param_count=2, params=0xbfbff75c,
no_separation=1, symbol_table=0x0)
at zend_execute_API.c:532
#4 0x28376197 in php_end_ob_buffer (send_buffer=1 '\001', just_flush=0
'\000') at output.c:177
#5 0x2837652f in php_end_ob_buffers (send_buffer=1 '\001') at
output.c:267
#6 0x2836b907 in php_request_shutdown (dummy=0x0) at main.c:775
#7 0x28368442 in php_apache_request_shutdown (dummy=0x0) at
mod_php4.c:390
#8 0x80514f2 in run_cleanups ()
#9 0x805cd15 in make_child ()
Cannot access memory at address 0x3dc26069.
#0 0x2836810e in sapi_apache_header_handler (sapi_header=0xbfbff5e4,
sapi_headers=0x2853c790) at mod_php4.c:259
259 table_set(r-headers_out, header_name,
header_content);
(gdb) list
254 if (!strcasecmp(header_name, Content-Type)) {
255 r-content_type = pstrdup(r-pool,
header_content);
256 } else if (!strcasecmp(header_name, Set-Cookie)) {
257 table_add(r-headers_out, header_name,
header_content);
258 } else {
259 table_set(r-headers_out, header_name,
header_content);
260 }
261
262 *p = ':'; /* a well behaved header handler shouldn't
change its original arguments */
263
(gdb) p r-headers_out
Cannot access memory at address 0x84.
--
Edit this bug report at http://bugs.php.net/?id=20211edit=1
#18588 [Fbk]: pointer mismatch
ID: 18588 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Warning -Operating System: OSF1 V4.0 1530 +Operating System: OSF1 V4.0 1530 (Tru64) PHP Version: 4CVS-2002-08-14 New Comment: In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/ctype/ctype.c:23: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:60: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:85: warning: redefinition of `uchar' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/sys/types.h:580: warning: `uchar' previously declared here /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c: In function `exif_process_IFD_in_JPEG': /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/ftp/php_ftp.c:26: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/ftp/ftp.c:22: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/mbstring/mbfilter_ja.c:86: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/mbstring/mbfilter_cn.c:29: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/mbstring/mbfilter_tw.c:29: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from
#19919 [Com]: segmentation violation in sapi_apache_header_handler, mod_php4.c line 208
ID: 19919
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: FreeBSD 4.7
PHP Version: 4.2.3, 4.3.0-Dev
New Comment:
Hi all,
I see this happen here too ... Also FreeBSD 4.7
and PHP from cvs ...
Previous Comments:
[2002-10-21 15:20:22] [EMAIL PROTECTED]
Still core dumps using the latest snapshot.
PHP Version 4.3.0-dev
System FreeBSD Server-0-2. 4.7-STABLE FreeBSD
4.7-STABLE #27: Mon Oct i386
Build Date Oct 17 2002 13:19:31
Configure './configure' '--with-apxs=/usr/local/sbin/apxs'
Command'--with-config-file-path=/usr/local/etc'
'--enable-versioning' '--with-regex=system'
'--without-gd'
'--without-mysql' '--enable-debug' '--with-imap'
'--with-pgsql' '--with-gettext' '--enable-track-vars'
'--enable-wddx' '--disable-magic-quotes'
'--enable-short-tags' '--enable-debug' '--with-zlib'
'--with-imap=/usr/local' '--with-pgsql=/usr/local'
'--enable-wddx' '--with-gettext=/usr/local'
'--enable-sockets' '--enable-trans-sid'
'--with-expat-dir=/
usr/local' '--prefix=/usr/local'
'i386-portbld-freebsd4.7'
Server API Apache
Virtualdisabled
Directory
Support
Configuration /usr/local/www/data/php.ini
File
(php.ini)
Path
PHP API20020307
PHP Extension 20020429
Zend 20021010
Extension
Debug Buildyes
Thread Safety disabled
Registered php, http, ftp, compress.zlib
PHP Streams
--
Date: Mon, 21 Oct 2002 15:57:02 GMT
Core was generated by `httpd'.
Program terminated with signal 11, Segmentation fault.
#0 0x28309a83 in sapi_apache_header_handler (sapi_header=0xbfbfe3c0,
sapi_headers=0x2836f510)
at
/home/wgate/mod_php4/work/php4-200210160300/sapi/apache/mod_php4.c:188
#0 0x28309a83 in sapi_apache_header_handler (sapi_header=0xbfbfe3c0,
sapi_headers=0x2836f510)
at
/home/wgate/mod_php4/work/php4-200210160300/sapi/apache/mod_php4.c:188
#1 0x282c88dd in sapi_header_op (op=SAPI_HEADER_ADD, arg=0xbfbfe410)
at /home/wgate/mod_php4/work/php4-200210160300/main/SAPI.c:629
#2 0x2827cd09 in php_setcookie (name=0x824d564 TICS0, name_len=5,
value=0x82e7024
TG9naW58YToxMzp7czo1OiJCb3hJRCI7czoxMjoiMDAwMDAwMDAyNzI4IjtzOjc6IkJveFR5cGUiO3M6MToiNCI7czoxMzoiQ2hhbm5lbE51bWJlciI7czoxOiIwIjtzOjQ6Ik5vZGUiO3M6MToiMCI7czo5OiJTZXNzaW9uSUQiO3M6MTY6IjJNMVZFRlEwVVI4OFBF...,
value_len=2200, expires=0, path=0x824d724 /, path_len=1,
domain=0x824d6a4 , domain_len=0, secure=0)
at
/home/wgate/mod_php4/work/php4-200210160300/ext/standard/head.c:133
#3 0x2827cdcf in zif_setcookie (ht=5, return_value=0x8220f64,
this_ptr=0x0,
return_value_used=0)
at
/home/wgate/mod_php4/work/php4-200210160300/ext/standard/head.c:155
#4 0x28302338 in execute (op_array=0x81b6c80)
at
/home/wgate/mod_php4/work/php4-200210160300/Zend/zend_execute.c:1599
#5 0x282e581b in call_user_function_ex (function_table=0x80cef00,
object_pp=0x0, function_name=0x81c2964, retval_ptr_ptr=0xbfbff1b8,
param_count=2, params=0x824d924, no_separation=1,
symbol_table=0x0)
at
/home/wgate/mod_php4/work/php4-200210160300/Zend/zend_execute_API.c:561
#6 0x282e50e4 in call_user_function (function_table=0x80cef00,
object_pp=0x0,
function_name=0x81c2964, retval_ptr=0x82c3c24, param_count=2,
params=0xbfbff234)
at
/home/wgate/mod_php4/work/php4-200210160300/Zend/zend_execute_API.c:403
#7 0x282550a3 in ps_call_handler (func=0x81c2964, argc=2,
argv=0xbfbff234)
at
/home/wgate/mod_php4/work/php4-200210160300/ext/session/mod_user.c:60
#8 0x2825550c in ps_write_user (mod_data=0x2836e570,
key=0x81fc2a4 10a5228266dd083119c5df2c9d5f0518,
val=0x80b2024
Login|a:13:{s:5:\BoxID\;s:12:\2728\;s:7:\BoxType\;s:1:\4\;s:13:\ChannelNumber\;s:1:\0\;s:4:\Node\;s:1:\0\;s:9:\SessionID\;s:16:\2M1VEFQ0UR88PE0R\;s:9:\LoginType\;s:2:\WG\;s:6:\TocsIP\;s:17:\17...,
vallen=1650)
at
/home/wgate/mod_php4/work/php4-200210160300/ext/session/mod_user.c:148
#9 0x28251b2c in php_session_save_current_state ()
at
/home/wgate/mod_php4/work/php4-200210160300/ext/session/session.c:676
#10 0x282544e9 in php_session_flush ()
at
/home/wgate/mod_php4/work/php4-200210160300/ext/session/session.c:1553
#11 0x2825450c in zif_session_write_close (ht=0,
return_value=0x82083a4,
this_ptr=0x0, return_value_used=0)
at
/home/wgate/mod_php4/work/php4-200210160300/ext/session/session.c:1562
#12 0x28302338 in execute (op_array=0x81b6e80)
at
/home/wgate/mod_php4/work/php4-200210160300/Zend/zend_execute.c:1599
#13 0x282e581b in call_user_function_ex (function_table=0x80cef00,
#18588 [Fbk-Opn]: pointer mismatch
ID: 18588 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Compile Warning Operating System: OSF1 V4.0 1530 (Tru64) PHP Version: 4CVS-2002-08-14 Previous Comments: [2002-11-01 05:43:28] [EMAIL PROTECTED] In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/ctype/ctype.c:23: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:60: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:85: warning: redefinition of `uchar' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/sys/types.h:580: warning: `uchar' previously declared here /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c: In function `exif_process_IFD_in_JPEG': /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/ftp/php_ftp.c:26: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/ftp/ftp.c:22: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/mbstring/mbfilter_ja.c:86: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/mbstring/mbfilter_cn.c:29: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/mbstring/mbfilter_tw.c:29: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63,
#20203 [Fbk-Opn]: odbc_do() or odbc_exec() Always produces a segmentation fault core dump
ID: 20203
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: ODBC related
Operating System: sparc solaris 2.8 and 2.6
PHP Version: 4.2.3
New Comment:
Please i am not too familiar with gdb can you tell me how
I can print query and result-stmt variables in step #10 ?
Bets regards
Christos
Previous Comments:
[2002-10-31 19:45:27] [EMAIL PROTECTED]
Also can you please turn on SQL Logging so we can see which steps are
being processed. From the looks of it the SQLExtendedFetch is catching
an error condition or possibly a need to re-allocate data and refetch
furth of data.
I find it hard to believe that the odbc_exect (a very basic part of any
DB layer) isn't working with MSSQL. What are the types of data you're
trying to extract?
[2002-10-31 19:31:52] [EMAIL PROTECTED]
On step #10 could you print the values of:
query and result-stmt
[2002-10-31 17:32:40] [EMAIL PROTECTED]
The result is the same after using the latest cvs and here is the
output of gdb 5.0 (and the trace back) :
** gdb output *
Program received signal SIGSEGV, Segmentation fault.
0xfeff55dc in SQLExtendedFetch () from
/usr/local/odbc/lib/sql_st_lt.so
(gdb) bt
#0 0xfeff55dc in SQLExtendedFetch () from
/usr/local/odbc/lib/sql_st_lt.so
#1 0xfeff6560 in SQLExtendedFetch () from
/usr/local/odbc/lib/sql_st_lt.so
#2 0xfefcc418 in SQLExtendedFetch () from
/usr/local/odbc/lib/sql_st_lt.so
#3 0xfefc76a0 in SQLExtendedFetch () from
/usr/local/odbc/lib/sql_st_lt.so
#4 0xfefc5af0 in SQLExtendedFetch () from
/usr/local/odbc/lib/sql_st_lt.so
#5 0xfefb3584 in SQLNumResultCols () from
/usr/local/odbc/lib/sql_st_lt.so
#6 0xfefac7d0 in SQLError () from /usr/local/odbc/lib/sql_st_lt.so
#7 0xfef97d54 in SQLDriverConnect () from
/usr/local/odbc/lib/sql_st_lt.so
#8 0xfefac89c in SQLExecDirect () from
/usr/local/odbc/lib/sql_st_lt.so
#9 0xff35e72c in SQLExecDirect () from
/usr/local/odbc/lib/libiodbc.so.2
#10 0x4c76c in zif_odbc_exec (ht=1811184, return_value=0x1b4760,
this_ptr=0x0,
return_value_used=1)
at /usr/pkg/php/php4-200210311500/ext/odbc/php_odbc.c:1318
#11 0x10a9e0 in execute (op_array=0x1b6110)
at /usr/pkg/php/php4-200210311500/Zend/zend_execute.c:1595
#12 0xfdb60 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /usr/pkg/php/php4-200210311500/Zend/zend.c:839
#13 0xd699c in php_execute_script (primary_file=0xffbefaf0)
at /usr/pkg/php/php4-200210311500/main/main.c:1541
#14 0x10ef8c in main (argc=2, argv=0xffbefb7c)
at /usr/pkg/php/php4-200210311500/sapi/cli/php_cli.c:695
[2002-10-31 17:01:02] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-10-31 15:06:24] [EMAIL PROTECTED]
The odbc driver from openlink software for ms sql 2000 is used.
Note that thru the openlink adminstator all works fine si this lead me
to
the thought that this must be a php problem
PHP was compiled with the option --with-openlink (--with-iodbc produces
the same)
Symptoms :
1) odbc_connect() suceeds and returns RESOURCE ID #1
2) the odbc_do() or odbc_exec() always produce
segmentation fault core dumped.
3) The error is the same if I run from the comand line php
ptest3.php
I guess i can also run from the command line ouside any web
server
This is the script (ptest3.php) that produces the error
*script start
?
// putenv(LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib);
// putenv(ODBCINSTINI=/usr/local/bin/odbcinst.ini);
// this location will be determined by your driver install.
// putenv(ODBCINI=/usr/local/bin/odbc.ini);
// odbc.ini contains your DSN,location determined by your driver
install
$dsn=eettn;
// this is a valid DSN. Can be tested in odbctest
$user=sa;
$password=anmaelky;
$sql=SELECT * FROM tab01 where col01=1;
echo ($LD_LIBRARY_PATH) ;
echo(aaabr) ;
echo($user) ;
echo(br) ;
$conn_id=odbc_connect($dsn,sa,anmaelky) ;
echo(CONNECTION ID = |) ;
echo($conn_id) ;
echo(|\n\n) ;
flush() ;
// exit() ;
if ($conn_id) {
echo connected to DSN: eettn\n\n;
$result=odbc_do($conn_id, $sql) ;
echo(result) ;
echo($result) ;
if($result) {
echo executing '$sql';
#20212 [NEW]: Content of form array variables will be cutted by the first 4 characters
From: [EMAIL PROTECTED] Operating system: SuSE Linux 8.0 PHP version: 4.2.3 PHP Bug Type: HTTP related Bug description: Content of form array variables will be cutted by the first 4 characters PHP 4.2.3 will cut the first 4 characters from content of form variables, if they are array's. This does not occur in PHP versions 4.1.1 and 4.1.2. The following 2 files demonstrate the bug. First the HTML form: Begin ++ html head titleDemonstrate error in form handling by PHP 4.2.3/title /head body bgcolor=white form action=http://139.18.20.141/formError.php; method=post !-- try the following URLs for action to see correctly working older systems: [PHP 4.1.1] http://www.abelard.info/formError.php [PHP 4.1.2] http://www.stura.uni-leipzig.de/sp/formError.php -- input type='checkbox' name='selectCourse[]' value='KURS_' checked=1KURS_ BR input type='checkbox' name='selectCourse[]' value='ABCD_KURS_0_1'ABCD_KURS_0_1 BR input type=submit name=submit value=Ok /form /body /html --- End -- Second, the processing PHP file: + Begin html headtitlePOST-Array test/title/head body h1POST-Array test/h1 p ?php echo 'selectCourse[0]='.$_POST['selectCourse'][0].br\n; echo 'selectCourse[1]='.$_POST['selectCourse'][1]; ? /p /body /html End If submitted by only clicking the OK-button, this should output ... selectCourse[0]=KURS_ ... but in fact it does this on older versions of PHP only. PHP 4.2.3 does output instead: ... selectCourse[0]=_ ... loosing the first 4 characters from variable content. Note: This occurs _only_ on array-like variables as above, normal variables were submitted correctly. *** Now the usual system information: You can obtain the full configuration by calling http://139.18.20.141/test.php The configure line here again: + Begin ++ './configure' '--prefix=/usr/share' '--datadir=/usr/share/php' '--bindir=/usr/bin' '--libdir=/usr/share' '--libdir=/usr/local/lib' '--includedir=/usr/include' '--includedir=/usr/local/include' '--with-config-file-path=/etc' '--with-exec-dir=/usr/lib/php/bin' '--disable-debug' '--enable-bcmath' '--enable-calendar' '--enable-ctype' '--enable-dbase' '--enable-discard-path' '--enable-exif' '--enable-force-cgi-redirect' '--enable-ftp' '--enable-inline-optimization' '--enable-magic-quotes' '--enable-mbstr-enc-trans' '--enable-mbstring' '--enable-memory-limit' '--enable-safe-mode' '--enable-shmop' '--enable-sigchild' '--enable-sysvsem' '--enable-sysvshm' '--enable-trans-sid' '--enable-versioning' '--with-bz2' '--with-dom=/usr/local/include/libxml2' '--with-ftp' '--with-gettext' '--with-imap=yes' '--with-jpeg-dir=/usr' '--with-mysql=/usr' '--with-png-dir=/usr' '--with-xml' '--with-zlib=yes' '--enable-xslt' '--with-xslt-sablot' '--with-mm' '--with-apxs=/usr/sbin/apxs' '--with-pcre-regex' '--without-pgsql' '--with-imap-ssl' --- End --- I have compiled PHP by getting php-4.2.3.tar.bz2 from http://de.php.net/get_download.php?df=php-4.2.3.tar.bz2 The md5 sum is OK. For APACHE I used the source RPM included in SuSE 8.0, that means version 1.3.23. ## -- Edit bug report at http://bugs.php.net/?id=20212edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20212r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20212r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20212r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20212r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20212r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20212r=support Expected behavior: http://bugs.php.net/fix.php?id=20212r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20212r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20212r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20212r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20212r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20212r=dst IIS Stability: http://bugs.php.net/fix.php?id=20212r=isapi
#20212 [Opn-Csd]: Content of form array variables will be cutted by the first 4 characters
ID: 20212 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: HTTP related Operating System: SuSE Linux 8.0 PHP Version: 4.2.3 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: [2002-11-01 06:23:17] [EMAIL PROTECTED] PHP 4.2.3 will cut the first 4 characters from content of form variables, if they are array's. This does not occur in PHP versions 4.1.1 and 4.1.2. The following 2 files demonstrate the bug. First the HTML form: Begin ++ html head titleDemonstrate error in form handling by PHP 4.2.3/title /head body bgcolor=white form action=http://139.18.20.141/formError.php; method=post !-- try the following URLs for action to see correctly working older systems: [PHP 4.1.1] http://www.abelard.info/formError.php [PHP 4.1.2] http://www.stura.uni-leipzig.de/sp/formError.php -- input type='checkbox' name='selectCourse[]' value='KURS_' checked=1KURS_ BR input type='checkbox' name='selectCourse[]' value='ABCD_KURS_0_1'ABCD_KURS_0_1 BR input type=submit name=submit value=Ok /form /body /html --- End -- Second, the processing PHP file: + Begin html headtitlePOST-Array test/title/head body h1POST-Array test/h1 p ?php echo 'selectCourse[0]='.$_POST['selectCourse'][0].br\n; echo 'selectCourse[1]='.$_POST['selectCourse'][1]; ? /p /body /html End If submitted by only clicking the OK-button, this should output ... selectCourse[0]=KURS_ ... but in fact it does this on older versions of PHP only. PHP 4.2.3 does output instead: ... selectCourse[0]=_ ... loosing the first 4 characters from variable content. Note: This occurs _only_ on array-like variables as above, normal variables were submitted correctly. *** Now the usual system information: You can obtain the full configuration by calling http://139.18.20.141/test.php The configure line here again: + Begin ++ './configure' '--prefix=/usr/share' '--datadir=/usr/share/php' '--bindir=/usr/bin' '--libdir=/usr/share' '--libdir=/usr/local/lib' '--includedir=/usr/include' '--includedir=/usr/local/include' '--with-config-file-path=/etc' '--with-exec-dir=/usr/lib/php/bin' '--disable-debug' '--enable-bcmath' '--enable-calendar' '--enable-ctype' '--enable-dbase' '--enable-discard-path' '--enable-exif' '--enable-force-cgi-redirect' '--enable-ftp' '--enable-inline-optimization' '--enable-magic-quotes' '--enable-mbstr-enc-trans' '--enable-mbstring' '--enable-memory-limit' '--enable-safe-mode' '--enable-shmop' '--enable-sigchild' '--enable-sysvsem' '--enable-sysvshm' '--enable-trans-sid' '--enable-versioning' '--with-bz2' '--with-dom=/usr/local/include/libxml2' '--with-ftp' '--with-gettext' '--with-imap=yes' '--with-jpeg-dir=/usr' '--with-mysql=/usr' '--with-png-dir=/usr' '--with-xml' '--with-zlib=yes' '--enable-xslt' '--with-xslt-sablot' '--with-mm' '--with-apxs=/usr/sbin/apxs' '--with-pcre-regex' '--without-pgsql' '--with-imap-ssl' --- End --- I have compiled PHP by getting php-4.2.3.tar.bz2 from http://de.php.net/get_download.php?df=php-4.2.3.tar.bz2 The md5 sum is OK. For APACHE I used the source RPM included in SuSE 8.0, that means version 1.3.23. ## -- Edit this bug report at http://bugs.php.net/?id=20212edit=1
#15509 [Com]: fifth argument in mail only supports one parameter and no spaces
ID: 15509
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Mail related
Operating System: Linux RedHat 7.1
PHP Version: 4.1.1
New Comment:
I think the security issue of the fifth parameter is a
red herring, as the parameter will rarely (never) contain
anything not explicitly written by the programmer. That
is, it will never contain arbitrary web page input.
I need to do -odd [EMAIL PROTECTED], which, with the
current restriction, means that I have to write my own
mail() function, which shouldn't really be necessary for
something like this (odd sets deferred delivery, dumping
mail in the queue for the daemon to pick up later).
I have in fact made a (very clean) patch against PHP-4.2.3
ext/mail.c to allow multiple params, I'll be happy to pass
it on.
-- Per
Previous Comments:
[2002-08-17 20:17:13] [EMAIL PROTECTED]
mail ('foo','bar','[EMAIL PROTECTED]','',';killall -9 httpd');
(of course this will only kill httpd's running as the httpd user)
Derick
[2002-08-17 17:08:57] [EMAIL PROTECTED]
what are the security issues involved in passing multiple parameters.
[2002-06-10 11:25:06] [EMAIL PROTECTED]
The behaviour was changed for security reason, only one parameter can
be passed, even when spaces are in the parameter.
[2002-06-10 10:30:34] [EMAIL PROTECTED]
I don't have safe-mode enabled - in php.ini
;
; Safe Mode
;
safe_mode = Off
Thanks!
Andreia
[2002-06-02 18:26:17] [EMAIL PROTECTED]
Do you have safe_mode enabled?
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/15509
--
Edit this bug report at http://bugs.php.net/?id=15509edit=1
#20202 [Com]: Form elements id Attrbute Ignored
ID: 20202 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Feature/Change Request Operating System: WinXP SP1 PHP Version: 4.2.2 New Comment: I'd just like to add that [EMAIL PROTECTED] is actually incorrect, and there is nothing to correct here. Quoting from the URL s/he posted before, the name attribute is deprecated *only* for the a, applet, form, frame, iframe, img, and map tags. It is most definitely *not* deprecated for the individual form element tags, and indeed is an integral part of the XHTML spec for those tags. Cheers! Previous Comments: [2002-11-01 05:22:02] [EMAIL PROTECTED] Okay then, not a error/problem in PHP so we mark this as bogus. Derick [2002-10-31 18:50:55] [EMAIL PROTECTED] OK so, I trace Moziila 1.1beta Win32 with HTTPTrace 2.0 and indeed you were right , when only the id attribe is set mozilla does not send the content of the element. Unfortunately the program did not work with the other browser but I suspet the same issue is involved. For information I tested : Moziila 1.1b, Opera 6.01, Amaya 6.4 and Internet Explorer 6.0 SP1 on Win32 and Mozilla 1.0, Lynx and Links, Konqueror on Linux. Every browser reported the error but acted differently some time . IE6 for exmple did not even report the PHP error message as Mozilla did. The XHTML 1.0/1.1 still accept the name attribute as does XHTML Basic but I do believe that UA developpers should correct this issue for the future [2002-10-31 14:48:55] [EMAIL PROTECTED] This is up to the browser to do. Did you verify with a line sniffer / network tracer to see what happened? My bet is that the browser didn't send the data correctly, and of course PHP doesn't record it then. Derick [2002-10-31 14:46:26] [EMAIL PROTECTED] W3C Specs page about id attribute in XHTML 1.0 is at http://www.w3.org/TR/xhtml1/#h-4.10 [2002-10-31 14:36:20] [EMAIL PROTECTED] PHP seems to ignore the id attribute given to form elements. It just consider the name attribute So while a element like input type=text name=first_name / will create a $_post[first_name] variable if submitted, for exemple, the similar tag input type=text id=first_name / will not create any variable. The problem is that in the XHTML 1.0 W3C specs the name attribute is depreached in favor of id. This could cause problems in the near future where XHTML whill be more widespread. It would be appreciated if the id attribute handling is added to future PHP releases. Info: I installed PHP on my WinXP SP1 for use with IIS using the included installer and use all the default choices. My inst -- Edit this bug report at http://bugs.php.net/?id=20202edit=1
#20190 [Com]: Random mem corruption: zend_get_executed_filename() mismatch
ID: 20190
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache related
Operating System: FreeBSD
PHP Version: 4.3.0-dev
New Comment:
My patch explained a bit more ...
The main trick is that we do a stat() on
$path:
if (( stat (path, statbuf)) 0) {
If the file does not exist, we can be sure that we triggered the bug
and we let the check pass.
As already said, this is only a workaround for the ugly
bug ...
Martin
Previous Comments:
[2002-10-31 18:06:01] [EMAIL PROTECTED]
hi all,
I think I can now even provide more information ... :-)
$path beeing wrong does relate from a wrong include_path.
It looks like if the apache child has proceeded a request
from a webserver with include_path or safe_mode_include_dir
set, these are still there. If now a virtual server without
these admin values is called, we fail.
Looks to me like these variables are not properly initialized and still
contain their old values.
Of course the openbasedir checks then against the wrong
include path and there we are :-(
I'll look if I can really find the bug and fix it.
Martin
[2002-10-31 17:09:40] [EMAIL PROTECTED]
I have tried to do workarounds earlier.
But it seems that this one here now has solved both issues,
the wrong random basedir message and the segfaults I encountered with
my first two patches.
http://people.freebsd.org/~mbr/patches/patch-main+fopen_wrappers.c
The solution is quite easy. In the onyl case where the error happens,
zend_get_executed_filename() is correct.
and can be used.
Since the error happens on perfect legitimate requests,
which work most of the time, I don't think this is a
security risk. If no executed filename is set, I set
$newpath to a empty string.
Note that this is a workaround only. And I print
the errors to syslog, since I can watch that easier.
[2002-10-31 16:34:24] [EMAIL PROTECTED]
It looks to me that $path is composed somewhere.
And a the old basedir entry was not overwritten
correctly.
So $path is $basedir + $called phpfile and
the $basedir is plain wrong.
Some hint where this happens ?
[2002-10-31 16:24:52] [EMAIL PROTECTED]
Sorry ...
There is no /www/doc/www.bbb.imp.ch-80/html/visions/php
exists, but this is a different customer.
This should be:
There is a dir /www/doc/www.bbb.imp.ch-80 ...
but this is a different customer.
[2002-10-31 16:23:17] [EMAIL PROTECTED]
This is a example:
Correct:
PG(open_basedir)=/www/doc/www.aaa.ch-80,
Correct:
zend_get_executed_filename() = /www/doc/www.aaa.ch-80/index.php,
Wrong:
path=/www/doc/www.bbb.imp.ch-80/html/visions/php//ueberuns/mannschaft.php
There is no /www/doc/www.bbb.imp.ch-80/html/visions/php
exists, but this is a different customer.
The correct filename would be:
/www/doc/www.aaa.ch-80/ueberuns/mannschaft.php
Also note the two // slashes ...
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/20190
--
Edit this bug report at http://bugs.php.net/?id=20190edit=1
#19768 [Bgs-Opn]: Expires header incorrectly set, cannot be overwritten
ID: 19768 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Session related Operating System: Win32, Unix PHP Version: 4.2.1 New Comment: Judging from http://www.w3.org/Protocols/HTTP/1.0/spec.html#Expires the Expires header was the intended header in HTTP/1.0 for cache control. I do not understand why you say, a past header should be sent instead of a correct date. header() doesn't enable me to replace an Expires header, as stated in my original report. Previous Comments: [2002-10-28 23:23:03] [EMAIL PROTECTED] Since HTTP/1.0 lacks cache control feature can be found in HTTP/1.1, past date expire header should be sent. It's not a bug, but a intended behavior for HTTP/1.0 clients. See also header() manual page to replace header, but add new one. [2002-10-26 11:23:15] [EMAIL PROTECTED] Also see my detailed comment on bug #5415 http://bugs.php.net/bug.php?id=5415 [2002-10-26 11:08:26] [EMAIL PROTECTED] I did use private, but this causes incorrect Expires headers as described. That's why I switched to none and created the headers myself. [2002-10-21 14:55:10] [EMAIL PROTECTED] There seems to be a misunderstanding: Using session_cache_limiter(private) will create the malformed Expires headers mentioned in my bug report. [2002-10-20 13:04:06] [EMAIL PROTECTED] The default value 'nocache' means that the page should not be cached at all. Have a look at php.ini-dist, you probably want to set session.cache_limiter to 'private'. 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/19768 -- Edit this bug report at http://bugs.php.net/?id=19768edit=1
#20203 [Opn]: odbc_do() or odbc_exec() Always produces a segmentation fault core dump
ID: 20203 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: ODBC related Operating System: sparc solaris 2.8 and 2.6 PHP Version: 4.2.3 New Comment: display query display result-stmt Previous Comments: [2002-11-01 06:16:39] [EMAIL PROTECTED] Please i am not too familiar with gdb can you tell me how I can print query and result-stmt variables in step #10 ? Bets regards Christos [2002-10-31 19:45:27] [EMAIL PROTECTED] Also can you please turn on SQL Logging so we can see which steps are being processed. From the looks of it the SQLExtendedFetch is catching an error condition or possibly a need to re-allocate data and refetch furth of data. I find it hard to believe that the odbc_exect (a very basic part of any DB layer) isn't working with MSSQL. What are the types of data you're trying to extract? [2002-10-31 19:31:52] [EMAIL PROTECTED] On step #10 could you print the values of: query and result-stmt [2002-10-31 17:32:40] [EMAIL PROTECTED] The result is the same after using the latest cvs and here is the output of gdb 5.0 (and the trace back) : ** gdb output * Program received signal SIGSEGV, Segmentation fault. 0xfeff55dc in SQLExtendedFetch () from /usr/local/odbc/lib/sql_st_lt.so (gdb) bt #0 0xfeff55dc in SQLExtendedFetch () from /usr/local/odbc/lib/sql_st_lt.so #1 0xfeff6560 in SQLExtendedFetch () from /usr/local/odbc/lib/sql_st_lt.so #2 0xfefcc418 in SQLExtendedFetch () from /usr/local/odbc/lib/sql_st_lt.so #3 0xfefc76a0 in SQLExtendedFetch () from /usr/local/odbc/lib/sql_st_lt.so #4 0xfefc5af0 in SQLExtendedFetch () from /usr/local/odbc/lib/sql_st_lt.so #5 0xfefb3584 in SQLNumResultCols () from /usr/local/odbc/lib/sql_st_lt.so #6 0xfefac7d0 in SQLError () from /usr/local/odbc/lib/sql_st_lt.so #7 0xfef97d54 in SQLDriverConnect () from /usr/local/odbc/lib/sql_st_lt.so #8 0xfefac89c in SQLExecDirect () from /usr/local/odbc/lib/sql_st_lt.so #9 0xff35e72c in SQLExecDirect () from /usr/local/odbc/lib/libiodbc.so.2 #10 0x4c76c in zif_odbc_exec (ht=1811184, return_value=0x1b4760, this_ptr=0x0, return_value_used=1) at /usr/pkg/php/php4-200210311500/ext/odbc/php_odbc.c:1318 #11 0x10a9e0 in execute (op_array=0x1b6110) at /usr/pkg/php/php4-200210311500/Zend/zend_execute.c:1595 #12 0xfdb60 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/pkg/php/php4-200210311500/Zend/zend.c:839 #13 0xd699c in php_execute_script (primary_file=0xffbefaf0) at /usr/pkg/php/php4-200210311500/main/main.c:1541 #14 0x10ef8c in main (argc=2, argv=0xffbefb7c) at /usr/pkg/php/php4-200210311500/sapi/cli/php_cli.c:695 [2002-10-31 17:01:02] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20203 -- Edit this bug report at http://bugs.php.net/?id=20203edit=1
#13035 [Com]: 404 on a .php results in SERVER ERROR when using php as a cgi
ID: 13035 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Other web server Operating System: Linux 2.4.6 PHP Version: 4.2.3 New Comment: OK, I downloaded and built yesterday's CVS snapshot (php4-200210311500) and the problem is still present: pointing the PHP CGI to a non-existing .php file produces no output, which results in a missing HTTP headers error in the Apache error_log. I did not submit the original bug, so I'm not able to reopen this bug myself. BTW, I tried this with an old PHP 3.0.16 CGI to see what it used to do, and PHP3 would produce the following output when pointed to a non-existing PHP file... not quite as good as a real 404 error, but better than nothing: X-Powered-By: PHP/3.0.16 Content-type: text/html br bFatal error/b: Unable to open ttt.php in b-/b on line b0/bbr Previous Comments: [2002-10-29 04:24:46] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-28 23:27:23] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Reopen to confirm if the problem is in 4.3.0-dev [2002-10-24 08:35:35] [EMAIL PROTECTED] I would like the PHP developers to please consider reopening this bug. I don't think it is bogus. It still happens with PHP 4.2.x: The problem is simple: when using PHP as a CGI and pointing to a non-existing PHP file, instead of a 404 error we receive an empty page or a 500 - Internal Server error from the PHP CGI due to missing HTTP headers. I think the solution is that the PHP CGI should be modified to return a 404 error header when it cannot find the .php file that it is being pointed to. [2002-06-13 18:04:46] [EMAIL PROTECTED] Sorry, but the bug system is not the appropriate forum for asking support questions. 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 Thank you for your interest in PHP. [2002-03-26 18:50:25] [EMAIL PROTECTED] This problem has been annoying me for a while and is still present in 4.1.2 (CGI) at least. I stepped through the code in a debugger and found out that when the php script doesn't exist then zend_error() is called at the lower-level, but the zend_catch in cgi_main.c catches the error and the php execution ends without any HTTP headers or anything... hence the '500 Server Error'. I don't know enough about the way Zend works to propose a patch, but I found a nice WORKAROUND... in your php.ini, set log_errors=On; This way, the error message will be sent to your Apache error_log, and the php execution will end nicely with proper HTTP headers, but an empty document, which is better than a 500 server 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/13035 -- Edit this bug report at http://bugs.php.net/?id=13035edit=1
#13008 [Fbk-Opn]: Multiple update/inserts fail
ID: 13008 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: MSSQL related Operating System: Linux 2.2.12-20 Red Hat 6.1 PHP Version: 4.0.6 New Comment: OK, I know that a lot of things changed in this test, sorry about that - too much time elapsed I guess... I have the following configuration: Mandrake 8.2 system Apache 2.0.43 FreeTDS 0.60 PHP 4.3.0-dev (latest snap) PHP API 20020307 PHP Extension 20020429 Zend Extension 20021010 './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-gd' '--with-zlib' '--with-jpeg' '--with-png' '--with-mssql' '--with-sybase=/usr/local' '--enable-track-vars' '--with-mysql' With that setup all apears to work OK now. I can have a failing insert due to a key restraint in the database table and still do updates and other inserts without having to close the connection. Thanks for the help and your patience with my getting around to testing it. Previous Comments: [2002-10-30 08:08:45] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-30 08:04:46] [EMAIL PROTECTED] I'm trying to recreate the problem, but unfortunately I no longer have the system that I originally had the problem on. I only have available an HP-UX 11.0 system and a Mandrake 8.2 system, and I'm having all kinds of problems building PHP on the HP-UX system. I have just about got it built except for some GD shared library problems. Based upon Chris's last report the problem still exists. Hopefully I will be able to test again by the end of the week. [2002-10-30 03:59:13] [EMAIL PROTECTED] Im am using Windows NT and PHP 4.2.3 and experience the same problems with MS SQL Server 2000: i try to do multiple inserts in one query: script $sql = INSERT INTO tbl (col1, col2) VALUES( $int1, '$str1'); INSERT INTO tbl (col1, col2) VALUES( $int2, '$str2'); ... mssql_query($sql); /script the thing is: one query with more than one insert works, the data is is in the DB. But all others fail. It also works if I do only one insert at the time. Even it works, if I put all inserts in one string and do 1 inserts with one query. I see a problem here, because the amount of data can grow very large. so there are probably some restrictions to the contents of a string-Variable and the String-Length of a query. I dont understand, why it is not possible to do a second query after inserting more then one lines... chris [2002-10-25 01:00:06] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2002-10-09 11:59:14] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip If the problem still occures try upgrading to freetds-0.53 and seeing if that'll solve the problem. 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/13008 -- Edit this bug report at http://bugs.php.net/?id=13008edit=1
#13008 [Opn-Csd]: Multiple update/inserts fail
ID: 13008 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: MSSQL related Operating System: Linux 2.2.12-20 Red Hat 6.1 PHP Version: 4.0.6 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. User reports that the problem has been fixed. Previous Comments: [2002-11-01 09:59:43] [EMAIL PROTECTED] OK, I know that a lot of things changed in this test, sorry about that - too much time elapsed I guess... I have the following configuration: Mandrake 8.2 system Apache 2.0.43 FreeTDS 0.60 PHP 4.3.0-dev (latest snap) PHP API 20020307 PHP Extension 20020429 Zend Extension 20021010 './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-gd' '--with-zlib' '--with-jpeg' '--with-png' '--with-mssql' '--with-sybase=/usr/local' '--enable-track-vars' '--with-mysql' With that setup all apears to work OK now. I can have a failing insert due to a key restraint in the database table and still do updates and other inserts without having to close the connection. Thanks for the help and your patience with my getting around to testing it. [2002-10-30 08:08:45] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-30 08:04:46] [EMAIL PROTECTED] I'm trying to recreate the problem, but unfortunately I no longer have the system that I originally had the problem on. I only have available an HP-UX 11.0 system and a Mandrake 8.2 system, and I'm having all kinds of problems building PHP on the HP-UX system. I have just about got it built except for some GD shared library problems. Based upon Chris's last report the problem still exists. Hopefully I will be able to test again by the end of the week. [2002-10-30 03:59:13] [EMAIL PROTECTED] Im am using Windows NT and PHP 4.2.3 and experience the same problems with MS SQL Server 2000: i try to do multiple inserts in one query: script $sql = INSERT INTO tbl (col1, col2) VALUES( $int1, '$str1'); INSERT INTO tbl (col1, col2) VALUES( $int2, '$str2'); ... mssql_query($sql); /script the thing is: one query with more than one insert works, the data is is in the DB. But all others fail. It also works if I do only one insert at the time. Even it works, if I put all inserts in one string and do 1 inserts with one query. I see a problem here, because the amount of data can grow very large. so there are probably some restrictions to the contents of a string-Variable and the String-Length of a query. I dont understand, why it is not possible to do a second query after inserting more then one lines... chris [2002-10-25 01:00:06] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. 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/13008 -- Edit this bug report at http://bugs.php.net/?id=13008edit=1
#20211 [Opn-Bgs]: Segfault in sapi_apache_header_handler
ID: 20211
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Zlib Related
Operating System: FreeBSD
PHP Version: 4CVS-2002-11-01
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 original bug instead.
Thank you for your interest in PHP.
Previous Comments:
[2002-11-01 05:42:36] [EMAIL PROTECTED]
Looks like this one is related to:
#19919
[2002-11-01 05:34:33] [EMAIL PROTECTED]
#0 0x2836810e in sapi_apache_header_handler (sapi_header=0xbfbff5e4,
sapi_headers=0x2853c790) at mod_php4.c:259
259 table_set(r-headers_out, header_name,
header_content);
(gdb) bt
#0 0x2836810e in sapi_apache_header_handler (sapi_header=0xbfbff5e4,
sapi_headers=0x2853c790) at mod_php4.c:259
#1 0x28370f79 in sapi_add_header_ex (header_line=0x8be0a0c
Content-Encoding, header_line_len=22, duplicate=1 '\001',
replace=1 '\001') at SAPI.c:557
#2 0x283828ac in zif_ob_gzhandler (ht=2, return_value=0x8bdb86c,
this_ptr=0x0, return_value_used=1) at zlib.c:1273
#3 0x2835178e in call_user_function_ex (function_table=0x80de080,
object_pp=0x0, function_name=0x8d7718c,
retval_ptr_ptr=0xbfbff7a8, param_count=2, params=0xbfbff75c,
no_separation=1, symbol_table=0x0)
at zend_execute_API.c:532
#4 0x28376197 in php_end_ob_buffer (send_buffer=1 '\001', just_flush=0
'\000') at output.c:177
#5 0x2837652f in php_end_ob_buffers (send_buffer=1 '\001') at
output.c:267
#6 0x2836b907 in php_request_shutdown (dummy=0x0) at main.c:775
#7 0x28368442 in php_apache_request_shutdown (dummy=0x0) at
mod_php4.c:390
#8 0x80514f2 in run_cleanups ()
#9 0x805cd15 in make_child ()
Cannot access memory at address 0x3dc26069.
#0 0x2836810e in sapi_apache_header_handler (sapi_header=0xbfbff5e4,
sapi_headers=0x2853c790) at mod_php4.c:259
259 table_set(r-headers_out, header_name,
header_content);
(gdb) list
254 if (!strcasecmp(header_name, Content-Type)) {
255 r-content_type = pstrdup(r-pool,
header_content);
256 } else if (!strcasecmp(header_name, Set-Cookie)) {
257 table_add(r-headers_out, header_name,
header_content);
258 } else {
259 table_set(r-headers_out, header_name,
header_content);
260 }
261
262 *p = ':'; /* a well behaved header handler shouldn't
change its original arguments */
263
(gdb) p r-headers_out
Cannot access memory at address 0x84.
--
Edit this bug report at http://bugs.php.net/?id=20211edit=1
#19919 [Opn-Ctl]: segmentation violation in sapi_apache_header_handler, mod_php4.c line 208
ID: 19919
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Critical
Bug Type: Reproducible crash
Operating System: FreeBSD 4.7
PHP Version: 4.2.3, 4.3.0-Dev
Previous Comments:
[2002-11-01 05:43:44] [EMAIL PROTECTED]
Hi all,
I see this happen here too ... Also FreeBSD 4.7
and PHP from cvs ...
[2002-10-21 15:20:22] [EMAIL PROTECTED]
Still core dumps using the latest snapshot.
PHP Version 4.3.0-dev
System FreeBSD Server-0-2. 4.7-STABLE FreeBSD
4.7-STABLE #27: Mon Oct i386
Build Date Oct 17 2002 13:19:31
Configure './configure' '--with-apxs=/usr/local/sbin/apxs'
Command'--with-config-file-path=/usr/local/etc'
'--enable-versioning' '--with-regex=system'
'--without-gd'
'--without-mysql' '--enable-debug' '--with-imap'
'--with-pgsql' '--with-gettext' '--enable-track-vars'
'--enable-wddx' '--disable-magic-quotes'
'--enable-short-tags' '--enable-debug' '--with-zlib'
'--with-imap=/usr/local' '--with-pgsql=/usr/local'
'--enable-wddx' '--with-gettext=/usr/local'
'--enable-sockets' '--enable-trans-sid'
'--with-expat-dir=/
usr/local' '--prefix=/usr/local'
'i386-portbld-freebsd4.7'
Server API Apache
Virtualdisabled
Directory
Support
Configuration /usr/local/www/data/php.ini
File
(php.ini)
Path
PHP API20020307
PHP Extension 20020429
Zend 20021010
Extension
Debug Buildyes
Thread Safety disabled
Registered php, http, ftp, compress.zlib
PHP Streams
--
Date: Mon, 21 Oct 2002 15:57:02 GMT
Core was generated by `httpd'.
Program terminated with signal 11, Segmentation fault.
#0 0x28309a83 in sapi_apache_header_handler (sapi_header=0xbfbfe3c0,
sapi_headers=0x2836f510)
at
/home/wgate/mod_php4/work/php4-200210160300/sapi/apache/mod_php4.c:188
#0 0x28309a83 in sapi_apache_header_handler (sapi_header=0xbfbfe3c0,
sapi_headers=0x2836f510)
at
/home/wgate/mod_php4/work/php4-200210160300/sapi/apache/mod_php4.c:188
#1 0x282c88dd in sapi_header_op (op=SAPI_HEADER_ADD, arg=0xbfbfe410)
at /home/wgate/mod_php4/work/php4-200210160300/main/SAPI.c:629
#2 0x2827cd09 in php_setcookie (name=0x824d564 TICS0, name_len=5,
value=0x82e7024
TG9naW58YToxMzp7czo1OiJCb3hJRCI7czoxMjoiMDAwMDAwMDAyNzI4IjtzOjc6IkJveFR5cGUiO3M6MToiNCI7czoxMzoiQ2hhbm5lbE51bWJlciI7czoxOiIwIjtzOjQ6Ik5vZGUiO3M6MToiMCI7czo5OiJTZXNzaW9uSUQiO3M6MTY6IjJNMVZFRlEwVVI4OFBF...,
value_len=2200, expires=0, path=0x824d724 /, path_len=1,
domain=0x824d6a4 , domain_len=0, secure=0)
at
/home/wgate/mod_php4/work/php4-200210160300/ext/standard/head.c:133
#3 0x2827cdcf in zif_setcookie (ht=5, return_value=0x8220f64,
this_ptr=0x0,
return_value_used=0)
at
/home/wgate/mod_php4/work/php4-200210160300/ext/standard/head.c:155
#4 0x28302338 in execute (op_array=0x81b6c80)
at
/home/wgate/mod_php4/work/php4-200210160300/Zend/zend_execute.c:1599
#5 0x282e581b in call_user_function_ex (function_table=0x80cef00,
object_pp=0x0, function_name=0x81c2964, retval_ptr_ptr=0xbfbff1b8,
param_count=2, params=0x824d924, no_separation=1,
symbol_table=0x0)
at
/home/wgate/mod_php4/work/php4-200210160300/Zend/zend_execute_API.c:561
#6 0x282e50e4 in call_user_function (function_table=0x80cef00,
object_pp=0x0,
function_name=0x81c2964, retval_ptr=0x82c3c24, param_count=2,
params=0xbfbff234)
at
/home/wgate/mod_php4/work/php4-200210160300/Zend/zend_execute_API.c:403
#7 0x282550a3 in ps_call_handler (func=0x81c2964, argc=2,
argv=0xbfbff234)
at
/home/wgate/mod_php4/work/php4-200210160300/ext/session/mod_user.c:60
#8 0x2825550c in ps_write_user (mod_data=0x2836e570,
key=0x81fc2a4 10a5228266dd083119c5df2c9d5f0518,
val=0x80b2024
Login|a:13:{s:5:\BoxID\;s:12:\2728\;s:7:\BoxType\;s:1:\4\;s:13:\ChannelNumber\;s:1:\0\;s:4:\Node\;s:1:\0\;s:9:\SessionID\;s:16:\2M1VEFQ0UR88PE0R\;s:9:\LoginType\;s:2:\WG\;s:6:\TocsIP\;s:17:\17...,
vallen=1650)
at
/home/wgate/mod_php4/work/php4-200210160300/ext/session/mod_user.c:148
#9 0x28251b2c in php_session_save_current_state ()
at
/home/wgate/mod_php4/work/php4-200210160300/ext/session/session.c:676
#10 0x282544e9 in php_session_flush ()
at
/home/wgate/mod_php4/work/php4-200210160300/ext/session/session.c:1553
#11 0x2825450c in zif_session_write_close (ht=0,
return_value=0x82083a4,
this_ptr=0x0, return_value_used=0)
at
/home/wgate/mod_php4/work/php4-200210160300/ext/session/session.c:1562
#12 0x28302338 in execute (op_array=0x81b6e80)
at
#18588 [Opn-Fbk]: pointer mismatch
ID: 18588 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Warning Operating System: OSF1 V4.0 1530 (Tru64) PHP Version: 4CVS-2002-08-14 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip And NOT the pre2! Previous Comments: [2002-11-01 05:43:28] [EMAIL PROTECTED] In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/ctype/ctype.c:23: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:60: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:85: warning: redefinition of `uchar' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/sys/types.h:580: warning: `uchar' previously declared here /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c: In function `exif_process_IFD_in_JPEG': /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/ftp/php_ftp.c:26: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/ftp/ftp.c:22: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/mbstring/mbfilter_ja.c:86: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/mbstring/mbfilter_cn.c:29: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/mbstring/mbfilter_tw.c:29: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list'
#19404 [Csd]: phpMyAdmin does not work properly anymore
ID: 19404 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: mbstring related Operating System: SuSE Linux 8.0 PHP Version: 4.2.3 New Comment: IMPORTANT NOTICE: This page is not intended to support ANY KINDS OF phpMyAdmin RELATED THINGS. If you are looking for information about phpMyAdmin, please visit http://www.phpmyadmin.net/. Thank you. -- I'm not sure what is going on here, but actually google takes you to this page with a simple phrase phpMyAdmin not work. Anyway the first-four-characters-lost problem is completely fixed in both STABLE and DEVELOPMENT version of CVS snapshots. Previous Comments: [2002-11-01 04:32:09] [EMAIL PROTECTED] Is it fixed in STABLE CVS or LATEST CVS? Also how come there are comments here like in other languages and OT comments like i want to make a good forum for my homepage [2002-10-31 20:13:55] [EMAIL PROTECTED] Úíæä ÇáßæíÊ [2002-10-31 13:16:43] [EMAIL PROTECTED] 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. [2002-10-31 12:07:09] [EMAIL PROTECTED] This bug was fixed long time ago in CVS. Stop posting any more comments here. Thank you. [2002-10-31 10:10:37] [EMAIL PROTECTED] Got the same error (first four characters left off strings) using another (not phpMyAdmin) script on: FreeBSD with PHP (4.2.3) and MySQL (3.23.52) Looks like a PHP/MySQL bug, not phpMyAdmin. 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/19404 -- Edit this bug report at http://bugs.php.net/?id=19404edit=1
#5919 [Com]: stri_replace() to compliment str_replace()
ID: 5919 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: Slackware Linux 7.0 PHP Version: 4.3.0 New Comment: What about just adding a parameter to the existing function, rather than making a whole new function? You could just put sensitive or insensitive (maybe callous?) or something on the end: str_replace($a, $b, $c, sensitive) I think that some other languages (maybe the ill-fated Oracle Media Objects) have that. Another parameter could be match so that if $a=street $b= avenue $c= 1313 Mockingbird Street the result would be 1313 Mockingbird Avenue the idea being that the search routine realized that Street was capitalized, so therefore Avenue should match the case. Previous Comments: [2002-10-30 05:55:03] [EMAIL PROTECTED] Well, if you really need it you can always hire a competent developer to do it, it's Open Source after all... [2002-10-30 04:49:55] [EMAIL PROTECTED] In reply to [EMAIL PROTECTED], perhaps the reason people capable of adding this feature don't is because they have reached the level where they are able to understand ereg_replace sufficiently. Unfortunately not all developers can. It's elitist to argue that novices should be denied an obviously useful function until they have mastered the language. Not to mention that this function would speed up the development time for a lot of developers. [2002-05-25 18:42:29] [EMAIL PROTECTED] Nothing is stopping you from submitting a patch that implements this. People generally add the features they need. Apparently nobody capable of writing this feature has ever needed it. (That might tell you something) [2002-05-25 18:26:11] [EMAIL PROTECTED] I think it's a shame that two years after this feature was requested it has not been implemented... Lots of people are missing this feature and therefore it would be a great addition to PHP... If anyone knows how to make a patch for this, please do so... I am sure it would be appreciated by many. [2002-05-21 20:09:48] [EMAIL PROTECTED] Russians call the '@', little dog, 'sabachkee'. Anyway, I like the idea of stri_replace because the only alternative is a slower, and more complex usage of [eregi|pregi]_replace. And if one is replacing a lot of symbols, (like I am), and not just strings, then extensive knowledge of regex is required , (which I don't have yet), to replace all the symbols. I'm trying to escape all the key words and key symbols in Oracle's applications. Works great with str_replace, **IF** I want to change the whole string to upper or lower case, or use a function of my own. Otherwise, it sucks. I am implementing one of my own for now though, (actually copying the non recursive one under 'str_replace()'. To see an example of it, see: http://www.qweeka.com/db_tools.php after memorial day. 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/5919 -- Edit this bug report at http://bugs.php.net/?id=5919edit=1
#20179 [Com]: Apache ./configure fails after a static installation of php with oci8 support.
ID: 20179 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: OCI8 related Operating System: Linux 2.4.7-10smp (RedHat 7.2) PHP Version: 4.2.3 New Comment: I got the latest cvs snapshot, and got the following errors during `make` after doing `./configure --enable-socktes --with-mysql --with-oracle=/home/oracle/OraHome1 --with-apache=../apache_1.3.27`: ext/mysql/libmysql/my_tempnam.o: In function `my_tempnam': /root/php4-200211010900/ext/mysql/libmysql/my_tempnam.c:103: the use of `tempnam' is dangerous, better use `mkstemp' ext/oci8/oci8.o: In function `php_oci_init_globals': /root/php4-200211010900/ext/oci8/oci8.c:445: undefined reference to `OCIEnvInit' /root/php4-200211010900/ext/oci8/oci8.c:451: undefined reference to `OCIHandleAlloc' ext/oci8/oci8.o: In function `zm_startup_oci': /root/php4-200211010900/ext/oci8/oci8.c:475: undefined reference to `OCIInitialize' ext/oci8/oci8.o: In function `zm_shutdown_oci': /root/php4-200211010900/ext/oci8/oci8.c:599: undefined reference to `OCIHandleFree' ext/oci8/oci8.o: In function `_oci_stmt_list_dtor': /root/php4-200211010900/ext/oci8/oci8.c:750: undefined reference to `OCIHandleFree' /root/php4-200211010900/ext/oci8/oci8.c:758: undefined reference to `OCIHandleFree' ext/oci8/oci8.o: In function `_oci_conn_list_dtor': /root/php4-200211010900/ext/oci8/oci8.c:807: undefined reference to `OCITransRollback' /root/php4-200211010900/ext/oci8/oci8.c:820: undefined reference to `OCIHandleFree' /root/php4-200211010900/ext/oci8/oci8.c:832: undefined reference to `OCIHandleFree' ext/oci8/oci8.o: In function `_oci_descriptor_list_dtor': /root/php4-200211010900/ext/oci8/oci8.c:887: undefined reference to `OCIDescriptorFree' ext/oci8/oci8.o: In function `oci_error': /root/php4-200211010900/ext/oci8/oci8.c:973: undefined reference to `OCIErrorGet' ext/oci8/oci8.o: In function `oci_ping': /root/php4-200211010900/ext/oci8/oci8.c:1008: undefined reference to `OCIServerVersion' ext/oci8/oci8.o: In function `oci_new_desc': /root/php4-200211010900/ext/oci8/oci8.c:1158: undefined reference to `OCIDescriptorAlloc' ext/oci8/oci8.o: In function `oci_setprefetch': /root/php4-200211010900/ext/oci8/oci8.c:1307: undefined reference to `OCIAttrSet' /root/php4-200211010900/ext/oci8/oci8.c:1322: undefined reference to `OCIAttrSet' ext/oci8/oci8.o: In function `oci_parse': /root/php4-200211010900/ext/oci8/oci8.c:1349: undefined reference to `OCIHandleAlloc' /root/php4-200211010900/ext/oci8/oci8.c:1356: undefined reference to `OCIHandleAlloc' /root/php4-200211010900/ext/oci8/oci8.c:1364: undefined reference to `OCIStmtPrepare' /root/php4-200211010900/ext/oci8/oci8.c:1374: undefined reference to `OCIHandleFree' /root/php4-200211010900/ext/oci8/oci8.c:1378: undefined reference to `OCIHandleFree' ext/oci8/oci8.o: In function `oci_execute': /root/php4-200211010900/ext/oci8/oci8.c:1429: undefined reference to `OCIAttrGet' /root/php4-200211010900/ext/oci8/oci8.c:1459: undefined reference to `OCIStmtExecute' /root/php4-200211010900/ext/oci8/oci8.c:1497: undefined reference to `OCIAttrGet' /root/php4-200211010900/ext/oci8/oci8.c:1525: undefined reference to `OCIParamGet' /root/php4-200211010900/ext/oci8/oci8.c:1538: undefined reference to `OCIAttrGet' /root/php4-200211010900/ext/oci8/oci8.c:1552: undefined reference to `OCIAttrGet' /root/php4-200211010900/ext/oci8/oci8.c:1569: undefined reference to `OCIAttrGet' /root/php4-200211010900/ext/oci8/oci8.c:1583: undefined reference to `OCIAttrGet' /root/php4-200211010900/ext/oci8/oci8.c:1597: undefined reference to `OCIAttrGet' /root/php4-200211010900/ext/oci8/oci8.c:1705: undefined reference to `OCIDefineByPos' ext/oci8/oci8.o: In function `oci_fetch': /root/php4-200211010900/ext/oci8/oci8.c:1757: undefined reference to `OCIStmtFetch' /root/php4-200211010900/ext/oci8/oci8.c:1794: undefined reference to `OCIStmtSetPieceInfo' /root/php4-200211010900/ext/oci8/oci8.c:1806: undefined reference to `OCIStmtFetch' ext/oci8/oci8.o: In function `oci_loadlob': /root/php4-200211010900/ext/oci8/oci8.c:1866: undefined reference to `OCILobFileOpen' /root/php4-200211010900/ext/oci8/oci8.c:1879: undefined reference to `OCILobGetLength' /root/php4-200211010900/ext/oci8/oci8.c:1894: undefined reference to `OCILobRead' /root/php4-200211010900/ext/oci8/oci8.c:1926: undefined reference to `OCILobFileClose' ext/oci8/oci8.o: In function `_oci_open_session': /root/php4-200211010900/ext/oci8/oci8.c:2179: undefined reference to `OCIHandleAlloc' /root/php4-200211010900/ext/oci8/oci8.c:2192: undefined reference to `OCIHandleAlloc' /root/php4-200211010900/ext/oci8/oci8.c:2205: undefined reference to `OCIAttrSet' /root/php4-200211010900/ext/oci8/oci8.c:2219: undefined reference to `OCIAttrSet' /root/php4-200211010900/ext/oci8/oci8.c:2233: undefined reference to `OCIAttrSet' /root/php4-200211010900/ext/oci8/oci8.c:2246: undefined
#20214 [NEW]: Scripts included via HTTP don't show up in get_included_files
From: [EMAIL PROTECTED] Operating system: RH 7.3 PHP version: 4CVS-2002-11-01 PHP Bug Type: Zend Engine 2 problem Bug description: Scripts included via HTTP don't show up in get_included_files Please consider the following script. ? include(http://www.php.net/index.php;); print_r(get_included_files()); ? Using require(), require_once() or include_once() causes http://www.php.net/index.php; to appear in get_included_files()'s return value. -- Edit bug report at http://bugs.php.net/?id=20214edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20214r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20214r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20214r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20214r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20214r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20214r=support Expected behavior: http://bugs.php.net/fix.php?id=20214r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20214r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20214r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20214r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20214r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20214r=dst IIS Stability: http://bugs.php.net/fix.php?id=20214r=isapi
#19758 [Bgs-Csd]: Loading extensions isn't functional
ID: 19758 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Closed Bug Type: Dynamic loading Operating System: Win 2000 Server PHP Version: 4.2.3 New Comment: For those who read this, here was the resolution to the problem: php_mssql.dll uses other dlls to function. These DLL's are located in the DLL directory under the php directory. These need to be placed it the System32 directory on your machine. In my particular case, the ntwdblib.dll wasn't in the directory. Once placed it worked fine. However, I would still call this a bug. The Error message incorrectly notifies us of this problem. It says can't find php_mssql.php dll, but acctually it should of said ntwdblib.dll DLL not found Previous Comments: [2002-10-07 13:09:18] [EMAIL PROTECTED] My appologizes for posting this report, if this truly isn't a bug. However, Win 2000 Server comes with the mssql drivers, so all that is needed is to load the php_mssql.dll. But, your extenesion_dir isn't functioning so I can't do that. I find it hard to believe, that with the correct configuration for the extenesion_dir, and that it wouldn't ready any dll's in the specified directory, you don't call this a bug. I said before that I've installed php on 5 other windows 2000 computers, so I know my php.ini is correct. Thanks for the help. I just hope support doesn't send me back here. [2002-10-05 02:53:25] [EMAIL PROTECTED] Sorry, but the bug system is not the appropriate forum for asking support questions. 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 Thank you for your interest in PHP. You need to install the MSSSQL client DLLs. [2002-10-04 15:17:10] [EMAIL PROTECTED] Well, since I thought I might have something miss installed, I've gone ahead and re-started my Win2000 Server installation. I'm back to the same problem however. Error Message: Unable to load dynamic library 'd:\php\extensions\php_mssql.dll' - The specified module could not be found Any directory I specify for the extension_dir dll's, won't work. I've tried, d:\php\extensions, d:\php\\extensions\, d:\\php\\extensions, d:\\php\exetensions\\, d:/php/extensions, d://php//extensions, d://php/extensions/, d://php//extensions// I've attempted as well to move the dll into the system 32 directory, and in the same directory has the php.exe file. No luck. Below are my specifications: Server: Dell Power App 120 Server, SCSI hard drives. OS: Window 2000 Server running IIS 5 PHP: Version 4.2.3 running ISAP installation Php ini file : c:\WINNT\php.ini Php directory : d:\php Extension directory : d:\php\extensions Note: I've installed this same version on 6 other Win2000 clients (Pro and Server) with IIS 5, and have not run into this problem before. The only main difference is that its a Power App Server, with SCSI drives. -- Edit this bug report at http://bugs.php.net/?id=19758edit=1
#20215 [NEW]: fputs(); (Line Feed / Carriage Return)
From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version: 4.2.3
PHP Bug Type: Filesystem function related
Bug description: fputs(); (Line Feed / Carriage Return)
To every writings the function fput adds jumps of lines in too much.
Sample script :
FORM ACTION = ?save=1 METHOD = post
TEXTAREA NAME = contenu ROWS=10 COLS=40
?
$fichier = fichier.txt;
if($save) {
$fp = fopen($fichier, w);
fputs($fp, stripslashes($contenu));
fclose($fp);
}
readfile($fichier);
?
/TEXTAREABR
INPUT TYPE = submit VALUE = Enregistrer
/FORM
--
Edit bug report at http://bugs.php.net/?id=20215edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20215r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20215r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20215r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20215r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20215r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20215r=support
Expected behavior: http://bugs.php.net/fix.php?id=20215r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20215r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20215r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20215r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20215r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20215r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20215r=isapi
#20215 [Opn-Fbk]: fputs(); (Line Feed / Carriage Return)
ID: 20215
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: Windows 2000
PHP Version: 4.2.3
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
Previous Comments:
[2002-11-01 16:05:39] [EMAIL PROTECTED]
To every writings the function fput adds jumps of lines in too much.
Sample script :
FORM ACTION = ?save=1 METHOD = post
TEXTAREA NAME = contenu ROWS=10 COLS=40
?
$fichier = fichier.txt;
if($save) {
$fp = fopen($fichier, w);
fputs($fp, stripslashes($contenu));
fclose($fp);
}
readfile($fichier);
?
/TEXTAREABR
INPUT TYPE = submit VALUE = Enregistrer
/FORM
--
Edit this bug report at http://bugs.php.net/?id=20215edit=1
#20023 [Fbk-Opn]: Page Fault on Socket read
ID: 20023 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Sockets related Operating System: Win 98 SP2 PHP Version: 4.2.2 4.3 New Comment: I tried again with 4.3 Build Nov 1, 2002 16:12:01 and no luck: socket_get_status complains over the result from socket_select stating that this is not a valid stream resource, socket_last_error says: 0 and socket_get_peername knows about the correct ip and port. Then comes socket_read and dies with a page fault in module unknown at :0003. This occurs either upon entering a character in a telnet client on the same machine or upon closing the connection from such a client prior to entering anything from there. Killing the telnet client results in a page fault in php4ts. My installation is without any php related stuff in %WINDIR% or %WINSYSDIR%, just a PATH set to the folder containing the .EXE. I launch the script from a CLI set to the folder of the .EXE with the command: php -f absolute path to script.php extension_dir is specified absolutely in php.ini and the output of phpinfo() looks reasonable (sockets enabled and path to extensions correctly specified). A parallel inst of 4.2.2 running the same script can read the characters from the telnet client and dies only when the telnet client is killed without a correct shutdown of the socket. Previous Comments: [2002-10-28 07:55:57] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-25 13:09:03] [EMAIL PROTECTED] I didn't update - I did a new parallel inst of 4.3 obviously leading to some inst issues. These are covered in another bug thread because they seem to be due to the environmental diffences between CGI and module mode. One thing is certain: 4.3 behaves different from 4.2.2 using the same inst strategy - I will try to sort it out. Sven [2002-10-24 01:55:00] [EMAIL PROTECTED] you most likely didn't update PHP correctly. Just make sure you first REMOVE all existing PHP related binaries (dlls, etc.) and then install the new version. [2002-10-23 09:47:58] [EMAIL PROTECTED] I did as you suggested. But now it isn't working at all anymore: as with 4.2.2 I can do everything up to (but not including) entering a character into the telnet client. doing socket_read or even an echo(socket_strerror(socket_last_error($client[$i]))); upon recieving that character triggers a Page Fault in php4ts. [2002-10-22 10:19:05] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20023 -- Edit this bug report at http://bugs.php.net/?id=20023edit=1
#19499 [Com]: Populating a large array of arrays doesn't scale linearly
ID: 19499
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Performance problem
Operating System: WinME
PHP Version: 4.2.3
New Comment:
So I assume you get linear time on non-Windows machines? I don't have
a Linux machine handy, but you're saying allocating 35 MB should be
trivial on that platform???
Previous Comments:
[2002-09-26 18:06:35] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Well, there is a very good reason when the 2nd example shows linear
increase in time. The reason being that you are making a copy on write
of $otherBits array, which means unless you modify that data all it
will contain, is a pointer to a single $otherBits array. This means
that you've created n times pointers to a single array.
The 1st example actually causes the creation of n times arrays and
their subsequent assignment into storage array. Meaning that you are
doing using up a lot more memory. Given the fact Window's memory
menager is not the most effecient thing aroung and you may be going
into swap you do not get a linear time increase.
Just as point of reference, the 1st test caused 35.5 megs of memory to
be allocated, while the 2nd only caused 5.1 megs to be allocated.
[2002-09-19 18:37:41] [EMAIL PROTECTED]
Here is a somewhat more useful and probably more accurate repro script
that will show how much time we have spent (so far) every 125
iterations. It avoids the de-allocation time penalty we get with the
long repro script included in the last contribution. It also allows
for easier plotting in your favorite spreadsheet software. (just
adjust the print function to output the numbers, copy and paste them
into the spreadsheet)
?php
function getmicrotime ( )
{
list ( $usec, $sec ) = explode ( , microtime () );
return ( (float) $usec + (float) $sec );
}
set_time_limit ( 0 );
$line =
'x','s','n','f','n','a','c','b','y','e',?,'s','s','o','o','p','o','o','p','o','c','l','e';
$storage = array ( );
$start_time = getmicrotime ( );
for ( $times = 0; $times 8000; $times += 125,
print ( $times = . ( getmicrotime ( ) - $start_time ) . \n ) )
{
for ( $a = 0; $a 125; $a++ )
{
$storage[] = explode ( ,, $line );
}
}
?
I ran this new script on an Athlon 900 machine running Windows 98 and
got the following results:
125 = 0.012104988098145
250 = 0.036535978317261
375 = 0.088302969932556
500 = 0.19990205764771
625 = 0.37106597423553
750 = 0.6065239906311
875 = 0.90365397930145
1000 = 1.253583073616
1125 = 1.6664990186691
1250 = 2.1331380605698
1375 = 2.6527270078659
1500 = 3.2355539798737
1625 = 3.8985589742661
1750 = 4.68299305439
1875 = 5.6240310668945
2000 = 6.781278014183
2125 = 8.2345640659332
2250 = 10.012183070183
2375 = 12.181863069534
2500 = 14.771154046059
2625 = 17.770683050156
2750 = 21.163032054901
2875 = 24.917178034782
3000 = 28.996559023857
3125 = 33.361265063286
3250 = 37.975730061531
3375 = 42.820783019066
3500 = 47.88387298584
3625 = 53.16420006752
3750 = 58.659978985786
3875 = 64.360311985016
4000 = 70.265311002731
4125 = 76.383864998817
4250 = 82.977863073349
4375 = 90.194562077522
4500 = 97.04804659
4625 = 103.93731307983
4750 = 111.02486097813
4875 = 118.31274199486
5000 = 125.80013000965
5125 = 133.48784804344
5250 = 141.95425903797
5375 = 152.91942405701
5500 = 161.20297205448
5625 = 169.70409607887
5750 = 178.36672604084
5875 = 187.21697604656
6000 = 196.26174402237
6125 = 205.5024510622
6250 = 214.93042397499
6375 = 224.54999697208
6500 = 234.35991597176
6625 = 244.3618350029
6750 = 254.5541960001
6875 = 264.93612003326
7000 = 275.82330298424
7125 = 286.85267901421
7250 = 298.12616407871
7375 = 309.47215306759
7500 = 320.87820506096
7625 = 332.56023800373
7750 = 344.28222107887
7875 = 356.19291603565
8000 = 368.28939902782
HTH,
Oli
[2002-09-19 08:36:33] [EMAIL PROTECTED]
Steps to Reproduce:
0 - Standard PHP 4.2.3 installed using the installer.
1 - Create an array of strings using something like explode on a CSV
line
2 - Add that array to another array
3 - Repeat steps 1 and 2 1000, 2000, 3000, 4000, 5000 and 6000 times
Example snippet (short):
$times = 6000; /* change this to 1000-6000 */
$line =
'x','s','n','f','n','a','c','b','y','e',?,'s','s','o','o','p','o','o','p','o','c','l','e';
$storage = array ( );
for ( $a = 0; $a $times; $a++ )
{
$bits = explode ( ,, $line );
$storage[] = $bits;
}
Expected Behaviour:
The time it takes
#20170 [Bgs]: PHP session don't save variables data on Windows.
ID: 20170
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Session related
Operating System: Windows XP
PHP Version: 4.3.0-pre2
New Comment:
You are right. Thanks!
But, I still got no session functionality unless I pass the session id
along GET or POST data to other pages. The cookies are been accepted,
so I don't have a clue of why this is happenning. Any idea?
Best regards,
Josue
Previous Comments:
[2002-10-30 19:00:35] [EMAIL PROTECTED]
RTFM:
http://www.php.net/manual/en/ref.session.php
If register_globals is disabled, only members of the global
associative array $_SESSION can be registered as session
variables. The restored session variables will only be
available in the array $_SESSION.
[2002-10-30 08:55:06] [EMAIL PROTECTED]
1. What I did:
---file1.php---
?php
session_start();
session_register('stack');
$stack[]='word1';
header('Location: file2.php');
?
---file2.php---
?php
session_start();
$stack[]='word2';
print_r($stack);
?
2. What I expected to have happen:
---output---
Array ( [0] = word1 [1] = word2 )
3. What actually have happened:
---output---
Array ( [0] = word2 )
[2002-10-30 08:08:11] [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.
[2002-10-30 07:53:41] [EMAIL PROTECTED]
PHP session don't save variables data on Windows.
This is a bug described long ago and registered in PHP.net forum.
Does anyone knows how to make a PHP 4.2.x ou 4.3.x session work as it
should be.
I am using Windows XP + Apache 1.3.26 + PHP 4.3.0-pre2.
Thanks in advance.
Best regards,
Josue
--
Edit this bug report at http://bugs.php.net/?id=20170edit=1
#19553 [Com]: Failed html tags when trans sid is enabled
ID: 19553 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Session related Operating System: Linux PHP Version: 4.2.3 New Comment: fixed in php-4.3.2pre2 Previous Comments: [2002-10-14 19:26:55] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2002-09-26 20:17:05] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-09-25 07:37:03] [EMAIL PROTECTED] may be similar to http://bugs.php.net/bug.php?id=17236 [2002-09-25 07:27:11] [EMAIL PROTECTED] This looks to me as if the rewriter would fail to clear a buffer and thus insert random data into the stream. I would appreciate an example script which reproduces the behaviour. [2002-09-23 02:34:35] [EMAIL PROTECTED] had a similar effect last week, looks like trans_sid cutting off bytes at buffer ends under certain (not yet identified) circumstances from what i have seen it mostly happens at the very end of a document and only sometimes on the border of http 1.1 chunks might have been there for quite some time without being noticed as it will usually only cut off the trailing lt;bodygt;lt;htmlgt; which do not affect output in common browsers ... 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/19553 -- Edit this bug report at http://bugs.php.net/?id=19553edit=1
#19553 [Com]: Failed html tags when trans sid is enabled
ID: 19553 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Session related Operating System: Linux PHP Version: 4.2.3 New Comment: sorry not php-4.3.2pre2 but php-4.3.0pre2 ;) Previous Comments: [2002-11-01 18:43:47] [EMAIL PROTECTED] fixed in php-4.3.2pre2 [2002-10-14 19:26:55] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2002-09-26 20:17:05] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-09-25 07:37:03] [EMAIL PROTECTED] may be similar to http://bugs.php.net/bug.php?id=17236 [2002-09-25 07:27:11] [EMAIL PROTECTED] This looks to me as if the rewriter would fail to clear a buffer and thus insert random data into the stream. I would appreciate an example script which reproduces the behaviour. 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/19553 -- Edit this bug report at http://bugs.php.net/?id=19553edit=1
#17931 [NoF-Csd]: Segfault when passing array as second arg to xslt_set_error_handler
ID: 17931 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Closed Bug Type: XSLT related Operating System: Linux PHP Version: 4.2.1 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. It's fixed in the current version and there's a testcase for this as well: bug17931.phpt Previous Comments: [2002-10-19 01:00:03] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2002-10-03 13:42:56] [EMAIL PROTECTED] ifstream should be in your stdc++ lib. If you use: LDFLAGS='-lstdc++' ./configure [your flags here] does that help? Here's what I get on my stdc++ lib: $ nm /usr/lib/libstdc++.so | grep vt_3 00036238 D __vt_3ios [2002-08-25 05:43:47] [EMAIL PROTECTED] Recently I downloaded Sablot 0.95 and the two patches ( One for sablot itself and one for PHP ( sablot.c )) It's absolutely the same result. Nothing works. [2002-07-05 15:50:33] [EMAIL PROTECTED] Ah, forgot some more Just compiled it without cli and now i get the following error: Starting web server: apache Cannot load /usr/lib/apache/1.3/libphp4.so into server: /usr/lib/libsablot.so.0: undefined symbol: __vt_3ios failed [2002-07-05 14:59:04] [EMAIL PROTECTED] After installation of the Sablot-CVS my PHP (cli version) doesn't compile anymore. Tested with 4.2.1 and 4.3.0-dev ... Here's the error: /usr/bin/ld: warning: libpng.so.2, needed by /usr/lib/libgd.so, may conflict with libpng.so.3 /usr/lib/libsablot.so: undefined reference to `ios virtual table' /usr/lib/libsablot.so: undefined reference to `fstreambase::fstreambase(int)' /usr/lib/libsablot.so: undefined reference to `istream::ios virtual table' /usr/lib/libsablot.so: undefined reference to `istream::getline(char *, int, char)' /usr/lib/libsablot.so: undefined reference to `ifstream::~ifstream(void)' /usr/lib/libsablot.so: undefined reference to `fstreambase::open(char const *, int, int)' /usr/lib/libsablot.so: undefined reference to `ifstream::ios virtual table' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 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/17931 -- Edit this bug report at http://bugs.php.net/?id=17931edit=1
#20177 [Asn-Csd]: xslt_process adds arg: into all document calls on the xsl sheet.
ID: 20177
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Closed
Bug Type: XSLT related
Operating System: FreeBSD 4.7
PHP Version: 4.2.3
Assigned To: msopacua
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's a test as well (bug20177.phpt).
We now set the baseuri, for the 'arg' scheme, to the currently executed
file. This should be intuitive, but may still be confusing, when
dealing with includes.
Previous Comments:
[2002-10-31 05:40:54] [EMAIL PROTECTED]
It's foremost a documentation problem. But we're looking into making it
more intuitive.
However - using a combination of a filepath and 'arg:/' is discouraged,
when the documents use external files. Relative paths are resolved
based on their file location. Using 'arg://' the file location is
currently undefined - this will be set to $_SERVER['PATH_TRANSLATED']
in future versions and documented properly.
The problem is, that this will not only apply to the xsl sheet in your
example, but also the XML file. This is a design limitation in the
Sablotron library, as xslt_set_base applies to the $xh resource, not a
specific file.
[2002-10-30 15:08:52] [EMAIL PROTECTED]
Using Apache 2.0.43
[2002-10-30 15:04:38] [EMAIL PROTECTED]
Sablot 0.96 and expat 1.95 installed
php-4.2.3:
./configure --enable-xslt --with-xslt-sablot --with-mysql --with-imap
--with-apxs2=/usr/local/apache2/bin/apxs --with-expat=/usr/local
--with-gettext --with-xml --with-mcrypt --enable-ftp --with-tsrm-pth
Problem: When using xslt_process and a arg:xxx, any xslt document()
calls will point to arg:(and what was in the document call)
Example xsl sheet code:
xsl:apply-templates
select=document('/websites/xxx/htdocs/xml/messages.xml')//message[@id='nf-comp']/text[@xml:lang='en']/
would attempt to open:
arg:/websites/xxx/htdocs/xml/messages.xml
If I call the xsl sheet in from a file then it worked fine.
Origanal Code/Syntax Used:
?
$xh = xslt_create();
// set xml file to be used with translation
$xmlfile=$GLOBALS[DOCUMENT_ROOT]./xml/product.xml;
// load dynamic xsl sheet to be used with translation
$xslstyle=http://.$GLOBALS[SERVER_NAME]./styles/product-detail.php?id=.$GLOBALS[HTTP_GET_VARS][id;];
$fp = fopen($xslstyle, r);
$xsltdata[xsldata]=fread($fp, 50);
fclose($fp);
// do the translation
$result = xslt_process($xh, $xmlfile, 'arg:xsldata', NULL, $xsltdata);
?
Fix I used to get around this:
add this line after $xh = xslt_create();
xslt_set_base($xh, file:///);
Working Code:
?
$xh = xslt_create();
// Added to fix trying to open arg:(and the file name)
xslt_set_base($xh, file:///);
// End Added
// set xml file to be used with translation
$xmlfile=$GLOBALS[DOCUMENT_ROOT]./xml/product.xml;
// load dynamic xsl sheet to be used with translation
$xslstyle=http://.$GLOBALS[SERVER_NAME]./styles/product-detail.php?id=.$GLOBALS[HTTP_GET_VARS][id;];
$fp = fopen($xslstyle, r);
$xsltdata[xsldata]=fread($fp, 50);
fclose($fp);
// do the translation
$result = xslt_process($xh, $xmlfile, 'arg:xsldata', NULL, $xsltdata);
?
--
Edit this bug report at http://bugs.php.net/?id=20177edit=1
#18822 [Com]: Error: Failed to Recieve
ID: 18822 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *Mail Related Operating System: WinXP PHP Version: 4.2.2 New Comment: I get this same problem and I have searched every support document available. here is my error: Warning: Failed to Receive in c:\program files\apache group\apache\htdocs\webdex\sendinfo.php on line 21 I have version 4.1.2 Previous Comments: [2002-08-09 00:39:44] [EMAIL PROTECTED] Being marked bogus because this isn't a bug. This is a support issue, for which you can contact the php-general mailing list for more help. [2002-08-09 00:36:13] [EMAIL PROTECTED] Thats REALLY great.. but it still doesn't work for me, therefore it's a bug.. unless you have a solution..? Or maybe I dont understand what a bug is, please expound. Else, please dont call my proble Bogus because it's not a popular problem [2002-08-09 00:33:23] [EMAIL PROTECTED] still, it works for the rest of us. [2002-08-09 00:30:37] [EMAIL PROTECTED] I run WinXP.. PHP.. Apache. For some odd reason.. teh PHP always says Failed to Recieve. I just make a page that only has ? mail([EMAIL PROTECTED], TesT, Test) ? and thats the error I get. In php.ini, I have the SMTP set as localhost, and the sendmail_from = [EMAIL PROTECTED] I run my own SMTP server, and it works, as I send mail from Outlook all the time. Still, PHP doesn't work [2002-08-09 00:24:50] [EMAIL PROTECTED] Sorry, but the bug system is not the appropriate forum for asking support questions. 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 Thank you for your interest in 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/18822 -- Edit this bug report at http://bugs.php.net/?id=18822edit=1
#20217 [NEW]: .htaccess config settings ignored
From: [EMAIL PROTECTED] Operating system: RH Linux 7.3 PHP version: 4.3.0-pre2 PHP Bug Type: Apache2 related Bug description: .htaccess config settings ignored Hi there, This is something I believe I've encountered before (having briefly installed an earlier 4.3.0 snapshot) and now just stumbled over again after upgrading from 4.2.3 to 4.3.0pre2 under Apache2 on Linux. (It may have been the reason I dropped back to 4.2.3 then, IIRC.) Basically, I'm noticing that a significant number of PHP configuration settings in my .htaccess file(s) are being ignored entirely -- settings that worked fine under 4.2.3 (and earlier) and which have remained unmodified. This problem may very well be related to bug #17234. Given this .htaccess snippet: php_flag register_globals off php_flag log_errors on php_flag display_errors on php_flag display_startup_errors on php_flag session.use_trans_sid off php_value include_path .:/var/www/site/_include php_value auto_prepend_file global.php php_value error_log /var/www/site/_log/php_error_log.txt I've determined that only log_errors, display_errors, display_startup_errors, include_path, and error_log are accepted -- the rest are ignored as if they were not specified at all (but can be set in php.ini). A brief test also showed that asp_tags and short_open_tag (as in bug #17234) were ignored in htaccess too. I don't think I'm doing anything wrong, but any suggestions as to a workaround are greatly appreciated -- I depend on these htaccess overrides (particularly auto_prepend_file) and can't move to 4.3.x until they're working flawlessly (in a backward-compatible way with 4.0.x+)... Thanks! -- Edit bug report at http://bugs.php.net/?id=20217edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20217r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20217r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20217r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20217r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20217r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20217r=support Expected behavior: http://bugs.php.net/fix.php?id=20217r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20217r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20217r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20217r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20217r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20217r=dst IIS Stability: http://bugs.php.net/fix.php?id=20217r=isapi
#18119 [Fbk-NoF]: domxml extension: DomDocument-create_element() doesn't work
ID: 18119 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Zend Engine 2 problem Operating System: ALTLinux-2.4.18, glibc 2.2.5 PHP Version: 4.0CVS-2002-07-02 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. Previous Comments: [2002-10-20 21:42:03] [EMAIL PROTECTED] I got the same problem also. I'm using ZendEngine2 (PHP4.3.0_zend2_alpha3). Following are my two test cases. 1. $elm = new DomElement(element); It returns an DomElement object with NO property. I traced the source code, found that the internal constructor function domxml_doc_create_element() was not invoked. 2. $elm = $doc-create_element(element); The method returns NULL. Furthermore, the internal function domxml_doc_create_element() applied on the wrong object $doc instead of $elm ($doc's type changed to XML_ELEMENT_NODE, previously it was XML_DOCUMENT_NODE ). Dump of $doc is like this: domdocument Object ( [name] = #document [url] = [version] = 1.0 [standalone] = -1 [type] = 1 [compression] = -1 [charset] = 1 [0] = 2 [1] = 136550520 [tagname] = element ) Above bugs exist in all Dom* classes and create_* methods. After I compiled php4 with zend1.3.0, above test cases passed, everything became OK. So I believe it is some kind of bug within ZendEnging2. [2002-10-17 22:01:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-07-02 18:11:03] [EMAIL PROTECTED] It seems, that ZendEngine2 breaks create_element() behavior. This method returns NULL instead of DomElement object. There is my test code. ?php $doc = domxml_new_doc(1.0); $root = $doc-create_element(xdocument); $root = $doc-append_child($root); $descr = $doc-create_element(description); $descr = $root-append_child($descr); print $doc-dump_mem(); ? -- Edit this bug report at http://bugs.php.net/?id=18119edit=1
#9044 [Fbk-NoF]: Compiling with latest Openlink ODBC fails with PHP4
ID: 9044 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: ODBC related Operating System: Redhat Linux (Cobalt RAQ2) PHP Version: All PHP4 (402, 404sp1 atleast) New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. Previous Comments: [2002-10-17 09:04:17] [EMAIL PROTECTED] Yes, OpenLink drivers are glibc sensitive - ensure you are using the correct version please. I've had no problems doing several builds of iODBC with PHP4, including the latest 4.2.3. [2002-10-16 12:06:10] [EMAIL PROTECTED] You need to give more detailed information on what exactly the errors are. OpenLink works just fine on the three test platforms I'm using, and has worked fine since 4.1 release. You should really though being using the --with-iodbc flag, as --with-openlink is deprecated. [2002-10-16 10:26:36] [EMAIL PROTECTED] sorry i'm late... (1 year) ... I think teh problem could be the glibc version... I have installed php4.2.2(also 4.2.1 and 4.2.3) + apache(1.3.27 and the now httpd release at this time 2.0.43) in the Red Hat 7.3 version, and everithing works fine (except for a problem in the Openlink lite version driver for SQL-Server whe you make a odbc_exec() call), but when i've tryed to install the same configuration in the redhat 7.2 throws the same make-error taht you comment... try to update to rh 7.3 (maybe 8.0), or update glibc or the lib used to compile... Sorry if i'm wrong... Regards Adriano [2001-02-06 21:52:36] [EMAIL PROTECTED] Copied contents of /ext/odbc/ of PHP404sp1 and tried compiling this with PHP403sp1 ... Compile fine; but Driver Not Capable error continues. [2001-02-03 14:49:56] [EMAIL PROTECTED] Allegedly PHP404sp1 fixes this Openlink problem ... but see bug id http://bugs.php.net/?id=9088edit=1 for why i couldnt get PHP404sp1 to work with apache :( 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/9044 -- Edit this bug report at http://bugs.php.net/?id=9044edit=1
#19373 [Fbk-NoF]: conn.execute($sqlstm) failed for add, update and delete in microsoft access 97
ID: 19373 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: COM related Operating System: Windows 2000 PHP Version: 4.2.3 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. Previous Comments: [2002-10-17 12:32:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-17 11:26:30] [EMAIL PROTECTED] pease try a recent version from snaps.php.net [2002-10-02 19:11:31] [EMAIL PROTECTED] no error message, it just won't execute the sql statement for add, update and delete. select sql statement is ok. [2002-10-02 07:21:46] [EMAIL PROTECTED] do you get any error messages ? [2002-09-12 06:54:16] [EMAIL PROTECTED] like summary, conn.execute($sqlstm) failed for adding, updating and deleting sqlstament against microsoft access (ver. 97) i haven't try it in office access 2000. my test == i get two computer(A and B), with same php.ini file, using the same php script. comp A is installled with php 4.2.2 while comp B is installed with php 4.2.3 after setup, i run the script, comp A can execute the sql statement i gave without problem... while comp B can only perform sql statement (SELECT * FROM TABLENAME) UPDATE, INSERT INTO and DELETE failed for comp B which is using php 4.2.3 i post the following problem already in the php forum please go there to get the script i test. http://www.phpbuilder.com/board/showthread.php?s=threadid=10209715 sincerely, Jimson Chang -- Edit this bug report at http://bugs.php.net/?id=19373edit=1
#18834 [Fbk-NoF]: private mibs and PHP ???
ID: 18834 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: SNMP related Operating System: W2000 PHP Version: 4.2.2 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. Previous Comments: [2002-10-17 20:21:20] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-08-09 12:41:19] [EMAIL PROTECTED] I'm using php 4.2.2, Apache and W2000. I can use snmp functions with standard mibs (in /usr/mibs) but when I want to use private mibs (Cisco, Microsoft...), they are not recognized (I have copy Cisco mibs in /usr/mibs and restart Apache) examples : When I use the OID $result=snmpget $host,$community,.1.3.6.1.4.1.9.3.6.12.0); I obtain a result. but when I use the mib name =.iso.org.dod.internet.private.enterprises.cisco.temporary.chassis.chassisSlots.0, I have a message like this : Warning: Invalid object identifier: .iso.org.dod... Is it a bug ??? -- Edit this bug report at http://bugs.php.net/?id=18834edit=1
#19020 [Fbk-NoF]: Segmentation fault
ID: 19020 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Apache2 related Operating System: AIX 4.3.3 PHP Version: 4.2.2 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. Previous Comments: [2002-10-17 17:54:32] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-09-23 08:43:14] [EMAIL PROTECTED] I am having this same issue with solaris 2.7 and php version 4.2.3. It seems if I remove the line that calls the apache module . . . Apache starts up fine. [2002-08-22 11:45:13] [EMAIL PROTECTED] I hope this tell's you enough # more php_version.h /* automatically generated by configure */ /* edit configure.in to change version number */ #define PHP_MAJOR_VERSION 4 #define PHP_MINOR_VERSION 3 #define PHP_RELEASE_VERSION 0 #define PHP_EXTRA_VERSION -dev #define PHP_VERSION 4.3.0-dev php4-200208211200 apache info: ./httpd -l Compiled in modules: core.c mod_access.c mod_auth.c mod_include.c mod_log_config.c mod_env.c mod_setenvif.c prefork.c http_core.c mod_mime.c mod_status.c mod_autoindex.c mod_asis.c mod_cgi.c mod_negotiation.c mod_dir.c mod_imap.c mod_actions.c mod_userdir.c mod_alias.c mod_so.c # ./httpd -v Server version: Apache/2.0.40 Server built: Aug 16 2002 16:40:35 # ./httpd -V Server version: Apache/2.0.40 Server built: Aug 16 2002 16:40:35 Server's Module Magic Number: 20020628:0 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/prefork -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 -D APR_USE_PROC_PTHREAD_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT=/usr/local/apache2 -D SUEXEC_BIN=/usr/local/apache2/bin/suexec -D DEFAULT_PIDLOG=logs/httpd.pid -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_LOCKFILE=logs/accept.lock -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf apcache configure line ./configure --enable-so --enable-cgi so I guess the mpm would be prefork [2002-08-22 11:20:11] [EMAIL PROTECTED] You really should be using php4.3-dev (latest unstable snapshot) if you are going to be playing with Apache 2.0 Also, which mpm are you using for Apache2? [2002-08-22 11:15:57] [EMAIL PROTECTED] and the last bit (gdb) frame 4 #4 0x1000b7e4 in invoke_cmd (cmd=0x200028a0, parms=0x2ff22988, mconfig=0x2ff208d8, args=0x2ff20968 ) at config.c:736 736 config.c: No such file or directory. in config.c 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/19020 -- Edit this bug report at http://bugs.php.net/?id=19020edit=1
#19954 [Fbk-NoF]: HTTP Response Code not set correctly
ID: 19954 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Apache2 related Operating System: Linux 2.4.19 PHP Version: 4CVS-2002-10-17 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. Previous Comments: [2002-10-17 12:32:01] [EMAIL PROTECTED] I am refering to the 1.3.x API as the old API! [2002-10-17 10:31:08] [EMAIL PROTECTED] When you refer to the old sapi, are you talking about the 1.3.X sapi or previous versions of the apache2filter sapi? [2002-10-17 10:27:17] [EMAIL PROTECTED] I've compiled Apache 2.0.43 and PHP 4.3.0-dev from CVS. I configured PHP with --with-apxs2=/usr/local/apache2/bin/apxs. In my httpd.conf I have the following lines: ErrorDocument 404 /error-404.php ErrorDocument 403 /error-403.php These two scripts DON'T output any header information via header(). They just output some HTML. Now when I try to GET an document that does not exist, I get HTTP/1.1 200 OK and the document /error-404.php instead of a HTTP/1.1 404 Not Found. I think that the problem exists in the apache2filter SAPI since this behaviour does not occur in the old apache SAPI. -- Edit this bug report at http://bugs.php.net/?id=19954edit=1
#20054 [Com]: safe_mode_include_dir not being used correctly
ID: 20054
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Scripting Engine problem
Operating System: Linux - Redhat 7.3
PHP Version: 4.3.0-dev
New Comment:
I've got Apache 2 and PHP 4.3.0-dev on Red Hat 7.2 with /usr/share/pear
in safe_mode_include_dir and I get SAFE MODE Restriction in effect.
The script whose uid is 502 is not allowed to access
/usr/share/pear/Mail.php owned by uid 0 etc., with 'require_once(
Mail.php );' and 'require( Mail.php );' and 'include( Mail.php
);' and 'include( /usr/share/pear/Mail.php );' and every other
variation I can think to try.
Previous Comments:
[2002-10-30 11:37:56] [EMAIL PROTECTED]
The current implementation of safe_mode_include_dir only allows
require/include functions to bypass safe_mode. I've began a discussion
on php-dev on whether or not this should be expanded to include other
file operations. If you have an opinion on the matter, make it known
there (php-dev).
[2002-10-24 12:17:37] [EMAIL PROTECTED]
Correct version (user tried with snapshot too..)
[2002-10-24 02:49:22] [EMAIL PROTECTED]
This is possibly related to Bug #17858.
We've got Apache2 on Redhat 7.3, with safemode in php enabled. We
have safe_mode_gid set to on as well. The safe_mode include directory
is set as follows:
safe_mode_include_dir = /home/staff/ryan/WWW
I've then got the test script:
?php
if ($dir = opendir(/home/staff/ryan/WWW))
{while (($file = readdir($dir)) !== false) {
echo $file\n;
}
closedir($dir);
} else {
echo FAILED;
}
?
That script has the following ownership permissions:
-rw-r--r--1 web nobody229 Oct 24 15:31 test2.php
And /home/staff/ryan/WWW is:
drwxr-xr-x5 ryan staff4096 Oct 21 17:30 WWW
Calling the script displays FAILED on the browser and causes
the two following errors in the error log:
PHP Warning: opendir() [a
href='http://www.php.net/function.opendir'function.opendir/a]: SAFE
MODE Restriction in effect. The script whose uid/gid is 89/99 is not
allowed to access /home/staff/ryan/WWW/ owned by uid/gid 270/110 in
/home/www/DOCS/phptest/test2.php on line 3
PHP Warning: opendir(/home/staff/ryan/WWW/) [a
href='http://www.php.net/function.opendir'function.opendir/a]:
failed to open dir: Inappropriate ioctl for device in
/home/www/DOCS/phptest/test2.php on line 3
Changing the ownership permissions to the same user and/or group
causes the script to execute fine, displaying the contents with no
problems or errors.
It would appear that the safe_mode_include_dir value is not being
used, but I'm also open to the suggesion that I've stuffed up somewhere
else.
For the record, I originally started having problems with 4.2.2
(user and group returned as -1) this was fixed upgrading to 4.3.0-pre1,
but then the include_dir still had problems. I've tested it with
today's snapshot (php4-200210232100) and still have the same problem.
My config options looks like :
./configure --with-mysql=/usr/local/mysql --with-openssl --with-xml
--enable-track-vars --enable-force-cgi-redirect --enable-versioning
--with-apxs2=/usr/local/httpd/bin/apxs --with-zlib --enable-ftp
--enable-sockets --with-gettext --with-imap=/usr/local/imap
--with-imap-ssl
Ummm, help?
Cheers,
Ryan.
--
Edit this bug report at http://bugs.php.net/?id=20054edit=1
