#20896 [Com]: php -w hangs indefinitely at 100% CPU
ID: 20896 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: SuSE 7.2 PHP Version: 4.3.0RC2 New Comment: Also repeatable on SuSE 8.0 Previous Comments: [2002-12-09 00:03:12] [EMAIL PROTECTED] Not quite a crash, but I found no better category (time to add one for the CLI SAPI?) A simple php -w filename.php will on my system output the things it should, but then hang forever at full CPU consumption. [PHP Modules] ctype gd mysql overload pcre pgsql posix session standard tokenizer xml zlib -- Edit this bug report at http://bugs.php.net/?id=20896&edit=1
#20896 [Opn->Ver]: php -w hangs indefinitely at 100% CPU
ID: 20896 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Verified -Bug Type: Reproducible crash +Bug Type: *General Issues Operating System: SuSE 7.2 PHP Version: 4.3.0RC2 New Comment: This happens also with the -s option. And with CGI binary too. Basically the reason is that the -s / -w options use some hackish way to accomplish the tasks. Which seems to work on some systems though.. Previous Comments: [2002-12-11 02:20:06] [EMAIL PROTECTED] Also repeatable on SuSE 8.0 [2002-12-09 00:03:12] [EMAIL PROTECTED] Not quite a crash, but I found no better category (time to add one for the CLI SAPI?) A simple php -w filename.php will on my system output the things it should, but then hang forever at full CPU consumption. [PHP Modules] ctype gd mysql overload pcre pgsql posix session standard tokenizer xml zlib -- Edit this bug report at http://bugs.php.net/?id=20896&edit=1
#20928 [Opn->Csd]: Static compile of PHP module with IBM DB2 doesn't work right with apache
ID: 20928 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: ODBC related Operating System: RH 7.2 PHP Version: 4.3.0RC2 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-12-11 01:22:06] [EMAIL PROTECTED] It got much further this time, but results are the same. Here is the paste of the last command and error: <=== src/modules/throttle ===> src/modules/php4 gcc -c -I../../os/unix -I../../include -O2 -march=i386 -mcpu=i686 -DLINUX=22 - I/usr/include/db1 -DMOD_SSL=208110 -DEAPI `../../apaci` -fpic -DSHARED_MODULE -D LINUX=22 -I/usr/include/db1 -DMOD_SSL=208110 -I/usr/src/redhat/BUILD/php4-20021 2110630/main -I/usr/src/redhat/BUILD/php4-200212110630/Zend -I/usr/src/redhat/BU ILD/php4-200212110630/TSRM -I/usr/src/redhat/BUILD/php4-200212110630 -I/usr/src/ redhat/BUILD/php4-200212110630/sapi/apache -I/usr/src/redhat/BUILD/php4-20021211 0630/main -I/usr/src/redhat/BUILD/php4-200212110630/Zend -I/usr/src/redhat/BUILD /php4-200212110630/TSRM mod_php4.c && mv mod_php4.o mod_php4.so-o rm -f libphp4.so gcc -shared -o libphp4.so mod_php4.so-o libmodphp4.a -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr/local/Informix/lib -Wl,-rpath,/usr/local/Informix/lib/esql -Wl,- rpath,/usr/src/redhat/BUILD/php4-200212110630/ext/informix -rdynamic -rdynamic -L/usr/local/lib -L/usr/local/Informix/lib -L/usr/local/Informix/lib/esql -L/usr /src/redhat/BUILD/php4-200212110630/ext/informix -Lmodules/php4 -L../modules/php 4 -L../../modules/php4 -lmodphp4 -ldb2 -lcrypto -lssl -lc-client -lifsql -lifa sf -lifgen -lifos -lifgls -ldl -lcrypt -lphpifx -lifglx -lpdf -lz -lldap -llber -lcrypt -lpam -lfdftk -lz -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -lm -lcrypt -ldb1 -ldb -lexpat -ldl -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr/local/Informi x/lib -Wl,-rpath,/usr/local/Informix/lib/esql -Wl,-rpath,/usr/src/redhat/BUILD/p hp4-200212110630/ext/informix -rdynamic -rdynamic -L/usr/local/lib -L/usr/local /Informix/lib -L/usr/local/Informix/lib/esql -L/usr/src/redhat/BUILD/php4-200212 110630/ext/informix -Lmodules/php4 -L../modules/php4 -L../../modules/php4 -lmodp hp4 -ldb2 -lcrypto -lssl -lc-client -lifsql -lifasf -lifgen -lifos -lifgls -ld l -lcrypt -lphpifx -lifglx -lpdf -lz -lldap -llber -lcrypt -lpam -lfdftk -lz -lc rypt -lresolv -lm -ldl -lnsl -lcrypt -lm -lcrypt -ldb1 -ldb /usr/bin/ld: cannot find -ldb2 collect2: ld returned 1 exit status make[4]: *** [libphp4.so] Error 1 make[3]: *** [all] Error 1 make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/apache_1.3.26/src' make[1]: *** [build-std] Error 2 make[1]: Leaving directory `/usr/src/redhat/BUILD/apache_1.3.26' make: *** [build] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.89498 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.89498 (%build) [2002-12-11 00:48:46] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-11 00:46:35] [EMAIL PROTECTED] BTW, when I look at the command that compiles apache, it is clearly missing the -L/home/db2inst1/sqllib/lib in the list of library paths. This is the reason it's failing. I don't know how to add that path so that make in the apache dir will pick it up properly. [2002-12-11 00:43:16] [EMAIL PROTECTED] I actually added the LDFLAGS myself to try and get things to start working. When you set up an instance (called db2inst1), it creates symbolic links in the instance directory to the /usr/IBMdb2/V7.1 directory for all the commands, libraries, and utilities. So LDFLAGS can be set to either, it really doesn't matter. [2002-12-11 00:24:49] [EMAIL PROTECTED] You're passing the configure a different path to the DB2 install directory and then you set LDFLAGS to something else. Not PHP bug, user error. The remainder of the comments fo
#20871 [Opn]: Apache restarts with no output
ID: 20871 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: IMAP related Operating System: win2K PHP Version: 4.2.3 New Comment: I'd be glad to know if any measures are being taken in order to fix the buggie. I hope that you at least succeeded reproduction of the bug. Previous Comments: [2002-12-06 20:38:06] [EMAIL PROTECTED] Latest snapshot did not help. Actually, i fount the better place to "breakpoint" - I did comment out the line containing "$headers=imap_search($mbox, "FROM @");" *perhaps* that is the point where a crash(?) occures. [2002-12-06 20:25:45] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-06 20:10:23] [EMAIL PROTECTED] test script could be reached at http://decmon.fond-darina.ru/mail.php and http://decmon.fond-darina.ru/mail.php?phpinfo=1 the latter one will start producing phpinfo() report (I added "if (isset($phpinfo))phpinfo();" line to the beginning of the script [2002-12-06 20:05:46] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-06 20:01:42] [EMAIL PROTECTED] Same thing happens on a machine that is described by phpinfo() like following: -- System FreeBSD v6.valuehost.ru 4.4-STABLE FreeBSD 4.4-STABLE #0: Mon Jan 14 05:22:29 MSK 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/V6 i386 Build Date Sep 19 2002 15:39:18 Configure Command './configure' '--prefix=/usr/local' '--with-config-file-path=/usr/local/etc' '--enable-memory-limit' '--with-gd=/usr/local' '--with-freetype-dir=/usr/local' '--enable-gd-native-ttf' '--with-zlib' '--with-pdflib=/usr/local' '--with-zlib-dir=/usr' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-tiff-dir=/usr/local' '--with-mysql=/usr/local/mysql' '--with-dbase' '--with-ldap=/usr/local' '--with-openssl=/usr/local' '--with-xml' '--enable-xslt' '--with-dom=/usr/local' '--with-xslt-sablot' '--with-expat-dir=/usr/local' '--with-t1lib=/usr/local' '--with-curl=/usr/local' '--with-gettext=/usr/local' '--with-iconv=/usr/local' '--with-mcrypt=/usr/local' '--enable-sysvsem' '--enable-sysvshm' '--enable-trans-sid' '--enable-sockets' '--with-imap=/usr/local' '--enable-ftp' '--enable-exif' '--enable-mbstring' '--enable-mbregexp' '--enable-bcmath' Server API Apache The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20871 -- Edit this bug report at http://bugs.php.net/?id=20871&edit=1
#20539 [Ctl->Csd]: PHP CLI Segmentation Fault
ID: 20539 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Critical +Status: Closed Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4CVS-2002-11-21 (stable) New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-12-09 06:09:00] [EMAIL PROTECTED] Date: Thu, 28 Nov 2002 19:38:38 +0100 (CET) From: Sascha Schumann <[EMAIL PROTECTED]> To: Edin Kadribasic <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Patch for bug #20539 On Thu, 28 Nov 2002, Edin Kadribasic wrote: > Forget the patch, its not working well. The problem is that with > session autostart SID constant gets defined in rinit and gets > destroyed twice. Yes, that's why I don't like to rely on internals of something which should be a black box. The constants API needs an interface for deleting entries. - Sascha [2002-11-28 03:55:05] [EMAIL PROTECTED] This crash happens when php.ini (or php-cli.ini :) contains 'session.auto_start = 1' AND 'magic_quotes_gpc = On' [2002-11-28 02:46:31] [EMAIL PROTECTED] I can't tell. Is php.ini loaded if php-cli.ini doesn't exists by default ? [2002-11-28 02:32:59] [EMAIL PROTECTED] Is that php.ini loaded by php then when this crash happens? [2002-11-28 02:28:09] [EMAIL PROTECTED] If I remove the php-cli.ini from my /usr/local/lib directory the backtrace is the same. And no - I do not have multiple php-*.ini files. One php.ini and a php-cli.ini ( since today morning ). I copied the original php.ini-dist to /usr/local/lib/php-cli.ini and everything is fine. ( I will customize the file later ) 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/20539 -- Edit this bug report at http://bugs.php.net/?id=20539&edit=1
#20932 [NEW]: Class without member variables gives "empty"/"null" objects
From: [EMAIL PROTECTED]
Operating system: Windows XP
PHP version: 4.2.3
PHP Bug Type: Class/Object related
Bug description: Class without member variables gives "empty"/"null" objects
take the following example:
doSomething();
print("empty(OBJ): ".(empty($OBJ) ? "true" : "false")."\n");
print("OBJ == null: ".(($OBJ == null) ? "true" : "false")."\n");
print("OBJ === null: ".(($OBJ === null) ? "true" : "false")."\n");
?>
it gives the following output:
OBJ: doing something
empty(OBJ): true
OBJ == null: true
OBJ === null: false
now, if you uncomment the $dummy member variable:
OBJ: doing something
empty(OBJ): false
OBJ == null: false
OBJ === null: false
Sure, one should/could use "static calls" - like
MethodsOnly::doSomething() - in this case (class without member vars), but
we discovered this when migrating a project from PHP3 to PHP4
.. and, anyway, shouldn't an existing object behave the same wether it has
member variables or not? ;)
--
Edit bug report at http://bugs.php.net/?id=20932&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20932&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20932&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20932&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20932&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20932&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20932&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20932&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20932&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20932&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20932&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20932&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20932&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20932&r=isapi
#20467 [Bgs->Opn]: Buffer overflow returning binary
ID: 20467 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Sybase (dblib) related Operating System: Linux PHP Version: 4.2.3 New Comment: Perhaps is better to reopen Previous Comments: [2002-12-10 14:04:46] [EMAIL PROTECTED] dbconvert is called passing res_length as source length. This can cause problems... Row dbconvert(NULL,coltype(offset),dbdata(sybase_ptr->link,offset), res_length,SYBCHAR,res_buf,res_length); should be replaced with dbconvert(NULL,coltype(offset),dbdata(sybase_ptr->link,offset), src_length,SYBCHAR,res_buf,res_length); freddy77 [2002-12-10 09:44:50] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-12-09 04:11:36] [EMAIL PROTECTED] You have also to decide what result you want for binary data. If you use dbconvert for this type your results will be a hexadecimal string. If you want binary data instead you should manually copy data (use just memcpy) or do a conversion to binary, not to characters. freddy77 [2002-12-07 01:29:42] [EMAIL PROTECTED] Someone familiar with the workings of the sybase extension should definately review the patch and make the necessary corrections before the next RC is out. [2002-11-18 13:25:50] [EMAIL PROTECTED] I found also another problem. If NULL is returned (length == 0) the loop "while (*p == ' ') --p;" can lead to a buffer underflow, "while (p >= res_buf && *p == ' ') --p;" fix the problem freddy77 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/20467 -- Edit this bug report at http://bugs.php.net/?id=20467&edit=1
#20871 [Opn->Fbk]: Apache restarts with no output
ID: 20871 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: IMAP related Operating System: win2K -PHP Version: 4.2.3 +PHP Version: 4.3.0-dev New Comment: Please provide a short, complete and self-contained example script which can be used to reproduce this. Previous Comments: [2002-12-11 04:22:02] [EMAIL PROTECTED] I'd be glad to know if any measures are being taken in order to fix the buggie. I hope that you at least succeeded reproduction of the bug. [2002-12-06 20:38:06] [EMAIL PROTECTED] Latest snapshot did not help. Actually, i fount the better place to "breakpoint" - I did comment out the line containing "$headers=imap_search($mbox, "FROM @");" *perhaps* that is the point where a crash(?) occures. [2002-12-06 20:25:45] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-06 20:10:23] [EMAIL PROTECTED] test script could be reached at http://decmon.fond-darina.ru/mail.php and http://decmon.fond-darina.ru/mail.php?phpinfo=1 the latter one will start producing phpinfo() report (I added "if (isset($phpinfo))phpinfo();" line to the beginning of the script [2002-12-06 20:05:46] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip 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/20871 -- Edit this bug report at http://bugs.php.net/?id=20871&edit=1
#20828 [Opn->Csd]: dba_open hang on nfs files
ID: 20828 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: DBM/DBA related Operating System: Linux 2.2.16 PHP Version: 4.3.0RC2 Assigned To: helly New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. The default is now locking on the database file. This is done by GDBM handler automatically and maybe other future handlers will do also. So now all handlers behave the same way when no further modifier is used. Previous Comments: [2002-12-09 12:09:57] [EMAIL PROTECTED] It is important to keep the .lck file - so that is no problem. Also database access needs to be locked - so generally locking is wanted and not having it was an error in older dba versions. I added modifier '-' to disable/skip/ignore locking (or whatever to call it). [2002-12-05 09:09:50] [EMAIL PROTECTED] dba_open hang when trying to open a file located on a nfs server : test script : with file "E.db" on a nfs server : Block with file "E.db" on a local filesystem : Ok In both case, E.db.lck is created (Hey! i've used "r" not "rl" ???) and by the way, not removed. Seems the new locking scheme start by itself, doesn't cleanup on exit and finally hang on nfs. -- Edit this bug report at http://bugs.php.net/?id=20828&edit=1
#20871 [Fbk->Opn]: Apache restarts with no output
ID: 20871 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: IMAP related Operating System: win2K PHP Version: 4.3.0-dev New Comment: "; $totmsg=imap_num_msg($mbox); //still works if ($totmsg>0) echo "some messages found"; $headers=imap_search($mbox, "FROM @", 0);//fails $headers=imap_headers($mbox);//fails //any of above would 'crash'. if (is_array($headers))echo "Total messages found: ".count($headers)."/$totmsg"; ?> Previous Comments: [2002-12-11 05:14:11] [EMAIL PROTECTED] Please provide a short, complete and self-contained example script which can be used to reproduce this. [2002-12-11 04:22:02] [EMAIL PROTECTED] I'd be glad to know if any measures are being taken in order to fix the buggie. I hope that you at least succeeded reproduction of the bug. [2002-12-06 20:38:06] [EMAIL PROTECTED] Latest snapshot did not help. Actually, i fount the better place to "breakpoint" - I did comment out the line containing "$headers=imap_search($mbox, "FROM @");" *perhaps* that is the point where a crash(?) occures. [2002-12-06 20:25:45] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-06 20:10:23] [EMAIL PROTECTED] test script could be reached at http://decmon.fond-darina.ru/mail.php and http://decmon.fond-darina.ru/mail.php?phpinfo=1 the latter one will start producing phpinfo() report (I added "if (isset($phpinfo))phpinfo();" line to the beginning of the script 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/20871 -- Edit this bug report at http://bugs.php.net/?id=20871&edit=1
#20933 [NEW]: isset of string offset is always false
From: [EMAIL PROTECTED]
Operating system: OS X 10.2
PHP version: 4CVS-2002-12-11 (dev)
PHP Bug Type: Zend Engine 2 problem
Bug description: isset of string offset is always false
php -r '$a="a"; var_dump(@isset($a{2}));
var_dump(@isset($a{0}));'
this should return false, true, and does with ZE1.4.
with ZE2, it returns false, false.
--
Edit bug report at http://bugs.php.net/?id=20933&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20933&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20933&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20933&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20933&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20933&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20933&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20933&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20933&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20933&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20933&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20933&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20933&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20933&r=isapi
#20932 [Opn->Bgs]: Class without member variables gives "empty"/"null" objects
ID: 20932
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: Windows XP
PHP Version: 4.2.3
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-12-11 04:47:43] [EMAIL PROTECTED]
take the following example:
doSomething();
print("empty(OBJ): ".(empty($OBJ) ? "true" : "false")."\n");
print("OBJ == null: ".(($OBJ == null) ? "true" : "false")."\n");
print("OBJ === null: ".(($OBJ === null) ? "true" : "false")."\n");
?>
it gives the following output:
OBJ: doing something
empty(OBJ): true
OBJ == null: true
OBJ === null: false
now, if you uncomment the $dummy member variable:
OBJ: doing something
empty(OBJ): false
OBJ == null: false
OBJ === null: false
Sure, one should/could use "static calls" - like
MethodsOnly::doSomething() - in this case (class without member vars),
but we discovered this when migrating a project from PHP3 to PHP4
.. and, anyway, shouldn't an existing object behave the same wether it
has member variables or not? ;)
--
Edit this bug report at http://bugs.php.net/?id=20932&edit=1
#20922 [Fbk->Opn]: socket_select() blocks for some reason
ID: 20922 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Sockets related Operating System: linux debian latest unstable PHP Version: 4.4.0-dev New Comment: hmm ok, here is the thing.. the script failed on socket_select - but it was from a previous error before i did socket select i also did a file() on an url - the server was down so i guess somehow the error just got projected to another socket without the file($url) code i cant replicate it's behaviour, so i removed it. my original report is still valid - socked_select() seemed to stop in its tracks after that invalid file($url) request. (I had debug output before and after to see why/how it hangs and i haddnt suspected file($url) since it wen't without verbosity on that part) Previous Comments: [2002-12-11 01:08:29] [EMAIL PROTECTED] Please provide a complete, self-contained and short example script which can be used to reproduce this. [2002-12-10 17:31:35] [EMAIL PROTECTED] ughm sorry for my rushed english, what i ment to say is.. the snapshot version produces the same output as rc2, just without the crash. [2002-12-10 17:12:12] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip One more try: TRY THE SNAPSHOT. Not the RC2..(snapshot, as in the given url..) [2002-12-10 11:11:26] [EMAIL PROTECTED] same result on windows rc2, just no more crash [2002-12-10 09:15:09] [EMAIL PROTECTED] Please try the snapshot, iirc, there were some fixed done which are NOT in RC2. 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/20922 -- Edit this bug report at http://bugs.php.net/?id=20922&edit=1
#20927 [Fbk->Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2
ID: 20927 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: PostgreSQL related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 New Comment: Backtrace for Apache 1.3.27 and PHP 4.3.0RC2: Program received signal SIGSEGV, Segmentation fault. 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 (gdb) where #0 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 #1 0x42073155 in malloc () from /lib/i686/libc.so.6 #2 0x402bda44 in pqResultAlloc () from /usr/lib/libpq.so.2 #3 0x402be3d5 in getRowDescriptions () from /usr/lib/libpq.so.2 #4 0x402be2f1 in parseInput () from /usr/lib/libpq.so.2 #5 0x402be970 in PQgetResult () from /usr/lib/libpq.so.2 #6 0x402bea78 in PQexec () from /usr/lib/libpq.so.2 #7 0x40251626 in zif_pg_query (ht=135421720, return_value=0x812593c, this_ptr=0x0, return_value_used=1) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/ext/pgsql/pgsql.c:931 #8 0x40201692 in execute (op_array=0x80f1e54) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1596 #9 0x40201433 in execute (op_array=0x80f3a84) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #10 0x40201433 in execute (op_array=0x80b0d40) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #11 0x40201433 in execute (op_array=0x80a36a0) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #12 0x40201433 in execute (op_array=0x80a8a24) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #13 0x401f4fdd in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend.c:864 #14 0x401d09d4 in php_execute_script (primary_file=0xb530) ---Type to continue, or q to quit--- at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/main/main.c:1549 #15 0x4020525e in apache_php_module_main (r=0x8099974, display_source_mode=0) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/sapi/apache/sapi_apache.c:55 #16 0x40205c25 in send_php (r=0x8099974, display_source_mode=0, filename=0x0) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/sapi/apache/mod_php4.c:556 #17 0x40205dba in send_parsed_php (r=0x8099974) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/sapi/apache/mod_php4.c:571 #18 0x40022174 in ap_invoke_handler (r=0x8099974) at http_config.c:518 #19 0x40038477 in hypot () at http_request.c:1308 #20 0x400384e9 in ap_process_request (r=0x8099974) at http_request.c:1324 #21 0x4002ee39 in child_main (child_num_arg=0) at http_main.c:4603 #22 0x4002eff8 in make_child (s=0x804b7bc, slot=0, now=1039610873) at http_main.c:4718 #23 0x4002f182 in startup_children (number_to_start=5) at http_main.c:4800 #24 0x4002f838 in standalone_main (argc=2, argv=0xb9b4) at http_main.c:5108 #25 0x40030100 in ap_main (argc=2, argv=0xb9b4) at http_main.c:5456 #26 0x080485b3 in ?? () #27 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 Previous Comments: [2002-12-11 00:59:23] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2002-12-10 19:42:59] [EMAIL PROTECTED] This is difficult (impossible) to reproduce with a short script. Please download and unpack http://www.roaringpenguin.com/segfault.tar.bz2 You need to have PostgreSQL and create a specific database with specific data in it. Here's the README file from the tarball: SUMMARY: PHP segfaults for PHP versions > 4.1.2 --- THE SOURCE FILES IN THIS ARCHIVE ARE PROPRIETARY COMMERCIAL SOFTWARE. PLEASE USE THEM ONLY TO DEBUG PHP PROBLEMS. System: Red Hat Linux 8.0 PostgreSQL: 7.2.2, as supplied with Red Hat Linux 8.0 Apache: 1.3.27, configured as follows: ./configure --with-layout=Apache --enable-shared=max \ --enable-rule=SHARED_CORE PHP: Tried 4.2.2, 4.2.3 and 4.3.0RC2, all configured as follows: ./configure --with-pgsql=shared \ --with-gnu-ld \ --with-apxs=/usr/local/apache/bin/apxs HOW TO REPRODUCE: - 1) Install Apache 1.3.27 and PHP 4.2.2, 4.2.3 or 4.3.0RC2 from source. Configure PostgreSQL 7.2.2 to trust local connections. That is, in /var/lib/pgsql/data/pg_hba.conf, make the local line read thus: local all trust 2)
#20934 [NEW]: htmlspecialchars returns latin1 from UTF-8
From: [EMAIL PROTECTED] Operating system: Red hat linux 8.0 PHP version: 4CVS-2002-12-11 (dev) PHP Bug Type: Strings related Bug description: htmlspecialchars returns latin1 from UTF-8 I used the script bellow for testing (calling it from MS Internet Explorer to directly see the xml output). Calling it without parameters one should see a simple xml document showing a string in latin1. Calling it with "?charset=utf8", the script correctly converts the string from latin1 to UTF-8 but after using "htmlspecialchars" it goes back to latin1, and the xml becomes invalid. (put a comment on the "htmlspecialchars" line after the character conversion and the xml will show up in UTF-8 without problem). \n"; ?> -- Edit bug report at http://bugs.php.net/?id=20934&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20934&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20934&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20934&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20934&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20934&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20934&r=support Expected behavior: http://bugs.php.net/fix.php?id=20934&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20934&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20934&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20934&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20934&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20934&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20934&r=isapi
#20922 [Opn->Fbk]: socket_select() blocks for some reason
ID: 20922 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Sockets related Operating System: linux debian latest unstable PHP Version: 4.4.0-dev New Comment: Please provide a complete, self-contained and short example script which can be used to reproduce this. complete: Begins with self-contained: Does not require anything but itself. short: 10-15 lines. Previous Comments: [2002-12-11 06:38:08] [EMAIL PROTECTED] hmm ok, here is the thing.. the script failed on socket_select - but it was from a previous error before i did socket select i also did a file() on an url - the server was down so i guess somehow the error just got projected to another socket without the file($url) code i cant replicate it's behaviour, so i removed it. my original report is still valid - socked_select() seemed to stop in its tracks after that invalid file($url) request. (I had debug output before and after to see why/how it hangs and i haddnt suspected file($url) since it wen't without verbosity on that part) [2002-12-11 01:08:29] [EMAIL PROTECTED] Please provide a complete, self-contained and short example script which can be used to reproduce this. [2002-12-10 17:31:35] [EMAIL PROTECTED] ughm sorry for my rushed english, what i ment to say is.. the snapshot version produces the same output as rc2, just without the crash. [2002-12-10 17:12:12] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip One more try: TRY THE SNAPSHOT. Not the RC2..(snapshot, as in the given url..) [2002-12-10 11:11:26] [EMAIL PROTECTED] same result on windows rc2, just no more crash 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/20922 -- Edit this bug report at http://bugs.php.net/?id=20922&edit=1
#15209 [Ctl->Ver]: Under Apache, register_shutdown_function() broke between 4.0.x to 4.1.x
ID: 15209 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Critical +Status: Verified Bug Type: Scripting Engine problem Operating System: RH Linux 7.2 PHP Version: 4.3.0-dev New Comment: Changing to 'Verified', since there is some disagreement on how this function should operate. Previous Comments: [2002-10-12 10:21:46] [EMAIL PROTECTED] Marking as critical since this worked at some point. And there was also posting by [EMAIL PROTECTED] with a possible fix on [EMAIL PROTECTED] [2002-10-04 07:44:12] [EMAIL PROTECTED] I grabbed a snapshot today (php4-200210040300). I jtate's script, and still got the erroneous (IMO) behavior. My connection to the server did not close until the shutdown function completed. Looking at the suspect section of sapi_apache.c, I do not see any changes. Not that I expected to see my patch verbatim, but I would expect something in that vicinity to change. [2002-10-02 10:33:06] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-02 09:35:00] [EMAIL PROTECTED] Is this really a dupe of 14251? Maybe they involve some of the same code, but these are really two different issues. 14251 involves the fact that the shutdown function code gets a different working directory. 15209 concerns whether the shutdown function runs before or after the HTTP connection is closed. [2002-10-01 06:04:16] [EMAIL PROTECTED] Dup of #14251 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/15209 -- Edit this bug report at http://bugs.php.net/?id=15209&edit=1
#20467 [Opn->Csd]: Buffer overflow returning binary
ID: 20467 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Sybase (dblib) related Operating System: Linux PHP Version: 4.2.3 New Comment: No. The typo was already fixed. Previous Comments: [2002-12-11 05:03:21] [EMAIL PROTECTED] Perhaps is better to reopen [2002-12-10 14:04:46] [EMAIL PROTECTED] dbconvert is called passing res_length as source length. This can cause problems... Row dbconvert(NULL,coltype(offset),dbdata(sybase_ptr->link,offset), res_length,SYBCHAR,res_buf,res_length); should be replaced with dbconvert(NULL,coltype(offset),dbdata(sybase_ptr->link,offset), src_length,SYBCHAR,res_buf,res_length); freddy77 [2002-12-10 09:44:50] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-12-09 04:11:36] [EMAIL PROTECTED] You have also to decide what result you want for binary data. If you use dbconvert for this type your results will be a hexadecimal string. If you want binary data instead you should manually copy data (use just memcpy) or do a conversion to binary, not to characters. freddy77 [2002-12-07 01:29:42] [EMAIL PROTECTED] Someone familiar with the workings of the sybase extension should definately review the patch and make the necessary corrections before the next RC is out. 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/20467 -- Edit this bug report at http://bugs.php.net/?id=20467&edit=1
#20935 [NEW]: mssql_query causes segfault
From: [EMAIL PROTECTED] Operating system: RedHat Linux 7.2 / Apache 1.3.27 PHP version: 4.2.3 PHP Bug Type: MSSQL related Bug description: mssql_query causes segfault (FreeTDS 1.5 2002/08/24, MSSQL 7 (remote)) mssql_query causes when using the following SQLSTATEMENT "SELECT a.*, b.* FROM dbo.psl AS b LEFT JOIN dbo.prc AS a ON (a.idPSL = b.idPSL) WHERE b.OrderNo LIKE '%123169%' AND a.idPSL > '0'" while simple queries like "SELECT * FROM dbo.psl" works just fine. The problem appears only if the query tries to return information. -- Edit bug report at http://bugs.php.net/?id=20935&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20935&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20935&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20935&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20935&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20935&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20935&r=support Expected behavior: http://bugs.php.net/fix.php?id=20935&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20935&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20935&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20935&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20935&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20935&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20935&r=isapi
#20109 [Ctl->Ver]: iplanet 6 core dump w/NSAPI load
ID: 20109 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Critical +Status: Verified Bug Type: iPlanet related Operating System: Solaris 9 PHP Version: 4.3.0-dev, php4-STABLE-20021116 Previous Comments: [2002-11-21 22:57:08] [EMAIL PROTECTED] Added 4.3.0-dev to version. [2002-11-16 13:09:18] [EMAIL PROTECTED] Updated to iPlanet-WebServer-Enterprise/6.0SP5 and tried php4-STABLE-200211161630. Same crash, no change. [16/Nov/2002:14:07:33] catastrophe (22765): Server crash detected (signal SIGBUS) [16/Nov/2002:14:07:33] info (22765): Crash occurred in NSAPI SAF php4_execute [16/Nov/2002:14:07:33] info (22765): Crash occurred in function php_register_variable_ex from module /usr/iplanet/servers/bin/libphp4.so [2002-11-02 14:11:14] [EMAIL PROTECTED] As much as I don't like nsapi, we can't have it not working for 4.3.0 release... since it has historically worked (sometimes). [2002-10-27 08:49:16] [EMAIL PROTECTED] Tried php4-200210262100, same crash, same backtrace. Crash: [27/Oct/2002:09:45:07] catastrophe (29972): Server crash detected (signal SIGBUS) [27/Oct/2002:09:45:07] info (29972): Crash occurred in NSAPI SAF php4_execute [27/Oct/2002:09:45:07] info (29972): Crash occurred in function php_register_variable_ex from module /usr/iplanet/servers/bin/libphp4.so [27/Oct/2002:09:45:12] failure (29957): Child process admin thread is shutting down Backtrace: #0 0xfe629ccc in php_register_variable_ex (var=0xfe6c05c0 "REQUEST_LINE", val=0xfda5f6b8, track_vars_array=0xfe6c05c0, tsrm_ls=0x1792d8) at /home/cjs/work/php4-200210262100/main/php_variables.c:176 #1 0xfe62988c in php_register_variable_safe (var=0xfe6c05c0 "REQUEST_LINE", strval=0xc722f0 "GET /phpinfo.php HTTP/1.1", str_len=25, track_vars_array=0x35a6d8, tsrm_ls=0x1792d8) at /home/cjs/work/php4-200210262100/main/php_variables.c:56 #2 0xfe6297a4 in php_register_variable (var=0xfe6c05c0 "REQUEST_LINE", strval=0xc722f0 "GET /phpinfo.php HTTP/1.1", track_vars_array=0x35a6d8, tsrm_ls=0x1792d8) at /home/cjs/work/php4-200210262100/main/php_variables.c:37 #3 0xfe678e10 in sapi_nsapi_register_server_variables ( track_vars_array=0x35a6d8, tsrm_ls=0x1792d8) at /home/cjs/work/php4-200210262100/sapi/nsapi/nsapi.c:290 #4 0xfe61e7b4 in php_hash_environment (tsrm_ls=0x1792d8) at /home/cjs/work/php4-200210262100/main/main.c:1220 #5 0xfe61d278 in php_request_startup (tsrm_ls=0x1792d8) at /home/cjs/work/php4-200210262100/main/main.c:857 #6 0xfe679590 in nsapi_module_main (request_context=0xc72d60, tsrm_ls=0x1792d8) at /home/cjs/work/php4-200210262100/sapi/nsapi/nsapi.c:460 #7 0xfe679768 in php4_execute (pb=0xc3f88, sn=0xc36a48, rq=0xc36a90) at /home/cjs/work/php4-200210262100/sapi/nsapi/nsapi.c:525 #8 0xff1d89b4 in __0FNfunc_exec_strP6KFuncStructP6GpblockP6HSessionP6HRequest () from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so #9 0xff1d9cf8 in INTobject_execute () from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so #10 0xff1dd8e8 in INTservact_service () from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so #11 0xff1dde84 in INTservact_handle_processed () from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so #12 0xff215c0c in __0fLHttpRequestUUnacceleratedRespondPCcTBPc () from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so #13 0xff2150c0 in __0fLHttpRequestNHandleRequestP6Gnetbuf () from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so #14 0xff213388 in __0fNDaemonSessionDrunv () from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so #15 0xff163b80 in ThreadMain () from /usr/iplanet/servers/bin/https/lib/libnsprwrap.so #16 0xfede76a0 in _pt_root () from /usr/iplanet/servers/bin/https/lib/libnspr4.so [2002-10-26 17:01:52] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip I've just commited a patch to the CVS that may address the problem you are seeing. 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/20109 -- Edit this bug report at http://bugs.php.net/?id=20109&edit=1
#20935 [Opn->Fbk]: mssql_query causes segfault
ID: 20935 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: MSSQL related Operating System: RedHat Linux 7.2 / Apache 1.3.27 PHP Version: 4.2.3 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Previous Comments: [2002-12-11 08:40:15] [EMAIL PROTECTED] (FreeTDS 1.5 2002/08/24, MSSQL 7 (remote)) mssql_query causes when using the following SQLSTATEMENT "SELECT a.*, b.* FROM dbo.psl AS b LEFT JOIN dbo.prc AS a ON (a.idPSL = b.idPSL) WHERE b.OrderNo LIKE '%123169%' AND a.idPSL > '0'" while simple queries like "SELECT * FROM dbo.psl" works just fine. The problem appears only if the query tries to return information. -- Edit this bug report at http://bugs.php.net/?id=20935&edit=1
#20936 [NEW]: Patch for use of public keys
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4CVS-2002-12-11 (dev) PHP Bug Type: Feature/Change Request Bug description: Patch for use of public keys I required the use of public keys (not certificates) for a current project, so I patched ext/openssl/openssl.c to support public keys. The patch can be found at http://www.jeroenderks.com/php-4.4.0-dev-openssl.c.diff I tries to read a public key if reading a certificate failed in php_openssl_evp_from_zval(). Also a check was added to check whether a private key was requested and only a public key is available. -- Edit bug report at http://bugs.php.net/?id=20936&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20936&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20936&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20936&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20936&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20936&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20936&r=support Expected behavior: http://bugs.php.net/fix.php?id=20936&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20936&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20936&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20936&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20936&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20936&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20936&r=isapi
#20831 [Com]: include() from UNC paths does not work.
ID: 20831 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: IIS related Operating System: Windows 9x/2000/XP PHP Version: 4.3.0RC2 New Comment: UNC error still exists... i have tested again with with w2k-sp3/iis5/php-CGI config within iis5: .php -> g:\phpsnapshot\php-cgi.exe %s %s if i try to include a file from a "lower" dir like ../_php/include.php i still get the error described in this bug. what can be done? i have tested actual snapshot versions (stable,cvs) from 11.dec. 15:30 i have also retestet the CLI version php.exe, it dont work! in a older snapshot this has worked. i have not testet ISAPI. Previous Comments: [2002-12-10 20:11:24] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-12-10 08:59:05] [EMAIL PROTECTED] Hm, something did go wrong here. Confirming the problem still exists with 4.3.0-dev. [2002-12-10 08:46:58] [EMAIL PROTECTED] hi, i have tested actual win-snapshots (stable,cvs,ze2), and the problem still appears! [2002-12-09 11:47:38] [EMAIL PROTECTED] i have re-tested now: php4.3dev from 17:30 (9.12.2002) and php4.4dev-CVS from 15:30, problem still appears on my installation. what can be done? user rights problem? i will test the same with another win-os, winxp/iis6... [2002-12-09 05:04:21] [EMAIL PROTECTED] You will need to wait up to 3 hours for the snapshots to be rebuilt. We only commited the fix a few minutes after your comment. 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/20831 -- Edit this bug report at http://bugs.php.net/?id=20831&edit=1
#20937 [NEW]: PHP binary randomly consumes from 300kb to 5Mb
From: [EMAIL PROTECTED] Operating system: Win2000, MacOS PHP version: 4.2.3 PHP Bug Type: *General Issues Bug description: PHP binary randomly consumes from 300kb to 5Mb You need advanced tools to test this: Windows Task Manager! The PHP binary randomly cunsumes up to 5Mb of memory for no clear reason. When the whole application is loaded this leads to binaries from 2Mb to 12Mb. The script includes PEAR::DB (DB.php), connects to the database (MySQL) and dies. Zillions of users are complainin about exhausted memory problems and we have to make them change the maximum memory size for PHP scripts in their php.ini settings. -- Edit bug report at http://bugs.php.net/?id=20937&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20937&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20937&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20937&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20937&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20937&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20937&r=support Expected behavior: http://bugs.php.net/fix.php?id=20937&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20937&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20937&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20937&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20937&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20937&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20937&r=isapi
#20938 [NEW]: Error compiling php with newer version (i.e. 2.0.6) of gdlib
From: [EMAIL PROTECTED] Operating system: Solaris 8 PHP version: 4.2.3 PHP Bug Type: GD related Bug description: Error compiling php with newer version (i.e. 2.0.6) of gdlib Newer versions of gdlib (I am using version 2.0.6) use *gd_free in structure gdIOCtx* instead of *free. So in gd_ctx.c on lines 70 and 98 one has to use ctx->gd_free = _php_image_output_ctxfree; and ctx->gd_free(ctx); instead of ctx->free = _php_image_output_ctxfree; and ctx->free(ctx); The same applies to gd.c on lines 1014, 1017 and 1209. -- Edit bug report at http://bugs.php.net/?id=20938&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20938&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20938&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20938&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20938&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20938&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20938&r=support Expected behavior: http://bugs.php.net/fix.php?id=20938&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20938&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20938&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20938&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20938&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20938&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20938&r=isapi
#20831 [Com]: include() from UNC paths does not work.
ID: 20831 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: IIS related Operating System: Windows 9x/2000/XP PHP Version: 4.3.0RC2 New Comment: i meant 9:00 snapshot not 15:30 (this is localtime in austria) i have now testet the ISAPI module of the snapshot, this do not work, following error appears: PHP has encountered an Access Violation at 0F6C3B5E is there an user right problem? iis config? Previous Comments: [2002-12-11 09:01:27] [EMAIL PROTECTED] UNC error still exists... i have tested again with with w2k-sp3/iis5/php-CGI config within iis5: .php -> g:\phpsnapshot\php-cgi.exe %s %s if i try to include a file from a "lower" dir like ../_php/include.php i still get the error described in this bug. what can be done? i have tested actual snapshot versions (stable,cvs) from 11.dec. 15:30 i have also retestet the CLI version php.exe, it dont work! in a older snapshot this has worked. i have not testet ISAPI. [2002-12-10 20:11:24] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-12-10 08:59:05] [EMAIL PROTECTED] Hm, something did go wrong here. Confirming the problem still exists with 4.3.0-dev. [2002-12-10 08:46:58] [EMAIL PROTECTED] hi, i have tested actual win-snapshots (stable,cvs,ze2), and the problem still appears! [2002-12-09 11:47:38] [EMAIL PROTECTED] i have re-tested now: php4.3dev from 17:30 (9.12.2002) and php4.4dev-CVS from 15:30, problem still appears on my installation. what can be done? user rights problem? i will test the same with another win-os, winxp/iis6... 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/20831 -- Edit this bug report at http://bugs.php.net/?id=20831&edit=1
#20938 [Opn->Csd]: Error compiling php with newer version (i.e. 2.0.6) of gdlib
ID: 20938 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: GD related Operating System: Solaris 8 PHP Version: 4.2.3 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-12-11 09:09:51] [EMAIL PROTECTED] Newer versions of gdlib (I am using version 2.0.6) use *gd_free in structure gdIOCtx* instead of *free. So in gd_ctx.c on lines 70 and 98 one has to use ctx->gd_free = _php_image_output_ctxfree; and ctx->gd_free(ctx); instead of ctx->free = _php_image_output_ctxfree; and ctx->free(ctx); The same applies to gd.c on lines 1014, 1017 and 1209. -- Edit this bug report at http://bugs.php.net/?id=20938&edit=1
#20927 [Opn->Bgs]: Crash inside libpq (PQexec) with PHP > 4.1.2
ID: 20927 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: PostgreSQL related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. The crash is the fault of PostgreSQL and not that of PHP. Previous Comments: [2002-12-11 06:50:18] [EMAIL PROTECTED] Backtrace for Apache 1.3.27 and PHP 4.3.0RC2: Program received signal SIGSEGV, Segmentation fault. 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 (gdb) where #0 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 #1 0x42073155 in malloc () from /lib/i686/libc.so.6 #2 0x402bda44 in pqResultAlloc () from /usr/lib/libpq.so.2 #3 0x402be3d5 in getRowDescriptions () from /usr/lib/libpq.so.2 #4 0x402be2f1 in parseInput () from /usr/lib/libpq.so.2 #5 0x402be970 in PQgetResult () from /usr/lib/libpq.so.2 #6 0x402bea78 in PQexec () from /usr/lib/libpq.so.2 #7 0x40251626 in zif_pg_query (ht=135421720, return_value=0x812593c, this_ptr=0x0, return_value_used=1) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/ext/pgsql/pgsql.c:931 #8 0x40201692 in execute (op_array=0x80f1e54) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1596 #9 0x40201433 in execute (op_array=0x80f3a84) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #10 0x40201433 in execute (op_array=0x80b0d40) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #11 0x40201433 in execute (op_array=0x80a36a0) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #12 0x40201433 in execute (op_array=0x80a8a24) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #13 0x401f4fdd in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend.c:864 #14 0x401d09d4 in php_execute_script (primary_file=0xb530) ---Type to continue, or q to quit--- at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/main/main.c:1549 #15 0x4020525e in apache_php_module_main (r=0x8099974, display_source_mode=0) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/sapi/apache/sapi_apache.c:55 #16 0x40205c25 in send_php (r=0x8099974, display_source_mode=0, filename=0x0) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/sapi/apache/mod_php4.c:556 #17 0x40205dba in send_parsed_php (r=0x8099974) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/sapi/apache/mod_php4.c:571 #18 0x40022174 in ap_invoke_handler (r=0x8099974) at http_config.c:518 #19 0x40038477 in hypot () at http_request.c:1308 #20 0x400384e9 in ap_process_request (r=0x8099974) at http_request.c:1324 #21 0x4002ee39 in child_main (child_num_arg=0) at http_main.c:4603 #22 0x4002eff8 in make_child (s=0x804b7bc, slot=0, now=1039610873) at http_main.c:4718 #23 0x4002f182 in startup_children (number_to_start=5) at http_main.c:4800 #24 0x4002f838 in standalone_main (argc=2, argv=0xb9b4) at http_main.c:5108 #25 0x40030100 in ap_main (argc=2, argv=0xb9b4) at http_main.c:5456 #26 0x080485b3 in ?? () #27 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 [2002-12-11 00:59:23] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2002-12-10 19:42:59] [EMAIL PROTECTED] This is difficult (impossible) to reproduce with a short script. Please download and unpack http://www.roaringpenguin.com/segfault.tar.bz2 You need to have PostgreSQL and create a specific database with specific data in it. Here's the README file from the tarball: SUMMARY: PHP segfaults for PHP versions > 4.1.2 --- THE SOURCE FILES IN THIS ARCHIVE ARE PROPRIETARY COMMERCIAL SOFTWARE. PLEASE USE THEM ONLY TO DEBUG PHP PROBLEMS. System: Red Hat Linux 8.0 PostgreSQL: 7.2.2, as supplied with Red Hat Linux 8.0 Apache: 1.3.27, configured as follows: ./configure --with-layout=Apache --enable-shared=max \ --enable-rule=SHARED_CORE PHP: Tried 4.2.2, 4.2.3 and 4.3.0RC2, all configur
#20831 [Csd]: include() from UNC paths does not work.
ID: 20831 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: IIS related Operating System: Windows 9x/2000/XP PHP Version: 4.3.0RC2 New Comment: The CLI version should work, but to be sure, remove all old copies of 'php4ts.dll'. The fix is in this module. Previous Comments: [2002-12-11 09:11:12] [EMAIL PROTECTED] i meant 9:00 snapshot not 15:30 (this is localtime in austria) i have now testet the ISAPI module of the snapshot, this do not work, following error appears: PHP has encountered an Access Violation at 0F6C3B5E is there an user right problem? iis config? [2002-12-11 09:01:27] [EMAIL PROTECTED] UNC error still exists... i have tested again with with w2k-sp3/iis5/php-CGI config within iis5: .php -> g:\phpsnapshot\php-cgi.exe %s %s if i try to include a file from a "lower" dir like ../_php/include.php i still get the error described in this bug. what can be done? i have tested actual snapshot versions (stable,cvs) from 11.dec. 15:30 i have also retestet the CLI version php.exe, it dont work! in a older snapshot this has worked. i have not testet ISAPI. [2002-12-10 20:11:24] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-12-10 08:59:05] [EMAIL PROTECTED] Hm, something did go wrong here. Confirming the problem still exists with 4.3.0-dev. [2002-12-10 08:46:58] [EMAIL PROTECTED] hi, i have tested actual win-snapshots (stable,cvs,ze2), and the problem still appears! 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/20831 -- Edit this bug report at http://bugs.php.net/?id=20831&edit=1
#20831 [Csd]: include() from UNC paths does not work.
ID: 20831 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: IIS related Operating System: Windows 9x/2000/XP PHP Version: 4.3.0RC2 New Comment: I've tried the latest snap on WinXP using cli including "../../file.txt" & "server\path\file.txt" and both works flawlessly. The few people I spoke to also didn't not encounter a problem opening/including files via relative or UNC path. Therefor, I must conclude that the problem you are seeing is due to some issue on your end, possible left over dlls from older PHP, IIS config params and so on... Previous Comments: [2002-12-11 09:25:14] [EMAIL PROTECTED] The CLI version should work, but to be sure, remove all old copies of 'php4ts.dll'. The fix is in this module. [2002-12-11 09:11:12] [EMAIL PROTECTED] i meant 9:00 snapshot not 15:30 (this is localtime in austria) i have now testet the ISAPI module of the snapshot, this do not work, following error appears: PHP has encountered an Access Violation at 0F6C3B5E is there an user right problem? iis config? [2002-12-11 09:01:27] [EMAIL PROTECTED] UNC error still exists... i have tested again with with w2k-sp3/iis5/php-CGI config within iis5: .php -> g:\phpsnapshot\php-cgi.exe %s %s if i try to include a file from a "lower" dir like ../_php/include.php i still get the error described in this bug. what can be done? i have tested actual snapshot versions (stable,cvs) from 11.dec. 15:30 i have also retestet the CLI version php.exe, it dont work! in a older snapshot this has worked. i have not testet ISAPI. [2002-12-10 20:11:24] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-12-10 08:59:05] [EMAIL PROTECTED] Hm, something did go wrong here. Confirming the problem still exists with 4.3.0-dev. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20831 -- Edit this bug report at http://bugs.php.net/?id=20831&edit=1
#20939 [NEW]: PHP stops executing script when using sax handlers
From: [EMAIL PROTECTED]
Operating system: Debian GNU/Linux 2.4.19
PHP version: 4.2.3
PHP Bug Type: XSLT related
Bug description: PHP stops executing script when using sax handlers
When using xslt_set_sax_handlers, php stops executing after xslt_process.
Below a script that should reproduce the problem (I tested it on 2 servers
to be sure):
array('start_element','end_element')));
$aryArg['xml']=implode("\n",file(dirname(__FILE__).'/test.xml'));
$aryArg['xsl']=implode("\n",file(dirname(__FILE__).'/test.xsl'));
$strHTML = xslt_process($resXSL,'arg:xml','arg:xsl',NULL,$aryArg);
xslt_free($resXSL);
echo $strHTML;
function start_element($resParser,$strName,$aryAttribs) {
echo 'Start of '.$strName;
}
function end_element($resParser,$strName) {
echo 'End of '.$strName;
}
?>
When this is executed there is no output, when I comment the line where I
use xslt_set_sax_handlers, it works fine (the html is shown). When I
enable xslt logging sablotron seems to be in an endless loop:
Sablotron Message on line none, level log: Parsing 'arg:/xsl'...
Sablotron Message on line none, level log: Parse done in 0.002 seconds
Sablotron Message on line none, level log: Parsing 'arg:/xml'...
Sablotron Message on line none, level log: Parse done in 0.000 seconds
Sablotron Message on line none, level log: Executing stylesheet
'arg:/xsl'...
These lines are printed into the logfile about let's say 30 times, the
first time the message
Sablotron Message on line none, level log: Execution done in 0.002
seconds
appears, the other let's say 29 times not.
When I comment the xslt_set_sax_handlers line the logfile only shows the 5
lines mentioned before and also the 'Execution don in seconds' line
as you would expect
My guess is that sablotron is stuck in a loop...
PHP is compiled with: --with-dom --with-sablot --with-expat -with-dom-xslt
--with-dom-exslt --enable-xslt' --with-xslt-sablot
If you want to get the xml/xsl files I used, you can get them at
http://bruno.webfx.be/xslt_test/
Thanks in advance,
Bruno
--
Edit bug report at http://bugs.php.net/?id=20939&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20939&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20939&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20939&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20939&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20939&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20939&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20939&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20939&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20939&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20939&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20939&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20939&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20939&r=isapi
#20936 [Opn]: Patch for use of public keys
ID: 20936 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4CVS-2002-12-11 (dev) New Comment: Please read the CODING_STANDARDS and README.SUBMITTING-PATCH files in the php4/ directory; mail the patch as a MIME attachment (give it a .txt extension if your mailer doesn't set the mime type correctly, as binary attachments are stripped from the list), and CC the patch to the maintainer (that's me, [EMAIL PROTECTED]). Please also describe in more detail what the patch changes and or fixes, with a couple of lines of sample code. Previous Comments: [2002-12-11 08:51:13] [EMAIL PROTECTED] I required the use of public keys (not certificates) for a current project, so I patched ext/openssl/openssl.c to support public keys. The patch can be found at http://www.jeroenderks.com/php-4.4.0-dev-openssl.c.diff I tries to read a public key if reading a certificate failed in php_openssl_evp_from_zval(). Also a check was added to check whether a private key was requested and only a public key is available. -- Edit this bug report at http://bugs.php.net/?id=20936&edit=1
#20936 [Opn]: Patch for use of public keys
ID: 20936 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4CVS-2002-12-11 (dev) New Comment: the patch should go to [EMAIL PROTECTED], CC: [EMAIL PROTECTED] I was not able to download the patch from the URL you posted. Previous Comments: [2002-12-11 09:36:53] [EMAIL PROTECTED] Please read the CODING_STANDARDS and README.SUBMITTING-PATCH files in the php4/ directory; mail the patch as a MIME attachment (give it a .txt extension if your mailer doesn't set the mime type correctly, as binary attachments are stripped from the list), and CC the patch to the maintainer (that's me, [EMAIL PROTECTED]). Please also describe in more detail what the patch changes and or fixes, with a couple of lines of sample code. [2002-12-11 08:51:13] [EMAIL PROTECTED] I required the use of public keys (not certificates) for a current project, so I patched ext/openssl/openssl.c to support public keys. The patch can be found at http://www.jeroenderks.com/php-4.4.0-dev-openssl.c.diff I tries to read a public key if reading a certificate failed in php_openssl_evp_from_zval(). Also a check was added to check whether a private key was requested and only a public key is available. -- Edit this bug report at http://bugs.php.net/?id=20936&edit=1
#20927 [Bgs->Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2
ID: 20927 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: PostgreSQL related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 New Comment: I disagree. The bug *IS* in PHP, not libpq. The reason I assert this is as follows: - I tried Apache 1.3.27, 2.0.40 and 2.0.43 with libraries from PostgreSQL 7.2.2, 7.2.3 and 7.3, and PHP 4.2.2, 4.2.3 and PHP 4.3.0RC2. ALL combinations crashed reliably. With PHP 4.1.2, I am *unable* to get a crash. Something in PHP is corrupting memory, and later on, malloc() is failing. I use the same libpq library with Perl and Tcl, and have never yet had a segfault. For more info, here's a stack trace for Red Hat 8.0 with Red Hat's version of Apache (2.0.40) and Red Hat's PHP (4.2.2). Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 8192 (LWP 3305)] 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 (gdb) bt #0 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 #1 0x42073155 in malloc () from /lib/i686/libc.so.6 #2 0x4051881b in completed.1 () from /etc/httpd/modules/libphp4.so #3 0x405c5cb1 in completed.1 () from /etc/httpd/modules/libphp4.so #4 0x405c5fe1 in completed.1 () from /etc/httpd/modules/libphp4.so #5 0x405c615e in completed.1 () from /etc/httpd/modules/libphp4.so #6 0x40522efc in completed.1 () from /etc/httpd/modules/libphp4.so #7 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #8 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #9 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #10 0x4052f6b6 in completed.1 () from /etc/httpd/modules/libphp4.so #11 0x4053df7a in completed.1 () from /etc/httpd/modules/libphp4.so #12 0x4053a7bd in completed.1 () from /etc/httpd/modules/libphp4.so #13 0x0807169c in ap_pass_brigade () #14 0x08078e27 in default_handler () #15 0x08065bf5 in ap_run_handler () #16 0x0806620d in ap_invoke_handler () #17 0x080629c6 in ap_process_request () #18 0x0805e0ac in ap_process_http_connection () #19 0x0806f0d5 in ap_run_process_connection () #20 0x08064238 in child_main () #21 0x0806445a in make_child () #22 0x080644b6 in startup_children () #23 0x08064cdf in ap_mpm_run () #24 0x0806ac5f in main () #25 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 Previous Comments: [2002-12-11 09:17:15] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. The crash is the fault of PostgreSQL and not that of PHP. [2002-12-11 06:50:18] [EMAIL PROTECTED] Backtrace for Apache 1.3.27 and PHP 4.3.0RC2: Program received signal SIGSEGV, Segmentation fault. 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 (gdb) where #0 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 #1 0x42073155 in malloc () from /lib/i686/libc.so.6 #2 0x402bda44 in pqResultAlloc () from /usr/lib/libpq.so.2 #3 0x402be3d5 in getRowDescriptions () from /usr/lib/libpq.so.2 #4 0x402be2f1 in parseInput () from /usr/lib/libpq.so.2 #5 0x402be970 in PQgetResult () from /usr/lib/libpq.so.2 #6 0x402bea78 in PQexec () from /usr/lib/libpq.so.2 #7 0x40251626 in zif_pg_query (ht=135421720, return_value=0x812593c, this_ptr=0x0, return_value_used=1) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/ext/pgsql/pgsql.c:931 #8 0x40201692 in execute (op_array=0x80f1e54) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1596 #9 0x40201433 in execute (op_array=0x80f3a84) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #10 0x40201433 in execute (op_array=0x80b0d40) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #11 0x40201433 in execute (op_array=0x80a36a0) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #12 0x40201433 in execute (op_array=0x80a8a24) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #13 0x401f4fdd in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend.c:864 #14 0x401d09d4 in php_execute_script (primary_file=0xb530) ---Type to continue, or q to quit--- at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/main/main.c:1549 #15 0x4020525e in apache_php_module_main (r=0x8099974, display_source_mode=0) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/sapi/apache/sapi_apache.c:55 #16 0x40205c25 in send_php (r=0x8099974, display_source_mode=0, filename=0x0) at /home/dfs/canit-3
#20939 [Opn->Fbk]: PHP stops executing script when using sax handlers
ID: 20939
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: XSLT related
Operating System: Debian GNU/Linux 2.4.19
PHP Version: 4.2.3
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
I cannot replicate this problem with PHP 4.3.0 & Sablotron 0.96. If you
try the snapshot and still experience problems please include the
Sablotron version you are using in your report.
Previous Comments:
[2002-12-11 09:31:50] [EMAIL PROTECTED]
When using xslt_set_sax_handlers, php stops executing after
xslt_process. Below a script that should reproduce the problem (I
tested it on 2 servers to be sure):
array('start_element','end_element')));
$aryArg['xml']=implode("\n",file(dirname(__FILE__).'/test.xml'));
$aryArg['xsl']=implode("\n",file(dirname(__FILE__).'/test.xsl'));
$strHTML = xslt_process($resXSL,'arg:xml','arg:xsl',NULL,$aryArg);
xslt_free($resXSL);
echo $strHTML;
function start_element($resParser,$strName,$aryAttribs) {
echo 'Start of '.$strName;
}
function end_element($resParser,$strName) {
echo 'End of '.$strName;
}
?>
When this is executed there is no output, when I comment the line where
I use xslt_set_sax_handlers, it works fine (the html is shown). When I
enable xslt logging sablotron seems to be in an endless loop:
Sablotron Message on line none, level log: Parsing 'arg:/xsl'...
Sablotron Message on line none, level log: Parse done in 0.002 seconds
Sablotron Message on line none, level log: Parsing 'arg:/xml'...
Sablotron Message on line none, level log: Parse done in 0.000 seconds
Sablotron Message on line none, level log: Executing stylesheet
'arg:/xsl'...
These lines are printed into the logfile about let's say 30 times, the
first time the message
Sablotron Message on line none, level log: Execution done in 0.002
seconds
appears, the other let's say 29 times not.
When I comment the xslt_set_sax_handlers line the logfile only shows
the 5 lines mentioned before and also the 'Execution don in
seconds' line as you would expect
My guess is that sablotron is stuck in a loop...
PHP is compiled with: --with-dom --with-sablot --with-expat
-with-dom-xslt --with-dom-exslt --enable-xslt' --with-xslt-sablot
If you want to get the xml/xsl files I used, you can get them at
http://bruno.webfx.be/xslt_test/
Thanks in advance,
Bruno
--
Edit this bug report at http://bugs.php.net/?id=20939&edit=1
#20926 [Opn]: libmcrypt error in configure
ID: 20926 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: mcrypt related Operating System: NetBSD-1.5.2 PHP Version: 4.3.0RC2 New Comment: Which version of mcrypt do you use, and how did you configure mcrypt and PHP. I've no problems with libmcrypt 2.5.2 here. Please also show the relevant pieces of config.log in this bugreport. Derick Previous Comments: [2002-12-10 17:03:52] [EMAIL PROTECTED] When attempting to build php with the most recent version of libmcrypt (available at http://mcrypt.hellug.gr/), configure produces the following error: checking for mcrypt support... yes checking for mcrypt_module_open in -lmcrypt... no checking for init_mcrypt in -lmcrypt... no configure: error: Sorry, I was not able to diagnose which libmcrypt version you have installed. In config.log, the errors are related to undefined references to `lt_dlerror'. -- Edit this bug report at http://bugs.php.net/?id=20926&edit=1
#20927 [Opn->Bgs]: Crash inside libpq (PQexec) with PHP > 4.1.2
ID: 20927 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: PostgreSQL related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 New Comment: It crashs with PHP 4.2.2 because it runs in Apache 2. The PSQL lib ist most probably not thread safe. Previous Comments: [2002-12-11 09:55:43] [EMAIL PROTECTED] I disagree. The bug *IS* in PHP, not libpq. The reason I assert this is as follows: - I tried Apache 1.3.27, 2.0.40 and 2.0.43 with libraries from PostgreSQL 7.2.2, 7.2.3 and 7.3, and PHP 4.2.2, 4.2.3 and PHP 4.3.0RC2. ALL combinations crashed reliably. With PHP 4.1.2, I am *unable* to get a crash. Something in PHP is corrupting memory, and later on, malloc() is failing. I use the same libpq library with Perl and Tcl, and have never yet had a segfault. For more info, here's a stack trace for Red Hat 8.0 with Red Hat's version of Apache (2.0.40) and Red Hat's PHP (4.2.2). Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 8192 (LWP 3305)] 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 (gdb) bt #0 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 #1 0x42073155 in malloc () from /lib/i686/libc.so.6 #2 0x4051881b in completed.1 () from /etc/httpd/modules/libphp4.so #3 0x405c5cb1 in completed.1 () from /etc/httpd/modules/libphp4.so #4 0x405c5fe1 in completed.1 () from /etc/httpd/modules/libphp4.so #5 0x405c615e in completed.1 () from /etc/httpd/modules/libphp4.so #6 0x40522efc in completed.1 () from /etc/httpd/modules/libphp4.so #7 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #8 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #9 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #10 0x4052f6b6 in completed.1 () from /etc/httpd/modules/libphp4.so #11 0x4053df7a in completed.1 () from /etc/httpd/modules/libphp4.so #12 0x4053a7bd in completed.1 () from /etc/httpd/modules/libphp4.so #13 0x0807169c in ap_pass_brigade () #14 0x08078e27 in default_handler () #15 0x08065bf5 in ap_run_handler () #16 0x0806620d in ap_invoke_handler () #17 0x080629c6 in ap_process_request () #18 0x0805e0ac in ap_process_http_connection () #19 0x0806f0d5 in ap_run_process_connection () #20 0x08064238 in child_main () #21 0x0806445a in make_child () #22 0x080644b6 in startup_children () #23 0x08064cdf in ap_mpm_run () #24 0x0806ac5f in main () #25 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 [2002-12-11 09:17:15] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. The crash is the fault of PostgreSQL and not that of PHP. [2002-12-11 06:50:18] [EMAIL PROTECTED] Backtrace for Apache 1.3.27 and PHP 4.3.0RC2: Program received signal SIGSEGV, Segmentation fault. 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 (gdb) where #0 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 #1 0x42073155 in malloc () from /lib/i686/libc.so.6 #2 0x402bda44 in pqResultAlloc () from /usr/lib/libpq.so.2 #3 0x402be3d5 in getRowDescriptions () from /usr/lib/libpq.so.2 #4 0x402be2f1 in parseInput () from /usr/lib/libpq.so.2 #5 0x402be970 in PQgetResult () from /usr/lib/libpq.so.2 #6 0x402bea78 in PQexec () from /usr/lib/libpq.so.2 #7 0x40251626 in zif_pg_query (ht=135421720, return_value=0x812593c, this_ptr=0x0, return_value_used=1) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/ext/pgsql/pgsql.c:931 #8 0x40201692 in execute (op_array=0x80f1e54) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1596 #9 0x40201433 in execute (op_array=0x80f3a84) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #10 0x40201433 in execute (op_array=0x80b0d40) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #11 0x40201433 in execute (op_array=0x80a36a0) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #12 0x40201433 in execute (op_array=0x80a8a24) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #13 0x401f4fdd in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend.c:864 #14 0x401d09d4 in php_execute_script (primary_file=0xb530) ---Type to continue, or q to quit--- at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/main/main.c:1549 #15 0x4020525e in apache_php_module_main (r
#20927 [Bgs->Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2
ID: 20927 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: PostgreSQL related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 New Comment: Then how do you explain the crash in Apache 1.3.27? It is a PHP bug for sure, because changing PHP versions is the only thing which makes it go away. Previous Comments: [2002-12-11 10:32:10] [EMAIL PROTECTED] It crashs with PHP 4.2.2 because it runs in Apache 2. The PSQL lib ist most probably not thread safe. [2002-12-11 09:55:43] [EMAIL PROTECTED] I disagree. The bug *IS* in PHP, not libpq. The reason I assert this is as follows: - I tried Apache 1.3.27, 2.0.40 and 2.0.43 with libraries from PostgreSQL 7.2.2, 7.2.3 and 7.3, and PHP 4.2.2, 4.2.3 and PHP 4.3.0RC2. ALL combinations crashed reliably. With PHP 4.1.2, I am *unable* to get a crash. Something in PHP is corrupting memory, and later on, malloc() is failing. I use the same libpq library with Perl and Tcl, and have never yet had a segfault. For more info, here's a stack trace for Red Hat 8.0 with Red Hat's version of Apache (2.0.40) and Red Hat's PHP (4.2.2). Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 8192 (LWP 3305)] 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 (gdb) bt #0 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 #1 0x42073155 in malloc () from /lib/i686/libc.so.6 #2 0x4051881b in completed.1 () from /etc/httpd/modules/libphp4.so #3 0x405c5cb1 in completed.1 () from /etc/httpd/modules/libphp4.so #4 0x405c5fe1 in completed.1 () from /etc/httpd/modules/libphp4.so #5 0x405c615e in completed.1 () from /etc/httpd/modules/libphp4.so #6 0x40522efc in completed.1 () from /etc/httpd/modules/libphp4.so #7 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #8 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #9 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #10 0x4052f6b6 in completed.1 () from /etc/httpd/modules/libphp4.so #11 0x4053df7a in completed.1 () from /etc/httpd/modules/libphp4.so #12 0x4053a7bd in completed.1 () from /etc/httpd/modules/libphp4.so #13 0x0807169c in ap_pass_brigade () #14 0x08078e27 in default_handler () #15 0x08065bf5 in ap_run_handler () #16 0x0806620d in ap_invoke_handler () #17 0x080629c6 in ap_process_request () #18 0x0805e0ac in ap_process_http_connection () #19 0x0806f0d5 in ap_run_process_connection () #20 0x08064238 in child_main () #21 0x0806445a in make_child () #22 0x080644b6 in startup_children () #23 0x08064cdf in ap_mpm_run () #24 0x0806ac5f in main () #25 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 [2002-12-11 09:17:15] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. The crash is the fault of PostgreSQL and not that of PHP. [2002-12-11 06:50:18] [EMAIL PROTECTED] Backtrace for Apache 1.3.27 and PHP 4.3.0RC2: Program received signal SIGSEGV, Segmentation fault. 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 (gdb) where #0 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 #1 0x42073155 in malloc () from /lib/i686/libc.so.6 #2 0x402bda44 in pqResultAlloc () from /usr/lib/libpq.so.2 #3 0x402be3d5 in getRowDescriptions () from /usr/lib/libpq.so.2 #4 0x402be2f1 in parseInput () from /usr/lib/libpq.so.2 #5 0x402be970 in PQgetResult () from /usr/lib/libpq.so.2 #6 0x402bea78 in PQexec () from /usr/lib/libpq.so.2 #7 0x40251626 in zif_pg_query (ht=135421720, return_value=0x812593c, this_ptr=0x0, return_value_used=1) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/ext/pgsql/pgsql.c:931 #8 0x40201692 in execute (op_array=0x80f1e54) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1596 #9 0x40201433 in execute (op_array=0x80f3a84) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #10 0x40201433 in execute (op_array=0x80b0d40) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #11 0x40201433 in execute (op_array=0x80a36a0) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #12 0x40201433 in execute (op_array=0x80a8a24) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #13 0x401f4fdd in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/dfs/can
#20927 [Opn->Fbk]: Crash inside libpq (PQexec) with PHP > 4.1.2
ID: 20927 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: PostgreSQL related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 New Comment: Uhmm I should read better... What versions of libpq do you use with 4.1.2 and 4.2.x? Previous Comments: [2002-12-11 10:34:38] [EMAIL PROTECTED] Then how do you explain the crash in Apache 1.3.27? It is a PHP bug for sure, because changing PHP versions is the only thing which makes it go away. [2002-12-11 10:32:10] [EMAIL PROTECTED] It crashs with PHP 4.2.2 because it runs in Apache 2. The PSQL lib ist most probably not thread safe. [2002-12-11 09:55:43] [EMAIL PROTECTED] I disagree. The bug *IS* in PHP, not libpq. The reason I assert this is as follows: - I tried Apache 1.3.27, 2.0.40 and 2.0.43 with libraries from PostgreSQL 7.2.2, 7.2.3 and 7.3, and PHP 4.2.2, 4.2.3 and PHP 4.3.0RC2. ALL combinations crashed reliably. With PHP 4.1.2, I am *unable* to get a crash. Something in PHP is corrupting memory, and later on, malloc() is failing. I use the same libpq library with Perl and Tcl, and have never yet had a segfault. For more info, here's a stack trace for Red Hat 8.0 with Red Hat's version of Apache (2.0.40) and Red Hat's PHP (4.2.2). Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 8192 (LWP 3305)] 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 (gdb) bt #0 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 #1 0x42073155 in malloc () from /lib/i686/libc.so.6 #2 0x4051881b in completed.1 () from /etc/httpd/modules/libphp4.so #3 0x405c5cb1 in completed.1 () from /etc/httpd/modules/libphp4.so #4 0x405c5fe1 in completed.1 () from /etc/httpd/modules/libphp4.so #5 0x405c615e in completed.1 () from /etc/httpd/modules/libphp4.so #6 0x40522efc in completed.1 () from /etc/httpd/modules/libphp4.so #7 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #8 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #9 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #10 0x4052f6b6 in completed.1 () from /etc/httpd/modules/libphp4.so #11 0x4053df7a in completed.1 () from /etc/httpd/modules/libphp4.so #12 0x4053a7bd in completed.1 () from /etc/httpd/modules/libphp4.so #13 0x0807169c in ap_pass_brigade () #14 0x08078e27 in default_handler () #15 0x08065bf5 in ap_run_handler () #16 0x0806620d in ap_invoke_handler () #17 0x080629c6 in ap_process_request () #18 0x0805e0ac in ap_process_http_connection () #19 0x0806f0d5 in ap_run_process_connection () #20 0x08064238 in child_main () #21 0x0806445a in make_child () #22 0x080644b6 in startup_children () #23 0x08064cdf in ap_mpm_run () #24 0x0806ac5f in main () #25 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 [2002-12-11 09:17:15] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. The crash is the fault of PostgreSQL and not that of PHP. [2002-12-11 06:50:18] [EMAIL PROTECTED] Backtrace for Apache 1.3.27 and PHP 4.3.0RC2: Program received signal SIGSEGV, Segmentation fault. 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 (gdb) where #0 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 #1 0x42073155 in malloc () from /lib/i686/libc.so.6 #2 0x402bda44 in pqResultAlloc () from /usr/lib/libpq.so.2 #3 0x402be3d5 in getRowDescriptions () from /usr/lib/libpq.so.2 #4 0x402be2f1 in parseInput () from /usr/lib/libpq.so.2 #5 0x402be970 in PQgetResult () from /usr/lib/libpq.so.2 #6 0x402bea78 in PQexec () from /usr/lib/libpq.so.2 #7 0x40251626 in zif_pg_query (ht=135421720, return_value=0x812593c, this_ptr=0x0, return_value_used=1) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/ext/pgsql/pgsql.c:931 #8 0x40201692 in execute (op_array=0x80f1e54) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1596 #9 0x40201433 in execute (op_array=0x80f3a84) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #10 0x40201433 in execute (op_array=0x80b0d40) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #11 0x40201433 in execute (op_array=0x80a36a0) at /home/dfs/canit-3rdparty-builds/php-4.3.0RC2/Zend/zend_execute.c:1640 #12 0x402014
#20927 [Fbk->Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2
ID: 20927 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: PostgreSQL related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 New Comment: Hi, I've tried the following versions of libpq: 7.2.2 7.2.3 7.3.0 They all exhibit the same behaviour. The default version that comes with RH8.0 is 7.2.2. Thanks, David. Previous Comments: [2002-12-11 10:35:04] [EMAIL PROTECTED] Uhmm I should read better... What versions of libpq do you use with 4.1.2 and 4.2.x? [2002-12-11 10:34:38] [EMAIL PROTECTED] Then how do you explain the crash in Apache 1.3.27? It is a PHP bug for sure, because changing PHP versions is the only thing which makes it go away. [2002-12-11 10:32:10] [EMAIL PROTECTED] It crashs with PHP 4.2.2 because it runs in Apache 2. The PSQL lib ist most probably not thread safe. [2002-12-11 09:55:43] [EMAIL PROTECTED] I disagree. The bug *IS* in PHP, not libpq. The reason I assert this is as follows: - I tried Apache 1.3.27, 2.0.40 and 2.0.43 with libraries from PostgreSQL 7.2.2, 7.2.3 and 7.3, and PHP 4.2.2, 4.2.3 and PHP 4.3.0RC2. ALL combinations crashed reliably. With PHP 4.1.2, I am *unable* to get a crash. Something in PHP is corrupting memory, and later on, malloc() is failing. I use the same libpq library with Perl and Tcl, and have never yet had a segfault. For more info, here's a stack trace for Red Hat 8.0 with Red Hat's version of Apache (2.0.40) and Red Hat's PHP (4.2.2). Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 8192 (LWP 3305)] 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 (gdb) bt #0 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 #1 0x42073155 in malloc () from /lib/i686/libc.so.6 #2 0x4051881b in completed.1 () from /etc/httpd/modules/libphp4.so #3 0x405c5cb1 in completed.1 () from /etc/httpd/modules/libphp4.so #4 0x405c5fe1 in completed.1 () from /etc/httpd/modules/libphp4.so #5 0x405c615e in completed.1 () from /etc/httpd/modules/libphp4.so #6 0x40522efc in completed.1 () from /etc/httpd/modules/libphp4.so #7 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #8 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #9 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #10 0x4052f6b6 in completed.1 () from /etc/httpd/modules/libphp4.so #11 0x4053df7a in completed.1 () from /etc/httpd/modules/libphp4.so #12 0x4053a7bd in completed.1 () from /etc/httpd/modules/libphp4.so #13 0x0807169c in ap_pass_brigade () #14 0x08078e27 in default_handler () #15 0x08065bf5 in ap_run_handler () #16 0x0806620d in ap_invoke_handler () #17 0x080629c6 in ap_process_request () #18 0x0805e0ac in ap_process_http_connection () #19 0x0806f0d5 in ap_run_process_connection () #20 0x08064238 in child_main () #21 0x0806445a in make_child () #22 0x080644b6 in startup_children () #23 0x08064cdf in ap_mpm_run () #24 0x0806ac5f in main () #25 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 [2002-12-11 09:17:15] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. The crash is the fault of PostgreSQL and not that of 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/20927 -- Edit this bug report at http://bugs.php.net/?id=20927&edit=1
#20441 [Com]: PHP_AUTH_USER isn't set
ID: 20441
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Apache related
Operating System: Redhat Linux 7.1 kernel 2.4.2-2
PHP Version: 4.3.0-pre2
New Comment:
I agree with the previous poster that this is a serious bug. When we
upgraded to 4.3.0RC2 our development application broke.
Previous Comments:
[2002-11-22 02:40:55] [EMAIL PROTECTED]
This is not bogus!! This is a genuine bug. PHP_AUTH_USER was set in
4.2.3 why has the functionality been changed without warning? This will
break so many peoples scripts it is not true. This *HAS TO BE FIXED* os
that it works as it did before. Please stop trying to pretend that this
is not a bug. It is, and a serious one at that.
[2002-11-15 09:10:09] [EMAIL PROTECTED]
It was fixed to be like it should be since PHP 3.
[2002-11-15 03:52:04] [EMAIL PROTECTED]
So I should use $_SERVER["REMOTE_USER"] if I use .htaccess and
$_SERVER["PHP_AUTH_USER"] when I header the authentication?
Why is this behaviour changed without notice?
[2002-11-15 03:10:35] [EMAIL PROTECTED]
You need to decide if you are using an external auth mechanism or http
auth from php. You can't do both.
[2002-11-15 02:58:24] [EMAIL PROTECTED]
I've upgraded PHP 4.2.3 to the beta 4.3.0-pre2 and I've set register
globals on in php.ini.
My Apache version is 1.3.24.
PHP configure:
./configure --with-apxs=/usr/local/apache/bin/apxs
--with-mysql=/usr/local/mysql --enable-ftp --with-openssl
The script is using this .htaccess-file
AuthType Basic
AuthName 'Urenregistratie'
AuthUserFile /htpasswd/urenreg
require valid-user
I am sure that Apache is setting the PHP_AUTH_USER because the
following script gives the correct output:
// begin dirty hack
$headers = apache_request_headers();
foreach ($headers as $header => $value) {
if ($header == "Authorization")
{
$value = str_replace(" ", "", $value);
$value = str_replace("Basic", "", $value);
$userArray = explode(":", base64_decode($value));
$PHP_AUTH_USER = $userArray[0];
}
}
echo $PHP_AUTH_USER;
// end dirty hack
If I echo $PHP_AUTH_USER or $_SERVER["PHP_AUTH_USER"] above this script
I am getting a empty result.
Note: the script was functioning 100% properly with php 4.2.3
--
Edit this bug report at http://bugs.php.net/?id=20441&edit=1
#20940 [NEW]: After upgrading from PHP 4.2-dev to 4.2.3, garbage collection no longer occurs
From: [EMAIL PROTECTED] Operating system: Solaris 8 PHP version: 4.2.3 PHP Bug Type: Session related Bug description: After upgrading from PHP 4.2-dev to 4.2.3, garbage collection no longer occurs I am using the same PHP pages that were used in PHP 4.2-dev and the same php.ini file. The session files in the /tmp/session directory are not being gc'd after the gc_maxlifetime. GC is running. This was evidenced by the skyrocketing LA on the machine when I increased gc_probability to 50. Please contact me if more information is necesary, or you can suggest trouble shooting tests. -- Edit bug report at http://bugs.php.net/?id=20940&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20940&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20940&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20940&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20940&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20940&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20940&r=support Expected behavior: http://bugs.php.net/fix.php?id=20940&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20940&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20940&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20940&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20940&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20940&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20940&r=isapi
#20928 [Csd]: Static compile of PHP module with IBM DB2 doesn't work right with apache
ID: 20928 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: ODBC related Operating System: RH 7.2 PHP Version: 4.3.0RC2 New Comment: Fixed in which snapshot release? Just tried 4.3.x-dev and it's still broken: ===> src/modules/php4 gcc -c -I../../os/unix -I../../include -O2 -march=i386 -mcpu=i686 -DLINUX=22 - I/usr/include/db1 -DMOD_SSL=208110 -DEAPI `../../apaci` -fpic -DSHARED_MODULE -D LINUX=22 -I/usr/include/db1 -DMOD_SSL=208110 -I/usr/src/redhat/BUILD/php4-STABL E-200212111430/main -I/usr/src/redhat/BUILD/php4-STABLE-200212111430/Zend -I/usr /src/redhat/BUILD/php4-STABLE-200212111430/TSRM -I/usr/src/redhat/BUILD/php4-STA BLE-200212111430 -I/usr/src/redhat/BUILD/php4-STABLE-200212111430/sapi/apache -I /usr/src/redhat/BUILD/php4-STABLE-200212111430/main -I/usr/src/redhat/BUILD/php4 -STABLE-200212111430/Zend -I/usr/src/redhat/BUILD/php4-STABLE-200212111430/TSRM mod_php4.c && mv mod_php4.o mod_php4.so-o rm -f libphp4.so gcc -shared -o libphp4.so mod_php4.so-o libmodphp4.a -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr/local/Informix/lib -Wl,-rpath,/usr/local/Informix/lib/esql -Wl,- rpath,/usr/src/redhat/BUILD/php4-STABLE-200212111430/ext/informix -rdynamic -L/ usr/local/lib -L/usr/local/Informix/lib -L/usr/local/Informix/lib/esql -L/usr/sr c/redhat/BUILD/php4-STABLE-200212111430/ext/informix -Lmodules/php4 -L../modules /php4 -L../../modules/php4 -lmodphp4 -L/home/db2inst1/lib -rdynamic -L/usr/lo cal/lib -L/usr/local/Informix/lib -L/usr/local/Informix/lib/esql -L/usr/src/redh at/BUILD/php4-STABLE-200212111430/ext/informix -ldb2 -lcrypto -lssl -lc-client -lifsql -lifasf -lifgen -lifos -lifgls -ldl -lcrypt -lphpifx -lifglx -lpdf -lz -lldap -llber -lcrypt -lpam -lfdftk -lz -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -lm -lcrypt -ldb1 -ldb -lexpat -ldl -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr /local/Informix/lib -Wl,-rpath,/usr/local/Informix/lib/esql -Wl,-rpath,/usr/src/ redhat/BUILD/php4-STABLE-200212111430/ext/informix -rdynamic -L/usr/local/lib - L/usr/local/Informix/lib -L/usr/local/Informix/lib/esql -L/usr/src/redhat/BUILD/ php4-STABLE-200212111430/ext/informix -Lmodules/php4 -L../modules/php4 -L../../m odules/php4 -lmodphp4 -L/home/db2inst1/lib -rdynamic -L/usr/local/lib -L/usr/ local/Informix/lib -L/usr/local/Informix/lib/esql -L/usr/src/redhat/BUILD/php4-S TABLE-200212111430/ext/informix -ldb2 -lcrypto -lssl -lc-client -lifsql -lifas f -lifgen -lifos -lifgls -ldl -lcrypt -lphpifx -lifglx -lpdf -lz -lldap -llber - lcrypt -lpam -lfdftk -lz -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -lm -lcrypt -ldb1 -ldb /usr/bin/ld: cannot find -ldb2 collect2: ld returned 1 exit status make[4]: *** [libphp4.so] Error 1 make[3]: *** [all] Error 1 make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/apache_1.3.26/src' make[1]: *** [build-std] Error 2 make[1]: Leaving directory `/usr/src/redhat/BUILD/apache_1.3.26' make: *** [build] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.86132 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.86132 (%build) Previous Comments: [2002-12-11 02:42:30] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-12-11 01:22:06] [EMAIL PROTECTED] It got much further this time, but results are the same. Here is the paste of the last command and error: <=== src/modules/throttle ===> src/modules/php4 gcc -c -I../../os/unix -I../../include -O2 -march=i386 -mcpu=i686 -DLINUX=22 - I/usr/include/db1 -DMOD_SSL=208110 -DEAPI `../../apaci` -fpic -DSHARED_MODULE -D LINUX=22 -I/usr/include/db1 -DMOD_SSL=208110 -I/usr/src/redhat/BUILD/php4-20021 2110630/main -I/usr/src/redhat/BUILD/php4-200212110630/Zend -I/usr/src/redhat/BU ILD/php4-200212110630/TSRM -I/usr/src/redhat/BUILD/php4-200212110630 -I/usr/src/ redhat/BUILD/php4-200212110630/sapi/apache -I/usr/src/redhat/BUILD/php4-20021211 0630/main -I/usr/src/redhat/BUILD/php4-200212110630/Zend -I/usr/src/redhat/BUILD /php4-200212110630/TSRM mod_php4.c && mv mod_php4.o mod_php4.so-o rm -f libphp4.so gcc -shared -o libphp4.so mod_php4.so-o libmodphp4.a -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr/local/Informix/lib -Wl,-rpath,/usr/local/Informix/lib/esql -Wl,- rpath,/us
#20941 [NEW]: correct version
From: [EMAIL PROTECTED] Operating system: windows 2000 adv server PHP version: 4.2.3 PHP Bug Type: Apache2 related Bug description: correct version C:\Apache2\bin>Apache.exe -w -n "Apache2" -k start Apache.exe: module "c:\php4build\snap\sapi\apache2filter\sapi_apache2.c" is not compatible with this version of Apache (found 20020628, need 20020903). Please contact the vendor for the correct version. -- Edit bug report at http://bugs.php.net/?id=20941&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20941&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20941&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20941&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20941&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20941&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20941&r=support Expected behavior: http://bugs.php.net/fix.php?id=20941&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20941&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20941&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20941&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20941&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20941&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20941&r=isapi
#20941 [Opn->Bgs]: correct version
ID: 20941 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: windows 2000 adv server PHP Version: 4.2.3 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Previous Comments: [2002-12-11 10:52:06] [EMAIL PROTECTED] C:\Apache2\bin>Apache.exe -w -n "Apache2" -k start Apache.exe: module "c:\php4build\snap\sapi\apache2filter\sapi_apache2.c" is not compatible with this version of Apache (found 20020628, need 20020903). Please contact the vendor for the correct version. -- Edit this bug report at http://bugs.php.net/?id=20941&edit=1
#20926 [Opn]: libmcrypt error in configure
ID: 20926 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: mcrypt related Operating System: NetBSD-1.5.2 PHP Version: 4.3.0RC2 New Comment: The configure option I used to include libmcrypt is: --with-mcrypt=/usr/local I am using libmcrypt-2.5.3. The config.log entry is as follows: configure:47349: checking for mcrypt support configure:47388: result: yes configure:47412: checking for mcrypt_module_open in -lmcrypt configure:47445: gcc -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib -lltdl -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib conftest.c -lmcrypt -lpng -lz -ljpeg -lz -lcrypt -lssl -lcrypto -lm -lcrypt >&5 /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_dlclose': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:89: undefined reference to `lt_dlclose' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_dlsym': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:99: undefined reference to `lt_dlsym' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_close': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:112: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_dlopen': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:153: undefined referenc e to `lt_dlsetsearchpath' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:155: undefined referenc e to `lt_dlopenext' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_open': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:173: undefined referenc e to `lt_dlinit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:179: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:185: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:192: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:199: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:212: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:219: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_get_size': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:245: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_mode_get_size' : /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:264: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_set_key': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:296: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_enc_set_state' : /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:315: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_enc_get_state' : /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:333: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o):/devel/build/mcrypt/libmcrypt-2.5.3 /lib/mcrypt_modules.c:361: more undefined references to `lt_dlerror' follow /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_self_te st': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:630: undefined referenc e to `lt_dlinit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:637: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:656: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:649: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_algorit hm_version': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:672: undefined referenc e to `lt_dlinit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:678: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:697: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:690: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_mode_ve rsion': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:713: undefined referenc e to `lt_dlinit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:719: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:738: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:731: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_is_bloc k_algorithm':
#20926 [Opn->Fbk]: libmcrypt error in configure
ID: 20926 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: mcrypt related Operating System: NetBSD-1.5.2 PHP Version: 4.3.0RC2 Previous Comments: [2002-12-11 10:52:44] [EMAIL PROTECTED] The configure option I used to include libmcrypt is: --with-mcrypt=/usr/local I am using libmcrypt-2.5.3. The config.log entry is as follows: configure:47349: checking for mcrypt support configure:47388: result: yes configure:47412: checking for mcrypt_module_open in -lmcrypt configure:47445: gcc -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib -lltdl -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib conftest.c -lmcrypt -lpng -lz -ljpeg -lz -lcrypt -lssl -lcrypto -lm -lcrypt >&5 /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_dlclose': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:89: undefined reference to `lt_dlclose' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_dlsym': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:99: undefined reference to `lt_dlsym' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_close': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:112: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_dlopen': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:153: undefined referenc e to `lt_dlsetsearchpath' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:155: undefined referenc e to `lt_dlopenext' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_open': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:173: undefined referenc e to `lt_dlinit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:179: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:185: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:192: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:199: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:212: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:219: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_get_size': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:245: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_mode_get_size' : /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:264: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_set_key': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:296: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_enc_set_state' : /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:315: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_enc_get_state' : /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:333: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o):/devel/build/mcrypt/libmcrypt-2.5.3 /lib/mcrypt_modules.c:361: more undefined references to `lt_dlerror' follow /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_self_te st': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:630: undefined referenc e to `lt_dlinit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:637: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:656: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:649: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_algorit hm_version': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:672: undefined referenc e to `lt_dlinit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:678: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:697: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:690: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_mode_ve rsion': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:713: undefined referenc e to `lt_dlinit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:719: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:738: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_
#20942 [NEW]: Activating extension : imap, stops Apache
From: [EMAIL PROTECTED] Operating system: OpenBSD 3.2 PHP version: 4.2.3 PHP Bug Type: Apache related Bug description: Activating extension : imap, stops Apache Apache works with PHP until I do: pkg_add php4-imap-4.2.3.tg /usr/local/sbin/phpxs -a imap Then: apachectl start /usr/sbin/apachectl start: httpd could not be started My /var/www/logs/error_log shows: /usr/libexec/ld.so: httpd: libc-client.so.4.0: Invalid argument If I do: /usr/local/sbin/phpxs -r imap Apache then works again. I'm new at this. Any help would be great... Thanks, Dave Miller -- Edit bug report at http://bugs.php.net/?id=20942&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20942&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20942&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20942&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20942&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20942&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20942&r=support Expected behavior: http://bugs.php.net/fix.php?id=20942&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20942&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20942&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20942&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20942&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20942&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20942&r=isapi
#20441 [Bgs->Opn]: PHP_AUTH_USER isn't set
ID: 20441 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Apache related -Operating System: Redhat Linux 7.1 kernel 2.4.2-2 +Operating System: all PHP Version: 4.3.0-pre2 New Comment: Can someone explain this? Apparently some external auth systems did not populate PHP_AUTH_USER while others did... Was this BC break discussed? It has been documented forever but this behavior changed so please explain it. Previous Comments: [2002-12-11 10:39:14] [EMAIL PROTECTED] I agree with the previous poster that this is a serious bug. When we upgraded to 4.3.0RC2 our development application broke. [2002-11-22 02:40:55] [EMAIL PROTECTED] This is not bogus!! This is a genuine bug. PHP_AUTH_USER was set in 4.2.3 why has the functionality been changed without warning? This will break so many peoples scripts it is not true. This *HAS TO BE FIXED* os that it works as it did before. Please stop trying to pretend that this is not a bug. It is, and a serious one at that. [2002-11-15 09:10:09] [EMAIL PROTECTED] It was fixed to be like it should be since PHP 3. [2002-11-15 03:52:04] [EMAIL PROTECTED] So I should use $_SERVER["REMOTE_USER"] if I use .htaccess and $_SERVER["PHP_AUTH_USER"] when I header the authentication? Why is this behaviour changed without notice? [2002-11-15 03:10:35] [EMAIL PROTECTED] You need to decide if you are using an external auth mechanism or http auth from php. You can't do both. 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/20441 -- Edit this bug report at http://bugs.php.net/?id=20441&edit=1
#20926 [Fbk]: libmcrypt error in configure
ID: 20926 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: mcrypt related Operating System: NetBSD-1.5.2 PHP Version: 4.3.0RC2 New Comment: Oops! Which version of libtool are you using? And did you do a "make install" of libmcrypt? Derick Previous Comments: [2002-12-11 10:52:44] [EMAIL PROTECTED] The configure option I used to include libmcrypt is: --with-mcrypt=/usr/local I am using libmcrypt-2.5.3. The config.log entry is as follows: configure:47349: checking for mcrypt support configure:47388: result: yes configure:47412: checking for mcrypt_module_open in -lmcrypt configure:47445: gcc -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib -lltdl -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib conftest.c -lmcrypt -lpng -lz -ljpeg -lz -lcrypt -lssl -lcrypto -lm -lcrypt >&5 /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_dlclose': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:89: undefined reference to `lt_dlclose' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_dlsym': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:99: undefined reference to `lt_dlsym' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_close': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:112: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_dlopen': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:153: undefined referenc e to `lt_dlsetsearchpath' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:155: undefined referenc e to `lt_dlopenext' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_open': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:173: undefined referenc e to `lt_dlinit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:179: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:185: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:192: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:199: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:212: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:219: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_get_size': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:245: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_mode_get_size' : /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:264: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_set_key': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:296: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_enc_set_state' : /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:315: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_enc_get_state' : /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:333: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o):/devel/build/mcrypt/libmcrypt-2.5.3 /lib/mcrypt_modules.c:361: more undefined references to `lt_dlerror' follow /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_self_te st': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:630: undefined referenc e to `lt_dlinit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:637: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:656: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:649: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_algorit hm_version': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:672: undefined referenc e to `lt_dlinit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:678: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:697: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:690: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_mode_ve rsion': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:713: undefined referenc e to `lt_dlinit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:719: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules
#20942 [Opn->Fbk]: Activating extension : imap, stops Apache
ID: 20942 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Apache related Operating System: OpenBSD 3.2 PHP Version: 4.2.3 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2002-12-11 10:53:10] [EMAIL PROTECTED] Apache works with PHP until I do: pkg_add php4-imap-4.2.3.tg /usr/local/sbin/phpxs -a imap Then: apachectl start /usr/sbin/apachectl start: httpd could not be started My /var/www/logs/error_log shows: /usr/libexec/ld.so: httpd: libc-client.so.4.0: Invalid argument If I do: /usr/local/sbin/phpxs -r imap Apache then works again. I'm new at this. Any help would be great... Thanks, Dave Miller -- Edit this bug report at http://bugs.php.net/?id=20942&edit=1
#20441 [Opn->Bgs]: PHP_AUTH_USER isn't set
ID: 20441 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache related Operating System: all PHP Version: 4.3.0-pre2 New Comment: We fixed a bug, period. Derick Previous Comments: [2002-12-11 10:53:53] [EMAIL PROTECTED] Can someone explain this? Apparently some external auth systems did not populate PHP_AUTH_USER while others did... Was this BC break discussed? It has been documented forever but this behavior changed so please explain it. [2002-12-11 10:39:14] [EMAIL PROTECTED] I agree with the previous poster that this is a serious bug. When we upgraded to 4.3.0RC2 our development application broke. [2002-11-22 02:40:55] [EMAIL PROTECTED] This is not bogus!! This is a genuine bug. PHP_AUTH_USER was set in 4.2.3 why has the functionality been changed without warning? This will break so many peoples scripts it is not true. This *HAS TO BE FIXED* os that it works as it did before. Please stop trying to pretend that this is not a bug. It is, and a serious one at that. [2002-11-15 09:10:09] [EMAIL PROTECTED] It was fixed to be like it should be since PHP 3. [2002-11-15 03:52:04] [EMAIL PROTECTED] So I should use $_SERVER["REMOTE_USER"] if I use .htaccess and $_SERVER["PHP_AUTH_USER"] when I header the authentication? Why is this behaviour changed without notice? 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/20441 -- Edit this bug report at http://bugs.php.net/?id=20441&edit=1
#20546 [Com]: compile with gcc 3.2 fails due to parser errors
ID: 20546 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: RedHat Linux 8.0 PHP Version: 4.3.0-dev New Comment: php4-STABLE-200212111430 red hat 8.0 gcc version 3.2.1 autoconf version 2.13-5 (downgraded from more-current 2.56-1) automake version 1.6.3-1 libtool version 1.4.3-2 zlib version 1.1.4-4 ./configure --with-pgsql --with-gd --with-apxs2=/usr/local/apache2/bin/apxs --enable-track-vars --enable-force-cgi-redirect --with-gettext --with-gd --with-dom --with-zlib-dir=/usr/lib --enable-cli i tried this configure/make with autoconf 2.56-1 first (on a freshly un-tarred php4-stable snap) and it failed as it had before. then after downgrading to the recommended autoconf 2.13 and doing a 'make distclean; ./buildconf', i was still receiving make errors as previously stated in this bug report. is this a gcc issue? i have tried the recommended build tools, but have not tried (nor wanted) to downgrade my gcc to get PHP to build. here is my make output with autoconf 2.13 [root@thelocust php4-STABLE-200212111430]# make /bin/sh libtool --silent --mode=compile gcc -Iext/zlib/ -I/home/ben/src/php4-STABLE-200212111430/ext/zlib/ -DPHP_ATOM_INC -I/home/ben/src/php4-STABLE-200212111430/include -I/home/ben/src/php4-STABLE-200212111430/main -I/home/ben/src/php4-STABLE-200212111430 -I/usr/local/apache2/include -I/home/ben/src/php4-STABLE-200212111430/Zend -I/usr/include/libxml2 -I/home/ben/src/php4-STABLE-200212111430/ext/xml/expat -I/home/ben/src/php4-STABLE-200212111430/TSRM -g -prefer-pic -c /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c -o ext/zlib/zlib.lo In file included from /home/ben/src/php4-STABLE-200212111430/Zend/zend.h:202, from /home/ben/src/php4-STABLE-200212111430/main/php.h:34, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/Zend/zend_hash.h:119: parse error before "va_list" In file included from /home/ben/src/php4-STABLE-200212111430/Zend/zend.h:203, from /home/ben/src/php4-STABLE-200212111430/main/php.h:34, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/Zend/zend_llist.h:34: parse error before "va_list" In file included from /home/ben/src/php4-STABLE-200212111430/main/php.h:34, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/Zend/zend.h:285: parse error before "va_list" /home/ben/src/php4-STABLE-200212111430/Zend/zend.h:423: parse error before "va_list" In file included from /home/ben/src/php4-STABLE-200212111430/main/php.h:224, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/main/spprintf.h:40: parse error before "va_list" In file included from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/main/php.h:277: parse error before "va_list" In file included from /home/ben/src/php4-STABLE-200212111430/main/php.h:360, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/TSRM/tsrm_virtual_cwd.h:159: warning: `struct utimbuf' declared inside parameter list /home/ben/src/php4-STABLE-200212111430/TSRM/tsrm_virtual_cwd.h:159: warning: its scope is only this definition or declaration, which is probably not what you want In file included from /home/ben/src/php4-STABLE-200212111430/ext/standard/php_standard.h:23, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:48: /home/ben/src/php4-STABLE-200212111430/ext/standard/php_string.h: In function `php_memnstr': /home/ben/src/php4-STABLE-200212111430/ext/standard/php_string.h:142: warning: assignment makes pointer from integer without a cast In file included from /home/ben/src/php4-STABLE-200212111430/ext/standard/fsock.h:38, from /home/ben/src/php4-STABLE-200212111430/ext/standard/php_standard.h:44, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:48: /home/ben/src/php4-STABLE-200212111430/main/php_network.h: At top level: /home/ben/src/php4-STABLE-200212111430/main/php_network.h:113: warning: `struct sockaddr' declared inside parameter list In file included from /home/ben/src/php4-STABLE-200212111430/ext/standard/php_standard.h:44, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:48: /home/ben/src/php4-STABLE-200212111430/ext/standard/fsock.h:43: warning: `struct in_addr' declared inside parameter list make: *** [ext/zlib/zlib.lo] Error 1 Previous Comments: [2002-12-03 13:42:15] [EMAIL PROTECTED] Thanks for the heads-up on rebuilding the configure, but alas I just tri
#20926 [Fbk->Opn]: libmcrypt error in configure
ID: 20926 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: mcrypt related Operating System: NetBSD-1.5.2 PHP Version: 4.3.0RC2 New Comment: libtool --version ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) Yes, libmcrypt has been installed in /usr/local. Previous Comments: [2002-12-11 10:55:44] [EMAIL PROTECTED] Oops! Which version of libtool are you using? And did you do a "make install" of libmcrypt? Derick [2002-12-11 10:52:44] [EMAIL PROTECTED] The configure option I used to include libmcrypt is: --with-mcrypt=/usr/local I am using libmcrypt-2.5.3. The config.log entry is as follows: configure:47349: checking for mcrypt support configure:47388: result: yes configure:47412: checking for mcrypt_module_open in -lmcrypt configure:47445: gcc -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib -lltdl -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib conftest.c -lmcrypt -lpng -lz -ljpeg -lz -lcrypt -lssl -lcrypto -lm -lcrypt >&5 /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_dlclose': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:89: undefined reference to `lt_dlclose' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_dlsym': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:99: undefined reference to `lt_dlsym' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_close': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:112: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_dlopen': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:153: undefined referenc e to `lt_dlsetsearchpath' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:155: undefined referenc e to `lt_dlopenext' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_open': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:173: undefined referenc e to `lt_dlinit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:179: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:185: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:192: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:199: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:212: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:219: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_get_size': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:245: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_mode_get_size' : /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:264: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_set_key': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:296: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_enc_set_state' : /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:315: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_enc_get_state' : /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:333: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o):/devel/build/mcrypt/libmcrypt-2.5.3 /lib/mcrypt_modules.c:361: more undefined references to `lt_dlerror' follow /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_self_te st': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:630: undefined referenc e to `lt_dlinit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:637: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:656: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:649: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_algorit hm_version': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:672: undefined referenc e to `lt_dlinit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:678: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:697: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:690: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module
#20926 [Opn->Fbk]: libmcrypt error in configure
ID: 20926 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: mcrypt related Operating System: NetBSD-1.5.2 PHP Version: 4.3.0RC2 New Comment: In order to reproduce it, I'd like to have: 1. The full configure line of libmcrypt 2. The full configure line for PHP 3. version numbers of autoconf and automake 4. version numbers of relevant libraries. regards, Derick Previous Comments: [2002-12-11 10:59:43] [EMAIL PROTECTED] libtool --version ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) Yes, libmcrypt has been installed in /usr/local. [2002-12-11 10:55:44] [EMAIL PROTECTED] Oops! Which version of libtool are you using? And did you do a "make install" of libmcrypt? Derick [2002-12-11 10:52:44] [EMAIL PROTECTED] The configure option I used to include libmcrypt is: --with-mcrypt=/usr/local I am using libmcrypt-2.5.3. The config.log entry is as follows: configure:47349: checking for mcrypt support configure:47388: result: yes configure:47412: checking for mcrypt_module_open in -lmcrypt configure:47445: gcc -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib -lltdl -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib conftest.c -lmcrypt -lpng -lz -ljpeg -lz -lcrypt -lssl -lcrypto -lm -lcrypt >&5 /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_dlclose': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:89: undefined reference to `lt_dlclose' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_dlsym': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:99: undefined reference to `lt_dlsym' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_close': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:112: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_dlopen': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:153: undefined referenc e to `lt_dlsetsearchpath' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:155: undefined referenc e to `lt_dlopenext' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_open': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:173: undefined referenc e to `lt_dlinit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:179: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:185: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:192: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:199: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:212: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:219: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_get_size': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:245: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_mode_get_size' : /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:264: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_set_key': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:296: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_enc_set_state' : /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:315: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_enc_get_state' : /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:333: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o):/devel/build/mcrypt/libmcrypt-2.5.3 /lib/mcrypt_modules.c:361: more undefined references to `lt_dlerror' follow /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_self_te st': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:630: undefined referenc e to `lt_dlinit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:637: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:656: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:649: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_algorit hm_version': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:672: undefined referenc e to `lt_dlinit' /devel/build/mcrypt/libmcryp
#20926 [Fbk->Opn]: libmcrypt error in configure
ID: 20926 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: mcrypt related Operating System: NetBSD-1.5.2 PHP Version: 4.3.0RC2 New Comment: Please ignore the /pkg settings. These packages get installed into /usr/local. configure for libmcrypt: ./configure --prefix=/pkg/libmcrypt-2.5.3 --enable-shared=no --with-pic configure for php: ./configure --prefix=/pkg/php-4.3.0rc2 --enable-shared=no --with-mysql=/pkg/mysql-3.23.46 --enable-discard-path --with-config-file-path=/pkg/php-4.3.0rc2/libdata/php-4.3.0rc2 --with-xml --with-imap-ssl=/devel/build/pine/pine-4.50/imap/ --libdir=/pkg/php-4.3.0rc2/libdata/php-4.3.0rc2 --with-openssl=/usr/local --with-ndbm --with-gd --with-jpeg-dir=/usr/local --with-mcrypt=/usr/local --with-zlib-dir=/usr/local --with-db autoconf (GNU Autoconf) 2.53 automake (GNU automake) 1.4 libmcrypt-2.5.3 mysql-3.23.46 openssl-0.9.6g gd-2.0.4 jpeg-6b zlib-1.1.4 Previous Comments: [2002-12-11 11:02:53] [EMAIL PROTECTED] In order to reproduce it, I'd like to have: 1. The full configure line of libmcrypt 2. The full configure line for PHP 3. version numbers of autoconf and automake 4. version numbers of relevant libraries. regards, Derick [2002-12-11 10:59:43] [EMAIL PROTECTED] libtool --version ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) Yes, libmcrypt has been installed in /usr/local. [2002-12-11 10:55:44] [EMAIL PROTECTED] Oops! Which version of libtool are you using? And did you do a "make install" of libmcrypt? Derick [2002-12-11 10:52:44] [EMAIL PROTECTED] The configure option I used to include libmcrypt is: --with-mcrypt=/usr/local I am using libmcrypt-2.5.3. The config.log entry is as follows: configure:47349: checking for mcrypt support configure:47388: result: yes configure:47412: checking for mcrypt_module_open in -lmcrypt configure:47445: gcc -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib -lltdl -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib conftest.c -lmcrypt -lpng -lz -ljpeg -lz -lcrypt -lssl -lcrypto -lm -lcrypt >&5 /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_dlclose': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:89: undefined reference to `lt_dlclose' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_dlsym': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:99: undefined reference to `lt_dlsym' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_close': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:112: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_dlopen': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:153: undefined referenc e to `lt_dlsetsearchpath' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:155: undefined referenc e to `lt_dlopenext' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_open': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:173: undefined referenc e to `lt_dlinit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:179: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:185: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:192: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:199: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:212: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:219: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_get_size': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:245: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_mode_get_size' : /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:264: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_set_key': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:296: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_enc_set_state' : /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:315: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_enc_get_state' : /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:333: undefined referenc e to `lt
#20895 [Ver]: dirname() behaviour changed
ID: 20895
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Verified
Bug Type: Filesystem function related
Operating System: Win 2000Pro SP3
PHP Version: 4.3.0RC2
New Comment:
Suppose you have a file c:/file.txt and you want to open another file
from the same directory.
If dirname("c:/file.txt"); return '.', then fopen
("./another_file.txt") will fail because it is looking in the wrong
directory, the current current directory. If it returns c:/ or c: then
c: + / + file will resolve to the actual file and open it correctly.
Previous Comments:
[2002-12-10 20:05:55] [EMAIL PROTECTED]
A couple people just tested this and get the same results as the bug
report with 4.3.0RC2, please explain why this behavior changed.
[2002-12-08 23:56:53] [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-12-08 23:35:37] [EMAIL PROTECTED]
Hello.
Up to 4.2.3:
dirname("c:/");
// or
dirname("c:");
// both returned '.'
in 4.3.0 RC2, we got now:
dirname("c:/");
// gives you c:\
dirname("c:");
// gives you c:
(i) I'm not sure that such path shall be used with dirname(). But after
all, why not? And in fact I used it.
(ii) What's the reason for that behaviour change?
(iii) As some of my classes are now broken, will this new behaviour
become the rule for the future?
Apache independent.
Standarts php.ini (recommended) and httpd.conf
Mozilla 1.2
Thanks.
--
Edit this bug report at http://bugs.php.net/?id=20895&edit=1
#20831 [Com]: include() from UNC paths does not work.
ID: 20831 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: IIS related Operating System: Windows 9x/2000/XP PHP Version: 4.3.0RC2 New Comment: i have replaced the dll (only one copy), but it dont work for me. i will setup a second testinstall on another "clean" server. maybe its a iis config problem... i will check this now. thank for your helps... Previous Comments: [2002-12-11 09:26:23] [EMAIL PROTECTED] I've tried the latest snap on WinXP using cli including "../../file.txt" & "server\path\file.txt" and both works flawlessly. The few people I spoke to also didn't not encounter a problem opening/including files via relative or UNC path. Therefor, I must conclude that the problem you are seeing is due to some issue on your end, possible left over dlls from older PHP, IIS config params and so on... [2002-12-11 09:25:14] [EMAIL PROTECTED] The CLI version should work, but to be sure, remove all old copies of 'php4ts.dll'. The fix is in this module. [2002-12-11 09:11:12] [EMAIL PROTECTED] i meant 9:00 snapshot not 15:30 (this is localtime in austria) i have now testet the ISAPI module of the snapshot, this do not work, following error appears: PHP has encountered an Access Violation at 0F6C3B5E is there an user right problem? iis config? [2002-12-11 09:01:27] [EMAIL PROTECTED] UNC error still exists... i have tested again with with w2k-sp3/iis5/php-CGI config within iis5: .php -> g:\phpsnapshot\php-cgi.exe %s %s if i try to include a file from a "lower" dir like ../_php/include.php i still get the error described in this bug. what can be done? i have tested actual snapshot versions (stable,cvs) from 11.dec. 15:30 i have also retestet the CLI version php.exe, it dont work! in a older snapshot this has worked. i have not testet ISAPI. [2002-12-10 20:11:24] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. 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/20831 -- Edit this bug report at http://bugs.php.net/?id=20831&edit=1
#20815 [Com]: /main/reentrancy.c:192: too few arguments to function `readdir_r'
ID: 20815 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Compile Failure Operating System: Linux 2.4.18 i686 GNU PHP Version: 4.3.0RC2 New Comment: OK, Well, I understand. Thanks everybody. I will make things better next time. Previous Comments: [2002-12-04 18:00:10] [EMAIL PROTECTED] Not enough information and most likely user error / broken system includes. [2002-12-04 11:37:22] [EMAIL PROTECTED] $./configure ... $./make ... .../main/reentrancy.c:192: In function `readdir_r': .../main/reentrancy.c:192: too few arguments to function `readdir_r' make: *** [reentrancy.lo] Error 1 It was the last version. Please, ¿Could someone fix it in the next version? I will send the report until then. Thanks. -- Edit this bug report at http://bugs.php.net/?id=20815&edit=1
#20942 [Fbk->Opn]: Activating extension : imap, stops Apache
ID: 20942 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Apache related Operating System: OpenBSD 3.2 PHP Version: 4.2.3 New Comment: This is a fresh install of OpenBSD 3.2 on an i386 type machine. qmail for SMTP and courier for IMAP and POP3 were added and tested. The mysql server package (from the CD)was also added. The goal is to use squirrelmail. I downloaded the following packages from the Openbsd site for OpenBSD 3.2: php4-core-4.2.3.tgz php4-mysql-4.2.3.tgz php4-imap-4.2.3.tgz php4-pear-4.2.3.tgz I followed the instructions at: http://php3.de/manual/en/install.openbsd.php I edited my httpd.conf to show: DirectoryIndex index.php index.html and AddType application/x-httpd-php .php Apache will not start unless I disable the imap extension. My Apache error log shows: usr/libexec/ld.so: httpd: libc-client.so.4.0: Invalid argument help??? Previous Comments: [2002-12-11 10:56:41] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2002-12-11 10:53:10] [EMAIL PROTECTED] Apache works with PHP until I do: pkg_add php4-imap-4.2.3.tg /usr/local/sbin/phpxs -a imap Then: apachectl start /usr/sbin/apachectl start: httpd could not be started My /var/www/logs/error_log shows: /usr/libexec/ld.so: httpd: libc-client.so.4.0: Invalid argument If I do: /usr/local/sbin/phpxs -r imap Apache then works again. I'm new at this. Any help would be great... Thanks, Dave Miller -- Edit this bug report at http://bugs.php.net/?id=20942&edit=1
#20943 [NEW]: header("HTTP/1.1 nnn xxx") not working under Apache
From: [EMAIL PROTECTED]
Operating system: WIN2K, Apache 1.3.x/2.0.x
PHP version: 4.2.3
PHP Bug Type: Output Control
Bug description: header("HTTP/1.1 nnn xxx") not working under Apache
Tried writing this script (PHP 4.2.3, Apache 1.3.x/2.0.x, not tried under
IIS):
Hello
If PHP is configured as a Module it works fine. If PHP is configured as
CGI Apache breaks the output and shows its own "Internal Server Error"
page. Apache was installed as out-of-the box, no special options apart
PHP/CGI configuration directives. Apache error log line is:
[Wed Dec 11 18:41:38 2002] [error] [client 127.0.0.1] malformed header
from script. Bad header=HTTP/1.1 200 OK: php-cgi.exe
Is this a correct behaviour? My config is broken? Is it a bug for
Apache
Thanks
Michele
--
Edit bug report at http://bugs.php.net/?id=20943&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20943&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20943&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20943&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20943&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20943&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20943&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20943&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20943&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20943&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20943&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20943&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20943&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20943&r=isapi
#20926 [Opn->Fbk]: libmcrypt error in configure
ID: 20926 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: mcrypt related Operating System: NetBSD-1.5.2 PHP Version: 4.3.0RC2 New Comment: I believe the pkg prefix might be the problem here. Why don't you just use "/usr/local" here? Previous Comments: [2002-12-11 11:14:58] [EMAIL PROTECTED] Please ignore the /pkg settings. These packages get installed into /usr/local. configure for libmcrypt: ./configure --prefix=/pkg/libmcrypt-2.5.3 --enable-shared=no --with-pic configure for php: ./configure --prefix=/pkg/php-4.3.0rc2 --enable-shared=no --with-mysql=/pkg/mysql-3.23.46 --enable-discard-path --with-config-file-path=/pkg/php-4.3.0rc2/libdata/php-4.3.0rc2 --with-xml --with-imap-ssl=/devel/build/pine/pine-4.50/imap/ --libdir=/pkg/php-4.3.0rc2/libdata/php-4.3.0rc2 --with-openssl=/usr/local --with-ndbm --with-gd --with-jpeg-dir=/usr/local --with-mcrypt=/usr/local --with-zlib-dir=/usr/local --with-db autoconf (GNU Autoconf) 2.53 automake (GNU automake) 1.4 libmcrypt-2.5.3 mysql-3.23.46 openssl-0.9.6g gd-2.0.4 jpeg-6b zlib-1.1.4 [2002-12-11 11:02:53] [EMAIL PROTECTED] In order to reproduce it, I'd like to have: 1. The full configure line of libmcrypt 2. The full configure line for PHP 3. version numbers of autoconf and automake 4. version numbers of relevant libraries. regards, Derick [2002-12-11 10:59:43] [EMAIL PROTECTED] libtool --version ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) Yes, libmcrypt has been installed in /usr/local. [2002-12-11 10:55:44] [EMAIL PROTECTED] Oops! Which version of libtool are you using? And did you do a "make install" of libmcrypt? Derick [2002-12-11 10:52:44] [EMAIL PROTECTED] The configure option I used to include libmcrypt is: --with-mcrypt=/usr/local I am using libmcrypt-2.5.3. The config.log entry is as follows: configure:47349: checking for mcrypt support configure:47388: result: yes configure:47412: checking for mcrypt_module_open in -lmcrypt configure:47445: gcc -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib -lltdl -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib conftest.c -lmcrypt -lpng -lz -ljpeg -lz -lcrypt -lssl -lcrypto -lm -lcrypt >&5 /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_dlclose': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:89: undefined reference to `lt_dlclose' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_dlsym': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:99: undefined reference to `lt_dlsym' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_close': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:112: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_dlopen': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:153: undefined referenc e to `lt_dlsetsearchpath' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:155: undefined referenc e to `lt_dlopenext' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_module_open': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:173: undefined referenc e to `lt_dlinit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:179: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:185: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:192: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:199: undefined referenc e to `lt_dlexit' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:212: undefined referenc e to `lt_dlerror' /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:219: undefined referenc e to `lt_dlexit' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_get_size': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:245: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_mode_get_size' : /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:264: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_set_key': /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:296: undefined referenc e to `lt_dlerror' /usr/local/lib/libmcrypt.a(mcrypt_modules.o): In function `mcrypt_enc_set_state' : /devel/build/mcrypt/libmcrypt-2.5.3/lib/mcrypt_modules.c:315: und
#20943 [Opn->Fbk]: header("HTTP/1.1 nnn xxx") not working under Apache
ID: 20943 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Output Control Operating System: WIN2K, Apache 1.3.x/2.0.x PHP Version: 4.2.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-12-11 11:48:52] [EMAIL PROTECTED] Tried writing this script (PHP 4.2.3, Apache 1.3.x/2.0.x, not tried under IIS): Hello If PHP is configured as a Module it works fine. If PHP is configured as CGI Apache breaks the output and shows its own "Internal Server Error" page. Apache was installed as out-of-the box, no special options apart PHP/CGI configuration directives. Apache error log line is: [Wed Dec 11 18:41:38 2002] [error] [client 127.0.0.1] malformed header from script. Bad header=HTTP/1.1 200 OK: php-cgi.exe Is this a correct behaviour? My config is broken? Is it a bug for Apache Thanks Michele -- Edit this bug report at http://bugs.php.net/?id=20943&edit=1
#20937 [Opn->Bgs]: PHP binary randomly consumes from 300kb to 5Mb
ID: 20937 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: Win2000, MacOS PHP Version: 4.2.3 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. The memory usage will depend on the amount of data retrieved from the SQL server. Previous Comments: [2002-12-11 09:05:16] [EMAIL PROTECTED] You need advanced tools to test this: Windows Task Manager! The PHP binary randomly cunsumes up to 5Mb of memory for no clear reason. When the whole application is loaded this leads to binaries from 2Mb to 12Mb. The script includes PEAR::DB (DB.php), connects to the database (MySQL) and dies. Zillions of users are complainin about exhausted memory problems and we have to make them change the maximum memory size for PHP scripts in their php.ini settings. -- Edit this bug report at http://bugs.php.net/?id=20937&edit=1
#20942 [Opn->Bgs]: Activating extension : imap, stops Apache
ID: 20942 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache related Operating System: OpenBSD 3.2 PHP Version: 4.2.3 New Comment: Sounds like a missing library on your system, you need to install c-client (part of Washington IMAP server). Not a bug in PHP -> bogus Previous Comments: [2002-12-11 11:48:34] [EMAIL PROTECTED] This is a fresh install of OpenBSD 3.2 on an i386 type machine. qmail for SMTP and courier for IMAP and POP3 were added and tested. The mysql server package (from the CD)was also added. The goal is to use squirrelmail. I downloaded the following packages from the Openbsd site for OpenBSD 3.2: php4-core-4.2.3.tgz php4-mysql-4.2.3.tgz php4-imap-4.2.3.tgz php4-pear-4.2.3.tgz I followed the instructions at: http://php3.de/manual/en/install.openbsd.php I edited my httpd.conf to show: DirectoryIndex index.php index.html and AddType application/x-httpd-php .php Apache will not start unless I disable the imap extension. My Apache error log shows: usr/libexec/ld.so: httpd: libc-client.so.4.0: Invalid argument help??? [2002-12-11 10:56:41] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2002-12-11 10:53:10] [EMAIL PROTECTED] Apache works with PHP until I do: pkg_add php4-imap-4.2.3.tg /usr/local/sbin/phpxs -a imap Then: apachectl start /usr/sbin/apachectl start: httpd could not be started My /var/www/logs/error_log shows: /usr/libexec/ld.so: httpd: libc-client.so.4.0: Invalid argument If I do: /usr/local/sbin/phpxs -r imap Apache then works again. I'm new at this. Any help would be great... Thanks, Dave Miller -- Edit this bug report at http://bugs.php.net/?id=20942&edit=1
#20940 [Opn->Fbk]: After upgrading from PHP 4.2-dev to 4.2.3, garbage collection no longer occurs
ID: 20940 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Session related Operating System: Solaris 8 PHP Version: 4.2.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-12-11 10:42:51] [EMAIL PROTECTED] I am using the same PHP pages that were used in PHP 4.2-dev and the same php.ini file. The session files in the /tmp/session directory are not being gc'd after the gc_maxlifetime. GC is running. This was evidenced by the skyrocketing LA on the machine when I increased gc_probability to 50. Please contact me if more information is necesary, or you can suggest trouble shooting tests. -- Edit this bug report at http://bugs.php.net/?id=20940&edit=1
#19052 [Com]: $_POST doesn't work correctly
ID: 19052 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Apache2 related Operating System: Red Hat 7.3 Linux 2.4.18 PHP Version: 4CVS-2002-08-22 New Comment: I think I found the failure mode. The submit button in the example doesn't have a name attribute. If you add a name attribute to the "Insert Record" field, the bug disappears and the $_POST array appears correct. (I tried this using A/B comparisons between a page that worked and the example above until the example worked). Could the work-around be to ensure that all form elements have name attributes? Fixing this might be pretty important. I'm probably not the only person stuck running RedHat 8.0, which uses Apache 2.0.40 and php 4.2.2, and the version of RH 8.1 beta that I've checked seems to have the same bug. [sigh] Anyway, here's the "corrected" version of the script which seems to work on my configuration: Insert Form Text to add: "; ?> Previous Comments: [2002-09-27 13:06:13] [EMAIL PROTECTED] I just compiled apache 2.0.42 and php 200209270600 from snaps.php.net and still have the same error. I tried it with Mozilla 1.1 and IE 5.5. [2002-09-26 12:15:14] [EMAIL PROTECTED] Most likely problem within the browser. Also, try more recent versions of PHP and Apache2 if that is not the case. [2002-08-22 14:47:32] [EMAIL PROTECTED] Dupe of #19047. [2002-08-22 12:18:18] [EMAIL PROTECTED] Ah, ok, it is an Apache2-related issue then. This stuff is still very experimental. Use Apache 1.3 if you just want your stuff to work. Otherwise dive into the code and let us know what the fix is. [2002-08-22 12:14:17] [EMAIL PROTECTED] I am using Apache 2.0.40. It was compiled using ./configure --enable-modules=all I compiled PHP using ./configure --enable-track-vars --with-mysql --with-mail --with-apxs2=/usr/local/apache2/bin/apxs If you need the output of phpinfo(); it is http://www.squeezer.net/phpinfo.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/19052 -- Edit this bug report at http://bugs.php.net/?id=19052&edit=1
#19918 [Opn]: no libphp4.so produced
ID: 19918 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache2 related Operating System: HP-UX 11.00 PHP Version: 4.3.0-pre1 New Comment: tested with php4-200212111630 same result. @++ JC Previous Comments: [2002-11-26 18:46:28] [EMAIL PROTECTED] Using the latest CVS snapshot php4-STABLE-200211262230, I was able to locate what I believe to be the problem. Apparently PHP is trying to link in -lcrypt, and because libcrypt.a is not a shared library object, libtool is complaining and then not creating a shared libphp.so object because of it: *** Warning: linker path does not have real file for library -lcrypt. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libcrypt and none of the candidates passed a file format test *** using a file magic. Last file checked: /usr/lib/libcrypt.a *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module libphp4. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. So what I did was re-run the last libtool command, which is supposed to link all the objects together, and create a libphp4.so, but I took out the -lcrypt portion of the command. Once that was done, a libphp4.so was created as expected, and then a 'make install' worked also as expected putting libphp4.so into /opt/apache/modules. Starting apache so far also works without an error about 'Bad magic number'. I took a gamble that php didn't use or require the crypt library, otherwise I was half expecting to get an error from dld.sl about missing reference to 'crypt', but so far so good. [2002-11-21 14:27:38] [EMAIL PROTECTED] tested with php4-200211211830 same result. @++ JC [2002-11-19 18:59:57] [EMAIL PROTECTED] I'm having the same problem and I'm using the latest CVS snapshot of php4-200211200030, HP-UX 11.00 and Apache 2.0.43. The only way I was able to work around the problem was to go into where I have apache/modules located and rename libphp4.a to libphp4.so and then 'make install' again. This seems to work, but when I try to start apache, it can't use the libphp4.so. I get this error message: Cannot load /opt/apache/modules/libphp4.so into server: Bad magic number for shared library: /opt/apache/modules/libphp4.so [2002-11-10 18:30:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-15 22:33:08] [EMAIL PROTECTED] oopsie..the other bug is saying the compile doesn't work with apache 1.3.x...but you said that works so I'm reopening this. 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/19918 -- Edit this bug report at http://bugs.php.net/?id=19918&edit=1
#20937 [Bgs]: PHP binary randomly consumes from 300kb to 5Mb
ID: 20937 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *General Issues Operating System: Win2000, MacOS PHP Version: 4.2.3 New Comment: No single line of code is executed, the script only does an include so the problem is indeed the size of the PHP binary which varies from 2 to 5mb without a reason. Previous Comments: [2002-12-11 11:57:03] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. The memory usage will depend on the amount of data retrieved from the SQL server. [2002-12-11 09:05:16] [EMAIL PROTECTED] You need advanced tools to test this: Windows Task Manager! The PHP binary randomly cunsumes up to 5Mb of memory for no clear reason. When the whole application is loaded this leads to binaries from 2Mb to 12Mb. The script includes PEAR::DB (DB.php), connects to the database (MySQL) and dies. Zillions of users are complainin about exhausted memory problems and we have to make them change the maximum memory size for PHP scripts in their php.ini settings. -- Edit this bug report at http://bugs.php.net/?id=20937&edit=1
#12360 [Com]: fsockopen timeout doesn't work
ID: 12360 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Sockets related Operating System: RedHat 6.2 PHP Version: 4.0.6 New Comment: i have had the latest version for some time now, and the problem persists. scripts with the fsockopen function STILL DO HANG. Previous Comments: [2002-09-28 17:49:42] [EMAIL PROTECTED] [EMAIL PROTECTED]: 4.1.2 is too old; can you try a non-stable snapshot from http://snaps.php.net/win32/. Despite the term non-stable, it should be quite stable and will form the base of PHP 4.3 which we are branching for QA and the release process shortly. [2002-09-28 16:18:59] [EMAIL PROTECTED] It's now year 2002 and I'm using php 4.1.2 and neither is the timeout parameter to the fsockopen function working properly, nor is the socket_set_timeout function i've written a small monitoring program that kills php processes that has been working too long (i use the php scripts by running them in the console).. and the interesting thing is that when i run the same script in several instances, they seem to hang in pairs (but NOT always). Perhaps they try to use the same outgoing port? and this is not something rare, i've been logging the kills and it happens once (two kills) every 10-15 minutes, once killed they are restarted by a loop in a batch file. i'm using windows xp with php 4.1.2 and apache (but as i said, i'm simply running the scripts without apache in the console, "php script.php"..) i remember having this problem when run in linux.. i've seen many similar bugreports but nothing seem to have been done to adress the problem.. keep up the good work, Osman Darcan [2001-08-10 16:16:06] [EMAIL PROTECTED] I put that include in CVS, and it will be in 4.0.7 if there are no problems with it. I did limited testing, but don't know this helped. alindeman: _please_ test this... If this isn't fixed, please reopen. [2001-08-06 18:16:02] [EMAIL PROTECTED] [EMAIL PROTECTED]: > I have not looked into this a lot so I might be mistaken, but it > seems that the problem is that fcntl.h is not defined in main/network.c > > If I add the following lines to main/network.c it seems that timeout > works again: > > #ifndef _FCNTL_H > #include > #endif > > I'm running Debian 2.2r3 with PHP 4.0.6 > > Regards, > Michael [2001-07-25 09:34:30] [EMAIL PROTECTED] I have reproduced this error. When requesting an valid address, but a port that the server does not listen on, the script hangs. (*Andy*) 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/12360 -- Edit this bug report at http://bugs.php.net/?id=12360&edit=1
#20546 [Com]: compile with gcc 3.2 fails due to parser errors
ID: 20546 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: RedHat Linux 8.0 PHP Version: 4.3.0-dev New Comment: I added the patch to zend_hash.h as specified in this bug: http://bugs.php.net/bug.php?id=15217, (adding #include to zend_hash.h), and the seemed to rectify my initial problems, however, now I am getting the following warnings: /home/ben/src/php4-STABLE-200212111430/TSRM/tsrm_virtual_cwd.h:159: warning: `struct utimbuf' declared inside parameter list /home/ben/src/php4-STABLE-200212111430/TSRM/tsrm_virtual_cwd.h:159: warning: its scope is only this definition or declaration, which is probably not what you want from a number of different files. Previous Comments: [2002-12-11 10:59:38] [EMAIL PROTECTED] php4-STABLE-200212111430 red hat 8.0 gcc version 3.2.1 autoconf version 2.13-5 (downgraded from more-current 2.56-1) automake version 1.6.3-1 libtool version 1.4.3-2 zlib version 1.1.4-4 ./configure --with-pgsql --with-gd --with-apxs2=/usr/local/apache2/bin/apxs --enable-track-vars --enable-force-cgi-redirect --with-gettext --with-gd --with-dom --with-zlib-dir=/usr/lib --enable-cli i tried this configure/make with autoconf 2.56-1 first (on a freshly un-tarred php4-stable snap) and it failed as it had before. then after downgrading to the recommended autoconf 2.13 and doing a 'make distclean; ./buildconf', i was still receiving make errors as previously stated in this bug report. is this a gcc issue? i have tried the recommended build tools, but have not tried (nor wanted) to downgrade my gcc to get PHP to build. here is my make output with autoconf 2.13 [root@thelocust php4-STABLE-200212111430]# make /bin/sh libtool --silent --mode=compile gcc -Iext/zlib/ -I/home/ben/src/php4-STABLE-200212111430/ext/zlib/ -DPHP_ATOM_INC -I/home/ben/src/php4-STABLE-200212111430/include -I/home/ben/src/php4-STABLE-200212111430/main -I/home/ben/src/php4-STABLE-200212111430 -I/usr/local/apache2/include -I/home/ben/src/php4-STABLE-200212111430/Zend -I/usr/include/libxml2 -I/home/ben/src/php4-STABLE-200212111430/ext/xml/expat -I/home/ben/src/php4-STABLE-200212111430/TSRM -g -prefer-pic -c /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c -o ext/zlib/zlib.lo In file included from /home/ben/src/php4-STABLE-200212111430/Zend/zend.h:202, from /home/ben/src/php4-STABLE-200212111430/main/php.h:34, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/Zend/zend_hash.h:119: parse error before "va_list" In file included from /home/ben/src/php4-STABLE-200212111430/Zend/zend.h:203, from /home/ben/src/php4-STABLE-200212111430/main/php.h:34, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/Zend/zend_llist.h:34: parse error before "va_list" In file included from /home/ben/src/php4-STABLE-200212111430/main/php.h:34, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/Zend/zend.h:285: parse error before "va_list" /home/ben/src/php4-STABLE-200212111430/Zend/zend.h:423: parse error before "va_list" In file included from /home/ben/src/php4-STABLE-200212111430/main/php.h:224, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/main/spprintf.h:40: parse error before "va_list" In file included from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/main/php.h:277: parse error before "va_list" In file included from /home/ben/src/php4-STABLE-200212111430/main/php.h:360, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:28: /home/ben/src/php4-STABLE-200212111430/TSRM/tsrm_virtual_cwd.h:159: warning: `struct utimbuf' declared inside parameter list /home/ben/src/php4-STABLE-200212111430/TSRM/tsrm_virtual_cwd.h:159: warning: its scope is only this definition or declaration, which is probably not what you want In file included from /home/ben/src/php4-STABLE-200212111430/ext/standard/php_standard.h:23, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:48: /home/ben/src/php4-STABLE-200212111430/ext/standard/php_string.h: In function `php_memnstr': /home/ben/src/php4-STABLE-200212111430/ext/standard/php_string.h:142: warning: assignment makes pointer from integer without a cast In file included from /home/ben/src/php4-STABLE-200212111430/ext/standard/fsock.h:38, from /home/ben/src/php4-STABLE-200212111430/ext/standard/php_standard.h:44, from /home/ben/src/php4-STABLE-200212111430/ext/zlib/zlib.c:48: /home/ben/src/php4-STABLE-200212111430/main/
#20939 [Fbk]: PHP stops executing script when using sax handlers
ID: 20939
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: XSLT related
Operating System: Debian GNU/Linux 2.4.19
PHP Version: 4.2.3
New Comment:
1) remove --with-sablot from your configure line.
2) If iconv is linked in with Sablotron, then use --with-iconv-dir as
well.
3) This is most likely fixed already as this loop is actually a
segfault. (see my mail)
Previous Comments:
[2002-12-11 10:19:38] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
I cannot replicate this problem with PHP 4.3.0 & Sablotron 0.96. If you
try the snapshot and still experience problems please include the
Sablotron version you are using in your report.
[2002-12-11 09:31:50] [EMAIL PROTECTED]
When using xslt_set_sax_handlers, php stops executing after
xslt_process. Below a script that should reproduce the problem (I
tested it on 2 servers to be sure):
array('start_element','end_element')));
$aryArg['xml']=implode("\n",file(dirname(__FILE__).'/test.xml'));
$aryArg['xsl']=implode("\n",file(dirname(__FILE__).'/test.xsl'));
$strHTML = xslt_process($resXSL,'arg:xml','arg:xsl',NULL,$aryArg);
xslt_free($resXSL);
echo $strHTML;
function start_element($resParser,$strName,$aryAttribs) {
echo 'Start of '.$strName;
}
function end_element($resParser,$strName) {
echo 'End of '.$strName;
}
?>
When this is executed there is no output, when I comment the line where
I use xslt_set_sax_handlers, it works fine (the html is shown). When I
enable xslt logging sablotron seems to be in an endless loop:
Sablotron Message on line none, level log: Parsing 'arg:/xsl'...
Sablotron Message on line none, level log: Parse done in 0.002 seconds
Sablotron Message on line none, level log: Parsing 'arg:/xml'...
Sablotron Message on line none, level log: Parse done in 0.000 seconds
Sablotron Message on line none, level log: Executing stylesheet
'arg:/xsl'...
These lines are printed into the logfile about let's say 30 times, the
first time the message
Sablotron Message on line none, level log: Execution done in 0.002
seconds
appears, the other let's say 29 times not.
When I comment the xslt_set_sax_handlers line the logfile only shows
the 5 lines mentioned before and also the 'Execution don in
seconds' line as you would expect
My guess is that sablotron is stuck in a loop...
PHP is compiled with: --with-dom --with-sablot --with-expat
-with-dom-xslt --with-dom-exslt --enable-xslt' --with-xslt-sablot
If you want to get the xml/xsl files I used, you can get them at
http://bruno.webfx.be/xslt_test/
Thanks in advance,
Bruno
--
Edit this bug report at http://bugs.php.net/?id=20939&edit=1
#20927 [Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2
ID: 20927 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: PostgreSQL related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 New Comment: More info: Under Solaris 8 on SPARC, Apache 1.3.27 and PHP 4.2.3, it works fine. Probably, Solaris's libc has different malloc strategy so the bug is not triggered. I recompiled Apache, PHP and libpq so everything was statically linked in a single http executable. Segfaulted. Ran it under valgrind (http://developer.kde.org/~sewardj/) and it worked perfectly. :-( Next, converted the script to a CGI, and installed stand-alone versions of php-4.2.3 and php-4.1.2. The cgi crashed with php-4.2.3, but worked fine with php-4.1.2. (Same Apache server in each case.) Therefore, I believe this is a hard-to-find memory corruption bug. :-( (To do the CGI test, copy showtrap.php to showtrap.cgi and add the appropriate #! line at the beginning, fix permissions, etc.) Previous Comments: [2002-12-11 10:36:28] [EMAIL PROTECTED] Hi, I've tried the following versions of libpq: 7.2.2 7.2.3 7.3.0 They all exhibit the same behaviour. The default version that comes with RH8.0 is 7.2.2. Thanks, David. [2002-12-11 10:35:04] [EMAIL PROTECTED] Uhmm I should read better... What versions of libpq do you use with 4.1.2 and 4.2.x? [2002-12-11 10:34:38] [EMAIL PROTECTED] Then how do you explain the crash in Apache 1.3.27? It is a PHP bug for sure, because changing PHP versions is the only thing which makes it go away. [2002-12-11 10:32:10] [EMAIL PROTECTED] It crashs with PHP 4.2.2 because it runs in Apache 2. The PSQL lib ist most probably not thread safe. [2002-12-11 09:55:43] [EMAIL PROTECTED] I disagree. The bug *IS* in PHP, not libpq. The reason I assert this is as follows: - I tried Apache 1.3.27, 2.0.40 and 2.0.43 with libraries from PostgreSQL 7.2.2, 7.2.3 and 7.3, and PHP 4.2.2, 4.2.3 and PHP 4.3.0RC2. ALL combinations crashed reliably. With PHP 4.1.2, I am *unable* to get a crash. Something in PHP is corrupting memory, and later on, malloc() is failing. I use the same libpq library with Perl and Tcl, and have never yet had a segfault. For more info, here's a stack trace for Red Hat 8.0 with Red Hat's version of Apache (2.0.40) and Red Hat's PHP (4.2.2). Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 8192 (LWP 3305)] 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 (gdb) bt #0 0x42073d65 in _int_malloc () from /lib/i686/libc.so.6 #1 0x42073155 in malloc () from /lib/i686/libc.so.6 #2 0x4051881b in completed.1 () from /etc/httpd/modules/libphp4.so #3 0x405c5cb1 in completed.1 () from /etc/httpd/modules/libphp4.so #4 0x405c5fe1 in completed.1 () from /etc/httpd/modules/libphp4.so #5 0x405c615e in completed.1 () from /etc/httpd/modules/libphp4.so #6 0x40522efc in completed.1 () from /etc/httpd/modules/libphp4.so #7 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #8 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #9 0x40522c6d in completed.1 () from /etc/httpd/modules/libphp4.so #10 0x4052f6b6 in completed.1 () from /etc/httpd/modules/libphp4.so #11 0x4053df7a in completed.1 () from /etc/httpd/modules/libphp4.so #12 0x4053a7bd in completed.1 () from /etc/httpd/modules/libphp4.so #13 0x0807169c in ap_pass_brigade () #14 0x08078e27 in default_handler () #15 0x08065bf5 in ap_run_handler () #16 0x0806620d in ap_invoke_handler () #17 0x080629c6 in ap_process_request () #18 0x0805e0ac in ap_process_http_connection () #19 0x0806f0d5 in ap_run_process_connection () #20 0x08064238 in child_main () #21 0x0806445a in make_child () #22 0x080644b6 in startup_children () #23 0x08064cdf in ap_mpm_run () #24 0x0806ac5f in main () #25 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 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/20927 -- Edit this bug report at http://bugs.php.net/?id=20927&edit=1
#20928 [Csd->Opn]: Static compile of PHP module with IBM DB2 doesn't work right with apache
ID: 20928 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: ODBC related Operating System: RH 7.2 PHP Version: 4.3.0RC2 New Comment: This is still broken, I used the PHP4.3.x_dev snapshot. Previous Comments: [2002-12-11 10:45:28] [EMAIL PROTECTED] Fixed in which snapshot release? Just tried 4.3.x-dev and it's still broken: ===> src/modules/php4 gcc -c -I../../os/unix -I../../include -O2 -march=i386 -mcpu=i686 -DLINUX=22 - I/usr/include/db1 -DMOD_SSL=208110 -DEAPI `../../apaci` -fpic -DSHARED_MODULE -D LINUX=22 -I/usr/include/db1 -DMOD_SSL=208110 -I/usr/src/redhat/BUILD/php4-STABL E-200212111430/main -I/usr/src/redhat/BUILD/php4-STABLE-200212111430/Zend -I/usr /src/redhat/BUILD/php4-STABLE-200212111430/TSRM -I/usr/src/redhat/BUILD/php4-STA BLE-200212111430 -I/usr/src/redhat/BUILD/php4-STABLE-200212111430/sapi/apache -I /usr/src/redhat/BUILD/php4-STABLE-200212111430/main -I/usr/src/redhat/BUILD/php4 -STABLE-200212111430/Zend -I/usr/src/redhat/BUILD/php4-STABLE-200212111430/TSRM mod_php4.c && mv mod_php4.o mod_php4.so-o rm -f libphp4.so gcc -shared -o libphp4.so mod_php4.so-o libmodphp4.a -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr/local/Informix/lib -Wl,-rpath,/usr/local/Informix/lib/esql -Wl,- rpath,/usr/src/redhat/BUILD/php4-STABLE-200212111430/ext/informix -rdynamic -L/ usr/local/lib -L/usr/local/Informix/lib -L/usr/local/Informix/lib/esql -L/usr/sr c/redhat/BUILD/php4-STABLE-200212111430/ext/informix -Lmodules/php4 -L../modules /php4 -L../../modules/php4 -lmodphp4 -L/home/db2inst1/lib -rdynamic -L/usr/lo cal/lib -L/usr/local/Informix/lib -L/usr/local/Informix/lib/esql -L/usr/src/redh at/BUILD/php4-STABLE-200212111430/ext/informix -ldb2 -lcrypto -lssl -lc-client -lifsql -lifasf -lifgen -lifos -lifgls -ldl -lcrypt -lphpifx -lifglx -lpdf -lz -lldap -llber -lcrypt -lpam -lfdftk -lz -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -lm -lcrypt -ldb1 -ldb -lexpat -ldl -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr /local/Informix/lib -Wl,-rpath,/usr/local/Informix/lib/esql -Wl,-rpath,/usr/src/ redhat/BUILD/php4-STABLE-200212111430/ext/informix -rdynamic -L/usr/local/lib - L/usr/local/Informix/lib -L/usr/local/Informix/lib/esql -L/usr/src/redhat/BUILD/ php4-STABLE-200212111430/ext/informix -Lmodules/php4 -L../modules/php4 -L../../m odules/php4 -lmodphp4 -L/home/db2inst1/lib -rdynamic -L/usr/local/lib -L/usr/ local/Informix/lib -L/usr/local/Informix/lib/esql -L/usr/src/redhat/BUILD/php4-S TABLE-200212111430/ext/informix -ldb2 -lcrypto -lssl -lc-client -lifsql -lifas f -lifgen -lifos -lifgls -ldl -lcrypt -lphpifx -lifglx -lpdf -lz -lldap -llber - lcrypt -lpam -lfdftk -lz -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -lm -lcrypt -ldb1 -ldb /usr/bin/ld: cannot find -ldb2 collect2: ld returned 1 exit status make[4]: *** [libphp4.so] Error 1 make[3]: *** [all] Error 1 make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/apache_1.3.26/src' make[1]: *** [build-std] Error 2 make[1]: Leaving directory `/usr/src/redhat/BUILD/apache_1.3.26' make: *** [build] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.86132 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.86132 (%build) [2002-12-11 02:42:30] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-12-11 01:22:06] [EMAIL PROTECTED] It got much further this time, but results are the same. Here is the paste of the last command and error: <=== src/modules/throttle ===> src/modules/php4 gcc -c -I../../os/unix -I../../include -O2 -march=i386 -mcpu=i686 -DLINUX=22 - I/usr/include/db1 -DMOD_SSL=208110 -DEAPI `../../apaci` -fpic -DSHARED_MODULE -D LINUX=22 -I/usr/include/db1 -DMOD_SSL=208110 -I/usr/src/redhat/BUILD/php4-20021 2110630/main -I/usr/src/redhat/BUILD/php4-200212110630/Zend -I/usr/src/redhat/BU ILD/php4-200212110630/TSRM -I/usr/src/redhat/BUILD/php4-200212110630 -I/usr/src/ redhat/BUILD/php4-200212110630/sapi/apache -I/usr/src/redhat/BUILD/php4-20021211 0630/main -I/usr/src/redhat/BUILD/php4-200212110630/Zend -I/usr/src/redhat/BUILD /php4-200212110630/TSRM mod_php4.c && mv mod_php4.o mod_php4.so-o
#20926 [Fbk]: libmcrypt error in configure
ID: 20926 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: mcrypt related Operating System: NetBSD-1.5.2 PHP Version: 4.3.0RC2 New Comment: The problem here is: --enable-shared=no in libmcrypt, but still there are lt_dl symbols in there. The lt_dl approach has never worked nicely - especially on BSD's and Derick is right, that the prefix does matter, even with --with-pic (use make DESTDIR=/pkg/libmcrypt-2.5.3 install for what I think you wanna do). The more recent versions, allow you to link in the encryptions in the shared lib, which is the approach I would recommend. Previous Comments: [2002-12-11 11:52:51] [EMAIL PROTECTED] I believe the pkg prefix might be the problem here. Why don't you just use "/usr/local" here? [2002-12-11 11:14:58] [EMAIL PROTECTED] Please ignore the /pkg settings. These packages get installed into /usr/local. configure for libmcrypt: ./configure --prefix=/pkg/libmcrypt-2.5.3 --enable-shared=no --with-pic configure for php: ./configure --prefix=/pkg/php-4.3.0rc2 --enable-shared=no --with-mysql=/pkg/mysql-3.23.46 --enable-discard-path --with-config-file-path=/pkg/php-4.3.0rc2/libdata/php-4.3.0rc2 --with-xml --with-imap-ssl=/devel/build/pine/pine-4.50/imap/ --libdir=/pkg/php-4.3.0rc2/libdata/php-4.3.0rc2 --with-openssl=/usr/local --with-ndbm --with-gd --with-jpeg-dir=/usr/local --with-mcrypt=/usr/local --with-zlib-dir=/usr/local --with-db autoconf (GNU Autoconf) 2.53 automake (GNU automake) 1.4 libmcrypt-2.5.3 mysql-3.23.46 openssl-0.9.6g gd-2.0.4 jpeg-6b zlib-1.1.4 [2002-12-11 11:02:53] [EMAIL PROTECTED] In order to reproduce it, I'd like to have: 1. The full configure line of libmcrypt 2. The full configure line for PHP 3. version numbers of autoconf and automake 4. version numbers of relevant libraries. regards, Derick [2002-12-11 10:59:43] [EMAIL PROTECTED] libtool --version ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) Yes, libmcrypt has been installed in /usr/local. [2002-12-11 10:55:44] [EMAIL PROTECTED] Oops! Which version of libtool are you using? And did you do a "make install" of libmcrypt? Derick 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/20926 -- Edit this bug report at http://bugs.php.net/?id=20926&edit=1
#20927 [Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2 (Actually, culprit is wordwrap)
ID: 20927 User updated by: [EMAIL PROTECTED] -Summary: Crash inside libpq (PQexec) with PHP > 4.1.2 Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: PostgreSQL related +Bug Type: Strings related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 New Comment: More insight, and something very useful: The bug is in the "wordwrap" function. Please see http://www.roaringpenguin.com/segfault2.tar.bz2 There are two PHP scripts: One crashes PHP when run from the command line, and the other works fine. The only difference between the two is a change in the argument to wordwrap(). Also, I ran valgrind on the standalone PHP executable, and here is its report. Hope all of this helps! Regards, David. ==7690== ERROR SUMMARY: 138 errors from 5 contexts (suppressed: 38 from 1) ==7690== ==7690== 1 errors in context 1 of 5: ==7690== Invalid write of size 1 ==7690==at 0x80FF654: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==Address 0x44DA1882 is 2 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 1 errors in context 2 of 5: ==7690== Invalid write of size 1 ==7690==at 0x4003C395: memcpy (vg_clientfuncs.c:503) ==7690==by 0x80FF64E: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==Address 0x44DA1881 is 1 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 1 errors in context 3 of 5: ==7690== Invalid write of size 1 ==7690==at 0x4003C36F: memcpy (vg_clientfuncs.c:496) ==7690==by 0x80FF711: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==Address 0x44DA1880 is 0 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 2 errors in context 4 of 5: ==7690== Invalid read of size 1 ==7690==at 0x80EE4ED: get_next_char (in /usr/bin/php) ==7690==by 0x80EDDAE: php_escape_html_entities (in /usr/bin/php) ==7690==by 0x80EE081: php_html_entities (in /usr/bin/php) ==7690==by 0x80EE1FE: zif_htmlentities (in /usr/bin/php) ==7690==Address 0x44DA1880 is 0 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 133 errors in context 5 of 5: ==7690== Conditional jump or move depends on uninitialised value(s) ==7690==at 0x420BD30B: (within /lib/i686/libc-2.2.93.so) ==7690==by 0x420C2DF5: (within /lib/i686/libc-2.2.93.so) ==7690==by 0x80FCD16: php_reg_replace (in /usr/bin/php) ==7690==by 0x80FD1A8: php_ereg_replace (in /usr/bin/php) --7690-- --7690-- supp: 38 elf_dynamic_do_rela.8/_dl_relocate_object_internal ==7690== ==7690== IN SUMMARY: 138 errors from 5 contexts (suppressed: 38 from 1) ==7690== ==7690== malloc/free: in use at exit: 161328 bytes in 4866 blocks. ==7690== malloc/free: 31375 allocs, 26509 frees, 3488507 bytes allocated. ==7690== For a detailed leak analysis, rerun with: --leak-check=yes ==7690== --7690-- lru: 502 epochs, 0 clearings. --7690-- translate: new 18262 (318370 -> 3436773), discard 3318 (51606 -> 539831). --7690-- dispatch: 2510 basic blocks, 504/89826 sched events, 32379 tt_fast misses. --7690-- reg-alloc: 5534 t-req-spill, 642096+38688 orig+spill uis, 91926 total-reg-r. --7690--sanity: 505 cheap, 21 expensive checks. Previous Comments: [2002-12-11 12:38:06] [EMAIL PROTECTED] More info: Under Solaris 8 on SPARC, Apache 1.3.27 and PHP 4.2.3, it works fine. Probably, Solaris's libc has different malloc strategy so the bug is not triggered. I recompiled Apache, PHP and libpq so everything was statically linked in a single http executable. Segfaulted. Ran it under valgrind (http://developer.kde.org/~sewardj/) and it worked perfectly. :-( Next, converted the scrip
#20926 [Fbk->Bgs]: libmcrypt error in configure
ID: 20926 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Bogus Bug Type: mcrypt related Operating System: NetBSD-1.5.2 PHP Version: 4.3.0RC2 New Comment: Right, not a PHP problem -> bogus. Previous Comments: [2002-12-11 12:50:22] [EMAIL PROTECTED] The problem here is: --enable-shared=no in libmcrypt, but still there are lt_dl symbols in there. The lt_dl approach has never worked nicely - especially on BSD's and Derick is right, that the prefix does matter, even with --with-pic (use make DESTDIR=/pkg/libmcrypt-2.5.3 install for what I think you wanna do). The more recent versions, allow you to link in the encryptions in the shared lib, which is the approach I would recommend. [2002-12-11 11:52:51] [EMAIL PROTECTED] I believe the pkg prefix might be the problem here. Why don't you just use "/usr/local" here? [2002-12-11 11:14:58] [EMAIL PROTECTED] Please ignore the /pkg settings. These packages get installed into /usr/local. configure for libmcrypt: ./configure --prefix=/pkg/libmcrypt-2.5.3 --enable-shared=no --with-pic configure for php: ./configure --prefix=/pkg/php-4.3.0rc2 --enable-shared=no --with-mysql=/pkg/mysql-3.23.46 --enable-discard-path --with-config-file-path=/pkg/php-4.3.0rc2/libdata/php-4.3.0rc2 --with-xml --with-imap-ssl=/devel/build/pine/pine-4.50/imap/ --libdir=/pkg/php-4.3.0rc2/libdata/php-4.3.0rc2 --with-openssl=/usr/local --with-ndbm --with-gd --with-jpeg-dir=/usr/local --with-mcrypt=/usr/local --with-zlib-dir=/usr/local --with-db autoconf (GNU Autoconf) 2.53 automake (GNU automake) 1.4 libmcrypt-2.5.3 mysql-3.23.46 openssl-0.9.6g gd-2.0.4 jpeg-6b zlib-1.1.4 [2002-12-11 11:02:53] [EMAIL PROTECTED] In order to reproduce it, I'd like to have: 1. The full configure line of libmcrypt 2. The full configure line for PHP 3. version numbers of autoconf and automake 4. version numbers of relevant libraries. regards, Derick [2002-12-11 10:59:43] [EMAIL PROTECTED] libtool --version ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) Yes, libmcrypt has been installed in /usr/local. 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/20926 -- Edit this bug report at http://bugs.php.net/?id=20926&edit=1
#20927 [Opn->Asn]: Crash inside libpq (PQexec) with PHP > 4.1.2 (Actually, culprit is wordwrap)
ID: 20927 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: Strings related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 -Assigned To: +Assigned To: derick Previous Comments: [2002-12-11 12:57:43] [EMAIL PROTECTED] More insight, and something very useful: The bug is in the "wordwrap" function. Please see http://www.roaringpenguin.com/segfault2.tar.bz2 There are two PHP scripts: One crashes PHP when run from the command line, and the other works fine. The only difference between the two is a change in the argument to wordwrap(). Also, I ran valgrind on the standalone PHP executable, and here is its report. Hope all of this helps! Regards, David. ==7690== ERROR SUMMARY: 138 errors from 5 contexts (suppressed: 38 from 1) ==7690== ==7690== 1 errors in context 1 of 5: ==7690== Invalid write of size 1 ==7690==at 0x80FF654: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==Address 0x44DA1882 is 2 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 1 errors in context 2 of 5: ==7690== Invalid write of size 1 ==7690==at 0x4003C395: memcpy (vg_clientfuncs.c:503) ==7690==by 0x80FF64E: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==Address 0x44DA1881 is 1 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 1 errors in context 3 of 5: ==7690== Invalid write of size 1 ==7690==at 0x4003C36F: memcpy (vg_clientfuncs.c:496) ==7690==by 0x80FF711: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==Address 0x44DA1880 is 0 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 2 errors in context 4 of 5: ==7690== Invalid read of size 1 ==7690==at 0x80EE4ED: get_next_char (in /usr/bin/php) ==7690==by 0x80EDDAE: php_escape_html_entities (in /usr/bin/php) ==7690==by 0x80EE081: php_html_entities (in /usr/bin/php) ==7690==by 0x80EE1FE: zif_htmlentities (in /usr/bin/php) ==7690==Address 0x44DA1880 is 0 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 133 errors in context 5 of 5: ==7690== Conditional jump or move depends on uninitialised value(s) ==7690==at 0x420BD30B: (within /lib/i686/libc-2.2.93.so) ==7690==by 0x420C2DF5: (within /lib/i686/libc-2.2.93.so) ==7690==by 0x80FCD16: php_reg_replace (in /usr/bin/php) ==7690==by 0x80FD1A8: php_ereg_replace (in /usr/bin/php) --7690-- --7690-- supp: 38 elf_dynamic_do_rela.8/_dl_relocate_object_internal ==7690== ==7690== IN SUMMARY: 138 errors from 5 contexts (suppressed: 38 from 1) ==7690== ==7690== malloc/free: in use at exit: 161328 bytes in 4866 blocks. ==7690== malloc/free: 31375 allocs, 26509 frees, 3488507 bytes allocated. ==7690== For a detailed leak analysis, rerun with: --leak-check=yes ==7690== --7690-- lru: 502 epochs, 0 clearings. --7690-- translate: new 18262 (318370 -> 3436773), discard 3318 (51606 -> 539831). --7690-- dispatch: 2510 basic blocks, 504/89826 sched events, 32379 tt_fast misses. --7690-- reg-alloc: 5534 t-req-spill, 642096+38688 orig+spill uis, 91926 total-reg-r. --7690--sanity: 505 cheap, 21 expensive checks. [2002-12-11 12:38:06] [EMAIL PROTECTED] More info: Under Solaris 8 on SPARC, Apache 1.3.27 and PHP 4.2.3, it works fine. Probably, Solaris's libc has different malloc strategy so the bug is not triggered. I recompiled Apache, PHP and libpq so everything was statically linked in a single http executable. Segfaulted. Ran it under valgrind (http://developer.kde
#20926 [Bgs->Opn]: libmcrypt error in configure
ID: 20926
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: mcrypt related
Operating System: NetBSD-1.5.2
PHP Version: 4.3.0RC2
New Comment:
Actually, the problem is here:
--- configure~ Wed Nov 27 15:02:21 2002
+++ configure Wed Dec 11 13:57:27 2002
@@ -47410,16 +47410,14 @@
save_old_LDFLAGS=$LDFLAGS
- LDFLAGS="
--L$MCRYPT_DIR/lib -lltdl
- $LDFLAGS"
+ LDFLAGS="$LDFLAGS"
echo "$as_me:$LINENO: checking for mcrypt_module_open in -lmcrypt"
>&5
echo $ECHO_N "checking for mcrypt_module_open in -lmcrypt... $ECHO_C"
>&6
if test "${ac_cv_lib_mcrypt_mcrypt_module_open+set}" = set; then
echo $ECHO_N "(cached) $ECHO_C" >&6
else
ac_check_lib_save_LIBS=$LIBS
-LIBS="-lmcrypt $LIBS"
+LIBS="-lmcrypt -lltdl $LIBS"
cat >conftest.$ac_ext <<_ACEOF
#line $LINENO "configure"
#include "confdefs.h"
Previous Comments:
[2002-12-11 12:59:36] [EMAIL PROTECTED]
Right, not a PHP problem -> bogus.
[2002-12-11 12:50:22] [EMAIL PROTECTED]
The problem here is:
--enable-shared=no
in libmcrypt, but still there are lt_dl symbols in there. The lt_dl
approach has never worked nicely - especially on BSD's and Derick is
right, that the prefix does matter, even with --with-pic (use make
DESTDIR=/pkg/libmcrypt-2.5.3 install for what I think you wanna do).
The more recent versions, allow you to link in the encryptions in the
shared lib, which is the approach I would recommend.
[2002-12-11 11:52:51] [EMAIL PROTECTED]
I believe the pkg prefix might be the problem here. Why don't you just
use "/usr/local" here?
[2002-12-11 11:14:58] [EMAIL PROTECTED]
Please ignore the /pkg settings. These packages get installed into
/usr/local.
configure for libmcrypt:
./configure --prefix=/pkg/libmcrypt-2.5.3 --enable-shared=no
--with-pic
configure for php:
./configure --prefix=/pkg/php-4.3.0rc2 --enable-shared=no
--with-mysql=/pkg/mysql-3.23.46 --enable-discard-path
--with-config-file-path=/pkg/php-4.3.0rc2/libdata/php-4.3.0rc2
--with-xml --with-imap-ssl=/devel/build/pine/pine-4.50/imap/
--libdir=/pkg/php-4.3.0rc2/libdata/php-4.3.0rc2
--with-openssl=/usr/local --with-ndbm --with-gd
--with-jpeg-dir=/usr/local --with-mcrypt=/usr/local
--with-zlib-dir=/usr/local --with-db
autoconf (GNU Autoconf) 2.53
automake (GNU automake) 1.4
libmcrypt-2.5.3
mysql-3.23.46
openssl-0.9.6g
gd-2.0.4
jpeg-6b
zlib-1.1.4
[2002-12-11 11:02:53] [EMAIL PROTECTED]
In order to reproduce it, I'd like to have:
1. The full configure line of libmcrypt
2. The full configure line for PHP
3. version numbers of autoconf and automake
4. version numbers of relevant libraries.
regards,
Derick
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/20926
--
Edit this bug report at http://bugs.php.net/?id=20926&edit=1
#20838 [Fbk->Opn]: Script hangs (endless loop) after shutdown
ID: 20838 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Output Control Operating System: Redhat Linux 7.1 PHP Version: 4.2.3 New Comment: Haven't had time to test against the latest, but I have a simple testcase: -- basically, any modification to the incoming data in-place, instead of copying to a new variable causes a hang. Previous Comments: [2002-12-05 15:29:54] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-05 15:22:41] [EMAIL PROTECTED] I think that Bug #11346 applies to 4.2.3 as well, and #17672 as well. I have a script using lots of output-buffer functions that seems to hang, eating 100% CPU, and occasionally truncates output. The error log shows: [Thu Dec 5 14:08:42 2002] [error] PHP Fatal error: Maximum execution time of 30 seconds exceeded in Unknown on line 0 for each process, and there are several HTTP processes running full-tilt, executing no system nor library calls. (strace and ltrace show nothing). Configure Command './configure' '--sysconfdir=/etc/httpd' '--with-mysql=/src/mysql/mysql-404-php' '--with-snmp' '--with-gd' '--with-jpeg-dir=/src/jpeg/jpeg-6b' '--with-png-dir=/src/png/libpng-1.0.12' '--with-zlib-dir=/src/zlib/zlib-1.1.3' '--with-gdbm' '--with-db3' '--enable-ftp' '--with-imap' '--enable-sockets' '--with-kerberos' '--with-imap-ssl' '--with-openssl' '--cache-file=/dev/null' '--with-apxs=/usr/local/apache/bin/apxs' '--with-xmlrpc' -- Edit this bug report at http://bugs.php.net/?id=20838&edit=1
#20926 [Opn->Fbk]: libmcrypt error in configure
ID: 20926
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: mcrypt related
Operating System: NetBSD-1.5.2
PHP Version: 4.3.0RC2
New Comment:
hmm, :-) Patching configure is of little use, it's generated from
config.m4 files. It would be nice if you could try to fix
ext/mcrypt/config.m4, but I doubt it's possible.
After you modify config.m4's dont forget to rm configure && ./buildconf
It works all fine here, so I cant really help you.
Derick
Previous Comments:
[2002-12-11 13:04:24] [EMAIL PROTECTED]
Actually, the problem is here:
--- configure~ Wed Nov 27 15:02:21 2002
+++ configure Wed Dec 11 13:57:27 2002
@@ -47410,16 +47410,14 @@
save_old_LDFLAGS=$LDFLAGS
- LDFLAGS="
--L$MCRYPT_DIR/lib -lltdl
- $LDFLAGS"
+ LDFLAGS="$LDFLAGS"
echo "$as_me:$LINENO: checking for mcrypt_module_open in -lmcrypt"
>&5
echo $ECHO_N "checking for mcrypt_module_open in -lmcrypt... $ECHO_C"
>&6
if test "${ac_cv_lib_mcrypt_mcrypt_module_open+set}" = set; then
echo $ECHO_N "(cached) $ECHO_C" >&6
else
ac_check_lib_save_LIBS=$LIBS
-LIBS="-lmcrypt $LIBS"
+LIBS="-lmcrypt -lltdl $LIBS"
cat >conftest.$ac_ext <<_ACEOF
#line $LINENO "configure"
#include "confdefs.h"
[2002-12-11 12:59:36] [EMAIL PROTECTED]
Right, not a PHP problem -> bogus.
[2002-12-11 12:50:22] [EMAIL PROTECTED]
The problem here is:
--enable-shared=no
in libmcrypt, but still there are lt_dl symbols in there. The lt_dl
approach has never worked nicely - especially on BSD's and Derick is
right, that the prefix does matter, even with --with-pic (use make
DESTDIR=/pkg/libmcrypt-2.5.3 install for what I think you wanna do).
The more recent versions, allow you to link in the encryptions in the
shared lib, which is the approach I would recommend.
[2002-12-11 11:52:51] [EMAIL PROTECTED]
I believe the pkg prefix might be the problem here. Why don't you just
use "/usr/local" here?
[2002-12-11 11:14:58] [EMAIL PROTECTED]
Please ignore the /pkg settings. These packages get installed into
/usr/local.
configure for libmcrypt:
./configure --prefix=/pkg/libmcrypt-2.5.3 --enable-shared=no
--with-pic
configure for php:
./configure --prefix=/pkg/php-4.3.0rc2 --enable-shared=no
--with-mysql=/pkg/mysql-3.23.46 --enable-discard-path
--with-config-file-path=/pkg/php-4.3.0rc2/libdata/php-4.3.0rc2
--with-xml --with-imap-ssl=/devel/build/pine/pine-4.50/imap/
--libdir=/pkg/php-4.3.0rc2/libdata/php-4.3.0rc2
--with-openssl=/usr/local --with-ndbm --with-gd
--with-jpeg-dir=/usr/local --with-mcrypt=/usr/local
--with-zlib-dir=/usr/local --with-db
autoconf (GNU Autoconf) 2.53
automake (GNU automake) 1.4
libmcrypt-2.5.3
mysql-3.23.46
openssl-0.9.6g
gd-2.0.4
jpeg-6b
zlib-1.1.4
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/20926
--
Edit this bug report at http://bugs.php.net/?id=20926&edit=1
#20942 [Bgs]: Activating extension : imap, stops Apache
ID: 20942 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Apache related Operating System: OpenBSD 3.2 PHP Version: 4.2.3 New Comment: That not the problem. c-client is installed. Here is my pkg_info: bash-2.05b-static GNU Bourne Again Shell libslang-1.4.5 stack-based interpreter for terminal applications jed-0.99.14text editor libiconv-1.8 character set conversion library gettext-0.10.40GNU gettext gmake-3.79.1 GNU make p5-DBI-1.30unified perl interface for database access mysql-client-3.23.49 multithreaded SQL database (client) p5-DBD-Msql-Mysql-1.22.19 MySQL drivers for the Perl DBI mysql-server-3.23.49 multithreaded SQL database (server) recode-3.6 convert files between character sets and usages php4-core-4.2.3server-side HTML-embedded scripting language c-client-4.44 University of Washington's c-client mail access routines php4-imap-4.2.3imap, pop3 and nntp extensions for php4 php4-mysql-4.2.3 mysql database access extensions for php4 php4-pear-4.2.3collection of base classes for common PHP tasks I am sorry to bother you if this is infact "bogus". Any other Ideas??? Previous Comments: [2002-12-11 11:58:49] [EMAIL PROTECTED] Sounds like a missing library on your system, you need to install c-client (part of Washington IMAP server). Not a bug in PHP -> bogus [2002-12-11 11:48:34] [EMAIL PROTECTED] This is a fresh install of OpenBSD 3.2 on an i386 type machine. qmail for SMTP and courier for IMAP and POP3 were added and tested. The mysql server package (from the CD)was also added. The goal is to use squirrelmail. I downloaded the following packages from the Openbsd site for OpenBSD 3.2: php4-core-4.2.3.tgz php4-mysql-4.2.3.tgz php4-imap-4.2.3.tgz php4-pear-4.2.3.tgz I followed the instructions at: http://php3.de/manual/en/install.openbsd.php I edited my httpd.conf to show: DirectoryIndex index.php index.html and AddType application/x-httpd-php .php Apache will not start unless I disable the imap extension. My Apache error log shows: usr/libexec/ld.so: httpd: libc-client.so.4.0: Invalid argument help??? [2002-12-11 10:56:41] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2002-12-11 10:53:10] [EMAIL PROTECTED] Apache works with PHP until I do: pkg_add php4-imap-4.2.3.tg /usr/local/sbin/phpxs -a imap Then: apachectl start /usr/sbin/apachectl start: httpd could not be started My /var/www/logs/error_log shows: /usr/libexec/ld.so: httpd: libc-client.so.4.0: Invalid argument If I do: /usr/local/sbin/phpxs -r imap Apache then works again. I'm new at this. Any help would be great... Thanks, Dave Miller -- Edit this bug report at http://bugs.php.net/?id=20942&edit=1
#20942 [Bgs]: Activating extension : imap, stops Apache
ID: 20942 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Apache related Operating System: OpenBSD 3.2 PHP Version: 4.2.3 New Comment: Please compile PHP yourself; we can't support Vendor binaries. You can get a snapshot from http://snaps.php.net Derick Previous Comments: [2002-12-11 13:14:13] [EMAIL PROTECTED] That not the problem. c-client is installed. Here is my pkg_info: bash-2.05b-static GNU Bourne Again Shell libslang-1.4.5 stack-based interpreter for terminal applications jed-0.99.14text editor libiconv-1.8 character set conversion library gettext-0.10.40GNU gettext gmake-3.79.1 GNU make p5-DBI-1.30unified perl interface for database access mysql-client-3.23.49 multithreaded SQL database (client) p5-DBD-Msql-Mysql-1.22.19 MySQL drivers for the Perl DBI mysql-server-3.23.49 multithreaded SQL database (server) recode-3.6 convert files between character sets and usages php4-core-4.2.3server-side HTML-embedded scripting language c-client-4.44 University of Washington's c-client mail access routines php4-imap-4.2.3imap, pop3 and nntp extensions for php4 php4-mysql-4.2.3 mysql database access extensions for php4 php4-pear-4.2.3collection of base classes for common PHP tasks I am sorry to bother you if this is infact "bogus". Any other Ideas??? [2002-12-11 11:58:49] [EMAIL PROTECTED] Sounds like a missing library on your system, you need to install c-client (part of Washington IMAP server). Not a bug in PHP -> bogus [2002-12-11 11:48:34] [EMAIL PROTECTED] This is a fresh install of OpenBSD 3.2 on an i386 type machine. qmail for SMTP and courier for IMAP and POP3 were added and tested. The mysql server package (from the CD)was also added. The goal is to use squirrelmail. I downloaded the following packages from the Openbsd site for OpenBSD 3.2: php4-core-4.2.3.tgz php4-mysql-4.2.3.tgz php4-imap-4.2.3.tgz php4-pear-4.2.3.tgz I followed the instructions at: http://php3.de/manual/en/install.openbsd.php I edited my httpd.conf to show: DirectoryIndex index.php index.html and AddType application/x-httpd-php .php Apache will not start unless I disable the imap extension. My Apache error log shows: usr/libexec/ld.so: httpd: libc-client.so.4.0: Invalid argument help??? [2002-12-11 10:56:41] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2002-12-11 10:53:10] [EMAIL PROTECTED] Apache works with PHP until I do: pkg_add php4-imap-4.2.3.tg /usr/local/sbin/phpxs -a imap Then: apachectl start /usr/sbin/apachectl start: httpd could not be started My /var/www/logs/error_log shows: /usr/libexec/ld.so: httpd: libc-client.so.4.0: Invalid argument If I do: /usr/local/sbin/phpxs -r imap Apache then works again. I'm new at this. Any help would be great... Thanks, Dave Miller -- Edit this bug report at http://bugs.php.net/?id=20942&edit=1
#20927 [Asn->Fbk]: Crash inside libpq (PQexec) with PHP > 4.1.2 (Actually, culprit is wordwrap)
ID: 20927 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Feedback Bug Type: Strings related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 Assigned To: derick New Comment: It would really help me if you could give me the parameters to wordwrap on which you get this error, I dont have postgres here so I can't try your script. Derick Previous Comments: [2002-12-11 12:57:43] [EMAIL PROTECTED] More insight, and something very useful: The bug is in the "wordwrap" function. Please see http://www.roaringpenguin.com/segfault2.tar.bz2 There are two PHP scripts: One crashes PHP when run from the command line, and the other works fine. The only difference between the two is a change in the argument to wordwrap(). Also, I ran valgrind on the standalone PHP executable, and here is its report. Hope all of this helps! Regards, David. ==7690== ERROR SUMMARY: 138 errors from 5 contexts (suppressed: 38 from 1) ==7690== ==7690== 1 errors in context 1 of 5: ==7690== Invalid write of size 1 ==7690==at 0x80FF654: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==Address 0x44DA1882 is 2 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 1 errors in context 2 of 5: ==7690== Invalid write of size 1 ==7690==at 0x4003C395: memcpy (vg_clientfuncs.c:503) ==7690==by 0x80FF64E: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==Address 0x44DA1881 is 1 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 1 errors in context 3 of 5: ==7690== Invalid write of size 1 ==7690==at 0x4003C36F: memcpy (vg_clientfuncs.c:496) ==7690==by 0x80FF711: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==Address 0x44DA1880 is 0 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 2 errors in context 4 of 5: ==7690== Invalid read of size 1 ==7690==at 0x80EE4ED: get_next_char (in /usr/bin/php) ==7690==by 0x80EDDAE: php_escape_html_entities (in /usr/bin/php) ==7690==by 0x80EE081: php_html_entities (in /usr/bin/php) ==7690==by 0x80EE1FE: zif_htmlentities (in /usr/bin/php) ==7690==Address 0x44DA1880 is 0 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 133 errors in context 5 of 5: ==7690== Conditional jump or move depends on uninitialised value(s) ==7690==at 0x420BD30B: (within /lib/i686/libc-2.2.93.so) ==7690==by 0x420C2DF5: (within /lib/i686/libc-2.2.93.so) ==7690==by 0x80FCD16: php_reg_replace (in /usr/bin/php) ==7690==by 0x80FD1A8: php_ereg_replace (in /usr/bin/php) --7690-- --7690-- supp: 38 elf_dynamic_do_rela.8/_dl_relocate_object_internal ==7690== ==7690== IN SUMMARY: 138 errors from 5 contexts (suppressed: 38 from 1) ==7690== ==7690== malloc/free: in use at exit: 161328 bytes in 4866 blocks. ==7690== malloc/free: 31375 allocs, 26509 frees, 3488507 bytes allocated. ==7690== For a detailed leak analysis, rerun with: --leak-check=yes ==7690== --7690-- lru: 502 epochs, 0 clearings. --7690-- translate: new 18262 (318370 -> 3436773), discard 3318 (51606 -> 539831). --7690-- dispatch: 2510 basic blocks, 504/89826 sched events, 32379 tt_fast misses. --7690-- reg-alloc: 5534 t-req-spill, 642096+38688 orig+spill uis, 91926 total-reg-r. --7690--sanity: 505 cheap, 21 expensive checks. [2002-12-11 12:38:06] [EMAIL PROTECTED] More info: Under Solaris 8 on SPARC, Apache 1.3.27 and PHP 4.2.3, it works fine. Probably, Solaris's libc has different malloc strategy so the bug is not trigger
#20927 [Fbk->Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2 (Actually, culprit is wordwrap)
ID: 20927 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Strings related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 Assigned To: derick New Comment: The word wrap parameters are in the tar file on my Web site. I do not know how you will duplicate the problem unless you have PostgreSQL. Anyway, the script which segfaults: $str = htmlentities(wordwrap($str, 20, "CANITBREAKFOO", 1)); The one which works OK: $str = htmlentities(wordwrap($str, 21, "CANITBREAKFOO", 1)); In both cases, the original value of $str is as follows: "ADV:CLAIM YOUR FORTUNE NOW !!MAKE xxHUNDREDS OF THOUSANDS" On one line (total 77 characters in length.) Previous Comments: [2002-12-11 13:24:41] [EMAIL PROTECTED] It would really help me if you could give me the parameters to wordwrap on which you get this error, I dont have postgres here so I can't try your script. Derick [2002-12-11 12:57:43] [EMAIL PROTECTED] More insight, and something very useful: The bug is in the "wordwrap" function. Please see http://www.roaringpenguin.com/segfault2.tar.bz2 There are two PHP scripts: One crashes PHP when run from the command line, and the other works fine. The only difference between the two is a change in the argument to wordwrap(). Also, I ran valgrind on the standalone PHP executable, and here is its report. Hope all of this helps! Regards, David. ==7690== ERROR SUMMARY: 138 errors from 5 contexts (suppressed: 38 from 1) ==7690== ==7690== 1 errors in context 1 of 5: ==7690== Invalid write of size 1 ==7690==at 0x80FF654: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==Address 0x44DA1882 is 2 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 1 errors in context 2 of 5: ==7690== Invalid write of size 1 ==7690==at 0x4003C395: memcpy (vg_clientfuncs.c:503) ==7690==by 0x80FF64E: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==Address 0x44DA1881 is 1 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 1 errors in context 3 of 5: ==7690== Invalid write of size 1 ==7690==at 0x4003C36F: memcpy (vg_clientfuncs.c:496) ==7690==by 0x80FF711: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==Address 0x44DA1880 is 0 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 2 errors in context 4 of 5: ==7690== Invalid read of size 1 ==7690==at 0x80EE4ED: get_next_char (in /usr/bin/php) ==7690==by 0x80EDDAE: php_escape_html_entities (in /usr/bin/php) ==7690==by 0x80EE081: php_html_entities (in /usr/bin/php) ==7690==by 0x80EE1FE: zif_htmlentities (in /usr/bin/php) ==7690==Address 0x44DA1880 is 0 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 133 errors in context 5 of 5: ==7690== Conditional jump or move depends on uninitialised value(s) ==7690==at 0x420BD30B: (within /lib/i686/libc-2.2.93.so) ==7690==by 0x420C2DF5: (within /lib/i686/libc-2.2.93.so) ==7690==by 0x80FCD16: php_reg_replace (in /usr/bin/php) ==7690==by 0x80FD1A8: php_ereg_replace (in /usr/bin/php) --7690-- --7690-- supp: 38 elf_dynamic_do_rela.8/_dl_relocate_object_internal ==7690== ==7690== IN SUMMARY: 138 errors from 5 contexts (suppressed: 38 from 1) ==7690== ==7690== malloc/free: in use at exit: 161328 bytes in 4866 blocks. ==7690== malloc/free: 31375 allocs, 26509 frees, 3488507 bytes allocated. ==7690== For a detailed leak analysis, rerun with: --leak-check=yes ==7690== --76
#19958 [NoF->Bgs]: lisablot.so.96: libsablot.so.96: Undefined symbol "__pure_virtual"
ID: 19958 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Bogus Bug Type: XSLT related Operating System: FreeBSD 4.2-RC1 PHP Version: 4.2.3 New Comment: I cannot conclude otherwise, that this is a problem with libtool. You're also running an RC of an OS, that is already at 4.7 (and upgrading to that version, solves a lot of problems, not only in the gcc area). IIC - this is - if anything - a libtool problem - not a php problem. Previous Comments: [2002-11-11 03:00:59] [EMAIL PROTECTED] Hi! I'm build PHP Version 4.3.0-dev. Finally I get same results. Now, I'm solve problem by build PHP as CGI application. Working fine! But configuration as apache-module still actual. My phpinfo: == System FreeBSD stweb.intranet 4.2-RC1 FreeBSD 4.2-RC1 #0: Wed Nov 8 i386 Build Date Oct 21 2002 09:36:08 Configure Command './configure' '--enable-force-cgi-redirect' '--enable-user-dir' '--with-mysql' '--with-zlib' '--enable-wddx' '--with-iconv=/usr/local/libiconv' '--with-iconv-dir=/usr/local/libiconv' '--with-xml' '--with-expat-dir=/usr/local/expat' '--enable-xslt' '--with-xslt-sablot=/usr/local/sablot' Server API CGI Virtual Directory Support disabled Configuration File (php.ini) Path /usr/local/lib/php.ini PHP API 20020307 PHP Extension 20020429 Zend Extension 20021010 Debug Build no Thread Safety disabled Registered PHP Streams php, http, ftp, compress.zlib xslt XSLT support enabled Backend Sablotron Sablotron Version 0.96 xml XML Support active XML Namespace Support active EXPAT Version expat_1.95.5 == regards, Sergei [2002-11-10 18:22:19] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2002-10-26 12:08:34] [EMAIL PROTECTED] Did the snapshot fix the problem? If not, can you paste the final line of the compilation process for php - especially if -lstdc++ is in there? recategorized [2002-10-17 12:32:44] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-17 11:15:52] [EMAIL PROTECTED] Hi! Problem for building Expat+Sablotron with PHP and Apache. My configuration: FreeBSD 4.2-RC1 apache_1.3.27 ./configure --enable-module=rewrite --prefix=/usr/local/apache --enable-module=so libiconv-1.8 ./configure prefix=/usr/local/libiconv expat-1.95.5 ./configure prefix=/usr/local/expat make buildlibmake installlib Sablot-0.96 with Sablot-0.96.1.patch ./configure --prefix=/usr/local/sablot \ --with-expat-prefix=/usr/local/expat --with-iconv-prefix=/usr/local/libiconv php-4.2.3 rm config.cache ./configure \ --with-mysql --with-apxs=/usr/local/apache/bin/apxs --with-zlib --enable-wddx \ --with-iconv=/usr/local/libiconv --with-iconv-dir=/usr/local/libiconv \ --with-expat-dir=/usr/local/expat --with-xslt --with-xslt-sablot=/usr/local/sablot For this config examples for test xslt-sablot not working. I get messages like this: Fatal error: Call to undefined function: xslt_create() in /wwwroot/home/xslt_transform/class.xslt.php on line 82 IF I add to this config key --enable-xslt, when re-starting web-server I get message like this: Syntax error on line 205 of /usr/local/apache/conf/httpd.conf: Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/sablot/lib/libsablot.so.96: Undefined symbol "__pure_virtual" /usr/local/apache/bin/apachectl start: httpd could not be started Who know how solve this problem, please? regards, Sergei -- Edit this bug report at http://bugs.php.net/?id=19958&edit=1
#16484 [NoF->Bgs]: segmentation fault
ID: 16484 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Bogus Bug Type: XSLT related Operating System: linux PHP Version: 4.1.2 New Comment: All support, old version, no follow up -> bogus Previous Comments: [2002-08-18 01:00:10] [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-08 06:14:56] [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-04-08 02:33:50] [EMAIL PROTECTED] I have segmentation fault on my apache child wich appears randomly. I have try to compile with a lot of version of php, apache, sablot and expat but the crash is always here. I have try to install php with sablot, expat and there is no pb during compilation. but always exit signal segmentation fault in my apache log. I have try --enable-rule=EXPAT=/dir_of_mylibexpat , or --disable-rule=EXPAT but always the problem. Please help me. Do you think a linux lib can be the problem? isthe memory limit configuration option with php can be important? Have I to compile expat and sablot with option? Have I to you papache with apxs? Sébastien [EMAIL PROTECTED] -- Edit this bug report at http://bugs.php.net/?id=16484&edit=1
#20274 [Com]: failed to create stream: Too many open files in Unknown on line
ID: 20274 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: iPlanet related Operating System: Solaris 8 PHP Version: 4CVS-2002-11-06 New Comment: I get the same error message "failed to create stream: Too many open files in Unknown on line 0" and "for inclusion (include_path='.:/usr/local/lib/php') in Unknown on line 0" I have php4.3.0RC2 and iplanet6 SP5. I opened the bug #20653. I was told to compile the latest php on my system and you send me php4.4.0-Dev. But I did not wanted to put Dev on the production box so I downloaded php4.3.0rc2 off of php.net site and installed it on my test box. I tested it for 10 days it worked fine. But now that I compiled the same thing on the production box I get the above error messages. What should I do? Previous Comments: [2002-12-01 04:43:02] [EMAIL PROTECTED] [EMAIL PROTECTED]: Can you try increasing your kernel file descriptor limit (Try doubling it)? (Don't ask me how; I don't have Solaris). It's possible that PHP just uses more files concurrently than it used to, however, it could also be a leak. [2002-11-30 18:04:12] [EMAIL PROTECTED] P.S. was able to correct the make issue with 4.2.3 with correct nsapi include path. [2002-11-30 17:44:25] [EMAIL PROTECTED] Hello all, I am experiencing nearly the same issue. This seems to happen randomly and is temporarily cleared by a webserver reboot. Here is what the browser sees; --- Begin browser output--- Warning: Unknown(/www/whitepine/htdocs/webmail/src/login.php): failed to create stream: Too many open files in Unknown on line 0 Warning: Failed opening '/www/whitepine/htdocs/webmail/src/login.php' for inclusion (include_path='.:/usr/local/lib/php') in Unknown on line 0 --- End browser output--- I'm on Solaris 9, Ultra 1. I'm using PHP 4.3.0ORC2 (installed fine); - Because 4.1.1 is old and crashes the server when php gets executed. (nasty errors in the iplanet6 server log) - And because 4.2.3 won't compile correctly for me. I get this error when trying to 'make' after a configure (my configure options for all 3 versions are below). ---Begin make output--- Making all in nsapi /bin/sh /dist/web/php/php-4.2.3/libtool --silent --mode=compile gcc -I. -I/dist/web/php/php-4.2.3/sapi/nsapi -I/dist/web/php/php-4.2.3/main -I/dist/web/php/php-4.2.3 -I/includ e -I/dist/web/php/php-4.2.3/Zend -I/opt/sfw/mysql/include/mysql -I/dist/web/php/php-4.2. 3/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -I/d ist/web/php/php-4.2.3/TSRM -g -O2 -pthreads -DZTS -prefer-pic -c nsapi.c nsapi.c:50: nsapi.h: No such file or directory nsapi.c:51: base/pblock.h: No such file or directory nsapi.c:52: base/session.h: No such file or directory nsapi.c:53: frame/req.h: No such file or directory nsapi.c:54: frame/protocol.h: No such file or directory nsapi.c:55: base/util.h: No such file or directory nsapi.c:56: frame/log.h: No such file or directory *** Error code 1 make: Fatal error: Command failed for target `nsapi.lo' Current working directory /dist/web/php/php-4.2.3/sapi/nsapi *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /dist/web/php/php-4.2.3/sapi/nsapi *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /dist/web/php/php-4.2.3/sapi *** Error code 1 make: Fatal error: Command failed for target `all-recursive' ---End make output--- --with-mysql=/opt/sfw/mysql --with-nsapi=/opt/iplanet/servers --enable-track-vars --enable-libgcc --with-gettext I'm also using gcc 2.95.3 if this helps. I'm also running Iplanet6 sp4 Does anybody have any ideas? ~Nate [2002-11-22 03:38:24] [EMAIL PROTECTED] We can't fix without more info/access to this platform. Can you try increasing your kernel file descriptor limit? If that does not work, we'll need some kind of strace output to see what is going on. [2002-11-21 17:47:55] [EMAIL PROTECTED] [EMAIL PROTECTED] might have the solution... I was forced to fall back on a previous build and not able to persue the problem further. 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/20274 -- Edit this bug report at http://bugs.php.net/?id=20274&edit=1
#20927 [Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2 (Actually, culprit is wordwrap)
ID: 20927 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Strings related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 Assigned To: derick New Comment: Scripts which duplicate the problem without PostgreSQL: This script crashes PHP 4.2.2 from Red Hat: This script works just fine: Previous Comments: [2002-12-11 13:31:49] [EMAIL PROTECTED] The word wrap parameters are in the tar file on my Web site. I do not know how you will duplicate the problem unless you have PostgreSQL. Anyway, the script which segfaults: $str = htmlentities(wordwrap($str, 20, "CANITBREAKFOO", 1)); The one which works OK: $str = htmlentities(wordwrap($str, 21, "CANITBREAKFOO", 1)); In both cases, the original value of $str is as follows: "ADV:CLAIM YOUR FORTUNE NOW !!MAKE xxHUNDREDS OF THOUSANDS" On one line (total 77 characters in length.) [2002-12-11 13:24:41] [EMAIL PROTECTED] It would really help me if you could give me the parameters to wordwrap on which you get this error, I dont have postgres here so I can't try your script. Derick [2002-12-11 12:57:43] [EMAIL PROTECTED] More insight, and something very useful: The bug is in the "wordwrap" function. Please see http://www.roaringpenguin.com/segfault2.tar.bz2 There are two PHP scripts: One crashes PHP when run from the command line, and the other works fine. The only difference between the two is a change in the argument to wordwrap(). Also, I ran valgrind on the standalone PHP executable, and here is its report. Hope all of this helps! Regards, David. ==7690== ERROR SUMMARY: 138 errors from 5 contexts (suppressed: 38 from 1) ==7690== ==7690== 1 errors in context 1 of 5: ==7690== Invalid write of size 1 ==7690==at 0x80FF654: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==Address 0x44DA1882 is 2 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 1 errors in context 2 of 5: ==7690== Invalid write of size 1 ==7690==at 0x4003C395: memcpy (vg_clientfuncs.c:503) ==7690==by 0x80FF64E: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==Address 0x44DA1881 is 1 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 1 errors in context 3 of 5: ==7690== Invalid write of size 1 ==7690==at 0x4003C36F: memcpy (vg_clientfuncs.c:496) ==7690==by 0x80FF711: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==Address 0x44DA1880 is 0 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 2 errors in context 4 of 5: ==7690== Invalid read of size 1 ==7690==at 0x80EE4ED: get_next_char (in /usr/bin/php) ==7690==by 0x80EDDAE: php_escape_html_entities (in /usr/bin/php) ==7690==by 0x80EE081: php_html_entities (in /usr/bin/php) ==7690==by 0x80EE1FE: zif_htmlentities (in /usr/bin/php) ==7690==Address 0x44DA1880 is 0 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 133 errors in context 5 of 5: ==7690== Conditional jump or move depends on uninitialised value(s) ==7690==at 0x420BD30B: (within /lib/i686/libc-2.2.93.so) ==7690==by 0x420C2DF5: (within /lib/i686/libc-2.2.93.so) ==7690==by 0x80FCD16: php_reg_replace (in /usr/bin/php) ==7690==by 0x80FD1A8: php_ereg_replace (in /usr/bin/php) --7690-- --7690-- supp: 38 elf_dynamic_do_rela.8/_dl_relocate_object_internal ==7690== ==7690== IN SUMMARY: 138 errors from 5 contexts (suppressed: 38 from 1) ==7690==
#20653 [NoF->Opn]: It works for a short time and then gives warning message
ID: 20653 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Open Bug Type: iPlanet related Operating System: solaris 8 PHP Version: 4.2.2 New Comment: I upgrated my php to 4.3.0RC2. I am getting the following error message know: failed to create stream: Too many open files in Unknown on line 0 Also the sendmail Path is not set not either. This was not a problem in older version of php (like 4.0.4pl1) Thanks Previous Comments: [2002-12-06 19:16:09] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2002-11-26 20:36:27] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-26 11:04:33] [EMAIL PROTECTED] We have sunone-iplanet webserver 6.0 sp4 and php 4.2.2 on our solaris 8 box. the php files come up for maybe half a day and after that we get warning messages like this one: Warning: Failed opening '/raid/www/docs/undserves/cdisplay.php' for inclusion (include_path='.:/usr/local/lib/php') in Unknown on line 0 The problem it intermittend. some time after reloding the file the warning goes away but it shows up next time we go to page. We just upgraded iplanet 4.1 to sunone-iplanet 6.0sp4 and also our php4.0.4pl1 to php4.2.2 Is this a bug or I am missing a step? I just thought of some thing! do you think I need to delete the /usr/local/php directory before compiling and installing the new version of php? thanks, -- Edit this bug report at http://bugs.php.net/?id=20653&edit=1
#20927 [Opn->Csd]: Crash inside libpq (PQexec) with PHP > 4.1.2 (Actually, culprit is wordwrap)
ID: 20927 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Strings related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 Assigned To: derick New Comment: ARGH! Why did you fill in 4.3.0RC2 as version number if you're talking about PHP 4.2.2? You just wasted my time trying to hunt down a bug that's already fixed. Indeed, this crashes with PHP 4.2.2 but not with 4.3.0RC2 and RC3. Derick Previous Comments: [2002-12-11 13:58:46] [EMAIL PROTECTED] Scripts which duplicate the problem without PostgreSQL: This script crashes PHP 4.2.2 from Red Hat: This script works just fine: [2002-12-11 13:31:49] [EMAIL PROTECTED] The word wrap parameters are in the tar file on my Web site. I do not know how you will duplicate the problem unless you have PostgreSQL. Anyway, the script which segfaults: $str = htmlentities(wordwrap($str, 20, "CANITBREAKFOO", 1)); The one which works OK: $str = htmlentities(wordwrap($str, 21, "CANITBREAKFOO", 1)); In both cases, the original value of $str is as follows: "ADV:CLAIM YOUR FORTUNE NOW !!MAKE xxHUNDREDS OF THOUSANDS" On one line (total 77 characters in length.) [2002-12-11 13:24:41] [EMAIL PROTECTED] It would really help me if you could give me the parameters to wordwrap on which you get this error, I dont have postgres here so I can't try your script. Derick [2002-12-11 12:57:43] [EMAIL PROTECTED] More insight, and something very useful: The bug is in the "wordwrap" function. Please see http://www.roaringpenguin.com/segfault2.tar.bz2 There are two PHP scripts: One crashes PHP when run from the command line, and the other works fine. The only difference between the two is a change in the argument to wordwrap(). Also, I ran valgrind on the standalone PHP executable, and here is its report. Hope all of this helps! Regards, David. ==7690== ERROR SUMMARY: 138 errors from 5 contexts (suppressed: 38 from 1) ==7690== ==7690== 1 errors in context 1 of 5: ==7690== Invalid write of size 1 ==7690==at 0x80FF654: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==Address 0x44DA1882 is 2 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 1 errors in context 2 of 5: ==7690== Invalid write of size 1 ==7690==at 0x4003C395: memcpy (vg_clientfuncs.c:503) ==7690==by 0x80FF64E: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==Address 0x44DA1881 is 1 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 1 errors in context 3 of 5: ==7690== Invalid write of size 1 ==7690==at 0x4003C36F: memcpy (vg_clientfuncs.c:496) ==7690==by 0x80FF711: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==Address 0x44DA1880 is 0 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 2 errors in context 4 of 5: ==7690== Invalid read of size 1 ==7690==at 0x80EE4ED: get_next_char (in /usr/bin/php) ==7690==by 0x80EDDAE: php_escape_html_entities (in /usr/bin/php) ==7690==by 0x80EE081: php_html_entities (in /usr/bin/php) ==7690==by 0x80EE1FE: zif_htmlentities (in /usr/bin/php) ==7690==Address 0x44DA1880 is 0 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 133 errors in context 5 of 5: ==7690== Conditional jump or move depends on uninitialised value(s) ==7690==at 0x420BD30B: (within /lib/
#20944 [NEW]: external gd dies with compile
From: [EMAIL PROTECTED] Operating system: FreeeBSD 4.7-RELEASE PHP version: 4CVS-2002-12-11 (dev) PHP Bug Type: Compile Failure Bug description: external gd dies with compile I am trying to use gd-2.0.1 with php and I get the following compile error: r-pic -c /home/matt/src/php4/ext/gd/gd.c -o ext/gd/gd.lo /home/matt/src/php4/ext/gd/gd.c: In function `_php_image_create_from': /home/matt/src/php4/ext/gd/gd.c:1445: warning: assignment makes pointer from integer without a cast /home/matt/src/php4/ext/gd/gd.c: In function `zif_imagecreatefromxpm': /home/matt/src/php4/ext/gd/gd.c:1515: `gdImageCreateFromXpm' undeclared (first use in this function) /home/matt/src/php4/ext/gd/gd.c:1515: (Each undeclared identifier is reported only once /home/matt/src/php4/ext/gd/gd.c:1515: for each function it appears in.) *** Error code 1 Stop in /home/matt/src/php4. Please note that this error does not occur with the builtin gd (the builtin was giving me a signal 10 while using jpgraph so I am trying the external). RC2 does not give this error in either. -- Edit bug report at http://bugs.php.net/?id=20944&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20944&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20944&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20944&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20944&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20944&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20944&r=support Expected behavior: http://bugs.php.net/fix.php?id=20944&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20944&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20944&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20944&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20944&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20944&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20944&r=isapi
#20927 [Csd->Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2 (Actually, culprit is wordwrap)
ID: 20927 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: Strings related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 Assigned To: derick New Comment: It DOES crash with 4.30RC2: I built 4.30RC2 with this configuration: ./configure --with-pgsql=shared \ --with-gnu-ld \ --with-apxs=/usr/local/apache/bin/apxs I then installed it and ran the command-line version: $ /usr/local/bin/php -v PHP 4.3.0RC2 (cli) (built: Dec 10 2002 19:58:29) Copyright (c) 1997-2002 The PHP Group Zend Engine v1.4.0, Copyright (c) 1998-2002 Zend Technologies $ /usr/local/bin/php test-wrap.php Segmentation fault $ /usr/local/bin/php test-wrap2.php (no output, but no segfault) Please don't accuse me of wasting your time without reading ALL of my comments... I said that 4.2.2, 4.2.3 and 4.3.0RC2 behave the same. -- David. Previous Comments: [2002-12-11 14:06:24] [EMAIL PROTECTED] ARGH! Why did you fill in 4.3.0RC2 as version number if you're talking about PHP 4.2.2? You just wasted my time trying to hunt down a bug that's already fixed. Indeed, this crashes with PHP 4.2.2 but not with 4.3.0RC2 and RC3. Derick [2002-12-11 13:58:46] [EMAIL PROTECTED] Scripts which duplicate the problem without PostgreSQL: This script crashes PHP 4.2.2 from Red Hat: This script works just fine: [2002-12-11 13:31:49] [EMAIL PROTECTED] The word wrap parameters are in the tar file on my Web site. I do not know how you will duplicate the problem unless you have PostgreSQL. Anyway, the script which segfaults: $str = htmlentities(wordwrap($str, 20, "CANITBREAKFOO", 1)); The one which works OK: $str = htmlentities(wordwrap($str, 21, "CANITBREAKFOO", 1)); In both cases, the original value of $str is as follows: "ADV:CLAIM YOUR FORTUNE NOW !!MAKE xxHUNDREDS OF THOUSANDS" On one line (total 77 characters in length.) [2002-12-11 13:24:41] [EMAIL PROTECTED] It would really help me if you could give me the parameters to wordwrap on which you get this error, I dont have postgres here so I can't try your script. Derick [2002-12-11 12:57:43] [EMAIL PROTECTED] More insight, and something very useful: The bug is in the "wordwrap" function. Please see http://www.roaringpenguin.com/segfault2.tar.bz2 There are two PHP scripts: One crashes PHP when run from the command line, and the other works fine. The only difference between the two is a change in the argument to wordwrap(). Also, I ran valgrind on the standalone PHP executable, and here is its report. Hope all of this helps! Regards, David. ==7690== ERROR SUMMARY: 138 errors from 5 contexts (suppressed: 38 from 1) ==7690== ==7690== 1 errors in context 1 of 5: ==7690== Invalid write of size 1 ==7690==at 0x80FF654: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==Address 0x44DA1882 is 2 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 1 errors in context 2 of 5: ==7690== Invalid write of size 1 ==7690==at 0x4003C395: memcpy (vg_clientfuncs.c:503) ==7690==by 0x80FF64E: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==Address 0x44DA1881 is 1 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690== ==7690== 1 errors in context 3 of 5: ==7690== Invalid write of size 1 ==7690==at 0x4003C36F: memcpy (vg_clientfuncs.c:496) ==7690==by 0x80FF711: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/php) ==7690==by 0x8152CDD: execute (in /usr/bin/php) ==7690==Address 0x44DA1880 is 0 bytes after a block of size 148 alloc'd ==7690==at 0x4003BA4E: malloc (vg_clientfuncs.c:100) ==7690==by 0x812A9AB: _emalloc (in /usr/bin/php) ==7690==by 0x80FF585: zif_wordwrap (in /usr/bin/php) ==7690==by 0x8152F6C: execute (in /usr/bin/p
#17606 [Com]: File upload fails on large files
ID: 17606 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: HTTP related Operating System: RedHat 7.3 PHP Version: 4.2.1 New Comment: I think you closed this "bug" prematurely! I have two very similar machines - both running PHP 4.2.3 and apache 1.3.26 on Redhat Linux 2.4.7-10 (7.1). I have an upload script and can upload ANY size file to one machine, but am limited to about 9mb on the other box. The php.ini and httpd.conf files are identical (actually, I swapped them over just for the hell of it). I've even swapped the libphp4.so files in the apache libexec directory, between boxes! If this isn't a bug, why does the upload work flawlessly on one machine, but not the other? It will not write to the /tmp directory (or any directory, no matter what I set upload_tmp_dir to) on the one box, but does on the other. Permissions and apache user/group are identical across boxes. It has me stumped! It should either work on both, or neither! Previous Comments: [2002-06-10 03:24:45] [EMAIL PROTECTED] Well, I have been doing more tests and it seems that the system memory that is being used is for the catching of the filesystem. I dont know if it is a good thing that so many memory is eaten just for file catching but this is an operating system issue and not php related bug so If everyone agrees I close the bug. Regarding last message from [EMAIL PROTECTED], did you double check the values for the php.ini file, related with post and file uploading? Remenber that post limit should be at least filesize+size of php script. memory_limit = ?? post_max_size = ?? file_uploads = On upload_max_filesize = ?? allow_url_fopen = On [2002-06-08 00:51:26] [EMAIL PROTECTED] I'm using debian with a packaged release of 4.2.1 I'm having the same problem with large uploads, 12 MB files. It will upload to the tmp directory, but fails to move it out of there to where I desire. It eats system memory as well. I've tried moving the uploaded file to a directory (checked the permissions so on and so forth) as well as moving the uploaded file into a mysql database as binary information. Nothing works. It uploads but wont do anything with it [2002-06-06 05:58:13] [EMAIL PROTECTED] Yes, I am using php-4.2.1, I have been doing tests with very big files, my current parameters regarding uploads in php.ini are the following: memory_limit = 8M post_max_size = 700M file_uploads = On upload_max_filesize = 700M allow_url_fopen = On When I try to upload a 400M file the web server starts writing it in the tmp dir but it also eats the system memory in the same amount so it can only handle properly one big upload at a time. [2002-06-06 05:58:08] [EMAIL PROTECTED] Yes, I am using php-4.2.1, I have been doing tests with very big files, my current parameters regarding uploads in php.ini are the following: memory_limit = 8M post_max_size = 700M file_uploads = On upload_max_filesize = 700M allow_url_fopen = On When I try to upload a 400M file the web server starts writing it in the tmp dir but it also eats the system memory in the same amount so it can only handle properly one big upload at a time. [2002-06-06 05:36:44] [EMAIL PROTECTED] Are you sure you are using php 4.2.1 ? Since php 4.2.0, uploaded files aren't stored in memory. 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/17606 -- Edit this bug report at http://bugs.php.net/?id=17606&edit=1
#20944 [Opn]: external gd dies with compile
ID: 20944 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: FreeeBSD 4.7-RELEASE PHP Version: 4CVS-2002-12-11 (dev) New Comment: Use the bundled gd library for now, the external gd lib has a bug, which causes the problem you are experiencing. Previous Comments: [2002-12-11 14:09:25] [EMAIL PROTECTED] I am trying to use gd-2.0.1 with php and I get the following compile error: r-pic -c /home/matt/src/php4/ext/gd/gd.c -o ext/gd/gd.lo /home/matt/src/php4/ext/gd/gd.c: In function `_php_image_create_from': /home/matt/src/php4/ext/gd/gd.c:1445: warning: assignment makes pointer from integer without a cast /home/matt/src/php4/ext/gd/gd.c: In function `zif_imagecreatefromxpm': /home/matt/src/php4/ext/gd/gd.c:1515: `gdImageCreateFromXpm' undeclared (first use in this function) /home/matt/src/php4/ext/gd/gd.c:1515: (Each undeclared identifier is reported only once /home/matt/src/php4/ext/gd/gd.c:1515: for each function it appears in.) *** Error code 1 Stop in /home/matt/src/php4. Please note that this error does not occur with the builtin gd (the builtin was giving me a signal 10 while using jpgraph so I am trying the external). RC2 does not give this error in either. -- Edit this bug report at http://bugs.php.net/?id=20944&edit=1
#20927 [Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2 (Actually, culprit is wordwrap)
ID: 20927 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Strings related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 Assigned To: derick New Comment: 4.3.0RC2 still crashes; the "10-percent-extra-space" hack fails. :-) Stepping through the code, by line 674 of string.c, we have: textlen = 77 linelength = 20 breakcharlen = 13 docut = 1 and line 674 computes newtextlen as 135. Unfortunately, under PHP 4.1.2, which works correctly, the length of the final string is 138 characters long, and you have a buffer overflow. :-) Test it if you don't believe me. The problem seems to be that the break string itself is being counted to determine whether or not to break the line. Here's the output from 4.1.2 (hard to see clearly...) ADV:CLAIM YOURCANITBREAKFOOFORTUNE NOW !!MAKECANITBREAKFOOxxHUNDREDSCANITBREAKFOOOFCANITBREAKFOOTHOUSANDSxxxCANITBREAKFOOx Note the two breaks very close together around the word "OF"? This yielded 5 breaks instead of the maximum 4 which the code assumes, and the break string was long enough to frustrate the "10% overhead" method. You really need to be extremely conservative when allocating space; assume that there can be as many breaks added as there are characters in the original string. For most cases, with short break strings, this won't lead to too much over-allocation, and it will fix the problem. -- David. Previous Comments: [2002-12-11 14:15:54] [EMAIL PROTECTED] It DOES crash with 4.30RC2: I built 4.30RC2 with this configuration: ./configure --with-pgsql=shared \ --with-gnu-ld \ --with-apxs=/usr/local/apache/bin/apxs I then installed it and ran the command-line version: $ /usr/local/bin/php -v PHP 4.3.0RC2 (cli) (built: Dec 10 2002 19:58:29) Copyright (c) 1997-2002 The PHP Group Zend Engine v1.4.0, Copyright (c) 1998-2002 Zend Technologies $ /usr/local/bin/php test-wrap.php Segmentation fault $ /usr/local/bin/php test-wrap2.php (no output, but no segfault) Please don't accuse me of wasting your time without reading ALL of my comments... I said that 4.2.2, 4.2.3 and 4.3.0RC2 behave the same. -- David. [2002-12-11 14:06:24] [EMAIL PROTECTED] ARGH! Why did you fill in 4.3.0RC2 as version number if you're talking about PHP 4.2.2? You just wasted my time trying to hunt down a bug that's already fixed. Indeed, this crashes with PHP 4.2.2 but not with 4.3.0RC2 and RC3. Derick [2002-12-11 13:58:46] [EMAIL PROTECTED] Scripts which duplicate the problem without PostgreSQL: This script crashes PHP 4.2.2 from Red Hat: This script works just fine: [2002-12-11 13:31:49] [EMAIL PROTECTED] The word wrap parameters are in the tar file on my Web site. I do not know how you will duplicate the problem unless you have PostgreSQL. Anyway, the script which segfaults: $str = htmlentities(wordwrap($str, 20, "CANITBREAKFOO", 1)); The one which works OK: $str = htmlentities(wordwrap($str, 21, "CANITBREAKFOO", 1)); In both cases, the original value of $str is as follows: "ADV:CLAIM YOUR FORTUNE NOW !!MAKE xxHUNDREDS OF THOUSANDS" On one line (total 77 characters in length.) [2002-12-11 13:24:41] [EMAIL PROTECTED] It would really help me if you could give me the parameters to wordwrap on which you get this error, I dont have postgres here so I can't try your script. Derick 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/20927 -- Edit this bug report at http://bugs.php.net/?id=20927&edit=1
#20927 [Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2 (Actually, culprit is wordwrap)
ID: 20927 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Strings related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 Assigned To: derick New Comment: One more thing and then I'll shut up. :-) Rather than allocating space to begin with, why not use something like Tcl's Dynamic Strings, which let you grow the buffer as required? Then you can just call dstring_append and not worry about space. Regards, David. Previous Comments: [2002-12-11 14:35:20] [EMAIL PROTECTED] 4.3.0RC2 still crashes; the "10-percent-extra-space" hack fails. :-) Stepping through the code, by line 674 of string.c, we have: textlen = 77 linelength = 20 breakcharlen = 13 docut = 1 and line 674 computes newtextlen as 135. Unfortunately, under PHP 4.1.2, which works correctly, the length of the final string is 138 characters long, and you have a buffer overflow. :-) Test it if you don't believe me. The problem seems to be that the break string itself is being counted to determine whether or not to break the line. Here's the output from 4.1.2 (hard to see clearly...) ADV:CLAIM YOURCANITBREAKFOOFORTUNE NOW !!MAKECANITBREAKFOOxxHUNDREDSCANITBREAKFOOOFCANITBREAKFOOTHOUSANDSxxxCANITBREAKFOOx Note the two breaks very close together around the word "OF"? This yielded 5 breaks instead of the maximum 4 which the code assumes, and the break string was long enough to frustrate the "10% overhead" method. You really need to be extremely conservative when allocating space; assume that there can be as many breaks added as there are characters in the original string. For most cases, with short break strings, this won't lead to too much over-allocation, and it will fix the problem. -- David. [2002-12-11 14:15:54] [EMAIL PROTECTED] It DOES crash with 4.30RC2: I built 4.30RC2 with this configuration: ./configure --with-pgsql=shared \ --with-gnu-ld \ --with-apxs=/usr/local/apache/bin/apxs I then installed it and ran the command-line version: $ /usr/local/bin/php -v PHP 4.3.0RC2 (cli) (built: Dec 10 2002 19:58:29) Copyright (c) 1997-2002 The PHP Group Zend Engine v1.4.0, Copyright (c) 1998-2002 Zend Technologies $ /usr/local/bin/php test-wrap.php Segmentation fault $ /usr/local/bin/php test-wrap2.php (no output, but no segfault) Please don't accuse me of wasting your time without reading ALL of my comments... I said that 4.2.2, 4.2.3 and 4.3.0RC2 behave the same. -- David. [2002-12-11 14:06:24] [EMAIL PROTECTED] ARGH! Why did you fill in 4.3.0RC2 as version number if you're talking about PHP 4.2.2? You just wasted my time trying to hunt down a bug that's already fixed. Indeed, this crashes with PHP 4.2.2 but not with 4.3.0RC2 and RC3. Derick [2002-12-11 13:58:46] [EMAIL PROTECTED] Scripts which duplicate the problem without PostgreSQL: This script crashes PHP 4.2.2 from Red Hat: This script works just fine: [2002-12-11 13:31:49] [EMAIL PROTECTED] The word wrap parameters are in the tar file on my Web site. I do not know how you will duplicate the problem unless you have PostgreSQL. Anyway, the script which segfaults: $str = htmlentities(wordwrap($str, 20, "CANITBREAKFOO", 1)); The one which works OK: $str = htmlentities(wordwrap($str, 21, "CANITBREAKFOO", 1)); In both cases, the original value of $str is as follows: "ADV:CLAIM YOUR FORTUNE NOW !!MAKE xxHUNDREDS OF THOUSANDS" On one line (total 77 characters in length.) 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/20927 -- Edit this bug report at http://bugs.php.net/?id=20927&edit=1
#20945 [NEW]: Parse error is not deteced by PHP
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.3 PHP Bug Type: Scripting Engine problem Bug description: Parse error is not deteced by PHP This parse error is not detected by PHP: if (isset($_POST['rerun')) && $_POST['rerun'] == 1) $script= 'script_rerun'; else $script= 'script_reproduce'; Note the paranthese instead of square bracket in the isset(). When PHP finds this page, it doesn't do anything. It shows a blank page. This really had me dumb founded, as I tried everything. I even threw in random text to generate errors, but PHP didn't catch this at all. Once I found this bracket and fixed it, everything worked again. Very odd. -- Edit bug report at http://bugs.php.net/?id=20945&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20945&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20945&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20945&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20945&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20945&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20945&r=support Expected behavior: http://bugs.php.net/fix.php?id=20945&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20945&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20945&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20945&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20945&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20945&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20945&r=isapi
#20927 [Opn]: Crash inside libpq (PQexec) with PHP > 4.1.2 (Actually, culprit is wordwrap)
ID: 20927 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Strings related Operating System: Red Hat Linux 8.0 on Intel PHP Version: 4.3.0RC2 Assigned To: derick New Comment: I still can't get it to crash here though, even with your configure line and scripts. Valgrind doesn't report anything either. Previous Comments: [2002-12-11 14:37:12] [EMAIL PROTECTED] One more thing and then I'll shut up. :-) Rather than allocating space to begin with, why not use something like Tcl's Dynamic Strings, which let you grow the buffer as required? Then you can just call dstring_append and not worry about space. Regards, David. [2002-12-11 14:35:20] [EMAIL PROTECTED] 4.3.0RC2 still crashes; the "10-percent-extra-space" hack fails. :-) Stepping through the code, by line 674 of string.c, we have: textlen = 77 linelength = 20 breakcharlen = 13 docut = 1 and line 674 computes newtextlen as 135. Unfortunately, under PHP 4.1.2, which works correctly, the length of the final string is 138 characters long, and you have a buffer overflow. :-) Test it if you don't believe me. The problem seems to be that the break string itself is being counted to determine whether or not to break the line. Here's the output from 4.1.2 (hard to see clearly...) ADV:CLAIM YOURCANITBREAKFOOFORTUNE NOW !!MAKECANITBREAKFOOxxHUNDREDSCANITBREAKFOOOFCANITBREAKFOOTHOUSANDSxxxCANITBREAKFOOx Note the two breaks very close together around the word "OF"? This yielded 5 breaks instead of the maximum 4 which the code assumes, and the break string was long enough to frustrate the "10% overhead" method. You really need to be extremely conservative when allocating space; assume that there can be as many breaks added as there are characters in the original string. For most cases, with short break strings, this won't lead to too much over-allocation, and it will fix the problem. -- David. [2002-12-11 14:15:54] [EMAIL PROTECTED] It DOES crash with 4.30RC2: I built 4.30RC2 with this configuration: ./configure --with-pgsql=shared \ --with-gnu-ld \ --with-apxs=/usr/local/apache/bin/apxs I then installed it and ran the command-line version: $ /usr/local/bin/php -v PHP 4.3.0RC2 (cli) (built: Dec 10 2002 19:58:29) Copyright (c) 1997-2002 The PHP Group Zend Engine v1.4.0, Copyright (c) 1998-2002 Zend Technologies $ /usr/local/bin/php test-wrap.php Segmentation fault $ /usr/local/bin/php test-wrap2.php (no output, but no segfault) Please don't accuse me of wasting your time without reading ALL of my comments... I said that 4.2.2, 4.2.3 and 4.3.0RC2 behave the same. -- David. [2002-12-11 14:06:24] [EMAIL PROTECTED] ARGH! Why did you fill in 4.3.0RC2 as version number if you're talking about PHP 4.2.2? You just wasted my time trying to hunt down a bug that's already fixed. Indeed, this crashes with PHP 4.2.2 but not with 4.3.0RC2 and RC3. Derick [2002-12-11 13:58:46] [EMAIL PROTECTED] Scripts which duplicate the problem without PostgreSQL: This script crashes PHP 4.2.2 from Red Hat: This script works just fine: 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/20927 -- Edit this bug report at http://bugs.php.net/?id=20927&edit=1
#20945 [Opn->Fbk]: Parse error is not deteced by PHP
ID: 20945 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.2.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-12-11 14:38:20] [EMAIL PROTECTED] This parse error is not detected by PHP: if (isset($_POST['rerun')) && $_POST['rerun'] == 1) $script= 'script_rerun'; else $script= 'script_reproduce'; Note the paranthese instead of square bracket in the isset(). When PHP finds this page, it doesn't do anything. It shows a blank page. This really had me dumb founded, as I tried everything. I even threw in random text to generate errors, but PHP didn't catch this at all. Once I found this bracket and fixed it, everything worked again. Very odd. -- Edit this bug report at http://bugs.php.net/?id=20945&edit=1
