Bug #16626 Updated: Only last cookie set
ID: 16626 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Apache2 related -Operating System: RedHat 7.2 (kernel 2.4.18) i386 +Operating System: All -PHP Version: 4.2.0 +PHP Version: 4.2.1 New Comment: This bug has been fixed in CVS. You can grab a snapshot of the CVS version 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. Thank you for the report, and for helping us make PHP better. Patch committed. Thanks, regina! Previous Comments: [2002-05-12 15:17:09] [EMAIL PROTECTED] Just ran into this problem as i was running apache 2 under win2k with php 4.2.0 installed as apache module. No Cookie seemed to be set correctly. I solved this problem by running PHP as CGI binary. [2002-05-03 01:11:05] [EMAIL PROTECTED] I did fix this problem by modifing "ext/standard/head.c". The diff is below. 124c124 < return sapi_add_header(cookie, strlen(cookie), 0); --- > return sapi_add_header_ex(cookie, strlen(cookie), 0, 0 TSRMLS_CC); PS) This bug should be killed at next version. May be [2002-04-26 16:00:46] [EMAIL PROTECTED] Yeap I have the same problem ... Very interessting is, sometimes works. For Example: I have written a Bulletin Board, so I can't Login (with Cookie) my wife have no problem ... I don't know why. [2002-04-25 00:44:01] [EMAIL PROTECTED] I just want to add, that this is a apache 2.0 compatiblity bug, I'm sure you all tested this out on apache 1.3.24 and it works fine for me. so I think with the shtml bugs that apache is having this could be included with that issue. [2002-04-24 15:13:00] [EMAIL PROTECTED] I can confirm that the replacement function for setcookie by [EMAIL PROTECTED] (send_htCookie) just sets the last cookie in the HTTP response header on my system 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/16626 -- Edit this bug report at http://bugs.php.net/?id=16626&edit=1
Bug #17282 Updated: Identical float values are not identical when compared
ID: 17282 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Operating System: FreeBSD 4.4-STABLE PHP Version: 4.2.1 New Comment: Actually this is documented: http://www.php.net/manual/en/language.types.float.php > I am well aware that there can be errors due to loss of precision, but > in that case, the number should not appear to be _exactly the same_. > There should be some way to tell that they are different. You can tell they are different by comparing them, which obviously almost always fails, but i fyou do this: if (41.96 == 41.96) it will return true ofcourse. There was some discussion on this topic before, and the consensus of the list was not to change anything related to this. regards, Derick Previous Comments: [2002-05-17 02:36:19] [EMAIL PROTECTED] That does not seem right. The numbers appear to be exactly the same. Even if they can't be compared as floats, comparing untyped should work, because they look exactly the same (when var_dump'd and printed). Even if this is in fact bogus, it needs to be documented. I am well aware that there can be errors due to loss of precision, but in that case, the number should not appear to be _exactly the same_. There should be some way to tell that they are different. [2002-05-17 02:16:22] [EMAIL PROTECTED] You can't compare floats like this, a float is an approximation of the number, but never exact the number. This is not a bug, this wouldn't work in most languages, including C -> Bogus [2002-05-16 22:23:02] [EMAIL PROTECTED] This problem also occurs on PHP 4.1.2. The following code fragment produces very odd results: The results are shown below: 41.96 != 41.96 bool(true) t = float(41.96) a[0] = float(41.96) Both variables appear to be the same type, and look the same, yet compare incorrectly with both typed and untyped comparisons. -- Edit this bug report at http://bugs.php.net/?id=17282&edit=1
Bug #17282 Updated: Identical float values are not identical when compared
ID: 17282 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Operating System: FreeBSD 4.4-STABLE PHP Version: 4.2.1 New Comment: That does not seem right. The numbers appear to be exactly the same. Even if they can't be compared as floats, comparing untyped should work, because they look exactly the same (when var_dump'd and printed). Even if this is in fact bogus, it needs to be documented. I am well aware that there can be errors due to loss of precision, but in that case, the number should not appear to be _exactly the same_. There should be some way to tell that they are different. Previous Comments: [2002-05-17 02:16:22] [EMAIL PROTECTED] You can't compare floats like this, a float is an approximation of the number, but never exact the number. This is not a bug, this wouldn't work in most languages, including C -> Bogus [2002-05-16 22:23:02] [EMAIL PROTECTED] This problem also occurs on PHP 4.1.2. The following code fragment produces very odd results: The results are shown below: 41.96 != 41.96 bool(true) t = float(41.96) a[0] = float(41.96) Both variables appear to be the same type, and look the same, yet compare incorrectly with both typed and untyped comparisons. -- Edit this bug report at http://bugs.php.net/?id=17282&edit=1
Bug #14999 Updated: apache_lookup_uri returning array for apache2 instead of object
ID: 14999
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Apache2 related
-Operating System: linux
+Operating System: All
-PHP Version: 4.1.1
+PHP Version: 4.2.1
New Comment:
This bug has been fixed in CVS. You can grab a snapshot of the
CVS version 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.
Thank you for the report, and for helping us make PHP better.
I committed a variant of your patch. Same idea, just done with the
existing macros to reduce diff (and code) verbosity. I had to account
for the fact that rr->request_time and rr->mtime are apr_time_t's
(microseconds) now rather than time_t's (seconds) as well. It should
now be the case that the only difference between apache 2.0's
apache_lookup_uri() and apache 1.3's are the missing byterange and
boundary fields (boundary just now disappeared as of 2.0.37). Is it
worth having those in there with wrong (zero) values? Or should we
just leave them out and document that they're gone? Send me an email
if you have an opinion on the matter. Thanks!
Previous Comments:
[2002-02-18 12:49:53] [EMAIL PROTECTED]
What about this patch ?
has someone try it ?
what is the way of apache2 fonction ?
keep the maximum of backwards compatibility ?
[2002-01-23 17:36:04] [EMAIL PROTECTED]
The Apache request_rec struct has many change between version 1.3 and
2.0. perhaps we should rename this fonction in apache2_lookup_uri
for example the byterange has desapear
here is the patch to be more compatible with apache 1.3 version
PHP_FUNCTION(apache_lookup_uri)
{
pval **filename;
request_rec *rr=NULL;
rr = php_apache_lookup_uri(INTERNAL_FUNCTION_PARAM_PASSTHRU);
if (!rr)
WRONG_PARAM_COUNT;
object_init(return_value);
add_property_long(return_value,"status", rr->status);
if (rr->the_request) {
add_property_string(return_value,"the_request",
rr->the_request, 1);
}
if (rr->status_line) {
add_property_string(return_value,"status_line", (char
*)rr->status_line, 1);
}
if (rr->method) {
add_property_string(return_value,"method", (char
*)rr->method, 1);
}
if (rr->content_type) {
add_property_string(return_value,"content_type", (char
*)rr->content_type, 1);
}
if (rr->handler) {
add_property_string(return_value,"handler", (char
*)rr->handler, 1);
}
if (rr->uri) {
add_property_string(return_value,"uri", rr->uri, 1);
}
if (rr->filename) {
add_property_string(return_value,"filename",
rr->filename, 1);
}
if (rr->path_info) {
add_property_string(return_value,"path_info",
rr->path_info, 1);
}
if (rr->args) {
add_property_string(return_value,"args", rr->args, 1);
}
if (rr->range) {
add_property_string(return_value,"range",(char
*)rr->range, 1);
}
if (rr->boundary) {
add_property_string(return_value,"boundary",(char
*)rr->boundary, 1);
}
add_property_long(return_value,"no_cache", rr->no_cache);
add_property_long(return_value,"no_local_copy",
rr->no_local_copy);
add_property_long(return_value,"allowed", rr->allowed);
add_property_long(return_value,"sent_bodyct",
rr->sent_bodyct);
add_property_long(return_value,"bytes_sent", rr->bytes_sent);
add_property_long(return_value,"clength", rr->clength);
#if MODULE_MAGIC_NUMBER >= 19980324
if (rr->unparsed_uri) {
add_property_string(return_value,"unparsed_uri",
rr->unparsed_uri, 1);
}
if(rr->mtime) {
add_property_long(return_value,"mtime", rr->mtime);
}
#endif
if(rr->request_time) {
add_property_long(return_value,"request_time",
rr->request_time);
}
ap_destroy_sub_req(rr);
}
[2002-01-11 12:59:34] [EMAIL PROTECTED]
this is simple: apache_lookup_uri is returning array on apache2 instead
of object (as it is doing on apache 1.3 and as it is written in
documentation). the array is filled good with right keys and values,
only problem is that it is array and not object
-
Bug #17282 Updated: Identical float values are not identical when compared
ID: 17282 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: FreeBSD 4.4-STABLE PHP Version: 4.2.1 New Comment: You can't compare floats like this, a float is an approximation of the number, but never exact the number. This is not a bug, this wouldn't work in most languages, including C -> Bogus Previous Comments: [2002-05-16 22:23:02] [EMAIL PROTECTED] This problem also occurs on PHP 4.1.2. The following code fragment produces very odd results: The results are shown below: 41.96 != 41.96 bool(true) t = float(41.96) a[0] = float(41.96) Both variables appear to be the same type, and look the same, yet compare incorrectly with both typed and untyped comparisons. -- Edit this bug report at http://bugs.php.net/?id=17282&edit=1
Bug #16769 Updated: Upgraded to Apache 2 with PHP not working
ID: 16769 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Apache2 related Operating System: Windows 2000 PHP Version: 4.2.0 New Comment: I've encountered the exact same problem on Win98. Apache 1.3.23 (Win32) runs PHP/4.2.0 fine, however, Apache 2.0.36 (Win32) crashes with the following error: -- Syntax error on line 946 of (path_to_conf)/httpd.conf: Cannot load (path_to_php)/sapi/php4apache.dll into server: One of the library files needed to run this application cannot be found. -- Previous Comments: [2002-05-03 11:17:17] [EMAIL PROTECTED] i tested php with Apache 2 on windows 2000 and dont work! the entries of MODULES CONFIGS for the Apache 1.2.24 dont run in Apache 2.0.35 [2002-04-23 16:12:16] [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". [2002-04-23 15:53:21] [EMAIL PROTECTED] Basically I tested PHP on the windows binary of apache 1.3.24 and everything was great. However when going to apache 2.0.35, the same entries that worked for apache 1.3.24 seem to cause errors. Apache will only run when I comment out the MODULES CONFIGS in the httpd.conf. I hope this is a known issue, I just do not want to reload the old apache if you have a patch or different commands. -- Edit this bug report at http://bugs.php.net/?id=16769&edit=1
Bug #17269 Updated: compile problem with GD & JPEG support
ID: 17269 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: GD related Operating System: FreeBSD 4.3 PHP Version: 4.2.1 New Comment: Ok, closing then. Derick Previous Comments: [2002-05-16 19:20:31] [EMAIL PROTECTED] Finally got it running! well, it's not a problem with PHP, but as Derick mentioned a shared library problem. The issue with not building shared libraries happens with jpeg-6b and gdbm 1.8.0 I wasn't able to find the stuff [EMAIL PROTECTED] mentioned in libtool, ltconfig or ltmain.sh so i started a search on my own for a solution. The problem is related to the version of ltconfig and ltmain.sh, jpeg6b and gdbm are using. With this version, compiling shared libraries fails on FreeBSD 4.3(x?) d57107# ./ltconfig --version ltconfig (GNU libtool) 1.2 Forcing shared libraries in Makefile doesn't work either, It messes up the gcc -shared command jpeg is using and it fails to build the compile line in a good order (something with 'gcc -o ./libs' where ./libs should be an output file and not a directory?) anyway the solution is to do a cp /usr/local/share/libtool/ltconfig ltconfig and a cp /usr/local/share/libtool/ltmain.sh ltmain.sh it 'updates' the old ltconfig, jpeg and gdbm are using too this version: d57107# /usr/local/share/libtool/ltconfig --version ltconfig (GNU libtool) 1.3.4-freebsd-ports (1.385.2.196 1999/12/07 21:47:57) when you've done this and run confure/gmake, jpeg and gdbm are reporting some errors during compilation: 'test: no: unexpected operator' you can safely (?) ignore these, it does work. and this is my new configure line, as you can see i added some packages: ./configure \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-config-file-path=/etc \ --enable-shared \ --enable-track-vars \ --enable-ftp \ --with-gdbm \ --with-gd \ --enable-gd-native-ttf \ --with-jpeg-dir \ --with-png-dir \ --with-freetype-dir \ --with-mysql=/usr/local \ --with-zlib-dir \ --with-zlib \ --with-pdflib \ --with-tsrm-pth \ --with-openssl \ --with-zip \ --with-snmp \ --with-tsrm-pth \ only have to rebuild php to update zlib to 1.1.4: zlib ZLib Support enabled Compiled Version 1.1.4 Linked Version 1.1.3 --- /me is very happy it works now :) thank you all for the support! [2002-05-16 13:21:30] [EMAIL PROTECTED] In the libtool script, check whether file_magic_cmd in the freebsd* case statement lists '/usr/bin/file -L' instead of plain /usr/bin/file and change accordingly (it should be '/usr/bin/file -L'). Then try to recompile with shared support. [2002-05-16 13:09:40] [EMAIL PROTECTED] just tried it: d57107# ./configure --enable-shared --- checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes --- libtool version 1.4.2.tar.gz for some reason jpeg won't compile as a shared library. tried to edit Makefile and change ./libtool to /usr/local/bin/libtool, but that doesn't make a difference, they are the same version. can i change Makefile to build a shared library while configure says it can't? and ideas? [2002-05-16 11:06:31] [EMAIL PROTECTED] First of all, thanks for this very extensive report... if only all reports where like this :) I think the problem might be that libjpeg.a is a static library which is compiled in in both gd and libpdf, you might try a shared variant and see if this fixes it. Derick [2002-05-16 07:04:49] [EMAIL PROTECTED] when compiling PHP with GD & JPEG support i get a lot of errors with libjpeg.a moaning about 'multiple definitions' and 'first defined here' stuff. system config: FreeBSD 4.3 Apache 2.0.36 PHP 4.2.1 GD 1.8.4 (compiled ok with support for png, jpeg, freetype) Jpeg 6B Libpng 1.2.2 Gdbm 1.8.0 Pdflib 4.0.2 Freetype 2.1.0 configure: ./configure \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-config-file-path=/etc \ --enable-shared \ --enable-track-vars \ --enable-ftp \ --with-gdbm=/usr/local \ --with-gd=/usr/local/graph/gd \ --with-jpeg-dir=/usr/local/graph/jpeg \ --enable-gd-native-ttf \ --with-png-dir=/usr/local/graph/png \ --with-freetype-dir=/usr/local/graph/freetype2 \ --with-mysql=/usr/local \ --with-zlib-dir=/usr/local/graph/zlib \ --with-zlib \ --with-pdflib=/usr/local/graph/pdflib \ --with-tsrm-pth \ configure goes OK. all the functions are supported and no errors are given. When i do a gmake i get this error: /usr/
Bug #16489 Updated: php_admin_value not allowed in virtualhost
ID: 16489 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Apache2 related -Operating System: Freebsd 4.5-stable +Operating System: All -PHP Version: 4.2.0 +PHP Version: 4.2.1 New Comment: This bug has been fixed in CVS. You can grab a snapshot of the CVS version 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. Thank you for the report, and for helping us make PHP better. I just applied a patch for this. Thanks for the report! The patch is at http://cvs.php.net/diff.php/php4/sapi/apache2filter/apache_config.c?r1=1.20&r2=1.21&ty=u Previous Comments: [2002-04-25 17:07:55] [EMAIL PROTECTED] Problem still with 4.2.0 release. Updated version. [2002-04-25 10:48:29] [EMAIL PROTECTED] I tried this on OS/2 apache2 and Win32 apache2. PHP 4.2 Release. Bug still exist :( I can`t swith to apache2 now :( [2002-04-15 18:19:31] [EMAIL PROTECTED] When can we expect this fixed? [2002-04-14 19:36:06] [EMAIL PROTECTED] ..and will most likely also exist in the actual release. Apache2 support in it will still be experimental. [2002-04-14 19:30:09] [EMAIL PROTECTED] Problem still exist in 4.2.0 RC4. 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/16489 -- Edit this bug report at http://bugs.php.net/?id=16489&edit=1
Bug #16629 Updated: php_flag not working and php_value strange behavior
ID: 16629 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Apache2 related -Operating System: Windows XP +Operating System: All -PHP Version: 4.2.0 +PHP Version: 4.2.1 New Comment: This bug has been fixed in CVS. You can grab a snapshot of the CVS version 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. Thank you for the report, and for helping us make PHP better. I just applied a patch for this. Thanks for the report! The patch is at http://cvs.php.net/diff.php/php4/sapi/apache2filter/apache_config.c?r1=1.20&r2=1.21&ty=u Previous Comments: [2002-05-16 03:34:28] [EMAIL PROTECTED] Same. Win XP Apache 2.0.35 PHP 4.2.1 [2002-05-10 03:12:09] [EMAIL PROTECTED] The same here: FreeBSD 4.6-PRERELEASE (~ 01 May 2002) PHP 4.2.0 Apache 2.0.35 php_flag in .htaccess produces an error by means of unrecognized command or something. php_value works fine. regards [2002-05-04 01:43:54] [EMAIL PROTECTED] got no error message by adding php_flag register_globals on However.. it has no effect at all. I tried to change the name for mod_php4.c to php4_module ,mod_php3.c,mod_php42.c but it seem that since with apache2 we dont need to specify AddModule mod_php4.c I dont know if its appache that doesnt go in the If Statement or if it is the php module that ignore the apache directive. It only work with php_value outside the if statement. as mentionned by katana. Im using Linux-Apache2.0.35 with php4.2.0 [2002-04-28 22:04:19] [EMAIL PROTECTED] I also have this problem under FreeBSD with Apache 2.0.35 and PHP/4.3.0-dev, and I have a working patch. I don't know where to sedn it or how to attach it. If someone could email me where to send it, I'll send it. [2002-04-26 17:47:09] [EMAIL PROTECTED] Same problem on Linux machine running apache 2.0.35 with FINAL release of php 4.2.0 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/16629 -- Edit this bug report at http://bugs.php.net/?id=16629&edit=1
Bug #10469 Updated: ODBC_result() fails on DB2 LONG VARCHAR columns
ID: 10469 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: ODBC related Operating System: Linux Slackware 7.1+ PHP Version: 4.0.4pl1 New Comment: 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". Previous Comments: [2002-04-16 14:18:33] [EMAIL PROTECTED] is this bug still valid in the recent releases? [2001-06-12 10:28:10] [EMAIL PROTECTED] not recognizing anything as a bug yet, i haven't gotten db2 installed to try these out :P [2001-06-08 16:14:35] [EMAIL PROTECTED] Heh.. Does that mean you recognize both as bugs, not user errors? I'd be real pleased to hear that, since I've been tearing out a considerable amount of hair over these two.. Hope you can figure it out asap, I'm currently working around the problems in various not-so-pretty ways.. -Eirik [2001-06-08 15:51:08] [EMAIL PROTECTED] saw the other bug too. i've seen it for awhile. it falls under the 2 problems i currently have. :\ [2001-06-02 05:02:03] [EMAIL PROTECTED] None of the two remedies you suggest make any difference. It's the odbc_longreadlen() I've been experimenting with too, but whatever I do it doesn't solve the problem, it just makes it more confusing ;) Actually.. The string in the LONG VARCHAR column might be as long or as short as you want, the same result arises anyhow. Btw, did you ever see the CHAR(x) FOR BIT DATA bug I've opened before? I was asked for feedback on it, and gave this, but nothing more happened... (It's used for the DB2 generation of unique keys...) -Eirik 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/10469 -- Edit this bug report at http://bugs.php.net/?id=10469&edit=1
Bug #17283: register_tick_function();
From: [EMAIL PROTECTED] Operating system: win2000 PHP version: 4.2.1 PHP Bug Type: Apache related Bug description: register_tick_function(); PHP as a module in Apache!(Apache1.3.24 + PHP4.2.1) -- Edit bug report at http://bugs.php.net/?id=17283&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17283&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17283&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17283&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17283&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17283&r=support Expected behavior: http://bugs.php.net/fix.php?id=17283&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17283&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17283&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17283&r=globals
Bug #17282: Identical float values are not identical when compared
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.4-STABLE PHP version: 4.2.1 PHP Bug Type: Scripting Engine problem Bug description: Identical float values are not identical when compared This problem also occurs on PHP 4.1.2. The following code fragment produces very odd results: The results are shown below: 41.96 != 41.96 bool(true) t = float(41.96) a[0] = float(41.96) Both variables appear to be the same type, and look the same, yet compare incorrectly with both typed and untyped comparisons. -- Edit bug report at http://bugs.php.net/?id=17282&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17282&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17282&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17282&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17282&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17282&r=support Expected behavior: http://bugs.php.net/fix.php?id=17282&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17282&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17282&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17282&r=globals
Bug #14283 Updated: printer_create_dc - Example has errors in manual
ID: 14283
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Unknown/Other Function
Operating System: WinXP ger
PHP Version: 4.0.6
New Comment:
The original code presented by joerglklein will not print at all for
me. I get the same errors on both Win 98 and Win NT 4 SP4 using a
Generic Text driver as well as a printer specific driver.
I found if I put the printer_create_dc() and printer_set_option()
outside of printer_start_doc() and printer_start_page() that it did
print without most errors, but of course it didn't print correctly.
Previous Comments:
[2001-11-29 10:43:25] [EMAIL PROTECTED]
take a look at
http://www.php.net/manual/en/function.printer-create-dc.php
at first you should replace printer_endpage($handle); with
printer_end_page($handle);
his is the correct code:
01:
Second: when I tried out this example I get an one error and one
warning:
Warning: couldn't end the page in /test.php on line 19
Fatal error: couldn't terminate print job in /test.php on line 20
When I try to open a special printer with
$handle = printer_open("$printer");
I get these errors and warnings:
Warning: No DeviceContext created in /test.php on line 17
Warning: couldn't end the page in /test.php on line 19
Fatal error: couldn't terminate print job in /test.php on line 20
So I think there a some problems with the Device Contexts
Joerg
--
Edit this bug report at http://bugs.php.net/?id=14283&edit=1
Bug #17281: session_encode is causing segmentation fault
From: [EMAIL PROTECTED]
Operating system: Solaris 2.7
PHP version: 4.2.1
PHP Bug Type: Session related
Bug description: session_encode is causing segmentation fault
I am running apache 1.3.24/PHP 4.2.1 on Solaris 2.7 (with
recent OS patches applied.)
When I call session_encode() as follows I get the
segmentation fault error below...
$session_array = explode(";", session_encode());
[Thu May 16 20:50:45 2002] [notice] child pid 26235 exit signal
Segmentation Fault (11)
Rubens.
--
Edit bug report at http://bugs.php.net/?id=17281&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17281&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17281&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17281&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17281&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17281&r=support
Expected behavior: http://bugs.php.net/fix.php?id=17281&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17281&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17281&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17281&r=globals
Bug #17269 Updated: compile problem with GD & JPEG support
ID: 17269 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: GD related Operating System: FreeBSD 4.3 PHP Version: 4.2.1 New Comment: Finally got it running! well, it's not a problem with PHP, but as Derick mentioned a shared library problem. The issue with not building shared libraries happens with jpeg-6b and gdbm 1.8.0 I wasn't able to find the stuff [EMAIL PROTECTED] mentioned in libtool, ltconfig or ltmain.sh so i started a search on my own for a solution. The problem is related to the version of ltconfig and ltmain.sh, jpeg6b and gdbm are using. With this version, compiling shared libraries fails on FreeBSD 4.3(x?) d57107# ./ltconfig --version ltconfig (GNU libtool) 1.2 Forcing shared libraries in Makefile doesn't work either, It messes up the gcc -shared command jpeg is using and it fails to build the compile line in a good order (something with 'gcc -o ./libs' where ./libs should be an output file and not a directory?) anyway the solution is to do a cp /usr/local/share/libtool/ltconfig ltconfig and a cp /usr/local/share/libtool/ltmain.sh ltmain.sh it 'updates' the old ltconfig, jpeg and gdbm are using too this version: d57107# /usr/local/share/libtool/ltconfig --version ltconfig (GNU libtool) 1.3.4-freebsd-ports (1.385.2.196 1999/12/07 21:47:57) when you've done this and run confure/gmake, jpeg and gdbm are reporting some errors during compilation: 'test: no: unexpected operator' you can safely (?) ignore these, it does work. and this is my new configure line, as you can see i added some packages: ./configure \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-config-file-path=/etc \ --enable-shared \ --enable-track-vars \ --enable-ftp \ --with-gdbm \ --with-gd \ --enable-gd-native-ttf \ --with-jpeg-dir \ --with-png-dir \ --with-freetype-dir \ --with-mysql=/usr/local \ --with-zlib-dir \ --with-zlib \ --with-pdflib \ --with-tsrm-pth \ --with-openssl \ --with-zip \ --with-snmp \ --with-tsrm-pth \ only have to rebuild php to update zlib to 1.1.4: zlib ZLib Support enabled Compiled Version 1.1.4 Linked Version 1.1.3 --- /me is very happy it works now :) thank you all for the support! Previous Comments: [2002-05-16 13:21:30] [EMAIL PROTECTED] In the libtool script, check whether file_magic_cmd in the freebsd* case statement lists '/usr/bin/file -L' instead of plain /usr/bin/file and change accordingly (it should be '/usr/bin/file -L'). Then try to recompile with shared support. [2002-05-16 13:09:40] [EMAIL PROTECTED] just tried it: d57107# ./configure --enable-shared --- checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes --- libtool version 1.4.2.tar.gz for some reason jpeg won't compile as a shared library. tried to edit Makefile and change ./libtool to /usr/local/bin/libtool, but that doesn't make a difference, they are the same version. can i change Makefile to build a shared library while configure says it can't? and ideas? [2002-05-16 11:06:31] [EMAIL PROTECTED] First of all, thanks for this very extensive report... if only all reports where like this :) I think the problem might be that libjpeg.a is a static library which is compiled in in both gd and libpdf, you might try a shared variant and see if this fixes it. Derick [2002-05-16 07:04:49] [EMAIL PROTECTED] when compiling PHP with GD & JPEG support i get a lot of errors with libjpeg.a moaning about 'multiple definitions' and 'first defined here' stuff. system config: FreeBSD 4.3 Apache 2.0.36 PHP 4.2.1 GD 1.8.4 (compiled ok with support for png, jpeg, freetype) Jpeg 6B Libpng 1.2.2 Gdbm 1.8.0 Pdflib 4.0.2 Freetype 2.1.0 configure: ./configure \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-config-file-path=/etc \ --enable-shared \ --enable-track-vars \ --enable-ftp \ --with-gdbm=/usr/local \ --with-gd=/usr/local/graph/gd \ --with-jpeg-dir=/usr/local/graph/jpeg \ --enable-gd-native-ttf \ --with-png-dir=/usr/local/graph/png \ --with-freetype-dir=/usr/local/graph/freetype2 \ --with-mysql=/usr/local \ --with-zlib-dir=/usr/local/graph/zlib \ --with-zlib \ --with-pdflib=/usr/local/graph/pdflib \ --with-tsrm-pth \ configure goes OK. all the functions are supported and no errors are given. When i do a gmake i get this error: /usr/local/lib/libjpeg.a(jcapimin.o): In function `jpeg_CreateCompress': jcapimin.o(.text+0x0): multiple definition of `jpeg_CreateCompress' /usr/local/lib/libjpeg.a(jcapimi
Bug #16888 Updated: domXML causes Segfault, when you create to many Nodes
ID: 16888
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: DOM XML related
Operating System: Windows XP
PHP Version: 4.2.0
New Comment:
Oh, and I've tested it to work with 70,000 elements...
Previous Comments:
[2002-05-16 19:04:25] [EMAIL PROTECTED]
I seem to have found the problem. Nodes are being freed twice: once in
a call to php_free_xml_node, and once in a call to node_wrapper_dtor.
I've made two changes, one i've replaced the "free" code in
php_free_xml_node with a call to the static inline function
node_wrapper_dtor, and then call dom_object_set_data to clear the data
(a check should be put here to make sure that the refcount is 0 before
doing this, but I don't have time right now). I'll post the patch to
the php-dev list so that people can look it over, and make sure that it
doesn't introduce any memory leaks. I'll mark the bug fixed when I
commit my change.
[2002-05-16 15:59:08] [EMAIL PROTECTED]
Ahh, Now I'm understanding the original poster. I never got the 404
page. Must have been a browser specific issue. The error occurs in
the cleanup routines on both iis and apache. The stack trace is as
follows:
_zval_ptr_dtor(_zval_struct * * 0x00e2f568, char * 0x10023020 `string',
unsigned int 0x01f8) line 272 + 5 bytes
node_wrapper_dtor(_xmlNode * 0x005cb9c8) line 504 + 26 bytes
node_list_wrapper_dtor(_xmlNode * 0x005cb9c8) line 531 + 9 bytes
node_list_wrapper_dtor(_xmlNode * 0x005c3c18) line 521 + 12 bytes
php_free_xml_doc(_zend_rsrc_list_entry * 0x00e38e18, void * * *
0x00afe7a8) line 563 + 12 bytes
list_entry_destructor(void * 0x00e38e18) line 177 + 16 bytes
zend_hash_apply_deleter(_hashtable * 0x00b2cac4, bucket * 0x00e38db8)
line 596 + 15 bytes
zend_hash_graceful_reverse_destroy(_hashtable * 0x00b2cac4) line 662 +
13 bytes
zend_destroy_rsrc_list(_hashtable * 0x00b2cac4, void * * * 0x00afe7a8)
line 233 + 9 bytes
shutdown_executor(void * * * 0x00afe7a8) line 196 + 30 bytes
zend_deactivate(void * * * 0x00afe7a8) line 596 + 9 bytes
php_request_shutdown(void * 0x) line 787 + 9 bytes
apache_php_module_main(request_rec * 0x00afc798, int 0x, void *
* * 0x00afe7a8) line 96 + 8 bytes
send_php(request_rec * 0x00afc798, int 0x, char * 0x00afd248)
line 575 + 17 bytes
send_parsed_php(request_rec * 0x00afc798) line 590 + 13 bytes
ap_invoke_handler(request_rec * 0x00afc798) line 517 + 10 bytes
process_request_internal(request_rec * 0x00afc798) line 1308 + 9 bytes
ap_process_request(request_rec * 0x00afc798) line 1324 + 9 bytes
child_sub_main(int 0x) line 5881
[2002-05-16 14:05:41] [EMAIL PROTECTED]
The crash occurs weather you use append_sibling or append_child
[2002-05-16 13:29:39] [EMAIL PROTECTED]
To narrow down the problem. Does it also crash, when you don't use
append_sibling, but append_child in the for-loop?
chregu
[2002-05-16 13:03:37] [EMAIL PROTECTED]
even with the new php_domxml.dll it still crashes
also when you use the correct new function
append_sibling() it still crashes, even worser when you forget to add
content to your nodes as in the example above apache crashes in a loop
until the timeout is reached and no output reaches the browser.
create_element("HTML");
$root = $doc->append_child($root);
$body = $doc->create_element("element");
$body = $root->append_child($body);
//$body->set_content("content");
for($i = 1; $i < 130; $i++){
$element = $doc->create_element("element");
//$element->set_content("content ".$i);
$body->append_sibling($element);
}
echo htmlentities($doc->dump_mem(true));
?>
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/16888
--
Edit this bug report at http://bugs.php.net/?id=16888&edit=1
Bug #16888 Updated: domXML causes Segfault, when you create to many Nodes
ID: 16888
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: DOM XML related
Operating System: Windows XP
PHP Version: 4.2.0
New Comment:
I seem to have found the problem. Nodes are being freed twice: once in
a call to php_free_xml_node, and once in a call to node_wrapper_dtor.
I've made two changes, one i've replaced the "free" code in
php_free_xml_node with a call to the static inline function
node_wrapper_dtor, and then call dom_object_set_data to clear the data
(a check should be put here to make sure that the refcount is 0 before
doing this, but I don't have time right now). I'll post the patch to
the php-dev list so that people can look it over, and make sure that it
doesn't introduce any memory leaks. I'll mark the bug fixed when I
commit my change.
Previous Comments:
[2002-05-16 15:59:08] [EMAIL PROTECTED]
Ahh, Now I'm understanding the original poster. I never got the 404
page. Must have been a browser specific issue. The error occurs in
the cleanup routines on both iis and apache. The stack trace is as
follows:
_zval_ptr_dtor(_zval_struct * * 0x00e2f568, char * 0x10023020 `string',
unsigned int 0x01f8) line 272 + 5 bytes
node_wrapper_dtor(_xmlNode * 0x005cb9c8) line 504 + 26 bytes
node_list_wrapper_dtor(_xmlNode * 0x005cb9c8) line 531 + 9 bytes
node_list_wrapper_dtor(_xmlNode * 0x005c3c18) line 521 + 12 bytes
php_free_xml_doc(_zend_rsrc_list_entry * 0x00e38e18, void * * *
0x00afe7a8) line 563 + 12 bytes
list_entry_destructor(void * 0x00e38e18) line 177 + 16 bytes
zend_hash_apply_deleter(_hashtable * 0x00b2cac4, bucket * 0x00e38db8)
line 596 + 15 bytes
zend_hash_graceful_reverse_destroy(_hashtable * 0x00b2cac4) line 662 +
13 bytes
zend_destroy_rsrc_list(_hashtable * 0x00b2cac4, void * * * 0x00afe7a8)
line 233 + 9 bytes
shutdown_executor(void * * * 0x00afe7a8) line 196 + 30 bytes
zend_deactivate(void * * * 0x00afe7a8) line 596 + 9 bytes
php_request_shutdown(void * 0x) line 787 + 9 bytes
apache_php_module_main(request_rec * 0x00afc798, int 0x, void *
* * 0x00afe7a8) line 96 + 8 bytes
send_php(request_rec * 0x00afc798, int 0x, char * 0x00afd248)
line 575 + 17 bytes
send_parsed_php(request_rec * 0x00afc798) line 590 + 13 bytes
ap_invoke_handler(request_rec * 0x00afc798) line 517 + 10 bytes
process_request_internal(request_rec * 0x00afc798) line 1308 + 9 bytes
ap_process_request(request_rec * 0x00afc798) line 1324 + 9 bytes
child_sub_main(int 0x) line 5881
[2002-05-16 14:05:41] [EMAIL PROTECTED]
The crash occurs weather you use append_sibling or append_child
[2002-05-16 13:29:39] [EMAIL PROTECTED]
To narrow down the problem. Does it also crash, when you don't use
append_sibling, but append_child in the for-loop?
chregu
[2002-05-16 13:03:37] [EMAIL PROTECTED]
even with the new php_domxml.dll it still crashes
also when you use the correct new function
append_sibling() it still crashes, even worser when you forget to add
content to your nodes as in the example above apache crashes in a loop
until the timeout is reached and no output reaches the browser.
create_element("HTML");
$root = $doc->append_child($root);
$body = $doc->create_element("element");
$body = $root->append_child($body);
//$body->set_content("content");
for($i = 1; $i < 130; $i++){
$element = $doc->create_element("element");
//$element->set_content("content ".$i);
$body->append_sibling($element);
}
echo htmlentities($doc->dump_mem(true));
?>
[2002-05-16 11:06:57] [EMAIL PROTECTED]
I'm looking into it. No guarantees though. I tried it with IIS, and
it seemed to work ok (Well the domxml part), it just crashed later.
I'm installing Apache to see if I can reproduce the problem/fix it.
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/16888
--
Edit this bug report at http://bugs.php.net/?id=16888&edit=1
Bug #16989 Updated: Could not find/open font...
ID: 16989 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: GD related Operating System: WinNT PHP Version: 4.2.0 New Comment: See the last comment on http://bugs.php.net/bug.php?id=17192 Previous Comments: [2002-05-16 18:39:37] [EMAIL PROTECTED] Same again in 4.2.1 Have tried all sorts of different methods to access font file name - including c:/, c:\ /, \ - also using realname() which was suggested on some mailing list somewhere. Win2K, Apache 1.3.24, GD2 Matt [2002-05-03 06:51:54] [EMAIL PROTECTED] Oops? php_gd2.dll brings out 'Could not find/open font...' on $array = @ImageTTFBBox($size,0,$font,$textstring). [$font is a ttf-file in the same directory9 php_gd.dll works fine with SAME configuration... Probably a bug in the [Win32]GD2? greets, Lars -- Edit this bug report at http://bugs.php.net/?id=16989&edit=1
Bug #17280: FOPEN bug
From: [EMAIL PROTECTED]
Operating system: Freebsd 4.5
PHP version: 4.2.0
PHP Bug Type: *URL Functions
Bug description: FOPEN bug
Warning: fopen("http://www.google.com/search?q=test";, "r") - Message too
long in * on line 3
Error made by Fopen function... It was working before
--
Edit bug report at http://bugs.php.net/?id=17280&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17280&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17280&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17280&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17280&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17280&r=support
Expected behavior: http://bugs.php.net/fix.php?id=17280&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17280&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17280&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17280&r=globals
Bug #17106 Updated: Session variable disappears
ID: 17106
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Session related
Operating System: Win98, Win2000 Pro
PHP Version: 4.1.2
New Comment:
In answer to Rasmus:
in php.ini, register_globals has always been On
Cookie warning in Netscape shows that a cookie is sent at the beginning
of the session, but none is sent on "login".
There is a session file in /sessiondata, and it contains "userSN|N;" it
does not contain my username.
Previous Comments:
[2002-05-15 00:43:47] [EMAIL PROTECTED]
Here is a short version of my original script.
Behavior is similar to the original:
php 4.0.6 - 2nd time it is run, shows "You are logged in"
php 4.1.2, 4.2.1 - 2nd time it is run, prompts again for username and
password, so has lost the $userSN session variable
You have already logged in for this
session.\n");
printf("To logout click here.");
printf("");
exit;
}
//Check Password IF userSN is NOT SET AND clicked Submit
if ($submit) {
$form_password = md5($form_password);
$userSN = $form_username;
if (isset($userSN)) {
printf("Welcome to Provider Login");
printf("%s\n", $providerName);
printf("You are logged on from : %s \n",
$REMOTE_ADDR);
}
else printf("ERROR setting session
cookie");
printf("");
exit;
} //END of SUBMIT
?>
Username:
Password:
[2002-05-14 10:51:10] [EMAIL PROTECTED]
I just tried the following script on Windows 2000 Pro and it works
fine.
Don't forget to set session.save_path in your php.ini! Also make sure
the webserver has write access to that path.
[2002-05-14 00:30:09] [EMAIL PROTECTED]
Can you supply a small script reproducing this problem also how
frequent it happens?
every page view or random or every 10 page views?
_ brad
[2002-05-14 00:24:26] [EMAIL PROTECTED]
For f#cks sake, we STILL have this damn problem under 4.2.1 as well.
This is really starting to p#ss me off - we generate a HUGE amount of
traffic, one of the top ten movie related sites in this country, and
this session problem is causing viewers to constantly reload pages so
that their bloody cookie logs them in - thus our bandwidth is shooting
through the bloody roof (read $ down the toilet)...
[2002-05-13 20:32:50] [EMAIL PROTECTED]
The last version for which this script works on all my tested platforms
(Win98-Win2000, Apache1.3.22, Netscape 4.75) is 4.0.6. Using the
php4xx-installer.exe for MS Windows.
Also note that 4.0.6 does NOT register PHP in the MS Win registry,
whereas versions >= 4.1.0 DO register it. Could the registry be causing
problems with session variables? Just a question from an un-initiated
user.
Lee
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/17106
--
Edit this bug report at http://bugs.php.net/?id=17106&edit=1
Bug #16989 Updated: Could not find/open font...
ID: 16989 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GD related Operating System: WinNT PHP Version: 4.2.0 New Comment: Same again in 4.2.1 Have tried all sorts of different methods to access font file name - including c:/, c:\ /, \ - also using realname() which was suggested on some mailing list somewhere. Win2K, Apache 1.3.24, GD2 Matt Previous Comments: [2002-05-03 06:51:54] [EMAIL PROTECTED] Oops? php_gd2.dll brings out 'Could not find/open font...' on $array = @ImageTTFBBox($size,0,$font,$textstring). [$font is a ttf-file in the same directory9 php_gd.dll works fine with SAME configuration... Probably a bug in the [Win32]GD2? greets, Lars -- Edit this bug report at http://bugs.php.net/?id=16989&edit=1
Bug #10099 Updated: Segfault in Apache 1.3.19 + PHP4.0.x DSO
ID: 10099 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Apache related Operating System: Linux-mipsel (Cobalt Linux 5.0) PHP Version: 4.0.4pl1 New Comment: Hello, I thought I'd let everyone know that I encountered the same bug on a FreeBSD box that I'm testing on. The box is an i386 running FreeBSD 4.5. I have compiled Apache 2.0.36, mod_perl 2.0, and php 4.2.1. I built php as a DSO and ran the defacto test page and received the error. I used the fix in 9827 changing the 1.0 in line 109 of crypt.c to 1.0 and rebuilt php. Everything is working fine now. Just FYI. Thanks, Dave Previous Comments: [2001-10-20 23:08:40] [EMAIL PROTECTED] The fix is committed into CVS. --Jani [2001-04-03 12:03:15] [EMAIL PROTECTED] Ok, I have made the changes to the crypt.c file on line 105, based on Matti Weissmueller's idea. And PHP4 compiles cleanly and runs just as well seemingly. Could someone advise on any potential issues, that this change could have ? [2001-04-01 14:10:57] [EMAIL PROTECTED] Sniper, Thanks for the quick response. Here is the new debugged core dump: Starting program: /usr/sbin/httpd -X Program received signal SIGFPE, Arithmetic exception. 0x2b0b1da0 in php_minit_crypt (type=1, module_number=3) at crypt.c:105 105 php_srand(time(0) * getpid() * (php_combined_lcg() * 1.0)); (gdb) bt #0 0x2b0b1da0 in php_minit_crypt (type=1, module_number=3) at crypt.c:105 #1 0x2b0a3968 in php_minit_basic (type=1, module_number=3) at basic_functions.c:748 #2 0x2aff2068 in zend_startup_module (module=0x2b253b44) at zend_API.c:624 #3 0x2b01ac30 in php_startup_extensions (ptr=0x2b24e288, count=10) at main.c:701 #4 0x2b01ccb4 in php_startup_internal_extensions () at internal_functions.c:62 #5 0x2b01b390 in php_module_startup (sf=0x2b24d290) at main.c:861 #6 0x2b014ca4 in php_apache_startup (sapi_module=0x2b24d290) at mod_php4.c:259 #7 0x2b016820 in php_init_handler (s=0x10122cc8, p=0x10122ca0) at mod_php4.c:729 #8 0x4836b0 in ap_init_modules () #9 0x499dd4 in main () I believe there is a work-around for this. See Bug #9827 by Matti Weissmueller. He uses similar hardware. Thanks for your help. [2001-04-01 13:12:22] [EMAIL PROTECTED] 1. delete config.cache 2. add --enable-debug into your configure line 3. after configure 'make clean ; make ; make install' Now you might get better backtrace of the problem. Do you have PHP 3 installed into the apache? If not, you don't need --enable-versioning argument. --Jani [2001-04-01 12:18:23] [EMAIL PROTECTED] I have a Cobalt Qube2 (64-Bit MIPS little-endian). I have compiled PHP 4.0.4 and any release after that including 4.0.5RC2. PHP 4.0.x is configured like this: ./configure \ --with-apxs=/usr/sbin/apxs \ --enable-versioning \ --with-mysql=/usr/local/mysql \ --enable-track-vars \ --with-imap=/usr/local/imap-2000c \ --enable-ftp \ --with-mm=/usr/local/mm-1.1.3 \ --with-zlib (every interation of PHP after 4.0.4 was compiled with the options seen above) My GDB backtrace looks like this: #0 0x2aff60f8 in ?? () (gdb) bt #0 0x2aff60f8 in ?? () warning: Hit heuristic-fence-post without finding warning: enclosing function for address 0x2aff602c That's all I have found. -- Edit this bug report at http://bugs.php.net/?id=10099&edit=1
Bug #16064 Updated: array_merge_recursive() can be used for DoS
ID: 16064
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Arrays related
Operating System: RH 7.1
PHP Version: 4.0CVS-2002-03-1
New Comment:
Oops, forgot to include the link:
http://bugs.php.net/bug.php?id=17279
Previous Comments:
[2002-05-16 16:24:37] [EMAIL PROTECTED]
Your second example isn't like the first. $a[0] is a reference to
itself. The first bonks because $GLOBALS['GLOBALS'] is a reference to
$GLOBALS. An equivalent is:
which will produce the same results. I'm submitting a feature request
for array_recurse_safe($array) which returns an array with no infinite
loops.
[2002-03-14 09:33:52] [EMAIL PROTECTED]
OK. status -> open
[2002-03-14 09:31:58] [EMAIL PROTECTED]
streplace('them','him',$previous_vote);
[2002-03-14 09:30:40] [EMAIL PROTECTED]
I have talked to Zeev about this issues. Asked them may I have to fill
bug report and he said:
"They should either use hash_apply(), which automatically protects
against
recursion, or implement the recursion protection themselves (like
print_r()
does). You can/should open bug reports about them..."
In the start Zeev talks about some functions that have problems with
$GLOBALS and arrays that holds elements pointing ot itself.
[2002-03-14 09:23:45] [EMAIL PROTECTED]
I'm sure you can come up with a load of nasty things you can do with
$GLOBALS, but what do you want us to do about it? Disable $GLOBALS for
use with array_* functions (it that's even possible)? Disable $GLOBALS
at all?
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/16064
--
Edit this bug report at http://bugs.php.net/?id=16064&edit=1
Bug #17279: array_recurse_safe()
From: [EMAIL PROTECTED] Operating system: All PHP version: 4.1.2 PHP Bug Type: Feature/Change Request Bug description: array_recurse_safe() Will solve problems like: http://bugs.php.net/bug.php?id=16064 This code doesn't work, but I don't know enough C to write it right. It would work if PHP had a method for determining if two variables are the same reference. (unless there is one that I haven't found...) Also, the usage of unset() is improper here, but I left it in for simplicity. -- Edit bug report at http://bugs.php.net/?id=17279&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17279&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17279&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17279&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17279&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17279&r=support Expected behavior: http://bugs.php.net/fix.php?id=17279&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17279&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17279&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17279&r=globals
Bug #17277 Updated: strstr matches any variable surrounded by underscores
ID: 17277
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Strings related
Operating System: Linux
PHP Version: 4.2.1
New Comment:
You're missing something indeed, _$needle_ is equivalent with "." .
${"needle_"} as underscores can be part of a variablename.
As $needle_ is empty, the needle evaluates to "_", which is in "Moo
_bar_"
Not a bug > bogus.
Derick
Previous Comments:
[2002-05-16 17:15:55] [EMAIL PROTECTED]
_$ doesn't have anysignificance, but that trailing _ does,
since it will try to match $needle_ as the variable name
and that will be empty.
[2002-05-16 17:10:47] [EMAIL PROTECTED]
This script:
2: ";
echo strstr("Moo _bar_", "_{$needle}_");
echo "3: ";
echo strstr("Moo _foo_", "_{$needle}_");
echo "4: ";
echo strstr("Moo !bar!", "!$needle!");
?>
Gives this output:
1: _bar_
2:
3: _foo_
4:
Obviously, the line 1 is the problem. If both "haystack" and "needle"
have the strings surrounded by underscores - the strings are matched
even if they are actually different. This happens only if the "needle"
has a variable between the underscores, and the variable is not
surrounded by { and }.
Prehaps I am missing something and the combination of "_$" is supposed
to mean something, but i did not see it in the documentation.
--
Edit this bug report at http://bugs.php.net/?id=17277&edit=1
Bug #17277 Updated: strstr matches any variable surrounded by underscores
ID: 17277
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Strings related
Operating System: Linux
PHP Version: 4.2.1
Previous Comments:
[2002-05-16 17:15:55] [EMAIL PROTECTED]
_$ doesn't have anysignificance, but that trailing _ does,
since it will try to match $needle_ as the variable name
and that will be empty.
[2002-05-16 17:10:47] [EMAIL PROTECTED]
This script:
2: ";
echo strstr("Moo _bar_", "_{$needle}_");
echo "3: ";
echo strstr("Moo _foo_", "_{$needle}_");
echo "4: ";
echo strstr("Moo !bar!", "!$needle!");
?>
Gives this output:
1: _bar_
2:
3: _foo_
4:
Obviously, the line 1 is the problem. If both "haystack" and "needle"
have the strings surrounded by underscores - the strings are matched
even if they are actually different. This happens only if the "needle"
has a variable between the underscores, and the variable is not
surrounded by { and }.
Prehaps I am missing something and the combination of "_$" is supposed
to mean something, but i did not see it in the documentation.
--
Edit this bug report at http://bugs.php.net/?id=17277&edit=1
Bug #17278: Just can't compile on HP 11
From: [EMAIL PROTECTED] Operating system: HP-UX 11.00 PHP version: 4.1.2 PHP Bug Type: Compile Failure Bug description: Just can't compile on HP 11 We are trying to setup the following environment: - HP-UX 11 - HP Linux Porting Kit (i.e. libhplx) - gcc.depot 3.0.4 - Oracle 8i - Sablot 0.9 - expat-1.95.2 plus bison binutils perl ... and HP patches too After makeinstalling Apache 1.3.12 we use the following configure : --prefix=/APAPHP/PHP \ --with-config-file-path=/APAPHP \ --with-apxs=/APAPHP/bin/apxs\ --enable-track-vars \ --with-oci8=/oracle/app/oracle/product/8.1.7 \ --with-oracle=/oracle/app/oracle/product/8.1.7 \ --enable-magic-quotes \ --enable-debugger \ --enable-xslt \ --with-xslt-sablot The configure looks fine, but we cannot go any further, on the following error when we try to compile PHP: -- Making all in Zend /bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../main -DHPUX11 -DUSE_HSRE GEX -DUSE_EXPAT -I../TSRM -g -O2 -prefer-pic -c zend_operators.c zend_operators.c: In function `multi_convert_to_long_ex': zend_operators.c:563: warning: passing arg 1 of `__builtin_stdarg_start' from incompatible pointer type zend_operators.c:570: warning: passing arg 1 of `__builtin_va_end' from incompatible pointer type zend_operators.c:566: first argument to `va_arg' not of type `va_list' zend_operators.c: In function `multi_convert_to_double_ex': zend_operators.c:578: warning: passing arg 1 of `__builtin_stdarg_start' from incompatible pointer type zend_operators.c:585: warning: passing arg 1 of `__builtin_va_end' from incompatible pointer type zend_operators.c:581: first argument to `va_arg' not of type `va_list' zend_operators.c: In function `multi_convert_to_string_ex': zend_operators.c:593: warning: passing arg 1 of `__builtin_stdarg_start' from incompatible pointer type zend_operators.c:600: warning: passing arg 1 of `__builtin_va_end' from incompatible pointer type zend_operators.c:596: first argument to `va_arg' not of type `va_list' cd Zend*** Error exit code 1 Stop. *** Error exit code 1 --- Any help ? Pls! Thanks in advance -- Edit bug report at http://bugs.php.net/?id=17278&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17278&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17278&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17278&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17278&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17278&r=support Expected behavior: http://bugs.php.net/fix.php?id=17278&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17278&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17278&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17278&r=globals
Bug #17277 Updated: strstr matches any variable surrounded by underscores
ID: 17277
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Strings related
Operating System: Linux
PHP Version: 4.2.1
New Comment:
_$ doesn't have anysignificance, but that trailing _ does,
since it will try to match $needle_ as the variable name
and that will be empty.
Previous Comments:
[2002-05-16 17:10:47] [EMAIL PROTECTED]
This script:
2: ";
echo strstr("Moo _bar_", "_{$needle}_");
echo "3: ";
echo strstr("Moo _foo_", "_{$needle}_");
echo "4: ";
echo strstr("Moo !bar!", "!$needle!");
?>
Gives this output:
1: _bar_
2:
3: _foo_
4:
Obviously, the line 1 is the problem. If both "haystack" and "needle"
have the strings surrounded by underscores - the strings are matched
even if they are actually different. This happens only if the "needle"
has a variable between the underscores, and the variable is not
surrounded by { and }.
Prehaps I am missing something and the combination of "_$" is supposed
to mean something, but i did not see it in the documentation.
--
Edit this bug report at http://bugs.php.net/?id=17277&edit=1
Bug #17277: strstr matches any variable surrounded by underscores
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.2.1
PHP Bug Type: Strings related
Bug description: strstr matches any variable surrounded by underscores
This script:
2: ";
echo strstr("Moo _bar_", "_{$needle}_");
echo "3: ";
echo strstr("Moo _foo_", "_{$needle}_");
echo "4: ";
echo strstr("Moo !bar!", "!$needle!");
?>
Gives this output:
1: _bar_
2:
3: _foo_
4:
Obviously, the line 1 is the problem. If both "haystack" and "needle" have
the strings surrounded by underscores - the strings are matched even if
they are actually different. This happens only if the "needle" has a
variable between the underscores, and the variable is not surrounded by {
and }.
Prehaps I am missing something and the combination of "_$" is supposed to
mean something, but i did not see it in the documentation.
--
Edit bug report at http://bugs.php.net/?id=17277&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17277&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17277&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17277&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17277&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17277&r=support
Expected behavior: http://bugs.php.net/fix.php?id=17277&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17277&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17277&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17277&r=globals
Bug #17262 Updated: PHP 4.2.1 fails to install when compiled as a CGI
ID: 17262 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: *Compile Issues Operating System: RedHat linux 7.3 PHP Version: 4.2.1 New Comment: I think it´s my Bug ID 17203, so manually creating the directory "libs" may be the solution. Daniel Previous Comments: [2002-05-16 09:00:54] [EMAIL PROTECTED] This is the full error, I can paste the entire contents of the "make install" when I get to work if you like. [2002-05-16 06:41:20] [EMAIL PROTECTED] Can you please copy and paste the FULL error? [2002-05-15 18:20:04] [EMAIL PROTECTED] When compiling php with the following options on a stock RedHat 7.3 system: ./configure \ --without-mysql \ --with-config-file-path=/etc \ --with-zlib \ --with-gd \ --with-pgsql \ --with-system-regex \ --with-pdflib I recieve this error when performing the make install: Making install in . make[1]: Entering directory `/sources/php-4.2.1' make[1]: *** [install-sapi] Error 1 make[1]: Leaving directory `/sources/php-4.2.1' make: *** [install-recursive] Error 1 The php binary is not installed when I get this message. I can copy the file into the /usr/local/lib directory and it *appears* to work ok. This problem was not present in php version 4.1.2. -- Edit this bug report at http://bugs.php.net/?id=17262&edit=1
Bug #17276 Updated: example in CLI docs uses CGI command line option
ID: 17276 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: - PHP Version: 4.2.1 New Comment: OK, I had the time and facilities to correct this bug. I hope it will be OK now. It will show up in some days in the manual. Previous Comments: [2002-05-16 15:46:48] [EMAIL PROTECTED] This *is* a bug. The CLI version, command line options, etc. is explained in the text but the example uses the CGI version. Reopening. [2002-05-16 15:39: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 [2002-05-16 15:37:22] [EMAIL PROTECTED] The page at /manual/en/features.commandline.php uses a CGI-only option in the last example: Example 24-2. Batch file to run a command line PHP script (script.bat) @c:\php\php.exe -q script.php %1 %2 %3 %4 -- Edit this bug report at http://bugs.php.net/?id=17276&edit=1
Bug #16064 Updated: array_merge_recursive() can be used for DoS
ID: 16064
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Arrays related
Operating System: RH 7.1
PHP Version: 4.0CVS-2002-03-1
New Comment:
Your second example isn't like the first. $a[0] is a reference to
itself. The first bonks because $GLOBALS['GLOBALS'] is a reference to
$GLOBALS. An equivalent is:
which will produce the same results. I'm submitting a feature request
for array_recurse_safe($array) which returns an array with no infinite
loops.
Previous Comments:
[2002-03-14 09:33:52] [EMAIL PROTECTED]
OK. status -> open
[2002-03-14 09:31:58] [EMAIL PROTECTED]
streplace('them','him',$previous_vote);
[2002-03-14 09:30:40] [EMAIL PROTECTED]
I have talked to Zeev about this issues. Asked them may I have to fill
bug report and he said:
"They should either use hash_apply(), which automatically protects
against
recursion, or implement the recursion protection themselves (like
print_r()
does). You can/should open bug reports about them..."
In the start Zeev talks about some functions that have problems with
$GLOBALS and arrays that holds elements pointing ot itself.
[2002-03-14 09:23:45] [EMAIL PROTECTED]
I'm sure you can come up with a load of nasty things you can do with
$GLOBALS, but what do you want us to do about it? Disable $GLOBALS for
use with array_* functions (it that's even possible)? Disable $GLOBALS
at all?
[2002-03-14 09:15:54] [EMAIL PROTECTED]
On the test server all consoles hanged. 100%.CPU load. 98%
system - kswapd started to swap as a beast.
No problems with this.
--
Edit this bug report at http://bugs.php.net/?id=16064&edit=1
Bug #15317 Updated: setcookie() does not work with CGI PHP
ID: 15317
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: IIS related
Operating System: Windows 2000 SP2
PHP Version: 4.1.1
New Comment:
nope... doesn't work at my server... :(
Previous Comments:
[2002-04-22 13:46:39] [EMAIL PROTECTED]
Concerning cookies, check this usefull test to determine what "cookie
method" is working in your environment.
http://www.chipchapin.com/WebTools/cookietest.php?
source=true
I'm using PHP 4.11 under WNT 4 SP5, WNT 2K, WIN98 with Apache for
WIN32.
Client are IE4, IE 5.5, IE6 and NS 6 under WIN95,WIN98,WIN2K.
I got some problems by using a setcookie like :
setcookie("user","$info",time() + 15552000);
I changed in :
setcookie("user","$info","(time() + 15552000)");
and it's working fine now.
Hope that will help.
[2002-03-04 16:35:26] [EMAIL PROTECTED]
Experiencing the same problem. If the cookies are set using
setcookie() on a *nix box, they can successfully be read using PHP/ASP
running on Windows or *nix. However, cookies set with PHP using
setcookie() on Windows cannot be read by *either* ASP or PHP running on
*either* Windows or *nix. Since it's not triggering IE's cookie
protection nor lynx's it's a safe assumption that maybe setcookie()
just doesnt work on Windows.
[2002-01-31 14:04:31] [EMAIL PROTECTED]
When I use the IIS CGI version on Windows the setcookie() function does
not set the cookie. The $HTTP_COOKIE_VARS and $_COOKIE arrays are both
totally empty. However, it does work with the (very unstable) ISAPI
version and always works on Apache no matter the OS.
--
Edit this bug report at http://bugs.php.net/?id=15317&edit=1
Bug #16888 Updated: domXML causes Segfault, when you create to many Nodes
ID: 16888
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: DOM XML related
Operating System: Windows XP
PHP Version: 4.2.0
New Comment:
Ahh, Now I'm understanding the original poster. I never got the 404
page. Must have been a browser specific issue. The error occurs in
the cleanup routines on both iis and apache. The stack trace is as
follows:
_zval_ptr_dtor(_zval_struct * * 0x00e2f568, char * 0x10023020 `string',
unsigned int 0x01f8) line 272 + 5 bytes
node_wrapper_dtor(_xmlNode * 0x005cb9c8) line 504 + 26 bytes
node_list_wrapper_dtor(_xmlNode * 0x005cb9c8) line 531 + 9 bytes
node_list_wrapper_dtor(_xmlNode * 0x005c3c18) line 521 + 12 bytes
php_free_xml_doc(_zend_rsrc_list_entry * 0x00e38e18, void * * *
0x00afe7a8) line 563 + 12 bytes
list_entry_destructor(void * 0x00e38e18) line 177 + 16 bytes
zend_hash_apply_deleter(_hashtable * 0x00b2cac4, bucket * 0x00e38db8)
line 596 + 15 bytes
zend_hash_graceful_reverse_destroy(_hashtable * 0x00b2cac4) line 662 +
13 bytes
zend_destroy_rsrc_list(_hashtable * 0x00b2cac4, void * * * 0x00afe7a8)
line 233 + 9 bytes
shutdown_executor(void * * * 0x00afe7a8) line 196 + 30 bytes
zend_deactivate(void * * * 0x00afe7a8) line 596 + 9 bytes
php_request_shutdown(void * 0x) line 787 + 9 bytes
apache_php_module_main(request_rec * 0x00afc798, int 0x, void *
* * 0x00afe7a8) line 96 + 8 bytes
send_php(request_rec * 0x00afc798, int 0x, char * 0x00afd248)
line 575 + 17 bytes
send_parsed_php(request_rec * 0x00afc798) line 590 + 13 bytes
ap_invoke_handler(request_rec * 0x00afc798) line 517 + 10 bytes
process_request_internal(request_rec * 0x00afc798) line 1308 + 9 bytes
ap_process_request(request_rec * 0x00afc798) line 1324 + 9 bytes
child_sub_main(int 0x) line 5881
Previous Comments:
[2002-05-16 14:05:41] [EMAIL PROTECTED]
The crash occurs weather you use append_sibling or append_child
[2002-05-16 13:29:39] [EMAIL PROTECTED]
To narrow down the problem. Does it also crash, when you don't use
append_sibling, but append_child in the for-loop?
chregu
[2002-05-16 13:03:37] [EMAIL PROTECTED]
even with the new php_domxml.dll it still crashes
also when you use the correct new function
append_sibling() it still crashes, even worser when you forget to add
content to your nodes as in the example above apache crashes in a loop
until the timeout is reached and no output reaches the browser.
create_element("HTML");
$root = $doc->append_child($root);
$body = $doc->create_element("element");
$body = $root->append_child($body);
//$body->set_content("content");
for($i = 1; $i < 130; $i++){
$element = $doc->create_element("element");
//$element->set_content("content ".$i);
$body->append_sibling($element);
}
echo htmlentities($doc->dump_mem(true));
?>
[2002-05-16 11:06:57] [EMAIL PROTECTED]
I'm looking into it. No guarantees though. I tried it with IIS, and
it seemed to work ok (Well the domxml part), it just crashed later.
I'm installing Apache to see if I can reproduce the problem/fix it.
[2002-05-16 09:07:01] [EMAIL PROTECTED]
Edin created a new php_domxml.dll with libxml2-2.4.21 compile d in.
It's available at
http://ftp.proventum.net/pub/php/win32/php_domxml.zip
Can you check that. But i fear, it doesn't help solve the problem :(
Please be aware, that append_child changed the meaning in 4.2.1. The
former append_child is now append_sibling, and append_child behaves
like the w3c likes it. But appending a sibling to the root node,
doesn't make really sense, but it souldn't crash PHP, either :)
I would be very glad, if someone with windows programming experience
could hunt down the problem.
chregu
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/16888
--
Edit this bug report at http://bugs.php.net/?id=16888&edit=1
Bug #17276 Updated: example in CLI docs uses CGI command line option
ID: 17276 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Documentation problem Operating System: - PHP Version: 4.2.1 New Comment: This *is* a bug. The CLI version, command line options, etc. is explained in the text but the example uses the CGI version. Reopening. Previous Comments: [2002-05-16 15:39: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 [2002-05-16 15:37:22] [EMAIL PROTECTED] The page at /manual/en/features.commandline.php uses a CGI-only option in the last example: Example 24-2. Batch file to run a command line PHP script (script.bat) @c:\php\php.exe -q script.php %1 %2 %3 %4 -- Edit this bug report at http://bugs.php.net/?id=17276&edit=1
Bug #17276 Updated: example in CLI docs uses CGI command line option
ID: 17276 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: - PHP Version: 4.2.1 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 Previous Comments: [2002-05-16 15:37:22] [EMAIL PROTECTED] The page at /manual/en/features.commandline.php uses a CGI-only option in the last example: Example 24-2. Batch file to run a command line PHP script (script.bat) @c:\php\php.exe -q script.php %1 %2 %3 %4 -- Edit this bug report at http://bugs.php.net/?id=17276&edit=1
Bug #17276: example in CLI docs uses CGI command line option
From: [EMAIL PROTECTED] Operating system: - PHP version: 4.2.1 PHP Bug Type: Documentation problem Bug description: example in CLI docs uses CGI command line option The page at /manual/en/features.commandline.php uses a CGI-only option in the last example: Example 24-2. Batch file to run a command line PHP script (script.bat) @c:\php\php.exe -q script.php %1 %2 %3 %4 -- Edit bug report at http://bugs.php.net/?id=17276&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17276&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17276&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17276&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17276&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17276&r=support Expected behavior: http://bugs.php.net/fix.php?id=17276&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17276&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17276&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17276&r=globals
Bug #17275: IIS stop responding HTTP requests
From: [EMAIL PROTECTED] Operating system: NT4 Server PHP version: 4.2.1 PHP Bug Type: Reproducible crash Bug description: IIS stop responding HTTP requests I'm using the "Microsoft WebStress Application Tool" to test the server, and when MANY requests are made at the same time, many "php.exe's" are still running in the Task Manager but IIS stop responding the requests. No "Dr. Watson" or any other type of error occurs. It simple stop responding. If I made fewer requests, the IIS responds to all of them and for all the time I want... -- Edit bug report at http://bugs.php.net/?id=17275&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17275&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17275&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17275&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17275&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17275&r=support Expected behavior: http://bugs.php.net/fix.php?id=17275&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17275&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17275&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17275&r=globals
Bug #17028 Updated: [chm] bug on language.types.resource.html
ID: 17028 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: windows PHP Version: 4.1.2 New Comment: There is a new version available (built 2002-05-09), in which I don't get such an error. (Don't have the old version to check it). Would you please check this new version if the problem still persisits? Thomas Previous Comments: [2002-05-06 09:23:01] [EMAIL PROTECTED] WinME (4.90.3000) + IE 5.5 (128-bit Cipher Strength) Thanks, Dennis Williams [2002-05-06 04:07:55] [EMAIL PROTECTED] Strange. I still cannot reproduce any of these bugs with IE6 + Winxp and IE5 + Win2k. What Win OS do you have? Goba [2002-05-06 01:06:31] [EMAIL PROTECTED] I have found a bug on page language.types.resource.html [chm date: 2002-04-20]... I don't know if this is exactly a bug...it seems to do with IE 5.5 and script debugging. (I do have Microsoft Script Debugger installed on my system.) Even though I have script debugging turned off (and continue flag set to true when scripting errors encountered) I still get this pop-up on most pages in the .chm format help file: Internet Explorer Script Error An error has occurred in the script on this page. Line: 3 Char: 25 Error: 'document.all.unotes' is null or not an object Code: 0 URL: ... Do you want to continue running scripts on this page? Yes|No Line number, character number and error message seem to remain constant on all pages where this occurs. Thanks, Dennis Williams -- Edit this bug report at http://bugs.php.net/?id=17028&edit=1
Bug #17132 Updated: [chm] bug on function.header.html
ID: 17132 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: windows PHP Version: 4.0CVS-2002-05-09 New Comment: There is a new version available (built 2002-05-09), in which I can't find an error at the "header" function. (Don't have the old version to check it). Would you please check this new version if the problem still persisits? Previous Comments: [2002-05-10 04:38:27] [EMAIL PROTECTED] Reclassified. [2002-05-09 23:50:06] [EMAIL PROTECTED] I have found a bug on page function.header.html [chm date: 2002-04-20]... 'document.all.unotes' is null or not an object -- Edit this bug report at http://bugs.php.net/?id=17132&edit=1
Bug #16888 Updated: domXML causes Segfault, when you create to many Nodes
ID: 16888
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: DOM XML related
Operating System: Windows XP
PHP Version: 4.2.0
New Comment:
The crash occurs weather you use append_sibling or append_child
Previous Comments:
[2002-05-16 13:29:39] [EMAIL PROTECTED]
To narrow down the problem. Does it also crash, when you don't use
append_sibling, but append_child in the for-loop?
chregu
[2002-05-16 13:03:37] [EMAIL PROTECTED]
even with the new php_domxml.dll it still crashes
also when you use the correct new function
append_sibling() it still crashes, even worser when you forget to add
content to your nodes as in the example above apache crashes in a loop
until the timeout is reached and no output reaches the browser.
create_element("HTML");
$root = $doc->append_child($root);
$body = $doc->create_element("element");
$body = $root->append_child($body);
//$body->set_content("content");
for($i = 1; $i < 130; $i++){
$element = $doc->create_element("element");
//$element->set_content("content ".$i);
$body->append_sibling($element);
}
echo htmlentities($doc->dump_mem(true));
?>
[2002-05-16 11:06:57] [EMAIL PROTECTED]
I'm looking into it. No guarantees though. I tried it with IIS, and
it seemed to work ok (Well the domxml part), it just crashed later.
I'm installing Apache to see if I can reproduce the problem/fix it.
[2002-05-16 09:07:01] [EMAIL PROTECTED]
Edin created a new php_domxml.dll with libxml2-2.4.21 compile d in.
It's available at
http://ftp.proventum.net/pub/php/win32/php_domxml.zip
Can you check that. But i fear, it doesn't help solve the problem :(
Please be aware, that append_child changed the meaning in 4.2.1. The
former append_child is now append_sibling, and append_child behaves
like the w3c likes it. But appending a sibling to the root node,
doesn't make really sense, but it souldn't crash PHP, either :)
I would be very glad, if someone with windows programming experience
could hunt down the problem.
chregu
[2002-05-15 17:50:13] [EMAIL PROTECTED]
FWIW, the sample script works ok using the latest HEAD under IIS in
debug mode...well, works is an approximation. It doesn't crash until
the Zend tries to clean up memory, and then crashes in _zval_ptr_dtor.
Not feeling like a Zend guru today, I don't feel like attacking it.
I'll try Apache though to see if I can narrow this bug down.
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/16888
--
Edit this bug report at http://bugs.php.net/?id=16888&edit=1
Bug #17274: sem_remove gets SIGSEGV for not initializing the semun structure.
From: [EMAIL PROTECTED] Operating system: Linux 2.2.19 PHP version: 4.2.1 PHP Bug Type: Semaphore related Bug description: sem_remove gets SIGSEGV for not initializing the semun structure. Hi! PHP 4.2.1 gets a SIGSEGV in sem_remove(). The code in ext/sysvsem/sysvsem.c seems to forget the allocation of the buf member of the semun struct when it calls to semctl(). I solved it adding: struct semid_ds semidbuf; to the declaration of local variables, and: un.buf = &semidbuf; before each call to semctl(); I configured PHP using: configure --enable-sysvshm --enable-sysvsem --with-curl=/usr/local/lib/libcurl.a --enable-pcntl This is the gdb stack trace: (gdb) where #0 0x402864e2 in __new_semctl (semid=770, semnum=0, cmd=2) at ../sysdeps/i386/i486/bits/string.h:315 #1 0x80be3a3 in zif_sem_remove (ht=1, return_value=0x81a13cc, this_ptr=0x0, return_value_used=0) at sysvsem.c:406 #2 0x80fe6cf in execute (op_array=0x81946b8) at ./zend_execute.c:1598 #3 0x80fe889 in execute (op_array=0x8186c14) at ./zend_execute.c:1638 #4 0x80e4289 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:810 #5 0x8062879 in php_execute_script (primary_file=0xbbd0) at main.c:1381 #6 0x8060850 in main (argc=5, argv=0xbc74) at cgi_main.c:778 #7 0x401c2b65 in __libc_start_main (main=0x8060054 , argc=5, ubp_av=0xbc74, init=0x805ec7c <_init>, fini=0x81037bc <_fini>, rtld_fini=0x4000df24 <_dl_fini>, stack_end=0xbc6c) at ../sysdeps/generic/libc-start.c:111 -- Edit bug report at http://bugs.php.net/?id=17274&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17274&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17274&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17274&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17274&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17274&r=support Expected behavior: http://bugs.php.net/fix.php?id=17274&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17274&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17274&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17274&r=globals
Bug #16888 Updated: domXML causes Segfault, when you create to many Nodes
ID: 16888
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: DOM XML related
Operating System: Windows XP
PHP Version: 4.2.0
New Comment:
To narrow down the problem. Does it also crash, when you don't use
append_sibling, but append_child in the for-loop?
chregu
Previous Comments:
[2002-05-16 13:03:37] [EMAIL PROTECTED]
even with the new php_domxml.dll it still crashes
also when you use the correct new function
append_sibling() it still crashes, even worser when you forget to add
content to your nodes as in the example above apache crashes in a loop
until the timeout is reached and no output reaches the browser.
create_element("HTML");
$root = $doc->append_child($root);
$body = $doc->create_element("element");
$body = $root->append_child($body);
//$body->set_content("content");
for($i = 1; $i < 130; $i++){
$element = $doc->create_element("element");
//$element->set_content("content ".$i);
$body->append_sibling($element);
}
echo htmlentities($doc->dump_mem(true));
?>
[2002-05-16 11:06:57] [EMAIL PROTECTED]
I'm looking into it. No guarantees though. I tried it with IIS, and
it seemed to work ok (Well the domxml part), it just crashed later.
I'm installing Apache to see if I can reproduce the problem/fix it.
[2002-05-16 09:07:01] [EMAIL PROTECTED]
Edin created a new php_domxml.dll with libxml2-2.4.21 compile d in.
It's available at
http://ftp.proventum.net/pub/php/win32/php_domxml.zip
Can you check that. But i fear, it doesn't help solve the problem :(
Please be aware, that append_child changed the meaning in 4.2.1. The
former append_child is now append_sibling, and append_child behaves
like the w3c likes it. But appending a sibling to the root node,
doesn't make really sense, but it souldn't crash PHP, either :)
I would be very glad, if someone with windows programming experience
could hunt down the problem.
chregu
[2002-05-15 17:50:13] [EMAIL PROTECTED]
FWIW, the sample script works ok using the latest HEAD under IIS in
debug mode...well, works is an approximation. It doesn't crash until
the Zend tries to clean up memory, and then crashes in _zval_ptr_dtor.
Not feeling like a Zend guru today, I don't feel like attacking it.
I'll try Apache though to see if I can narrow this bug down.
[2002-05-15 16:15:27] [EMAIL PROTECTED]
I tried the newest xml-lib build from
http://www.fh-frankfurt.de/~igor/projects/libxml/ (Version 2.4.21) and
apache still crashes.
I also can confirm the barrier with 128 elements.
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/16888
--
Edit this bug report at http://bugs.php.net/?id=16888&edit=1
Bug #17180 Updated: Operator Precedence
ID: 17180 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed -Bug Type:Scripting Engine problem +Bug Type:Documentation problem PHP Version: 4.2.0 New Comment: Marking this as a doc problem. Previous Comments: [2002-05-14 13:46:58] [EMAIL PROTECTED] Actually this is a bug, since in PHP manual it's clearly stated that ! operator has a priority over = operator. > It makes no sense to assign anything to NOT(a variable), > so PHP takes care of that by > changing the precedence a little in this case. In other words - if user makes a mistake and writes illegal code, PHP takes care about that and makes this code work (but in a way different from what developer has expected). Also if you consider any other programming languages, if you write a code which should not compile by language specifications (like the above code in PHP), no compiler will try to "take care" of that. If you insist on that "care", then you definetely have to reflect that in the manual, otherwise it's nothing but a bug. [2002-05-13 18:30:31] [EMAIL PROTECTED] This behaviour is capable to confuse the developer and if this is "features" it must be documented in manual. [2002-05-13 18:20:14] [EMAIL PROTECTED] Well, but it's stupid to do something like that. It makes no sense to assign anything to NOT(a variable), so PHP takes care of that by changing the precedence a little in this case. [2002-05-13 17:56:54] [EMAIL PROTECTED] Yes, I want ASSIGN value to $a and check assigned value. But parser must say: "parser error", becouse it can not assign value to constant. Please reopen. [2002-05-13 17:48:54] [EMAIL PROTECTED] "if (!$a = foo(FALSE))" --> you're assigning the output of foo(FALSE) to $a "if (!$a == foo(FALSE))" --> you're comparing !$a and foo(FALSE) 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/17180 -- Edit this bug report at http://bugs.php.net/?id=17180&edit=1
Bug #17272 Updated: Failure to read Flash MX file size
ID: 17272 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: SWF related +Bug Type: Feature/Change Request Operating System: N/A PHP Version: 4.1.2 New Comment: Not really a bug, as it was not written for this :) Anyway, if you could mail me empty flash movies with the following size, I'll see what I can do: 255x127 640x480 400x256 (and perhaps some more) Derick Previous Comments: [2002-05-16 12:22:48] [EMAIL PROTECTED] The problem is with the getimagesize() function and its detection routines which don't detect Flash 6/MX content. [2002-05-16 12:00:44] [EMAIL PROTECTED] Flash file size detection seems to not work for Flash files published in the new Flash "MX" (version 6). When published to version 5 or lower, it works. -- Edit this bug report at http://bugs.php.net/?id=17272&edit=1
Bug #17269 Updated: compile problem with GD & JPEG support
ID: 17269 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: GD related Operating System: FreeBSD 4.3 PHP Version: 4.2.1 New Comment: In the libtool script, check whether file_magic_cmd in the freebsd* case statement lists '/usr/bin/file -L' instead of plain /usr/bin/file and change accordingly (it should be '/usr/bin/file -L'). Then try to recompile with shared support. Previous Comments: [2002-05-16 13:09:40] [EMAIL PROTECTED] just tried it: d57107# ./configure --enable-shared --- checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes --- libtool version 1.4.2.tar.gz for some reason jpeg won't compile as a shared library. tried to edit Makefile and change ./libtool to /usr/local/bin/libtool, but that doesn't make a difference, they are the same version. can i change Makefile to build a shared library while configure says it can't? and ideas? [2002-05-16 11:06:31] [EMAIL PROTECTED] First of all, thanks for this very extensive report... if only all reports where like this :) I think the problem might be that libjpeg.a is a static library which is compiled in in both gd and libpdf, you might try a shared variant and see if this fixes it. Derick [2002-05-16 07:04:49] [EMAIL PROTECTED] when compiling PHP with GD & JPEG support i get a lot of errors with libjpeg.a moaning about 'multiple definitions' and 'first defined here' stuff. system config: FreeBSD 4.3 Apache 2.0.36 PHP 4.2.1 GD 1.8.4 (compiled ok with support for png, jpeg, freetype) Jpeg 6B Libpng 1.2.2 Gdbm 1.8.0 Pdflib 4.0.2 Freetype 2.1.0 configure: ./configure \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-config-file-path=/etc \ --enable-shared \ --enable-track-vars \ --enable-ftp \ --with-gdbm=/usr/local \ --with-gd=/usr/local/graph/gd \ --with-jpeg-dir=/usr/local/graph/jpeg \ --enable-gd-native-ttf \ --with-png-dir=/usr/local/graph/png \ --with-freetype-dir=/usr/local/graph/freetype2 \ --with-mysql=/usr/local \ --with-zlib-dir=/usr/local/graph/zlib \ --with-zlib \ --with-pdflib=/usr/local/graph/pdflib \ --with-tsrm-pth \ configure goes OK. all the functions are supported and no errors are given. When i do a gmake i get this error: /usr/local/lib/libjpeg.a(jcapimin.o): In function `jpeg_CreateCompress': jcapimin.o(.text+0x0): multiple definition of `jpeg_CreateCompress' /usr/local/lib/libjpeg.a(jcapimin.o)(.text+0x0): first defined here It goes on for about 50 of these jpeg_. you can look at the complete error here: http://httpd.chello.nl/~jstienstra01/php/compile_error.txt The STRANGE thing is that if i leave apache2 support out (--with-apxs2) and compile it as a CGI-BINARY, i do not get errors and it compiles fine ? thing i've tried: -tried GD2.0.1 and gd 1.8.3 instead of gd 1.8.4 -did a system search for old jpeg/png/GD libraries. deleted them all and did a clean install for these packages -install the packages in standard directorys (/usr/lib and /usr/include etc), doesn't work either. -tried php 4.1.0, php 4.2.0 and php 4.2.1 -searching bug database for similiar problem :) -been busy googling for 4 days, yet to find no fix for this problem, only people that have the same problem and didnt get an answer too. THE thing that i don't understand is that if i leave apache support out and compile it as a cgi binary it gives no compile errors. help? -- Edit this bug report at http://bugs.php.net/?id=17269&edit=1
Bug #17269 Updated: compile problem with GD & JPEG support
ID: 17269 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: GD related Operating System: FreeBSD 4.3 PHP Version: 4.2.1 New Comment: just tried it: d57107# ./configure --enable-shared --- checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes --- libtool version 1.4.2.tar.gz for some reason jpeg won't compile as a shared library. tried to edit Makefile and change ./libtool to /usr/local/bin/libtool, but that doesn't make a difference, they are the same version. can i change Makefile to build a shared library while configure says it can't? and ideas? Previous Comments: [2002-05-16 11:06:31] [EMAIL PROTECTED] First of all, thanks for this very extensive report... if only all reports where like this :) I think the problem might be that libjpeg.a is a static library which is compiled in in both gd and libpdf, you might try a shared variant and see if this fixes it. Derick [2002-05-16 07:04:49] [EMAIL PROTECTED] when compiling PHP with GD & JPEG support i get a lot of errors with libjpeg.a moaning about 'multiple definitions' and 'first defined here' stuff. system config: FreeBSD 4.3 Apache 2.0.36 PHP 4.2.1 GD 1.8.4 (compiled ok with support for png, jpeg, freetype) Jpeg 6B Libpng 1.2.2 Gdbm 1.8.0 Pdflib 4.0.2 Freetype 2.1.0 configure: ./configure \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-config-file-path=/etc \ --enable-shared \ --enable-track-vars \ --enable-ftp \ --with-gdbm=/usr/local \ --with-gd=/usr/local/graph/gd \ --with-jpeg-dir=/usr/local/graph/jpeg \ --enable-gd-native-ttf \ --with-png-dir=/usr/local/graph/png \ --with-freetype-dir=/usr/local/graph/freetype2 \ --with-mysql=/usr/local \ --with-zlib-dir=/usr/local/graph/zlib \ --with-zlib \ --with-pdflib=/usr/local/graph/pdflib \ --with-tsrm-pth \ configure goes OK. all the functions are supported and no errors are given. When i do a gmake i get this error: /usr/local/lib/libjpeg.a(jcapimin.o): In function `jpeg_CreateCompress': jcapimin.o(.text+0x0): multiple definition of `jpeg_CreateCompress' /usr/local/lib/libjpeg.a(jcapimin.o)(.text+0x0): first defined here It goes on for about 50 of these jpeg_. you can look at the complete error here: http://httpd.chello.nl/~jstienstra01/php/compile_error.txt The STRANGE thing is that if i leave apache2 support out (--with-apxs2) and compile it as a CGI-BINARY, i do not get errors and it compiles fine ? thing i've tried: -tried GD2.0.1 and gd 1.8.3 instead of gd 1.8.4 -did a system search for old jpeg/png/GD libraries. deleted them all and did a clean install for these packages -install the packages in standard directorys (/usr/lib and /usr/include etc), doesn't work either. -tried php 4.1.0, php 4.2.0 and php 4.2.1 -searching bug database for similiar problem :) -been busy googling for 4 days, yet to find no fix for this problem, only people that have the same problem and didnt get an answer too. THE thing that i don't understand is that if i leave apache support out and compile it as a cgi binary it gives no compile errors. help? -- Edit this bug report at http://bugs.php.net/?id=17269&edit=1
Bug #16888 Updated: domXML causes Segfault, when you create to many Nodes
ID: 16888
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: DOM XML related
Operating System: Windows XP
PHP Version: 4.2.0
New Comment:
even with the new php_domxml.dll it still crashes
also when you use the correct new function
append_sibling() it still crashes, even worser when you forget to add
content to your nodes as in the example above apache crashes in a loop
until the timeout is reached and no output reaches the browser.
create_element("HTML");
$root = $doc->append_child($root);
$body = $doc->create_element("element");
$body = $root->append_child($body);
//$body->set_content("content");
for($i = 1; $i < 130; $i++){
$element = $doc->create_element("element");
//$element->set_content("content ".$i);
$body->append_sibling($element);
}
echo htmlentities($doc->dump_mem(true));
?>
Previous Comments:
[2002-05-16 11:06:57] [EMAIL PROTECTED]
I'm looking into it. No guarantees though. I tried it with IIS, and
it seemed to work ok (Well the domxml part), it just crashed later.
I'm installing Apache to see if I can reproduce the problem/fix it.
[2002-05-16 09:07:01] [EMAIL PROTECTED]
Edin created a new php_domxml.dll with libxml2-2.4.21 compile d in.
It's available at
http://ftp.proventum.net/pub/php/win32/php_domxml.zip
Can you check that. But i fear, it doesn't help solve the problem :(
Please be aware, that append_child changed the meaning in 4.2.1. The
former append_child is now append_sibling, and append_child behaves
like the w3c likes it. But appending a sibling to the root node,
doesn't make really sense, but it souldn't crash PHP, either :)
I would be very glad, if someone with windows programming experience
could hunt down the problem.
chregu
[2002-05-15 17:50:13] [EMAIL PROTECTED]
FWIW, the sample script works ok using the latest HEAD under IIS in
debug mode...well, works is an approximation. It doesn't crash until
the Zend tries to clean up memory, and then crashes in _zval_ptr_dtor.
Not feeling like a Zend guru today, I don't feel like attacking it.
I'll try Apache though to see if I can narrow this bug down.
[2002-05-15 16:15:27] [EMAIL PROTECTED]
I tried the newest xml-lib build from
http://www.fh-frankfurt.de/~igor/projects/libxml/ (Version 2.4.21) and
apache still crashes.
I also can confirm the barrier with 128 elements.
[2002-05-15 12:28:24] [EMAIL PROTECTED]
One more interesting remark - DOM XML module crashes if more then 128
elements are created. Less then 128 elements are created without
problems. Maybe it will help you somehow?
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/16888
--
Edit this bug report at http://bugs.php.net/?id=16888&edit=1
Bug #17273: symbol not found
From: [EMAIL PROTECTED] Operating system: Solaris 2.8 PHP version: 4.2.1 PHP Bug Type: Apache related Bug description: symbol not found After compiling and installing PHP apache would not load the module. After runnin apachectl configtest this was the result: Syntax error on line 206 of /www/conf/httpd.conf: Cannot load /www/libexec/libphp4.so into server: ld.so.1: /www/bin/httpd: fatal: relocation error: file /www/libexec/libphp4.so: symbol ap_block_alarms: referenced symbol not found The program versions are as follows: Apache version - 1.3.23 PHP version - 4.2.1 Imap version - 2001a Kerberos version 5-1.2.5 Here are the results on running ldd -r on the libphp4.so.: ldd -r /www/libexec/libphp4.so libdl.so.1 =>/usr/lib/libdl.so.1 libpam.so.1 => /usr/lib/libpam.so.1 libmysqlclient.so.10 => /usr/local/mysql/lib/mysql/libmysqlclient.so.10 libcrypt_i.so.1 => /usr/lib/libcrypt_i.so.1 libresolv.so.2 =>/usr/lib/libresolv.so.2 libm.so.1 => /usr/lib/libm.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libc.so.1 => /usr/lib/libc.so.1 libz.so => /usr/lib/libz.so libgen.so.1 => /usr/lib/libgen.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 /usr/platform/SUNW,UltraSPARC-IIi-cEngine/lib/libc_psr.so.1 symbol not found: ap_block_alarms (/www/libexec/libphp4.so) symbol not found: ap_unblock_alarms (/www/libexec/libphp4.so) symbol not found: ap_user_id(/www/libexec/libphp4.so) symbol not found: ap_server_root (/www/libexec/libphp4.so) symbol not found: ap_group_id (/www/libexec/libphp4.so) symbol not found: ap_user_name (/www/libexec/libphp4.so) symbol not found: top_module(/www/libexec/libphp4.so) symbol not found: ap_max_requests_per_child (/www/libexec/libphp4.so) symbol not found: ap_table_get (/www/libexec/libphp4.so) symbol not found: ap_table_setn (/www/libexec/libphp4.so) symbol not found: ap_update_mtime (/www/libexec/libphp4.so) symbol not found: ap_kill_timeout (/www/libexec/libphp4.so) symbol not found: ap_uudecode (/www/libexec/libphp4.so) symbol not found: ap_setup_client_block (/www/libexec/libphp4.so) symbol not found: ap_add_cgi_vars (/www/libexec/libphp4.so) symbol not found: ap_getword(/www/libexec/libphp4.so) symbol not found: ap_getword_nulls_nc (/www/libexec/libphp4.so) symbol not found: ap_destroy_sub_req (/www/libexec/libphp4.so) symbol not found: ap_pstrdup(/www/libexec/libphp4.so) symbol not found: ap_log_error (/www/libexec/libphp4.so) symbol not found: ap_table_add (/www/libexec/libphp4.so) symbol not found: ap_sub_req_lookup_uri (/www/libexec/libphp4.so) symbol not found: ap_run_sub_req (/www/libexec/libphp4.so) symbol not found: ap_register_cleanup (/www/libexec/libphp4.so) symbol not found: ap_signal (/www/libexec/libphp4.so) symbol not found: ap_send_http_header (/www/libexec/libphp4.so) symbol not found: ap_pstrndup (/www/libexec/libphp4.so) symbol not found: ap_block_alarms (/www/libexec/libphp4.so) symbol not found: ap_child_terminate (/www/libexec/libphp4.so) symbol not found: ap_set_etag (/www/libexec/libphp4.so) symbol not found: ap_rwrite (/www/libexec/libphp4.so) symbol not found: ap_table_set (/www/libexec/libphp4.so) symbol not found: ap_get_client_block (/www/libexec/libphp4.so) symbol not found: ap_add_version_component (/www/libexec/libphp4.so) symbol not found: ap_hard_timeout (/www/libexec/libphp4.so) symbol not found: ap_rflush (/www/libexec/libphp4.so) symbol not found: ap_set_last_modified (/www/libexec/libphp4.so) symbol not found: ap_reset_timeout (/www/libexec/libphp4.so) symbol not found: ap_unblock_alarms (/www/libexec/libphp4.so) symbol not found: ap_add_common_vars (/www/libexec/libphp4.so) And on my httpd: ldd -r /www/bin/httpd libsocket.so.1 =>/usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libpthread.so.1 => /usr/lib/libpthread.so.1 libcrypt_i.so.1 => /usr/lib/libcrypt_i.so.1 libc.so.1 => /usr/
Bug #17272 Updated: Failure to read Flash MX file size
ID: 17272 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: SWF related Operating System: N/A PHP Version: 4.1.2 New Comment: The problem is with the getimagesize() function and its detection routines which don't detect Flash 6/MX content. Previous Comments: [2002-05-16 12:00:44] [EMAIL PROTECTED] Flash file size detection seems to not work for Flash files published in the new Flash "MX" (version 6). When published to version 5 or lower, it works. -- Edit this bug report at http://bugs.php.net/?id=17272&edit=1
Bug #17272: Failure to read Flash MX file size
From: [EMAIL PROTECTED] Operating system: N/A PHP version: 4.1.2 PHP Bug Type: SWF related Bug description: Failure to read Flash MX file size Flash file size detection seems to not work for Flash files published in the new Flash "MX" (version 6). When published to version 5 or lower, it works. -- Edit bug report at http://bugs.php.net/?id=17272&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17272&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17272&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17272&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17272&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17272&r=support Expected behavior: http://bugs.php.net/fix.php?id=17272&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17272&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17272&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17272&r=globals
Bug #15177 Updated: Informix Shared Module will not compile
ID: 15177 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Compile Failure Operating System: RH Linux 7.2 PHP Version: 4.1.1 New Comment: OK, I made it compile, but I don't know how to change the things that generate the makefiles and such. I just did the configure, compiled it until it gave an error, and then modified the line and manually ran it until it worked. There were 2 problems. 2 libs were specified with relative paths, I was in /home/mike/php..., and on the line, they were /etc/..., so I changed them to /home/mike/etc... See the /home/mike in the line below. I haven't tested weather it actually works, but it finished compiling properly after that. /bin/sh /home/mike/php-4.2.1/libtool --silent --mode=link gcc -I. -I/home/mike/php-4.2.1/ext/informix -I/home/mike/php-4.2.1/main -I/home/mike/php-4.2.1 -I/home/mike/php-4.2.1/Zend -I/opt/informix/incl/esql -I/home/mike/php-4.2.1/ext/mysql/libmysql -I/home/mike/php-4.2.1/ext/xml/expat -I/home/mike/php-4.2.1/TSRM -g -O2 -o informix.la -avoid-version -module -rpath /home/mike/php-4.2.1/modules ifx.lo -R/home/mike/php-4.2.1/ext/informix -L/home/mike/php-4.2.1/ext/informix -R/opt/informix/lib/esql -L/opt/informix/lib/esql -R/opt/informix/lib -L/opt/informix/lib -lifsql -lifasf -lifgen -lifos -lifgls -ldl -lcrypt -lifglx Previous Comments: [2002-05-07 22:50:57] [EMAIL PROTECTED] Still busted in 4.2! I thought this was marked critical for 4.2? Same exact error for me (same platform): /bin/sh /home/zhamm/php-4.2.0/libtool --silent --mode=compile gcc -I. -I/home/zhamm/php-4.2.0/ext/informix -I/home/zhamm/php-4.2.0/main -I/home/zhamm/php-4.2.0 -I/home/zhamm/php-4.2.0/Zend -I/opt/informix/incl/esql -I/home/zhamm/php-4.2.0/TSRM -g -O2 -prefer-pic -c ifx.c && touch ifx.slo /bin/sh /home/zhamm/php-4.2.0/libtool --silent --mode=link gcc -I. -I/home/zhamm/php-4.2.0/ext/informix -I/home/zhamm/php-4.2.0/main -I/home/zhamm/php-4.2.0 -I/home/zhamm/php-4.2.0/Zend -I/opt/informix/incl/esql -I/home/zhamm/php-4.2.0/TSRM -g -O2 -o informix.la -avoid-version -module -rpath /home/zhamm/php-4.2.0/modules ifx.lo -Rext/informix -Lext/informix -R/opt/informix/lib/esql -L/opt/informix/lib/esql -R/opt/informix/lib -L/opt/informix/lib -lifsql -lifasf -lifgen -lifos -lifgls -ldl -lcrypt -lphpifx -lifglx libtool: link: only absolute run-paths are allowed make[3]: *** [informix.la] Error 1 make[3]: Leaving directory `/home/zhamm/php-4.2.0/ext/informix' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/zhamm/php-4.2.0/ext/informix' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/zhamm/php-4.2.0/ext' make: *** [all-recursive] Error 1 [2002-04-02 20:36:35] [EMAIL PROTECTED] This is still broken for php-4.2.0RC1: libtool: link: only absolute run-paths are allowed make[3]: *** [informix.la] Error 1 Ran configure with: # ./configure --with-apxs=/usr/sbin/apxs --enable-shared --with-informix=shared --without-mysql --without-xml Does anyone know how to fix this in libtool? [2002-03-07 12:12:10] [EMAIL PROTECTED] This might possibly be related to bug number 15803 as this is the last time (php-4.0.4pl1) I was able to compile Informix with IBM DB2 support at the same time as well... [2002-03-03 05:34:47] [EMAIL PROTECTED] Marking as Critical for release 4.2.0 [2002-03-03 05:30:06] [EMAIL PROTECTED] The last version where compile with-informix worked was php4-4.0.4pl1 None after that work, I've tryed them all, including snapshots 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/15177 -- Edit this bug report at http://bugs.php.net/?id=15177&edit=1
Bug #16888 Updated: domXML causes Segfault, when you create to many Nodes
ID: 16888 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: DOM XML related Operating System: Windows XP PHP Version: 4.2.0 New Comment: I'm looking into it. No guarantees though. I tried it with IIS, and it seemed to work ok (Well the domxml part), it just crashed later. I'm installing Apache to see if I can reproduce the problem/fix it. Previous Comments: [2002-05-16 09:07:01] [EMAIL PROTECTED] Edin created a new php_domxml.dll with libxml2-2.4.21 compile d in. It's available at http://ftp.proventum.net/pub/php/win32/php_domxml.zip Can you check that. But i fear, it doesn't help solve the problem :( Please be aware, that append_child changed the meaning in 4.2.1. The former append_child is now append_sibling, and append_child behaves like the w3c likes it. But appending a sibling to the root node, doesn't make really sense, but it souldn't crash PHP, either :) I would be very glad, if someone with windows programming experience could hunt down the problem. chregu [2002-05-15 17:50:13] [EMAIL PROTECTED] FWIW, the sample script works ok using the latest HEAD under IIS in debug mode...well, works is an approximation. It doesn't crash until the Zend tries to clean up memory, and then crashes in _zval_ptr_dtor. Not feeling like a Zend guru today, I don't feel like attacking it. I'll try Apache though to see if I can narrow this bug down. [2002-05-15 16:15:27] [EMAIL PROTECTED] I tried the newest xml-lib build from http://www.fh-frankfurt.de/~igor/projects/libxml/ (Version 2.4.21) and apache still crashes. I also can confirm the barrier with 128 elements. [2002-05-15 12:28:24] [EMAIL PROTECTED] One more interesting remark - DOM XML module crashes if more then 128 elements are created. Less then 128 elements are created without problems. Maybe it will help you somehow? [2002-05-15 12:23:10] [EMAIL PROTECTED] Confirmed under windows 2000 server running as CGI with following combinations: PHP 4.1.1 + libxml2 2.4.21 - works well PHP 4.2.0 + libxml2 2.4.21 - crash PHP 4.2.1 + libxml2 2.4.9 - crash Unfortunatelly latest PHP version - 4.2.1 have been build with libxml2 compiled as static library, so i can't test it with latest libxml2. So it is not a problem of libxml2, but something into DOM XML module itself. PHP crashes into final stage, when script execution itself is completed (and even function, registered as shutdown function have been executed). 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/16888 -- Edit this bug report at http://bugs.php.net/?id=16888&edit=1
Bug #17269 Updated: compile problem with GD & JPEG support
ID: 17269 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: GD related Operating System: FreeBSD 4.3 PHP Version: 4.2.1 New Comment: First of all, thanks for this very extensive report... if only all reports where like this :) I think the problem might be that libjpeg.a is a static library which is compiled in in both gd and libpdf, you might try a shared variant and see if this fixes it. Derick Previous Comments: [2002-05-16 07:04:49] [EMAIL PROTECTED] when compiling PHP with GD & JPEG support i get a lot of errors with libjpeg.a moaning about 'multiple definitions' and 'first defined here' stuff. system config: FreeBSD 4.3 Apache 2.0.36 PHP 4.2.1 GD 1.8.4 (compiled ok with support for png, jpeg, freetype) Jpeg 6B Libpng 1.2.2 Gdbm 1.8.0 Pdflib 4.0.2 Freetype 2.1.0 configure: ./configure \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-config-file-path=/etc \ --enable-shared \ --enable-track-vars \ --enable-ftp \ --with-gdbm=/usr/local \ --with-gd=/usr/local/graph/gd \ --with-jpeg-dir=/usr/local/graph/jpeg \ --enable-gd-native-ttf \ --with-png-dir=/usr/local/graph/png \ --with-freetype-dir=/usr/local/graph/freetype2 \ --with-mysql=/usr/local \ --with-zlib-dir=/usr/local/graph/zlib \ --with-zlib \ --with-pdflib=/usr/local/graph/pdflib \ --with-tsrm-pth \ configure goes OK. all the functions are supported and no errors are given. When i do a gmake i get this error: /usr/local/lib/libjpeg.a(jcapimin.o): In function `jpeg_CreateCompress': jcapimin.o(.text+0x0): multiple definition of `jpeg_CreateCompress' /usr/local/lib/libjpeg.a(jcapimin.o)(.text+0x0): first defined here It goes on for about 50 of these jpeg_. you can look at the complete error here: http://httpd.chello.nl/~jstienstra01/php/compile_error.txt The STRANGE thing is that if i leave apache2 support out (--with-apxs2) and compile it as a CGI-BINARY, i do not get errors and it compiles fine ? thing i've tried: -tried GD2.0.1 and gd 1.8.3 instead of gd 1.8.4 -did a system search for old jpeg/png/GD libraries. deleted them all and did a clean install for these packages -install the packages in standard directorys (/usr/lib and /usr/include etc), doesn't work either. -tried php 4.1.0, php 4.2.0 and php 4.2.1 -searching bug database for similiar problem :) -been busy googling for 4 days, yet to find no fix for this problem, only people that have the same problem and didnt get an answer too. THE thing that i don't understand is that if i leave apache support out and compile it as a cgi binary it gives no compile errors. help? -- Edit this bug report at http://bugs.php.net/?id=17269&edit=1
Bug #17271 Updated: stripslashes crashes with magic_quotes_sybase = On
ID: 17271
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Reproducible crash
Operating System: Windows 2000 SP2
PHP Version: 4.2.1
New Comment:
Fixed in CVS
Previous Comments:
[2002-05-16 10:14:46] [EMAIL PROTECTED]
The following code crashes PHP on a clean Win2k SP2 installation, at
least version 4.2.1 and 4.2.0
The problem seems to be any stripslashes with a string length of 23
characters (???)
Other string length seems to work fine.
ini_set ("magic_quotes_sybase",true);
echo stripslashes ("xxx");
echo stripslashes ("xx");
echo stripslashes ("");
--
Edit this bug report at http://bugs.php.net/?id=17271&edit=1
Bug #16721 Updated: Accentuation Support
ID: 16721 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: DOM XML related Operating System: SUSE Linux PHP Version: 4.1.2 New Comment: The funny characters are most certainly utf8 accented characters. you can convert them back to iso-8859-1 with utf8_decode() Previous Comments: [2002-04-21 11:56:03] [EMAIL PROTECTED] Correcting my bug´s description, the encoding that I used was ISO-8859-1 This is the recommended encoding for documents in Portuguese. Any other encoding makes xmldoc() return NULL when there are accents in the doc. With 'ISO-8859-1' document is parsed but accents become strange characters. [2002-04-21 11:49:37] [EMAIL PROTECTED] Accentuation support is not (correctly) implemented in DOM XML functions. I have used encoding=´ISO-8891-1´ in my XML docs with text in Portuguese. Document was parsed with xmldoc(), but accents appeared as strange characters. Removing the encoding=´ISO-8891-1´ part, xmldoc() returns NULL. -- Edit this bug report at http://bugs.php.net/?id=16721&edit=1
Bug #14895 Updated: Error when trying to load the php4 module
ID: 14895 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: OpenSSL related Operating System: FreeBSD 4.3-RELEASE PHP Version: 4.1.1 New Comment: Heya After recompiling imap-stuff, php with thousand of options and apache up and down for about half a day on a p90 (took damn long!) and always receiving the same bug on openbsd I think I can lift the mystery: Edit the Makefile in the UW-imap-Directory and set PASSWDTYPE=std By default it's none. On obsd it seems to fail on compiling. I hope I made now thousands of BSD users happy ;). BTW. I grepped the sources from the ftp and didn't installed it per package. Greetz Joel Wiesmann (You may change OS to - and Category to IMAP now ;)) Previous Comments: [2002-04-10 19:05:31] [EMAIL PROTECTED] Reopen if this still happens with latest CVS snapshot and if you're sure you don't have bogus c-client libs or header files in your system. [2002-02-27 23:57:42] [EMAIL PROTECTED] The answer is: Find and remove any old [lib]c-client.a|so on your system, then install the new uw c-client library or let php find it in your --with-imap directory. David [2002-02-27 23:28:46] [EMAIL PROTECTED] Any answers to this problem yet? #!/bin/bash rm config.cache; export LIBS="-ljpeg -lpng" LDFLAGS="-L/usr/local/ssl/lib -L/usr/X11R6/lib -L/usr/local/lib" \ CFLAGS="$CFLAGS -I/usr/local/include" CPPFLAGS="$CFLAGS" ./configure \ --with-apxs=/usr/local/apache/bin/apxs --enable-track-vars \ --enable-magic-quotes --enable-trans-sid --enable-memory-limit \ --enable-force-cgi-redirect --enable-discard-path --with-openssl \ --enable-sigchild --enable-bcmath --with-bz2 \ --enable-calendar --enable-ftp \ --with-imap=/usr/src/imap-2002.DEV.SNAP-0202261726/ --with-imap-ssl=/usr/local/ssl/lib \ --with-pgsql --enable-trans-sid --with-zlib \ --with-mysql=no \ --enable-sysvshm --x-libraries=/usr/X11R6/lib \ --with-freetype-dir=/usr/local/include/freetype1/ \ --with-jpeg-dir=shared \ --with-png-dir=shared --with-xpm-dir=shared --with-gd-dir=shared --with-gd ... Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/apache/libexec/libphp4.so: undefined symbol: ssl_onceonlyinit imapd is compiled as: make install SSLTYPE=nopwd ssl_onceonlyinit is located in imapd/src/osdep/unix/ssl_unix.c [2002-02-22 02:32:27] [EMAIL PROTECTED] Sorry, this actually WAS imap-ssl related. [2002-01-19 14:33:23] [EMAIL PROTECTED] I've searched the bugdb per your suggestion, Derick. All I found were two old IMAP-SSL related issues when I searched for the function name (ssl_onceonlyinit). I can download a copy of the CVS source if you like and retry my compile to see if it is fixed. Something to note, is on a fresh FreeBSD install (4.4-RELEASE), I installed apache and mod_php from a cvsup'ed ports collection, and I get the same error, so you may start to get more wide spread reports of this error. Let me know. 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/14895 -- Edit this bug report at http://bugs.php.net/?id=14895&edit=1
Bug #16647 Updated: DomDocument->get_element_by_id() doesn't work
ID: 16647
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Analyzed
+Status: Closed
Bug Type: DOM XML related
Operating System: linux 2.4.4
PHP Version: 4.0CVS-2002-04-1
New Comment:
Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at
http://www.php.net/downloads.php
Previous Comments:
[2002-04-18 10:10:58] [EMAIL PROTECTED]
Quote from the Document Object Model (DOM) Level 2 Core Specification:
Attributes with the name "ID" are not of type ID unless
so defined. Implementations that do not know whether
attributes are of type ID or not are expected to return
null.
That means that DomDocument->get_document_by_id("X") and
XPathContext->xpath_eval("//*[@id='X']) are not equivalent and that the
former function should only return a result if a DTD is referenced
which declares attributes of type ID.
[2002-04-18 07:44:04] [EMAIL PROTECTED]
Ooop. didn't much think about case sensitivity back then :)
A quick soultion would be:
"//*[@ID = '%s' or @id = '%s']".
I don't know, which version is really correct according to W3C (but
anyways, the ID-attribute should be stated in the DTD, so this whole
xpath-approach is actually rather wrong :) )
chregu
[2002-04-18 01:37:04] [EMAIL PROTECTED]
get_element_by_id() used xpath_eval as well but
searches for "//*[@ID = '%s']". If you capitalize
the id it should work. Do you have an idea how to search
case insensitve?
[2002-04-16 20:04:48] [EMAIL PROTECTED]
The following script returns bool(false):
Test
Test
Foo
_END;
$doc = domxml_open_mem($src);
$n = $doc->get_element_by_id("test");
var_dump($n);
?>
Workaround: Use Xpath expressions to find the node:
Test
Test
Foo
_END;
$doc = domxml_open_mem($src);
$ctx = $doc->xpath_new_context();
$res = $ctx->xpath_eval("//*[@id='test']");
$n = $res->nodeset[0];
var_dump($n);
?>
--
Edit this bug report at http://bugs.php.net/?id=16647&edit=1
Bug #16825 Updated: Latest updates make compilation fail
ID: 16825 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: DOM XML related Operating System: RedHat 7.1 PHP Version: 4.0CVS-2002-04-25 New Comment: You need at least libxml2-2.4.14 for a clean compile. This is fixed in CVS, so configure checks for that, Previous Comments: [2002-04-25 11:04:43] [EMAIL PROTECTED] After latest CVS update, compiling against installed libxml2-2.4.2 fails with the following: /projects/compile/php4/ext/domxml/php_domxml.c: In function `zif_domxml_doc_get_element_by_id': /projects/compile/php4/ext/domxml/php_domxml.c:2711: warning: passing arg 2 of `xmlHashScan' from incompatible pointer type -- Edit this bug report at http://bugs.php.net/?id=16825&edit=1
Bug #17271: stripslashes crashes with magic_quotes_sybase = On
From: [EMAIL PROTECTED]
Operating system: Windows 2000 SP2
PHP version: 4.2.1
PHP Bug Type: Reproducible crash
Bug description: stripslashes crashes with magic_quotes_sybase = On
The following code crashes PHP on a clean Win2k SP2 installation, at least
version 4.2.1 and 4.2.0
The problem seems to be any stripslashes with a string length of 23
characters (???)
Other string length seems to work fine.
ini_set ("magic_quotes_sybase",true);
echo stripslashes ("xxx");
echo stripslashes ("xx");
echo stripslashes ("");
--
Edit bug report at http://bugs.php.net/?id=17271&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17271&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17271&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17271&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17271&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17271&r=support
Expected behavior: http://bugs.php.net/fix.php?id=17271&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17271&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17271&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17271&r=globals
Bug #17234 Updated: setting short_open_tag in .htaccess does nothing
ID: 17234 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Apache2 related Operating System: Windows XP PHP Version: 4.2.1 Previous Comments: [2002-05-15 19:28:19] [EMAIL PROTECTED] Error message: /.htaccess: Invalid command 'php_flag', perhaps mis-spelled or defined by a module not included in the server configuration. This isn't bogus yet. [2002-05-15 14:41:15] [EMAIL PROTECTED] You need php_flag for on/off settings: php_flag short_open_tag off [2002-05-15 00:39:18] [EMAIL PROTECTED] Sorry, module. I've tried other values such as display_errors and that changes fine. [2002-05-15 00:32:23] [EMAIL PROTECTED] CGI or Apache module? The CGI version of PHP does not read .htaccess. [2002-05-14 23:45:19] [EMAIL PROTECTED] Entering a value for short_open_tag in the .htaccess file achieves nothing. Example: php_value short_open_tag X Where X is 0, 1, off, on, true, false, etc. Executing phpinfo() will reveal the local value does not change from the master value, whether the master value is on or off. I'd like to keep short_open_tag on for the majority of sites I'm running on my server but there is one in particular making use of XML which I want to disable short_open_tag for. -- Edit this bug report at http://bugs.php.net/?id=17234&edit=1
Bug #17270 Updated: Make fail with php 4.2.1 on Solaris 5.8
ID: 17270 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Closed Bug Type: Compile Failure Operating System: Solaris 5.8 PHP Version: 4.2.1 New Comment: Use CC=gcc ./configure Seems to be a bug in autoconf, closing. Previous Comments: [2002-05-16 08:37:30] [EMAIL PROTECTED] Duplicate of #17218. [2002-05-16 08:22:59] [EMAIL PROTECTED] I've tried to compile PHP-4.2.1 on Solaris 5.8. Here is my "configure" option: -- ./configure --prefix=/data/php-4.2.1 --with-mysql --with-apxs=/data/www/bin/apxs --with-oci8=/data/oracle/v817 --with-gd=/usr/local ... Here is the output of "make": - Making all in Zend make[1]: Entering directory `/tmp/php-4.2.1/Zend' /bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../main -D_POSIX_PTHREAD_SEMANTICS -DSOLARIS2=280 -DMOD_SSL=208105 -DEAPI -DUSE_EXPAT -I../TSRM -g -O2 -prefer-pic -c -o zend_language_parser.lo `test -f zend_language_parser.c || echo './'`zend_language_parser.c In file included from zend_compile.h:24, from zend_language_parser.c:147: zend.h:55: unix.h: No such file or directory make[1]: *** [zend_language_parser.lo] Error 1 make[1]: Leaving directory `/tmp/php-4.2.1/Zend' make: *** [all-recursive] Error 1 PHP 4.1.2 compiles just fine There no "unix.h" -- Edit this bug report at http://bugs.php.net/?id=17270&edit=1
Bug #17218 Updated: PHP 4.2.1 doesn't compile after ./configure
ID: 17218 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.2.1 New Comment: Confirmed here as well. CC=gcc does the trick. I'll take my configure output offline also. Thanks everyone who helped track down the problem! Previous Comments: [2002-05-16 09:15:38] [EMAIL PROTECTED] Ok. We can conclude that this is an autoconf bug with an easy workaround. Closing the bug report. [2002-05-16 09:06:33] [EMAIL PROTECTED] "export CC=gcc" solves the problems with the configure of 4.2.1! THANKS again p.s: I'm gonna delete the output files from our ftp directory [2002-05-15 18:34:32] [EMAIL PROTECTED] I can see that configure in 4.2.1 tarball wrongly tries to use cc instead of gcc in all the tests it fails. What happens if you try to run 4.2.1 configure with: CC=gcc ./configure ... [2002-05-15 14:39:13] [EMAIL PROTECTED] Here you can download the two outputs: ftp://ftp.tugraz.at/mirror/php/tmp/php-config/ [2002-05-15 14:38:49] [EMAIL PROTECTED] Configure output and config.log are here: http://dsb3.com/debug/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/17218 -- Edit this bug report at http://bugs.php.net/?id=17218&edit=1
Bug #17218 Updated: PHP 4.2.1 doesn't compile after ./configure
ID: 17218 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.2.1 New Comment: Ok. We can conclude that this is an autoconf bug with an easy workaround. Closing the bug report. Previous Comments: [2002-05-16 09:06:33] [EMAIL PROTECTED] "export CC=gcc" solves the problems with the configure of 4.2.1! THANKS again p.s: I'm gonna delete the output files from our ftp directory [2002-05-15 18:34:32] [EMAIL PROTECTED] I can see that configure in 4.2.1 tarball wrongly tries to use cc instead of gcc in all the tests it fails. What happens if you try to run 4.2.1 configure with: CC=gcc ./configure ... [2002-05-15 14:39:13] [EMAIL PROTECTED] Here you can download the two outputs: ftp://ftp.tugraz.at/mirror/php/tmp/php-config/ [2002-05-15 14:38:49] [EMAIL PROTECTED] Configure output and config.log are here: http://dsb3.com/debug/php/ [2002-05-15 14:32:16] [EMAIL PROTECTED] Configure output sent to mfischer by email since 4 files of ~ 100k each were attached (too large to paste into comment box). 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/17218 -- Edit this bug report at http://bugs.php.net/?id=17218&edit=1
Bug #16888 Updated: domXML causes Segfault, when you create to many Nodes
ID: 16888 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: DOM XML related Operating System: Windows XP PHP Version: 4.2.0 New Comment: Edin created a new php_domxml.dll with libxml2-2.4.21 compile d in. It's available at http://ftp.proventum.net/pub/php/win32/php_domxml.zip Can you check that. But i fear, it doesn't help solve the problem :( Please be aware, that append_child changed the meaning in 4.2.1. The former append_child is now append_sibling, and append_child behaves like the w3c likes it. But appending a sibling to the root node, doesn't make really sense, but it souldn't crash PHP, either :) I would be very glad, if someone with windows programming experience could hunt down the problem. chregu Previous Comments: [2002-05-15 17:50:13] [EMAIL PROTECTED] FWIW, the sample script works ok using the latest HEAD under IIS in debug mode...well, works is an approximation. It doesn't crash until the Zend tries to clean up memory, and then crashes in _zval_ptr_dtor. Not feeling like a Zend guru today, I don't feel like attacking it. I'll try Apache though to see if I can narrow this bug down. [2002-05-15 16:15:27] [EMAIL PROTECTED] I tried the newest xml-lib build from http://www.fh-frankfurt.de/~igor/projects/libxml/ (Version 2.4.21) and apache still crashes. I also can confirm the barrier with 128 elements. [2002-05-15 12:28:24] [EMAIL PROTECTED] One more interesting remark - DOM XML module crashes if more then 128 elements are created. Less then 128 elements are created without problems. Maybe it will help you somehow? [2002-05-15 12:23:10] [EMAIL PROTECTED] Confirmed under windows 2000 server running as CGI with following combinations: PHP 4.1.1 + libxml2 2.4.21 - works well PHP 4.2.0 + libxml2 2.4.21 - crash PHP 4.2.1 + libxml2 2.4.9 - crash Unfortunatelly latest PHP version - 4.2.1 have been build with libxml2 compiled as static library, so i can't test it with latest libxml2. So it is not a problem of libxml2, but something into DOM XML module itself. PHP crashes into final stage, when script execution itself is completed (and even function, registered as shutdown function have been executed). [2002-05-15 08:57:08] [EMAIL PROTECTED] I would blame libxml2 :) Do you have the latest libxml2 dll? (available anywhere from http://www.xmlsoft.org). Can you check with that? chregu 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/16888 -- Edit this bug report at http://bugs.php.net/?id=16888&edit=1
Bug #17218 Updated: PHP 4.2.1 doesn't compile after ./configure
ID: 17218 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.2.1 New Comment: "export CC=gcc" solves the problems with the configure of 4.2.1! THANKS again p.s: I'm gonna delete the output files from our ftp directory Previous Comments: [2002-05-15 18:34:32] [EMAIL PROTECTED] I can see that configure in 4.2.1 tarball wrongly tries to use cc instead of gcc in all the tests it fails. What happens if you try to run 4.2.1 configure with: CC=gcc ./configure ... [2002-05-15 14:39:13] [EMAIL PROTECTED] Here you can download the two outputs: ftp://ftp.tugraz.at/mirror/php/tmp/php-config/ [2002-05-15 14:38:49] [EMAIL PROTECTED] Configure output and config.log are here: http://dsb3.com/debug/php/ [2002-05-15 14:32:16] [EMAIL PROTECTED] Configure output sent to mfischer by email since 4 files of ~ 100k each were attached (too large to paste into comment box). [2002-05-15 13:53:52] [EMAIL PROTECTED] Could someone with access to solaris provide the full output of ./configure and config.log from both 2.13 and 2.52 for download ? Seems another detection thing we need to fix. 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/17218 -- Edit this bug report at http://bugs.php.net/?id=17218&edit=1
Bug #17262 Updated: PHP 4.2.1 fails to install when compiled as a CGI
ID: 17262 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: *Compile Issues Operating System: RedHat linux 7.3 PHP Version: 4.2.1 New Comment: This is the full error, I can paste the entire contents of the "make install" when I get to work if you like. Previous Comments: [2002-05-16 06:41:20] [EMAIL PROTECTED] Can you please copy and paste the FULL error? [2002-05-15 18:20:04] [EMAIL PROTECTED] When compiling php with the following options on a stock RedHat 7.3 system: ./configure \ --without-mysql \ --with-config-file-path=/etc \ --with-zlib \ --with-gd \ --with-pgsql \ --with-system-regex \ --with-pdflib I recieve this error when performing the make install: Making install in . make[1]: Entering directory `/sources/php-4.2.1' make[1]: *** [install-sapi] Error 1 make[1]: Leaving directory `/sources/php-4.2.1' make: *** [install-recursive] Error 1 The php binary is not installed when I get this message. I can copy the file into the /usr/local/lib directory and it *appears* to work ok. This problem was not present in php version 4.1.2. -- Edit this bug report at http://bugs.php.net/?id=17262&edit=1
Bug #16718 Updated: setlocale() corrupts all functions that depend on it: WDDX, strftime, ucwords
ID: 16718 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: Win 2k PHP Version: 4.1.2 New Comment: if you want to resolve this problem change all mssql querys with odbc querys and all will be ok...i tryed this and it works.:):):):) bye Previous Comments: [2002-04-21 06:48:54] [EMAIL PROTECTED] Just managed to get WDDX to run again, but it's rather a coincidence. I was playing around with the setlocale parameters and calling setlocale(LC_ALL,"ge"); Call the script 2x (twice!) and WDDX worked! Immediately commented the setlocale() out after and don't us it on win2k!!! "; echo htmlspecialchars($ser) . "\n"; var_dump($des); echo ""; ?> [2002-04-21 06:18:07] [EMAIL PROTECTED] Hi First a list of all bug repports that I've found that I think are all caused be the setlocale() function: Note that some assume the bug in WDDX, strftime or ucword but it's acctually the setlocale() that causes it. Bug List: - - - - - WDDX: "german characters cannot be stored" Status:OPEN http://bugs.php.net/bug.php?id=15800 ucwords(): "ucwords failing randomly with international characters" Status:OPEN http://bugs.php.net/bug.php?id=14655 strftime(): "xml in zlib.xml does not use CDATA for code" " Status:BOGUS http://bugs.php.net/bug.php?id=14180 mssql_fetch_array(): "French special characters" Status:BOGUS (Not sure about this one) http://bugs.php.net/bug.php?id=16151 setlocale(): "Does it exist some way how to sort Czech texts inside arrays" Status:CLOSED http://bugs.php.net/bug.php?id=10749 Intressting is that bug #14655 and my comment in bug #15800 that it's something random. I'm adding my bug comment from bug #15800 below: > It's very inconsisten! > At first I wasn't using setlocale() and all seamed fine. > But after I called setlocale() the wddx serialize failed all the time! > > Multiple calls of setlocale() produce 2 different results that alternate. > After every Apache restart the results changes sort of randomly! > If setlocale() is commented out, the the last result remains(even after apache is restarted). > > It seams as if setlocale() is writting something wrong to the apache conf. > Reboot didn't help, my wddx serializetion is mucked up now! :( > Don't use it on Win2000!!! Following code was used to test : "; echo htmlspecialchars($ser) . "\n"; var_dump($des); echo ""; ?> -- Edit this bug report at http://bugs.php.net/?id=16718&edit=1
Bug #17270 Updated: Make fail with php 4.2.1 on Solaris 5.8
ID: 17270 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Duplicate Bug Type: Compile Failure Operating System: Solaris 5.8 PHP Version: 4.2.1 New Comment: Duplicate of #17218. Previous Comments: [2002-05-16 08:22:59] [EMAIL PROTECTED] I've tried to compile PHP-4.2.1 on Solaris 5.8. Here is my "configure" option: -- ./configure --prefix=/data/php-4.2.1 --with-mysql --with-apxs=/data/www/bin/apxs --with-oci8=/data/oracle/v817 --with-gd=/usr/local ... Here is the output of "make": - Making all in Zend make[1]: Entering directory `/tmp/php-4.2.1/Zend' /bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../main -D_POSIX_PTHREAD_SEMANTICS -DSOLARIS2=280 -DMOD_SSL=208105 -DEAPI -DUSE_EXPAT -I../TSRM -g -O2 -prefer-pic -c -o zend_language_parser.lo `test -f zend_language_parser.c || echo './'`zend_language_parser.c In file included from zend_compile.h:24, from zend_language_parser.c:147: zend.h:55: unix.h: No such file or directory make[1]: *** [zend_language_parser.lo] Error 1 make[1]: Leaving directory `/tmp/php-4.2.1/Zend' make: *** [all-recursive] Error 1 PHP 4.1.2 compiles just fine There no "unix.h" -- Edit this bug report at http://bugs.php.net/?id=17270&edit=1
Bug #17270: Make fail with php 4.2.1 on Solaris 5.8
From: [EMAIL PROTECTED] Operating system: Solaris 5.8 PHP version: 4.2.1 PHP Bug Type: Compile Failure Bug description: Make fail with php 4.2.1 on Solaris 5.8 I've tried to compile PHP-4.2.1 on Solaris 5.8. Here is my "configure" option: -- ./configure --prefix=/data/php-4.2.1 --with-mysql --with-apxs=/data/www/bin/apxs --with-oci8=/data/oracle/v817 --with-gd=/usr/local ... Here is the output of "make": - Making all in Zend make[1]: Entering directory `/tmp/php-4.2.1/Zend' /bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../main -D_POSIX_PTHREAD_SEMANTICS -DSOLARIS2=280 -DMOD_SSL=208105 -DEAPI -DUSE_EXPAT -I../TSRM -g -O2 -prefer-pic -c -o zend_language_parser.lo `test -f zend_language_parser.c || echo './'`zend_language_parser.c In file included from zend_compile.h:24, from zend_language_parser.c:147: zend.h:55: unix.h: No such file or directory make[1]: *** [zend_language_parser.lo] Error 1 make[1]: Leaving directory `/tmp/php-4.2.1/Zend' make: *** [all-recursive] Error 1 PHP 4.1.2 compiles just fine There no "unix.h" -- Edit bug report at http://bugs.php.net/?id=17270&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17270&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17270&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17270&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17270&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17270&r=support Expected behavior: http://bugs.php.net/fix.php?id=17270&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17270&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17270&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17270&r=globals
Bug #17243 Updated: When trying to compile --with-mm, build failed
ID: 17243 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: Linux (RH 7.3) PHP Version: 4.2.1 New Comment: mm version is 1.1.3-4 (RH 7.3 default) and full configure line is: sh ./configure --with-mod_charset --with-openssl --enable-inline-optimization --enable-memory-limit --enable-track-vars --enable-sigchild --enable-magic-quotes --enable-gd-native-ttf --enable-discard-path --enable-trans-sid --enable-versioning --enable-sockets --enable-ftp --enable-bcmath --enable-dba --with-unixODBC --enable-safe-mode --with-config-file-path=/usr/local/etc --with-wddx --with-mysql=/usr --with-gd=/usr --enable-mbstring --with-jpeg-dir=/usr --with-zlib-dir=/usr --enable-shmop --enable-sysvsem --with-freetype --enable-dbase --with-bz2 --enable-calendar --with-pspell --with-qtdom --enable-tokenizer --with-mm This is configure line for CGI. For apache module, I have many things shared (openssl, mysql, bz2, etc.), but when configured with this line, it doesn't work. It works without "--with-mm". It doesn't care if it's shared or not. If it compiles without "--with-mm" and with "--with-bz2=shared", it writes Warning to error_log when starting apache: PHP Warning: Invalid library (maybe not a PHP library) 'bz2.so' in Unknown on line 0 It was OK, on same system with PHP<=4.1.2. Do you know what it means? I don't. If openssl support is configured as shared, no openssl.so file is created after build, but when I added "--with-oci8=shared" and "--with-oracle=shared", it was OK, the file openssl.so was created. Those are very strange errors. Previous Comments: [2002-05-15 14:39:08] [EMAIL PROTECTED] What is your full configure line and your version of MM? [2002-05-15 07:09:08] [EMAIL PROTECTED] Build ends with this error: internal_functions.c:57: `phpext_ps_mm_ptr' undeclared here (not in a function) internal_functions.c:57: initializer element is not constant internal_functions.c:57: (near initialization for `php_builtin_extensions[11]') -- Edit this bug report at http://bugs.php.net/?id=17243&edit=1
Bug #17269: compile problem with GD & JPEG support
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.3 PHP version: 4.2.1 PHP Bug Type: GD related Bug description: compile problem with GD & JPEG support when compiling PHP with GD & JPEG support i get a lot of errors with libjpeg.a moaning about 'multiple definitions' and 'first defined here' stuff. system config: FreeBSD 4.3 Apache 2.0.36 PHP 4.2.1 GD 1.8.4 (compiled ok with support for png, jpeg, freetype) Jpeg 6B Libpng 1.2.2 Gdbm 1.8.0 Pdflib 4.0.2 Freetype 2.1.0 configure: ./configure \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-config-file-path=/etc \ --enable-shared \ --enable-track-vars \ --enable-ftp \ --with-gdbm=/usr/local \ --with-gd=/usr/local/graph/gd \ --with-jpeg-dir=/usr/local/graph/jpeg \ --enable-gd-native-ttf \ --with-png-dir=/usr/local/graph/png \ --with-freetype-dir=/usr/local/graph/freetype2 \ --with-mysql=/usr/local \ --with-zlib-dir=/usr/local/graph/zlib \ --with-zlib \ --with-pdflib=/usr/local/graph/pdflib \ --with-tsrm-pth \ configure goes OK. all the functions are supported and no errors are given. When i do a gmake i get this error: /usr/local/lib/libjpeg.a(jcapimin.o): In function `jpeg_CreateCompress': jcapimin.o(.text+0x0): multiple definition of `jpeg_CreateCompress' /usr/local/lib/libjpeg.a(jcapimin.o)(.text+0x0): first defined here It goes on for about 50 of these jpeg_. you can look at the complete error here: http://httpd.chello.nl/~jstienstra01/php/compile_error.txt The STRANGE thing is that if i leave apache2 support out (--with-apxs2) and compile it as a CGI-BINARY, i do not get errors and it compiles fine ? thing i've tried: -tried GD2.0.1 and gd 1.8.3 instead of gd 1.8.4 -did a system search for old jpeg/png/GD libraries. deleted them all and did a clean install for these packages -install the packages in standard directorys (/usr/lib and /usr/include etc), doesn't work either. -tried php 4.1.0, php 4.2.0 and php 4.2.1 -searching bug database for similiar problem :) -been busy googling for 4 days, yet to find no fix for this problem, only people that have the same problem and didnt get an answer too. THE thing that i don't understand is that if i leave apache support out and compile it as a cgi binary it gives no compile errors. help? -- Edit bug report at http://bugs.php.net/?id=17269&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17269&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17269&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17269&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17269&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17269&r=support Expected behavior: http://bugs.php.net/fix.php?id=17269&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17269&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17269&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17269&r=globals
Bug #17262 Updated: PHP 4.2.1 fails to install when compiled as a CGI
ID: 17262 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *Compile Issues Operating System: RedHat linux 7.3 PHP Version: 4.2.1 New Comment: Can you please copy and paste the FULL error? Previous Comments: [2002-05-15 18:20:04] [EMAIL PROTECTED] When compiling php with the following options on a stock RedHat 7.3 system: ./configure \ --without-mysql \ --with-config-file-path=/etc \ --with-zlib \ --with-gd \ --with-pgsql \ --with-system-regex \ --with-pdflib I recieve this error when performing the make install: Making install in . make[1]: Entering directory `/sources/php-4.2.1' make[1]: *** [install-sapi] Error 1 make[1]: Leaving directory `/sources/php-4.2.1' make: *** [install-recursive] Error 1 The php binary is not installed when I get this message. I can copy the file into the /usr/local/lib directory and it *appears* to work ok. This problem was not present in php version 4.1.2. -- Edit this bug report at http://bugs.php.net/?id=17262&edit=1
Bug #17113 Updated: Apache 2.0 restart gives segmentation fault
ID: 17113
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Apache2 related
Operating System: Linux Mandrake 8.2
PHP Version: 4.2.0
New Comment:
Not yet solved in 4.2.1
Jan P. Sorensen
Previous Comments:
[2002-05-10 11:19:51] [EMAIL PROTECTED]
I tried CVS from may 10. It did not solve the restart
problem.
Jan P. Sorensen
[2002-05-09 17:10:14] [EMAIL PROTECTED]
This bug has been fixed in CVS. You can grab a snapshot of the
CVS version at http://snaps.php.net/. In case this was a documentation
problem, the fix will show up soon at http://www.php.net/manual/.
Thank you for the report.
This is fixed in CVS, I believe. Thanks!
[2002-05-09 15:50:35] [EMAIL PROTECTED]
I fail to get a usefull core dump.
I tried "httpd -X" and "kill -HUP pid" from another terminal. I also
tried "gdb ./httpd", "run -X" and "bt"
The result is probably useless, since I get the same result with and
without the PHP4 module.
Program received signal SIGHUP, Hangup.
[Switching to Thread 1024 (LWP 25947)]
0x401d20b2 in accept () from /lib/libc.so.6
(gdb) bt
#0 0x401d20b2 in accept () from /lib/libc.so.6
#1 0x400db646 in accept (fd=5, addr=
{__sockaddr__ = 0x817cc24, __sockaddr_at__ = 0x817cc24,
__sockaddr_ax25__ = 0x817cc24, __sockaddr_dl__ = 0x817cc24,
__sockaddr_eon__ = 0x817cc24, __sockaddr_in__ = 0x817cc24,
__sockaddr_in6__ = 0x817cc24, __sockaddr_inarp__ = 0x817cc24,
__sockaddr_ipx__ = 0x817cc24, __sockaddr_iso__ = 0x817cc24,
__sockaddr_ns__ = 0x817cc24, __sockaddr_un__ = 0x817cc24,
__sockaddr_x25__ = 0x817cc24}, addr_len=0x817cc40)
at wrapsyscall.c:187
#2 0x400381b6 in apr_accept (new=0xb8b0, sock=0x80b9340,
connection_context=0x817cb60) at sockets.c:189
#3 0x080969f4 in unixd_accept (accepted=0xb8e0, lr=0x817ab98,
ptrans=0x817cb60) at unixd.c:425
#4 0x0807fa91 in child_main (child_num_arg=0) at prefork.c:651
#5 0x0807fb9f in make_child (s=0x81477e0, slot=0) at prefork.c:711
#6 0x0807fc8d in startup_children (number_to_start=5) at
prefork.c:783
#7 0x0807ff9d in ap_mpm_run (_pconf=0x80bb020, plog=0x80f7110,
s=0x81477e0)
at prefork.c:999
#8 0x080850c7 in main (argc=2, argv=0xba74) at main.c:632
#9 0x400fe280 in __libc_start_main () from /lib/libc.so.6
Jan P. Sorensen
[2002-05-09 06:39:40] [EMAIL PROTECTED]
To properly diagnose this bug, we need a backtrace to see what is
happening behind the scenes. To find out how to generate a backtrace,
please read http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open".
[2002-05-09 06:33:42] [EMAIL PROTECTED]
PHP 4.2 CVS version from may 9. and Apache 2.0.36
may be started correctly by the command: "bin/apachectl start"
However after a "bin/apachectl restart" the Webserver crashes:
[Thu May 09 10:52:42 2002] [notice] Apache/2.0.36 (Unix) PHP/4.3.0-dev
configured -- resuming normal operations
[Thu May 09 10:53:30 2002] [notice] SIGHUP received. Attempting to
restart
[Thu May 09 10:53:31 2002] [notice] seg fault or similar nasty error
detected in the parent process
[Thu May 09 10:54:56 2002] [warn] pid file
/usr/local/apache2/logs/httpd.pid overwritten -- Unclean shutdown of
previous Apache run?
[Thu May 09 10:54:56 2002] [notice] Apache/2.0.36 (Unix) PHP/4.3.0-dev
configured -- resuming normal operations
A full stop and start of Apache will circumvent the problem.
Apache: ./configure --enable-proxy
PHP: ./configure --with-apxs2=../httpd-2.0.36/support/apxs
--enable-track-vars --with-mysql
The restart works correctly when the "modules/libphp4.so" is removed
fra the httpd.conf
This is a follow up to report #16475 where SSL was included.
Jan P. Sorensen
--
Edit this bug report at http://bugs.php.net/?id=17113&edit=1
Bug #16151 Updated: French special characters
ID: 16151 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: MSSQL related Operating System: windows 200 PHP Version: 4.1.2 New Comment: Hello ! i have similar problem : environment: Windows 2000 Pro SQL Server 2000 PHP 4.1.1 - i insert the caracter "é" in a table using mssql functions. - when i read the table in Entreprise Manager : i have "Ú" instead of "é" - i replace "Ú" by "é" in Entreprise Manager - when i read the table with php mssql functions : i have "," instead of "é" sorry for my poor english Previous Comments: [2002-04-21 06:26:28] [EMAIL PROTECTED] setlocale() on windows is the problem! See bug #16718 http://bugs.php.net/bug.php?id=16718 [2002-03-19 04:21:40] [EMAIL PROTECTED] The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php [2002-03-18 13:32:55] [EMAIL PROTECTED] Hello i want to insert in a MSSQL server 2000 some informations that are typed in french with éèàç etc.. like this : and after that in the database is just this TFta WHY i am not understanding!!!? PLEASE HELP ME !! thank you fou your help , Cris Badea Web Developer Tellme SA -- Edit this bug report at http://bugs.php.net/?id=16151&edit=1
Bug #17268 Updated: unset() hangs in infinite loop with Apache 1.3.24
ID: 17268 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Scripting Engine problem Operating System: Linux 2.4 PHP Version: 4.2.1 New Comment: No special script is required; even simple unset() calls fail: Previous Comments: [2002-05-16 05:34:12] [EMAIL PROTECTED] Please provide a short reproducing script. Derick [2002-05-16 05:20:59] [EMAIL PROTECTED] My PHP 4.2.1 with Apache 1.3.24 has the following problem: unset() hangs in most cases in an infinite loop. It's independent from the type of the variable, or if the variable does exist at all. I experienced this problem only with the Apache-compiled-in version; the same PHP version as standalone CGI with the same compile options and php.ini doesn't have this problem. The apache process executing a script which came to an unset() call uses >90% of the CPU time until it gets stopped by the maximum execution time limit. register_globals is set to "On". -- Edit this bug report at http://bugs.php.net/?id=17268&edit=1
Bug #12260 Updated: Compile failure --with-oci8 and Oracle 8.0.4
ID: 12260 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: OCI8 related Operating System: Solaris 7 and 8 PHP Version: 4.0.6 New Comment: sent 8.0.4 header files to [EMAIL PROTECTED], but: 8.0.4 is really old now. Previous Comments: [2002-05-16 00:00:03] [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-04-13 08:40:50] [EMAIL PROTECTED] please send me a .tar containing the header files for 8.0.4 [2001-07-19 12:52:46] [EMAIL PROTECTED] Compilation failes --with-oci8 and ORACLE_HOME pointing to oracle 8.0.4 installation. A typedef and define for symbol dword is only available in oratypes.h of newer Oracle versions (checked with 8.0.5, 8.1.5 and 8.1.7) . Solution: change dword to sb4 in ext/oci8/oci8.c, that's still matching the oracle prototype (orl.h of oracle 8.1.7) sword OCICollAssignElem(OCIEnv *env, OCIError *err, sb4 index, CONST dvoid *elem, CONST dvoid *elemind, OCIColl *coll); gcc error: oci8.c: In function `php_if_ocicollgetelem': oci8.c:4480: warning: passing arg 7 of `OCIDateToText' from incompatible pointer type oci8.c: In function `php_if_ocicollassignelem': oci8.c:4604: `dword' undeclared (first use in this function) oci8.c:4604: (Each undeclared identifier is reported only once oci8.c:4604: for each function it appears in.) oci8.c:4604: parse error before `)' oci8.c:4626: parse error before `)' oci8.c:4657: parse error before `)' cheers, Michael -- Edit this bug report at http://bugs.php.net/?id=12260&edit=1
Bug #17268 Updated: unset() hangs in infinite loop with Apache 1.3.24
ID: 17268 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Linux 2.4 PHP Version: 4.2.1 New Comment: Please provide a short reproducing script. Derick Previous Comments: [2002-05-16 05:20:59] [EMAIL PROTECTED] My PHP 4.2.1 with Apache 1.3.24 has the following problem: unset() hangs in most cases in an infinite loop. It's independent from the type of the variable, or if the variable does exist at all. I experienced this problem only with the Apache-compiled-in version; the same PHP version as standalone CGI with the same compile options and php.ini doesn't have this problem. The apache process executing a script which came to an unset() call uses >90% of the CPU time until it gets stopped by the maximum execution time limit. register_globals is set to "On". -- Edit this bug report at http://bugs.php.net/?id=17268&edit=1
Bug #17268: unset() hangs in infinite loop with Apache 1.3.24
From: [EMAIL PROTECTED] Operating system: Linux 2.4 PHP version: 4.2.1 PHP Bug Type: Scripting Engine problem Bug description: unset() hangs in infinite loop with Apache 1.3.24 My PHP 4.2.1 with Apache 1.3.24 has the following problem: unset() hangs in most cases in an infinite loop. It's independent from the type of the variable, or if the variable does exist at all. I experienced this problem only with the Apache-compiled-in version; the same PHP version as standalone CGI with the same compile options and php.ini doesn't have this problem. The apache process executing a script which came to an unset() call uses >90% of the CPU time until it gets stopped by the maximum execution time limit. register_globals is set to "On". -- Edit bug report at http://bugs.php.net/?id=17268&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17268&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17268&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17268&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17268&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17268&r=support Expected behavior: http://bugs.php.net/fix.php?id=17268&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17268&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17268&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17268&r=globals
Bug #16629 Updated: php_flag not working and php_value strange behavior
ID: 16629 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache2 related Operating System: Windows XP PHP Version: 4.2.0 New Comment: Same. Win XP Apache 2.0.35 PHP 4.2.1 Previous Comments: [2002-05-10 03:12:09] [EMAIL PROTECTED] The same here: FreeBSD 4.6-PRERELEASE (~ 01 May 2002) PHP 4.2.0 Apache 2.0.35 php_flag in .htaccess produces an error by means of unrecognized command or something. php_value works fine. regards [2002-05-04 01:43:54] [EMAIL PROTECTED] got no error message by adding php_flag register_globals on However.. it has no effect at all. I tried to change the name for mod_php4.c to php4_module ,mod_php3.c,mod_php42.c but it seem that since with apache2 we dont need to specify AddModule mod_php4.c I dont know if its appache that doesnt go in the If Statement or if it is the php module that ignore the apache directive. It only work with php_value outside the if statement. as mentionned by katana. Im using Linux-Apache2.0.35 with php4.2.0 [2002-04-28 22:04:19] [EMAIL PROTECTED] I also have this problem under FreeBSD with Apache 2.0.35 and PHP/4.3.0-dev, and I have a working patch. I don't know where to sedn it or how to attach it. If someone could email me where to send it, I'll send it. [2002-04-26 17:47:09] [EMAIL PROTECTED] Same problem on Linux machine running apache 2.0.35 with FINAL release of php 4.2.0 [2002-04-24 17:11:42] [EMAIL PROTECTED] I have the same problem under Windows 98 SE (Apache 2.0.35) and the FINAL RELEASE of PHP 4.2.0. 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/16629 -- Edit this bug report at http://bugs.php.net/?id=16629&edit=1
Bug #16743 Updated: php_mysql.c:55: redefinition of `ushort'
ID: 16743 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: MySQL related Operating System: RedHat Linux 7.2 PHP Version: 4.2.0 New Comment: What is the fix? comment out line 55? Previous Comments: [2002-04-27 10:06:20] [EMAIL PROTECTED] Works fine by now ;-) [2002-04-26 21:04:56] [EMAIL PROTECTED] reclassified. [2002-04-26 21:04:38] [EMAIL PROTECTED] Fixed in CVS. Fix will be in PHP 4.2.1. --Jani [2002-04-23 03:42:50] [EMAIL PROTECTED] Sorry for the german messages ;-) Making all in mysql make[2]: Wechsel in das Verzeichnis Verzeichnis »/usr/src/php-4.2.0/ext/mysql« make[3]: Wechsel in das Verzeichnis Verzeichnis »/usr/src/php-4.2.0/ext/mysql« gcc -I. -I/usr/src/php-4.2.0/ext/mysql -I/usr/src/php-4.2.0/main -I/usr/src/php-4.2.0 -I/usr/src/php-4.2.0/Zend -I/usr//include -I/usr//include/mysql -I/usr/src/php-4.2.0/ext/xml/expat -I/usr/src/php-4.2.0/TSRM -g -O2 -c php_mysql.c && touch php_mysql.lo php_mysql.c:55: redefinition of `ushort' /usr/include/sys/types.h:151: `ushort' previously declared here make[3]: *** [php_mysql.lo] Fehler 1 make[3]: Verlassen des Verzeichnisses Verzeichnis »/usr/src/php-4.2.0/ext/mysql« make[2]: *** [all-recursive] Fehler 1 make[2]: Verlassen des Verzeichnisses Verzeichnis »/usr/src/php-4.2.0/ext/mysql« make[1]: *** [all-recursive] Fehler 1 make[1]: Verlassen des Verzeichnisses Verzeichnis »/usr/src/php-4.2.0/ext« make: *** [all-recursive] Fehler 1 [2002-04-23 02:53:22] [EMAIL PROTECTED] The commandlines I've used for configure are: ./configure --prefix=/usr/server/php --with-config-file-path/usr/server/config/--without-pear --with-openssl=/usr/ --enable-bcmath --with-mysql=/usr/ After changing the source code of ext/mysql/php_mysql.c in line 55 it worked then ;-) -- Edit this bug report at http://bugs.php.net/?id=16743&edit=1
