Bug #16442: bug reporting password finder does not work
From: [EMAIL PROTECTED] Operating system: Yours PHP version: 4.1.2 PHP Bug Type: Unknown/Other Function Bug description: bug reporting password finder does not work I have forgotten my password for a bug entry, when I tried to use your facilility to recover it I got this The password for bug report #10155 is . sent to my email. Could you fix this so I can add additional info to this item as someone emailed me about it. -- Edit bug report at http://bugs.php.net/?id=16442&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16442&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16442&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16442&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16442&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16442&r=support Expected behavior: http://bugs.php.net/fix.php?id=16442&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16442&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16442&r=submittedtwice
Bug #13774 Updated: Missing information in isapi installation for apache
ID: 13774 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Windows PHP Version: 4.0.6 New Comment: One typo with the manual (Apache 1.3.24, WinME, PHP 4.1.1): LoadModule php4 module c:/php/sapi/php4apache.dll should be read as: LoadModule php4_module c:/php/sapi/php4apache.dll That had solved my problem with starting the Apache server, without a need for AddModule line, but that could be due to WinME. Previous Comments: [2002-01-23 16:55:18] [EMAIL PROTECTED] This documentation is still not updated in v4.11 [2001-10-20 14:51:22] [EMAIL PROTECTED] Under Windows 2000 Pro, when following the isapi install instructions for apache from the readme file, it fails to mention the need to add the line AddModule mod_php4.c in httpd.conf because the line LoadModule php4_module /php/sapi/php4apache.dll is not enough by itself to make it work correctly. This is probably true for other windows OSes. It happened for me with both binary and source distros of apache and PHP. -- Edit this bug report at http://bugs.php.net/?id=13774&edit=1
Bug #16441: mail bad formed
From: [EMAIL PROTECTED] Operating system: Red Hat 7.2 PHP version: 4.0.6 PHP Bug Type: Mail related Bug description: mail bad formed Hello, i'm trying to send mails with mail function, and the problem is the next: The mail arrives correctly, but some existent adreces refuse this mail, the error is the next: Sender domain must exist and in the From parameter i'm inserting a good sender domain but the mail function always puts as from [EMAIL PROTECTED] i think that this happens since i have aplied the patch for file uploads problem thank you in advance Fernando Caamaño -- Edit bug report at http://bugs.php.net/?id=16441&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16441&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16441&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16441&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16441&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16441&r=support Expected behavior: http://bugs.php.net/fix.php?id=16441&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16441&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16441&r=submittedtwice
Bug #16440: limiting number of rows to be displayed
From: [EMAIL PROTECTED] Operating system: Windows NT 4.0, Windows 2000 pr. PHP version: 4.1.2 PHP Bug Type: *Database Functions Bug description: limiting number of rows to be displayed Dear IT Specialist; I am using PHP, MYSQL and Apache Webserver for developing Online Database. I have a problem of limiting results, Suppose that the result of " select * from table; " will be 80 records and I want to display 10 records at a time. Can you give me an idea how to limit the select results, Solomon -- Edit bug report at http://bugs.php.net/?id=16440&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16440&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16440&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16440&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16440&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16440&r=support Expected behavior: http://bugs.php.net/fix.php?id=16440&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16440&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16440&r=submittedtwice
Bug #16439: strftime ("%V", $dat) does not give any result
From: [EMAIL PROTECTED]
Operating system: Win32
PHP version: 4.1.0
PHP Bug Type: Date/time related
Bug description: strftime ("%V", $dat) does not give any result
strftime ("%V", $dat) and strftime ("%G", $dat) do not give any result when
used with Win32 and Apache Server.
--
Edit bug report at http://bugs.php.net/?id=16439&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16439&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16439&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16439&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16439&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16439&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16439&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16439&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16439&r=submittedtwice
Bug #14865 Updated: php4apache.dll - phpinfo error - winXP - Apache
ID: 14865 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: Win XP Prof PHP Version: 4.1.1 New Comment: Same problems as everyone else has, I didn't realize it wasn't me until I saw this post. I have: OS: Windows XP Professional (Build: 2600) PHP: 4.2.0RC1 Apache: 1.3.23 PHP Installed as module First time I noticed this was with phpinfo() flashing like 10 times and then displaying the phpinfo page, or sometimes after the flashing would display dns error page. It's not something that happens every time, and some days are also better than others and I don't expierience any problems related to this. In fact when I'm using 'localhost' this doesn't happen to me. And in fact when I surf the pages myself, phpinfo loads just fine. But as soon as someone else tries to run my scripts it starts tweaking out on them. Every time they try they say phpinfo page will load anywhere from %15 to like %90 and then it will just cut off or turn into "compiled code" as they put it, or simply...garbage. The point at which it starts to garble or cut off is random and unpredictable. As soon as anyone gets a fix for this it would be great if they would let everyone know! :) It's annoying not being able to share my code I've worked so hard on with other people... Previous Comments: [2002-04-03 20:54:29] [EMAIL PROTECTED] I get a similar difficulty, but with ANY scripts no matter how small or large. 90% of the time it works perfectly, then all of a sudden PHP decides to spew a parse error or some other random phenomenon - even a single one line script will eventually suffer this fault. I experienced this when I moved to PHP 4.1.x, so reverted back to 4.0.6 which does not have the problem. Unfortunately 4.1.2 is a security fix so obviously have to upgrade, and now having to live with this problem. Not sure if its related, but 4.1.x also causes Apache's memory use to grow and grow and GROW until eventually a malloc fault occurrs. Sometimes Apache will restart, sometimes just crash. Again 4.0.6 has no such problem, just 4.1.x - had no choice but to configure Apache to self-restart every few hundred hits to overcome this memory leak. This is all with PHP as a Apache module. [2002-03-25 15:38:20] [EMAIL PROTECTED] I too am having the same problem. WinXP, Apache/1.3.22 (Win32), PHP/4.1.3-dev, mod_perl/1.26. PHP installed as a module. I haven't tried using it in CGI mode. It's not just phpinfo(). It happens regularly. Try going to: http://singularity.homedns.org/calendar/index.php Hit reload a few times, move to another month, etc. Eventually it will hose up. Spews garbage characters in the middle of the page. I understand going back to 4.0.6 seems to fix it, but I'd rather not. Any help would be..wellhelpful. IanW IanW [2002-03-22 00:24:26] [EMAIL PROTECTED] Another instance: I have a page that only contains and nothing else. PHP ver: 4.1.2 Machine: WinXP Pro HTTPD:Apache, PHP as a module When I browse to the page on my local machine (localhost) I get strange behaviour. I get a large number of instant redirects - in other words, the browser sits there redirecting itself to the same page for about 10 seconds (maybe 50 redirects in all). Finally the page either displays properly, or I get a DNS server not found error page in my browser. It's only started doing this since I upgraded from 4.0.6 to 4.1.2. I have just installed 4.2.0 RC1, but it makes no difference. If I go back to 4.0.6, it's fine. You can try this yourself. Go to: http://mvirtue.myip.org/test/index.php and see what you get. I got a friend of mine to try it from his machine, and he briefly saw the first few lines of the PHP info screen, and then was instantly redirected to a DNS error page. Often the page displays perfectly the first time you go there. It's only when you hit "Refresh" do you get the bizarre behaviour. [2002-01-18 08:50:59] [EMAIL PROTECTED] How I can get the new version? I tried to found by http://cvs.php.net/cvs.php/php4/win32 but I couldn't find the binary-Version for win32! Can you send me the new version or say me where I can find it? I don't beleve, that the but is fix, why the problem was not only with the verion 4.1.1, it was with 4.0.6 too! Greats Pascal [2002-01-11 10:43:45] [EMAIL PROTECTED] This problem occurs only on WIN XP (Pro?) as an OS. The remainder of the
Bug #15217 Updated: syntax error before `va_list'
ID: 15217 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Compile Failure Operating System: FreeBSD PHP Version: 4.1.1 New Comment: I'm getting the same error in 4.5-20020402-STABLE. Previous Comments: [2002-03-03 02:27:46] [EMAIL PROTECTED] works fine in FreeBSD 4.5 [2002-01-25 01:16:07] [EMAIL PROTECTED] I run ./configure and whether or not I pass arguments I receive this error on 'make'. This is the very first step in the build: Making all in Zend /bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../main -I../TSRM -g -O2 -prefer-non-pic -static -c zend_language_parser.c In file included from zend.h:164, from zend_compile.h:24, from zend_language_parser.c:148: zend_hash.h:119: syntax error before `va_list' In file included from zend.h:165, from zend_compile.h:24, from zend_language_parser.c:148: zend_llist.h:34: syntax error before `va_list' In file included from zend_compile.h:24, from zend_language_parser.c:148: zend.h:247: syntax error before `va_list' zend.h:378: syntax error before `va_list' *** Error code 1 Stop in /usr/sources/php-4.1.1/Zend. *** Error code 1 Stop in /usr/sources/php-4.1.1. Some previous bug reports I've seen were similar, but for previous versions. I tried some code edits anyway, with their ideas in mind, but to no avail. I'm starting to think my FreeBSD 4.4 STABLE build is broken. Thanks in advance :-) -- Edit this bug report at http://bugs.php.net/?id=15217&edit=1
Bug #16291 Updated: pg_last_notice causes SegFault
ID: 16291
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: PostgreSQL related
Operating System: linux MDK 8.1
PHP Version: 4.1.2
Assigned To: yohgaki
New Comment:
This bug has been fixed in CVS.
Thanks for reporting.
Fix will be available in 4.2.0, also.
Previous Comments:
[2002-03-28 21:41:48] [EMAIL PROTECTED]
Ok. I'll have look.
[2002-03-27 05:48:42] [EMAIL PROTECTED]
I use PostgreSQL 7.2 wich I've installed in /usr/local/pgsql (on clear,
first I did was rm -r -f /usr/local/pgsql, and also there is no postgre
packages from the distribution installed) there are no other postgresql
files on my disk, also I've compiled with it
--with-pgsql=/usr/local/pgsql, so I suppose I don't use different
versions.
If there is a more precise way of discovering this kind of error please
tell me (in phpinfo() i didn't find such info).
And as I said when I compile PHP with debug support
(--enable-debug=yes) it does not generate SegFaullts only this messages
which I posted before, so couldn't make a backtrace.
___
by the way here is the part of the code that is important for the
error:
if ($oid == 0) {
@pg_query($db_conn, "UPDATE resource SET project = NULL, resource =
NULL WHERE \"user\" = '$user' AND date = '$date' AND num = '$num'");
}else{
@pg_query($db_conn, "UPDATE resource SET project = pr.project,
resource = pr.resource FROM project_resource as pr WHERE pr.oid =
'$oid' AND \"user\" = '$user' AND date = '$date' AND num = '$num'");
}
$tmpn = pg_last_notice($db_conn);
every update actually updates only one row (since user,date,num is
primary key), on which a trigger generate this notice
[2002-03-26 19:28:04] [EMAIL PROTECTED]
Is your backend(PostgreSQL Server) and libpq matches?
(i.e. Do you use libpq version that comes with your PostgreSQL
Server?)
If version does not match, use the same versoin.
If you still have problem, please send backtrace. I'll fix it.
[2002-03-26 15:36:37] [EMAIL PROTECTED]
reclassified
[2002-03-26 14:16:44] [EMAIL PROTECTED]
I got again the latest CVS and compiled it with
./configure --prefix=/etc/httpd \
--with-apxs=/usr/sbin/apxs \
--with-config-file-path=/etc/php4/apache \
--enable-debug=yes \
--with-exec-dir=/usr/bin \
--with-system-regex \
--with-mysql=/usr/local/mysql \
--with-pgsql=/usr/local/pgsql \
--with-gd=/usr \
--with-freetype-dir=/usr\
--with-zlib \
--with-ldap \
--with-imap \
--enable-track-vars \
--enable-magic-quotes
and then there was NO segfault, but in the browser appeared (the
differences is of course --enable-debug=yes)
BROWSER START
__
Warning: String is not zero-terminated
(Ì*)
(source: ./zend_execute.c:449) in
/var/www/crm.dir.bg/project.planner.update.php on line
38
Warning: String is not zero-terminated
(ZÌ*)
(source: ./zend_execute.c:449) in
/var/www/crm.dir.bg/project.planner.update.php on line
38
Warning: String is not zero-terminated
(ZZZÌ*@Á)
(source: ./zend_execute.c:449) in
/var/www/crm.dir.bg/project.planner.update.php on line
38
Warning: Cannot add header information - headers already sent
by (output started at
/var/www/crm.dir.bg/project.planner.update.php:38) in
/var/www/crm.dir.bg/project.planner.update.php on line
48
Warning: String is not zero-terminated
(ZZZÌ*)
(source: zend_execute_API.c:274) in Unknown on line 0
___
BROWSER END
and in the error_log
ERROR_LOG START
___
[Tue Mar 26 21:22:52 2002] [error] NOTICE: Too Many Resources Assigned
to project TEST, needed 10, assigned 44.
[Tue Mar 26 21:2
Bug #15850 Updated: Compiling not possible due to incorrect creation of Makefile
ID: 15850 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Compile Failure Operating System: LinuxMandrake 7.2 (2.2.17-21mdk) PHP Version: 4.1.2 New Comment: No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-03-04 14:45:00] [EMAIL PROTECTED] Here are the version numbers. It really all goes back to the directory, when I changed from "/mnt/raid/Samba/Linux Programme/php-4.1.2" to "/mnt/raid/Samba/php-4.1.2" it worked perfectly. ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) automake (GNU automake) 1.4 Copyright (C) 1999 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Tom Tromey <[EMAIL PROTECTED]> Autoconf version 2.13 [2002-03-04 14:38:52] [EMAIL PROTECTED] Which versions of libtool, automake and autoconf are you using? Derick [2002-03-04 14:37:08] [EMAIL PROTECTED] Compiling path: /mnt/raid/Samba/Linux Programme/php-4.1.2 Everything works fine until the last step (creating files/generating files), as already mentioned. As this "bogus" _bug_ is reproducible, it would not have been difficult to figure that out by yourself, although I mentioned it. Extract from ./configure +++ Generating files checking for working mkdir -p... (cached) yes creating config_vars.mk updating cache ./config.cache creating ./config.status creating php4.spec creating Zend/Makefile creating main/build-defs.h creating pear/scripts/pear creating pear/scripts/phpize creating pear/scripts/php-config creating pear/scripts/pearize creating pear/scripts/phptar creating TSRM/Makefile creating main/php_config.h main/php_config.h is unchanged creating sapi/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/sapi/Makefile.in: No such file or directory creating ext/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/Makefile.in: No such file or directory creating Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/Makefile.in: No such file or directory creating pear/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/pear/Makefile.in: No such file or directory creating main/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/main/Makefile.in: No such file or directory creating ext/mysql/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/mysql/Makefile.in: No such file or directory creating ext/mysql/libmysql/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/mysql/libmysql/Makefile.in: No such file or directory creating ext/pcre/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/pcre/Makefile.in: No such file or directory creating ext/pcre/pcrelib/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/pcre/pcrelib/Makefile.in: No such file or directory creating ext/posix/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/posix/Makefile.in: No such file or directory creating ext/session/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/session/Makefile.in: No such file or directory creating ext/standard/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/standard/Makefile.in: No such file or directory creating ext/xml/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/xml/Makefile.in: No such file or directory creating ext/xml/expat/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/ext/xml/expat/Makefile.in: No such file or directory creating sapi/apache/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/sapi/apache/Makefile.in: No such file or directory creating regex/Makefile cat: /mnt/raid/Samba/Linux: Is a directory cat: Programme/php-4.1.2/regex/Makefile.in: No such file or directory creating main/internal_functions.c cat: ./main/internal_functions.c.in: No such file or directory +++ Happy? [2002-03-04 03:02:31] [EMAIL PROTECTED] Completely non-sensical bug report. -
Bug #15658 Updated: session.save_path directive has no influence on session files save_path
ID: 15658 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: *Configuration Issues Operating System: win2k PHP Version: 4.1.1 New Comment: No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-03-11 06:52:49] [EMAIL PROTECTED] I use the ISAPI version of PHP (IIS5) and Yes, I restarted that many times to checkt the (mis)behaviour of this directive. [2002-02-22 12:16:38] [EMAIL PROTECTED] Did you restart Apache? [2002-02-21 09:37:38] [EMAIL PROTECTED] I try to get PHP to save it's session files in the /sessions directory (set session.save_path = e:\sessions) on my document drive, but no matter what I do and how I specify the directory (forward and backward slashes) it keeps saving them in the /tmp directory on that same drive (e:\tmp). There is no reference to /tmp in my whole php.ini file! >From my point of view it looks like the session.save_path directive recognition in the php.ini file is broken. -- Edit this bug report at http://bugs.php.net/?id=15658&edit=1
Bug #12917 Updated: ext/java/Makefile.in places reflect.class in wrong place (with kaffe javac).
ID: 12917 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Java related Operating System: Linux PHP Version: 4.0.6 New Comment: No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-02-24 06:10:28] [EMAIL PROTECTED] Please test with PHP 4.1.1+JDK 1.2 and report the result back Please do not forget updating PHP version. Thanks. [2001-08-23 03:17:57] [EMAIL PROTECTED] default Makefile.in in ext/java (with kaffe 1.0.6 javac) places reflect.class in net/php/net/php instead of just net/php. Patch follows: 21a22 > @test -f net/php/net/php/reflect.class && \ mv net/php/net/php/*.class net/php 23a25,26 > @rmdir net/php/net/php > @rmdir net/php/net -- Edit this bug report at http://bugs.php.net/?id=12917&edit=1
Bug #16438 Updated: Segmentation fault
ID: 16438 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Red Hat Linux release 6.2 PHP Version: 4.1.2 New Comment: First, please try with PHP 4.2.0RC2 from http://www.php.net/~derick/ Second question is, how many rows are there in the array causing the crash? Previous Comments: [2002-04-04 21:02:10] [EMAIL PROTECTED] configuration line == ./configure --with-mysql --with-socket --enable-trans-sid --with-progel --with-gd --enable-discard-path description === chatv2.php - daily batch program, read database (MySQL), generate statistics, write database. As the records increased, it's occurs more often. debug info == $ gdb /usr/local/bin/php /home/tony/stats/bin/core GNU gdb 19991004 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `/usr/local/bin/php /home/tony/stats/bin/chatv2.php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /lib/libcrypt.so.1...done. Reading symbols from /lib/libresolv.so.2...done. Reading symbols from /lib/libpam.so.0...done. Reading symbols from /usr/lib/libgd.so.1...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libnsl.so.1...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /lib/libnss_files.so.2...done. Reading symbols from /usr/lib/gconv/ISO8859-1.so...done. #0 0x80eca73 in _array_init (arg=0xa4feb24) at zend_API.c:561 561 ALLOC_HASHTABLE_REL(arg->value.ht); (gdb) run /home/tony/stats/bin/chatv2.php Starting program: /usr/local/bin/php /home/tony/stats/bin/chatv2.php X-Powered-By: PHP/4.1.2 Content-type: text/html Process day : 2002-04-03 Program received signal SIGSEGV, Segmentation fault. 0x80eca73 in _array_init (arg=0xa4feb24) at zend_API.c:561 561 ALLOC_HASHTABLE_REL(arg->value.ht); (gdb) bt #0 0x80eca73 in _array_init (arg=0xa4feb24) at zend_API.c:561 #1 0x8070996 in php_mysql_fetch_hash (ht=1, return_value=0xa4feb24, this_ptr=0x0, return_value_used=1, result_type=1, expected_args=1) at php_mysql.c:1590 #2 0x8070b68 in zif_mysql_fetch_assoc (ht=1, return_value=0xa4feb24, this_ptr=0x0, return_value_used=1) at php_mysql.c:1664 #3 0x81057e6 in execute (op_array=0x8184f54) at ./zend_execute.c:1590 #4 0x80ebcb6 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:814 #5 0x8062aba in php_execute_script (primary_file=0xba74) at main.c:1307 #6 0x8060e6b in main (argc=2, argv=0xbad4) at cgi_main.c:738 (gdb) -- Edit this bug report at http://bugs.php.net/?id=16438&edit=1
Bug #16438: Segmentation fault
From: [EMAIL PROTECTED] Operating system: Red Hat Linux release 6.2 PHP version: 4.1.2 PHP Bug Type: Reproducible crash Bug description: Segmentation fault configuration line == ./configure --with-mysql --with-socket --enable-trans-sid --with-progel --with-gd --enable-discard-path description === chatv2.php - daily batch program, read database (MySQL), generate statistics, write database. As the records increased, it's occurs more often. debug info == $ gdb /usr/local/bin/php /home/tony/stats/bin/core GNU gdb 19991004 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `/usr/local/bin/php /home/tony/stats/bin/chatv2.php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /lib/libcrypt.so.1...done. Reading symbols from /lib/libresolv.so.2...done. Reading symbols from /lib/libpam.so.0...done. Reading symbols from /usr/lib/libgd.so.1...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libnsl.so.1...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /lib/libnss_files.so.2...done. Reading symbols from /usr/lib/gconv/ISO8859-1.so...done. #0 0x80eca73 in _array_init (arg=0xa4feb24) at zend_API.c:561 561 ALLOC_HASHTABLE_REL(arg->value.ht); (gdb) run /home/tony/stats/bin/chatv2.php Starting program: /usr/local/bin/php /home/tony/stats/bin/chatv2.php X-Powered-By: PHP/4.1.2 Content-type: text/html Process day : 2002-04-03 Program received signal SIGSEGV, Segmentation fault. 0x80eca73 in _array_init (arg=0xa4feb24) at zend_API.c:561 561 ALLOC_HASHTABLE_REL(arg->value.ht); (gdb) bt #0 0x80eca73 in _array_init (arg=0xa4feb24) at zend_API.c:561 #1 0x8070996 in php_mysql_fetch_hash (ht=1, return_value=0xa4feb24, this_ptr=0x0, return_value_used=1, result_type=1, expected_args=1) at php_mysql.c:1590 #2 0x8070b68 in zif_mysql_fetch_assoc (ht=1, return_value=0xa4feb24, this_ptr=0x0, return_value_used=1) at php_mysql.c:1664 #3 0x81057e6 in execute (op_array=0x8184f54) at ./zend_execute.c:1590 #4 0x80ebcb6 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:814 #5 0x8062aba in php_execute_script (primary_file=0xba74) at main.c:1307 #6 0x8060e6b in main (argc=2, argv=0xbad4) at cgi_main.c:738 (gdb) -- Edit bug report at http://bugs.php.net/?id=16438&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16438&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16438&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16438&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16438&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16438&r=support Expected behavior: http://bugs.php.net/fix.php?id=16438&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16438&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16438&r=submittedtwice
Bug #16436 Updated: ereg causes apache crashes
ID: 16436 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback -Bug Type: PCRE related +Bug Type: Regexps related Operating System: Linux PHP Version: 4.0CVS-2002-04-04 New Comment: I can not reproduce this with latest CVS or with 4.2.0RC2. Please add the configure line used into this bug report. Also, configure php with --enable-debug and generate a GDB backtrace of the crash. Previous Comments: [2002-04-04 15:37:51] [EMAIL PROTECTED] this line crashes the apache process with php 4.2.0RC2 as a module Lutz -- Edit this bug report at http://bugs.php.net/?id=16436&edit=1
Bug #16423 Updated: Sess_* files don't store data
ID: 16423 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Session related Operating System: Windows NT / IIS4 PHP Version: 4.1.2 New Comment: Remember to replace the php4ts.dll also.. Previous Comments: [2002-04-04 12:31:25] [EMAIL PROTECTED] I've downloaded the new php4apache.dll which was modified on the 20th of March.still did not solve the sess_ write over access problem. My $_SESSION[vars] still do not propagate across pages... [2002-04-04 04:51:35] [EMAIL PROTECTED] Can you please try the windows binaries from www.php.net/~derick/php-4.2.0RC1/ ? Derick [2002-04-04 04:48:05] [EMAIL PROTECTED] It seems this bug has been reported yet, but maybe I give some other infos; session file sess_xx are created but NOT filled with vars values, so that $_SESSION[...] are not propagated between pages. I have two simple php pages using a $_SESSION["myvar"] variable that works fine on linux+apache; I can see vars stored in temp session file. The same 2 pages do not work on WinNT/IIS4; the sess_xxx file is empty and "Warning: Undefined index:..." is reported by the second page when I do a submit from the first. If I "cut and past" the sess_xxx entries from the linux box into sess_xxx on NT It works fine ! So I think it's a problem of file rights or something like that. I modified IIS guest account, temp dir rights... but without success. Hope to be helpful, regards, andrea -- Edit this bug report at http://bugs.php.net/?id=16423&edit=1
Bug #16435 Updated: follow up bug 16043, $_SESSION can't use in PHP 4.1.2, PHP 4.2.0RC1
ID: 16435 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Session related Operating System: Windows 2000/XP PHP Version: 4.1.2 New Comment: ahhthe one minor detail that i forgot.thanks :) after php4ts.dll was copied over the old one in winnt/system32, my session worked like a charm. Previous Comments: [2002-04-04 19:29:25] [EMAIL PROTECTED] At http://www.php.net/~derick/ you can find RC2 so please test with that. Did you replace the php4ts.dll also? --Jani [2002-04-04 15:03:13] [EMAIL PROTECTED] I seem to have configuration problemsi just can't seem to get session variables written to in files under win2000, NTFS w/ Apache 1.3.23 and PHP 4.1.2 ..i've already done everything from session_start() on every page to making var globalanybody can help?? thanksbtw, i got the same system on a Linux box running apache and php and it works fine sample of my code: Apparently under the bug report database for bug number 16043, my exactly problem was described. According to the PHP team, this windows/apache1.3.23/php4.1.2 session not writing to file bug has been fixed in the 4.2.0RC1 binaries. I've patched my php4apache.dll with the ones from 4.2.0RC1 AND it still doesn't work!!! Anyone who used 4.2.0RC1 came across this problem and made it work? -- Edit this bug report at http://bugs.php.net/?id=16435&edit=1
Bug #16435 Updated: follow up bug 16043, $_SESSION can't use in PHP 4.1.2, PHP 4.2.0RC1
ID: 16435 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Session related Operating System: Windows 2000/XP PHP Version: 4.1.2 New Comment: At http://www.php.net/~derick/ you can find RC2 so please test with that. Did you replace the php4ts.dll also? --Jani Previous Comments: [2002-04-04 15:03:13] [EMAIL PROTECTED] I seem to have configuration problemsi just can't seem to get session variables written to in files under win2000, NTFS w/ Apache 1.3.23 and PHP 4.1.2 ..i've already done everything from session_start() on every page to making var globalanybody can help?? thanksbtw, i got the same system on a Linux box running apache and php and it works fine sample of my code: Apparently under the bug report database for bug number 16043, my exactly problem was described. According to the PHP team, this windows/apache1.3.23/php4.1.2 session not writing to file bug has been fixed in the 4.2.0RC1 binaries. I've patched my php4apache.dll with the ones from 4.2.0RC1 AND it still doesn't work!!! Anyone who used 4.2.0RC1 came across this problem and made it work? -- Edit this bug report at http://bugs.php.net/?id=16435&edit=1
Bug #16417 Updated: session_id() not working
ID: 16417 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed Bug Type: Session related Operating System: WinXP/Win2K PHP Version: 4.1.1 New Comment: In mod_files.c, starting at line 61 is function called ps_files_valid_key() which checks the key for invalid characters. It only allows a-z, A-Z and 0-9 chars. Previous Comments: [2002-04-04 12:51:04] [EMAIL PROTECTED] It should not matter if you use an underscore. Reopening. Derick [2002-04-04 12:29:33] [EMAIL PROTECTED] Aha! It appears that it is the underscore causing the problem. [2002-04-04 04:20:48] [EMAIL PROTECTED] No, it causes the same problem. I've tried it on Win2K/4.1.2, Win2K/4.2.0RC1 now too. I don't see how you can reset the session_id after calling session start anyway. When session_start() is called, the SID constant is set, cookie sent to the client etc. You must have to set a custom session_id before this happens. [2002-04-04 04:11:55] [EMAIL PROTECTED] Maybe you have to call session_id AFTER session_start()? This is what the docs say: "session_id() returns the session id for the current session. If id is specified, it will replace the current session id." If the session hasn't been started yet, there's no session id to replace. Does it work now? [2002-04-04 02:58:30] [EMAIL PROTECTED] How do you know I don't have a reason to change the session id? :-) Why claim to provide the functionality, then refuse to support it? I *do* need to change the session id. It is unavoidable. 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/16417 -- Edit this bug report at http://bugs.php.net/?id=16417&edit=1
Bug #10155 Updated: Insert or update query not functioning correctly
ID: 10155
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: ODBC related
Operating System: Windows NT 4.0 build 1381
PHP Version: 4.0.4pl1
New Comment:
Sorry...my PHP Configuration is:
'./configure' '--enable-inline-optimization'
'--with-apxs=/usr/local/apache/1.3.12/bin/apxs'
'--with-config-file-path=/usr/local/lib' '--disable-debug'
'--enable-memory-limit' '--with-gettext' '--without-pear'
'--with-regex=system' '--enable-mbstring' '--enable-mbstr-enc-trans'
'--with-iconv=/usr/local' '--with-gdbm=/usr/local'
'--with-dbm=/usr/local' '--enable-sockets' '--enable-versioning'
'--enable-ftp' '--with-imap' '--with-mcrypt=/usr/local'
'--with-mhash=/usr/local' '--with-mysql=/usr/local/mysql' '--with-zlib'
'--with-zlib-dir=/usr'
Previous Comments:
[2002-04-04 18:46:26] [EMAIL PROTECTED]
I am having the same or very similar problem:
(There's a bunch more code involved, of course, so I'm just including
relevant examples, below.)
< START EXAMPLE --->
<...appropriate persistent db access info...>
<...data-to-variable assignments...>
mysql_db_query("dbX","update tableX set col1='$data1' where
ID='$id'");
<...error-reporting code...>
echo mysql_affected_rows();
<-- END EXAMPLE -->
Result: no affected rows, no errors, and no update
I tried adding a SELECT statement immediately following the UPDATE
statement, per this bug report's suggestion:
Result: 1 affected row, no errors, and no update
So PHP thought 1 row had been updated...but it had not been.
This is a piece of script that we have been using successfully for
about 4 months, but it started to malfunction about 3 weeks ago.
INSERT, and DELETE statements work fine.
Version Info/Configuration:
FreeBSD 4.4 Release i386
PHP v. 4.1.2 (same problem with 4.0.6, by the way...)
Apache/1.3.12 OpenSSL/0.9.6a
MySQL v. 3.23.44
Thanks.
[2001-05-07 10:39:41] [EMAIL PROTECTED]
no feedback, considered closed. if untrue, please reopen the bug.
[2001-04-16 23:14:21] [EMAIL PROTECTED]
can you please provide a very simple test case for me? all local
attempts here have not yielded the same results as you are seeing.
a sample schema, and script to reproduce this would be very nice. but
please make sure it's all in the simplest form...
[2001-04-04 07:02:58] [EMAIL PROTECTED]
The database is Access 2000 with a few tables and relations set up in
the relationships area.
Put simply the update, insert and, possibly, delete querys all appear
to work perfectely with no errors reported, except that the database
ends up being unchanged afterwards. The only way I have been able to
fix this is to query the same table with a select before the end of the
script, the changes are then implemented.
I have played with autocommit and commit with no effect so I figure it
must be a bug in either PHP or the ODBC drivers.
Here is one of the scripts with a totally unecessary select towards
the end to make it work.
http://www.justbiz.co.uk
[EMAIL PROTECTED]
+ 44 (0)870 841 3040
Project:Space Windows
Routine:ModifySeries2.php
Created:23/03/01
Descrip:Modify series number, title and description, update database.
Also inserts new records.
Revision: a
Rev. Date 23/03/01
Descrip:Created.
Parameters - From ModifySeries.php form
*/
error_reporting(63);
require("Security.php");
require("OpenDatabase.php");
if($SeriesId == "-1") {
// Create append query
$Query = "insert into tbl_Series ";
$Query .= "(SeriesNumber, ShortSeriesTitle, Description) ";
$Query .= "values('$SeriesNumber', '$ShortSeriesTitle',
'$Description')";
}
else {
// Create update query
$Query = "update tbl_Series ";
$Query .= "set SeriesNumber= '$SeriesNumber', ShortSeriesTitle=
'$ShortSeriesTitle', ";
$Query .= "Description= '$Description' where (SeriesId = $SeriesId)";
}
$Result = odbc_do($Connect, $Query);
?>
Space Windows - Series modified
");
$Query = "select SeriesId, SeriesNumber, ShortSeriesTitle, Description
from tbl_Series";
$Result = odbc_do($Connect, $Query);
while(odbc_fetch_row($Result)) {
print(odbc_result($Result,1));
print(odbc_result($Result,2)."");
}
if(!$Result) print("Failed");
Print("Database Updated for Series ".$SeriesNumber."");
?> Return to Series Page
--
Edit this bug report at http://bu
Bug #14748 Updated: ftp_put problems
ID: 14748
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: FTP related
Operating System: Unix
PHP Version: 4.0.5
New Comment:
The ftp site is on a Unix server.
The php file is on a Unix/Apache web server (actually, the same unix
server).
The file we are attempting to upload is from the directory of the
person connecting to the server, i.e., usually Windows.
This is still in the testing phase.
Ftp is properly enabled. The server says so. I had him add code for it
to show the phpinfo.
What is the proper syntax for the file on the user computer? Or is
this improper usage of the program?
i.e., do we use:
c:\\ftptesting\\test1.csv
or
c:\ftptesting\test1.csv
or
c:\ftptesting\\test1.csv
or something else entirely?
Or is there a flag we need to set to do this?
Yes, I am working with Bob on this.
Thank you,
Karen Chapdelaine
[EMAIL PROTECTED]
Previous Comments:
[2002-04-04 18:35:51] [EMAIL PROTECTED]
I have the same problem.
The client on windows.
The server on unix.
$conn_id = ftp_connect($ftp_server);
ftp_login($conn_id, $ftp_user_name, $ftp_user_pass);
ftp_put($conn_id, "./download", "D:\essai.map", FTP_BINARY);
[2002-04-04 11:51:26] [EMAIL PROTECTED]
Yes, I still have this problem. As a matter of fact, I have the same
problem when I use ftp_get. It won't recognize my local drive. It
thinks the directory path is part of the file name (i.e. local path is
"c:\\ftptesting\\testfile.csv". It thinks the file name is
"c"\\ftptesting\\testfile.csv").
My local machine is a Windows 2000 box and the ftp server is a Unix
box.
[2002-03-26 18:40:16] [EMAIL PROTECTED]
How can you have OS: "Unix" and a C: drive? That strikes me as odd.
The example you showed works for me on a windows box
with either forward slash or backslash if you get rid of the extra
closing ')' in the last line.
Do you still have this problem with php 4.1.2?
[2001-12-28 17:21:25] [EMAIL PROTECTED]
Okay, I've scoured the bug reports and the message lists and I'm not
convinced that it's even possible to upload from a local file to an ftp
server using ftp_put. No one seems to have a good answer to the
multiple listings of people having this problem. I don't believe my
problem is a security problem. My problem is that PHP wants to use the
directory that my PHP program is in as the default directory for
uploading. ftp_put won't recognize my C: drive as a local drive.
Here is the gist of the code that doesn't seem to be working:
$host = "ftp.cwplus.com";
$user = "username";
$password = "password";
$remotefile = "/www/cwplus/wendy/images/$filename";
$conn = ftp_connect("$host");
ftp_login($conn, $user, $password);
ftp_put($conn, $remotefile, "C:/test.txt", FTP_BINARY))
I've done all kinds of slash manipulation for the local file and none
seem to help.
Thanks,
Bob
--
Edit this bug report at http://bugs.php.net/?id=14748&edit=1
Bug #16437: Reference to function namespace variables
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.1.2
PHP Bug Type: Feature/Change Request
Bug description: Reference to function namespace variables
I request that there be an associative array variable for each function
that references the local name space of that function, similar to how the
$GLOBALS variable works but endemic only to that function.
Suggestions for possible names for this variable:
$FUNCTION
$_FUNCTION
$LOCAL
$_LOCAL
i.e.
function test(){
$_FUNCTION['abc'] = 'Hello';
echo $abc;
}
My reason for requesting this is so that I can have global functions
function test(){
$_FUNCTION = &$GLOBALS;
)
--
Edit bug report at http://bugs.php.net/?id=16437&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16437&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16437&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16437&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16437&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16437&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16437&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16437&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16437&r=submittedtwice
Bug #10155 Updated: Insert or update query not functioning correctly
ID: 10155
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: ODBC related
Operating System: Windows NT 4.0 build 1381
PHP Version: 4.0.4pl1
New Comment:
I am having the same or very similar problem:
(There's a bunch more code involved, of course, so I'm just including
relevant examples, below.)
< START EXAMPLE --->
<...appropriate persistent db access info...>
<...data-to-variable assignments...>
mysql_db_query("dbX","update tableX set col1='$data1' where
ID='$id'");
<...error-reporting code...>
echo mysql_affected_rows();
<-- END EXAMPLE -->
Result: no affected rows, no errors, and no update
I tried adding a SELECT statement immediately following the UPDATE
statement, per this bug report's suggestion:
Result: 1 affected row, no errors, and no update
So PHP thought 1 row had been updated...but it had not been.
This is a piece of script that we have been using successfully for
about 4 months, but it started to malfunction about 3 weeks ago.
INSERT, and DELETE statements work fine.
Version Info/Configuration:
FreeBSD 4.4 Release i386
PHP v. 4.1.2 (same problem with 4.0.6, by the way...)
Apache/1.3.12 OpenSSL/0.9.6a
MySQL v. 3.23.44
Thanks.
Previous Comments:
[2001-05-07 10:39:41] [EMAIL PROTECTED]
no feedback, considered closed. if untrue, please reopen the bug.
[2001-04-16 23:14:21] [EMAIL PROTECTED]
can you please provide a very simple test case for me? all local
attempts here have not yielded the same results as you are seeing.
a sample schema, and script to reproduce this would be very nice. but
please make sure it's all in the simplest form...
[2001-04-04 07:02:58] [EMAIL PROTECTED]
The database is Access 2000 with a few tables and relations set up in
the relationships area.
Put simply the update, insert and, possibly, delete querys all appear
to work perfectely with no errors reported, except that the database
ends up being unchanged afterwards. The only way I have been able to
fix this is to query the same table with a select before the end of the
script, the changes are then implemented.
I have played with autocommit and commit with no effect so I figure it
must be a bug in either PHP or the ODBC drivers.
Here is one of the scripts with a totally unecessary select towards
the end to make it work.
http://www.justbiz.co.uk
[EMAIL PROTECTED]
+ 44 (0)870 841 3040
Project:Space Windows
Routine:ModifySeries2.php
Created:23/03/01
Descrip:Modify series number, title and description, update database.
Also inserts new records.
Revision: a
Rev. Date 23/03/01
Descrip:Created.
Parameters - From ModifySeries.php form
*/
error_reporting(63);
require("Security.php");
require("OpenDatabase.php");
if($SeriesId == "-1") {
// Create append query
$Query = "insert into tbl_Series ";
$Query .= "(SeriesNumber, ShortSeriesTitle, Description) ";
$Query .= "values('$SeriesNumber', '$ShortSeriesTitle',
'$Description')";
}
else {
// Create update query
$Query = "update tbl_Series ";
$Query .= "set SeriesNumber= '$SeriesNumber', ShortSeriesTitle=
'$ShortSeriesTitle', ";
$Query .= "Description= '$Description' where (SeriesId = $SeriesId)";
}
$Result = odbc_do($Connect, $Query);
?>
Space Windows - Series modified
");
$Query = "select SeriesId, SeriesNumber, ShortSeriesTitle, Description
from tbl_Series";
$Result = odbc_do($Connect, $Query);
while(odbc_fetch_row($Result)) {
print(odbc_result($Result,1));
print(odbc_result($Result,2)."");
}
if(!$Result) print("Failed");
Print("Database Updated for Series ".$SeriesNumber."");
?> Return to Series Page
--
Edit this bug report at http://bugs.php.net/?id=10155&edit=1
Bug #16430 Updated: phpinfo displaying wrong default include_path
ID: 16430 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed Bug Type: PHP options/info functions Operating System: Linux (Cobalt RaQ3) -PHP Version: 4.1.2 +PHP Version: 4.2.0RC2 New Comment: Tested with PHP 4.2.0RC2 and got the same result. The bug is in phpinfo() output which should show empty string there. If you want to have the default builtin path, comment out the whole include_path line in php.ini --Jani Previous Comments: [2002-04-04 12:06:30] [EMAIL PROTECTED] Given a "php.ini" file with: include_path = ; UNIX:"/path1:/path2" Windows:"\path1;\path2" "phpinfo();" reports: include_path = .:/usr/local/lib/php "require_once 'DB.php';" fails: Fatal error: Failed opening required 'DB.php' (include_path='') in ... on line ... I believe that the "include_path" should just default to "." according to the PHP documentation. So "phpinfo()" seems to report a wrong default "include_path". (Everything works just fine when the "php.ini" "include_path" is actually set to ".:/usr/local/lib/php".) -- Edit this bug report at http://bugs.php.net/?id=16430&edit=1
Bug #14748 Updated: ftp_put problems
ID: 14748
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: FTP related
Operating System: Unix
PHP Version: 4.0.5
New Comment:
I have the same problem.
The client on windows.
The server on unix.
$conn_id = ftp_connect($ftp_server);
ftp_login($conn_id, $ftp_user_name, $ftp_user_pass);
ftp_put($conn_id, "./download", "D:\essai.map", FTP_BINARY);
Previous Comments:
[2002-04-04 11:51:26] [EMAIL PROTECTED]
Yes, I still have this problem. As a matter of fact, I have the same
problem when I use ftp_get. It won't recognize my local drive. It
thinks the directory path is part of the file name (i.e. local path is
"c:\\ftptesting\\testfile.csv". It thinks the file name is
"c"\\ftptesting\\testfile.csv").
My local machine is a Windows 2000 box and the ftp server is a Unix
box.
[2002-03-26 18:40:16] [EMAIL PROTECTED]
How can you have OS: "Unix" and a C: drive? That strikes me as odd.
The example you showed works for me on a windows box
with either forward slash or backslash if you get rid of the extra
closing ')' in the last line.
Do you still have this problem with php 4.1.2?
[2001-12-28 17:21:25] [EMAIL PROTECTED]
Okay, I've scoured the bug reports and the message lists and I'm not
convinced that it's even possible to upload from a local file to an ftp
server using ftp_put. No one seems to have a good answer to the
multiple listings of people having this problem. I don't believe my
problem is a security problem. My problem is that PHP wants to use the
directory that my PHP program is in as the default directory for
uploading. ftp_put won't recognize my C: drive as a local drive.
Here is the gist of the code that doesn't seem to be working:
$host = "ftp.cwplus.com";
$user = "username";
$password = "password";
$remotefile = "/www/cwplus/wendy/images/$filename";
$conn = ftp_connect("$host");
ftp_login($conn, $user, $password);
ftp_put($conn, $remotefile, "C:/test.txt", FTP_BINARY))
I've done all kinds of slash manipulation for the local file and none
seem to help.
Thanks,
Bob
--
Edit this bug report at http://bugs.php.net/?id=14748&edit=1
Bug #15945 Updated: While starting Apache I get an undefined symbol error.mysql_field_count
ID: 15945 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: MySQL related Operating System: RedHat 7.2 PHP Version: 4.1.2 New Comment: If you could please try the PHP 4.2.0 RC2 to see if this happens with it too..http://www.php.net/~derick/ Also, you could try compiling with the bundled mysql libs. ie. leave the path out from the --with-mysql option. --Jani Previous Comments: [2002-03-08 07:08:44] [EMAIL PROTECTED] Try checking first that the libphp4.so is finding all necessary libraries: # ldd /etc/httpd/modules/libphp4.so Produced: [root@localhost etc]# ldd /etc/httpd/modules/libphp4.so libc.so.6 => /lib/i686/libc.so.6 (0x4011e000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) Added /usr/local/mysql/lib/mysql to /etc/ld.so.comfig leaving off the trailing "/" because the other entries didn't have one. Ran /sbin/ldconfigwithout apparent effect as it came back to the command line without any messages. Undefined symbol error unchanged. . [2002-03-08 03:00:28] [EMAIL PROTECTED] Try checking first that the libphp4.so is finding all necessary libraries: # ldd /etc/httpd/modules/libphp4.so As you might not have /usr/local/mysql/lib/mysql/ in your /etc/ld.so.conf Try adding it and run /sbin/ldconfig --Jani [2002-03-07 22:53:01] [EMAIL PROTECTED] While starting Apache I get an undefined symbol error. mysql_field_count Running RedHat 7.2 Installed MySQL 3.23.49a from binary into /usr/local/mysql from mysql-3.23.49a-pc-linux-gnu-i686. MySQL runs correctly. php-4.1.2.tar.gz untarred into php-4.1.2 build was ./configure "--with-mysql=/usr/local/mysql and --with-apxs=/usr/sbin/apxs" ran correctly (without error) make ran without error make install ran without error Apache won't start, reporting "undefined symbol" /etc/rc.d/init.d/httpd start Starting httpd: Syntax error on line 261 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/libphp4.so into server: /etc/httpd/modules/libphp4.so: undefined symbol: mysql_field_count [FAILED] -- Edit this bug report at http://bugs.php.net/?id=15945&edit=1
Bug #16305 Updated: curl post doesn't behave as per the manual
ID: 16305
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: cURL related
Operating System: Any
PHP Version: 4.1.2
New Comment:
I am Daniel Stenberg, quoted below. That quote is rather old and does
not apply to recent PHP.
What *is* the essence of this report, AFAICT, is somewhat confused (and
the PUT part is entirely incorrect) but I'll try to sum up things:
The bug report should've said:
If you set CURLOPT_POST to 1, and then pass an array to
CURLOPT_POSTFIELDS, it sets Content-type to multipart/form-data instead
of application/x-www-form-urlencoded.
I believe this is still true in the most recent versions of
ext/curl/curl.c, but I may be mistaking.
Again, if you pass an array it makes a multipart formpost, if you pass
a string it makes a regular http post.
Previous Comments:
[2002-04-04 07:50:10] [EMAIL PROTECTED]
Reopen if this doesn't work in PHP 4.2.0.
(works fine here)
[2002-04-04 07:44:27] [EMAIL PROTECTED]
Unfortunately, like 90% of people using PHP I am reliant on my host for
compiling and installing PHP, so I can't test it :-(
[2002-04-04 07:34:52] [EMAIL PROTECTED]
PHP 4.2.0-dev does not use curl_formparse..please try
the RC2 from http://www.php.net/~derick/
[2002-03-27 03:49:03] [EMAIL PROTECTED]
The curl extension is not behaving as described in the manual.
If you set CURLOPT_POST to 1, and then pass an array to
CURLOPT_POSTFIELDS, it sets Content-type to multipart/form-data instead
of application/x-www-form-urlencoded. This is wrong: the multipart
header should only be used when CURLOPT_PUT is set. To quote the PHP
manual:
{{{CURLOPT_POST: Set this option to a non-zero value if you want PHP to
do a regular HTTP POST. This POST is a normal
application/x-www-form-urlencoded kind, most commonly used by HTML
forms.}}}
Here is what the author of curl (Daniel Stenberg) says - full message
at :
{{{I took a tour into the inner workings of the php curl wrapper code
and I've now returned to tell about my findings! ;-)
When you pass an array to CURLOPT_POSTFIELDS, it is passed as a
multipart/form-data post exactly as you describe. The problem with this
is that it uses the libcurl function curl_formparse() to accomplish
this, and that is a lame function(*).
It does not support newlines in the contents like you tried here.
The wrapper should instead use the new (and much better) curl_formadd()
function for this purpose. It does not have this newline problem.
(*) = yet it was the only available one for a very long time.}}}
I think there is enough evidence here to change the behaviour of the
extension - I think it can be done without breaking backwards
compatibility. The extension was never meant to behave like this, as
the manual testifies.
Regards,
Peter Bowyer.
--
Edit this bug report at http://bugs.php.net/?id=16305&edit=1
Bug #16353 Updated: can upload other files but not zip or visio files
ID: 16353
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: HTTP related
Operating System: Irix 6.5
PHP Version: 4.0.6
New Comment:
You're right about it being browser related. Uploading zip and visio
files works with IE 6, but not with Netscape 6.2 or 4.7x and not with
IE 5.0. I haven't tested IE 5.5. Our admin will compile and install
the latest RC in the next few days. I'll report back on how that
affected uploads of our problem files.
Previous Comments:
[2002-04-02 13:40:39] [EMAIL PROTECTED]
I think it's a problem with your browser, not with PHP. Anyway, can you
try the latest RC from www.php.net/~derick ?
[2002-03-29 16:28:08] [EMAIL PROTECTED]
I have file uploads working with images, Word and Excel files and text
files, but when I try to upload zip or visio files I see this message:
"Unable to open 'none' for reading. No such file or directory..." It
captures the name and mime type (application/x-zip-compressed and
application/octet-stream, resp.) but $attachment is set to 'none' and
$attachment_size is 0.
Here's the relevant part of the form:
Here's the relevant part of the script that handles it:
$strLength1 = strlen($attachment_name);
if ($strLength1 > 0) {
$suffix1 = substr($attachment_name,($strLength1 - 4),4);
$upfile1 =
"/www/pub/changecontrol/files/".$latestRecord."-1".$suffix1;
//$latestRecord is defined earlier
if (!copy($attachment,$upfile1)) {
echo "Problem: Could not move file into directory.";
exit;
}
}
Any workaround for this?
We're using Apache 1.3.18.
--
Edit this bug report at http://bugs.php.net/?id=16353&edit=1
Bug #16436: ereg causes apache crashes
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0CVS-2002-04-04 PHP Bug Type: PCRE related Bug description: ereg causes apache crashes this line crashes the apache process with php 4.2.0RC2 as a module Lutz -- Edit bug report at http://bugs.php.net/?id=16436&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16436&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16436&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16436&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16436&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16436&r=support Expected behavior: http://bugs.php.net/fix.php?id=16436&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16436&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16436&r=submittedtwice
Bug #16435: follow up bug 16043, $_SESSION can't use in PHP 4.1.2, PHP 4.2.0RC1
From: [EMAIL PROTECTED] Operating system: Windows 2000/XP PHP version: 4.1.2 PHP Bug Type: Session related Bug description: follow up bug 16043, $_SESSION can't use in PHP 4.1.2, PHP 4.2.0RC1 I seem to have configuration problemsi just can't seem to get session variables written to in files under win2000, NTFS w/ Apache 1.3.23 and PHP 4.1.2 ..i've already done everything from session_start() on every page to making var globalanybody can help?? thanksbtw, i got the same system on a Linux box running apache and php and it works fine sample of my code: Apparently under the bug report database for bug number 16043, my exactly problem was described. According to the PHP team, this windows/apache1.3.23/php4.1.2 session not writing to file bug has been fixed in the 4.2.0RC1 binaries. I've patched my php4apache.dll with the ones from 4.2.0RC1 AND it still doesn't work!!! Anyone who used 4.2.0RC1 came across this problem and made it work? -- Edit bug report at http://bugs.php.net/?id=16435&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16435&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16435&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16435&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16435&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16435&r=support Expected behavior: http://bugs.php.net/fix.php?id=16435&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16435&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16435&r=submittedtwice
Bug #16434: Build Error
From: [EMAIL PROTECTED] Operating system: Linux 2.4.2-2 PHP version: 4.1.2 PHP Bug Type: Apache2 related Bug description: Build Error sapi_apache2.c refuses to build with Apache 2.0.32. The function call to ap_get_brigade, line 247, needs the APR_BLOCK_READ or APR_NONBLOCK_READ parameter added to the call. I don't know which is appropriate, so I chose to BLOCK. -- Edit bug report at http://bugs.php.net/?id=16434&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16434&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16434&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16434&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16434&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16434&r=support Expected behavior: http://bugs.php.net/fix.php?id=16434&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16434&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16434&r=submittedtwice
Bug #16433 Updated: Can't have support for png under gd
ID: 16433 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: GD related Operating System: Solaris 8 sparc PHP Version: 4.1.2 New Comment: Do NOT open two bugs for the same issue Previous Comments: [2002-04-04 13:49:17] [EMAIL PROTECTED] Compiling PHP 4.1.2 with apache 1.3.19 with gcc 2.95.3 under solaris 8 sparc 64 bit refuses to enable png support under gd. I have tryed all the good options (--with-png-dir=, --with-gd, etc.) all avalable gd, png, zlib library versions I could find, that compiles fine, and under many directories... Always the same result: it compiles fine without errors or warnings, it works fine for everything exept for png or even jpeg support under gd (I can see that under phpinfo, or when I try to use gd/png functions)... What the hell is wrong... I have made the same build under linux RedHat 6.2 or RedHat 7.2 and it works... I have tried to build it about 20 times differently under solaris and it does not work. Need help here. Thanks. -- Edit this bug report at http://bugs.php.net/?id=16433&edit=1
Bug #16433: Can't have support for png under gd
From: [EMAIL PROTECTED] Operating system: Solaris 8 sparc PHP version: 4.1.2 PHP Bug Type: GD related Bug description: Can't have support for png under gd Compiling PHP 4.1.2 with apache 1.3.19 with gcc 2.95.3 under solaris 8 sparc 64 bit refuses to enable png support under gd. I have tryed all the good options (--with-png-dir=, --with-gd, etc.) all avalable gd, png, zlib library versions I could find, that compiles fine, and under many directories... Always the same result: it compiles fine without errors or warnings, it works fine for everything exept for png or even jpeg support under gd (I can see that under phpinfo, or when I try to use gd/png functions)... What the hell is wrong... I have made the same build under linux RedHat 6.2 or RedHat 7.2 and it works... I have tried to build it about 20 times differently under solaris and it does not work. Need help here. Thanks. -- Edit bug report at http://bugs.php.net/?id=16433&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16433&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16433&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16433&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16433&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16433&r=support Expected behavior: http://bugs.php.net/fix.php?id=16433&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16433&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16433&r=submittedtwice
Bug #16432 Updated: fwrite fails on long text string
ID: 16432 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Filesystem function related Operating System: Linux 2.2.18 PHP Version: 4.1.2 New Comment: I can't install the RC on the server right now (its a production machine and my dev is currently under repair). If its not easily reproduceable, I guess don't worry about it, the workaround for me isn't that hard. Previous Comments: [2002-04-04 13:44:03] [EMAIL PROTECTED] Can't reproduce. Just wrote about 300 megs in one call :) I'm runnig Linux 2.4.17. Can you try 4.2.0RC2 from www.php.net/~derick ? [2002-04-04 13:28:06] [EMAIL PROTECTED] fwrite appears to fail when the input string is too long (on the order of 160k). I've been creating dynamic stats pages from a database and writing them to a file. Recently the text to write has exceed some threshold that caused fwrite to not write to the fill and to not return an error code. Writing the files in chunks fixes the problem. However, there is nothing in the documentation about max length of strings to write. -- Edit this bug report at http://bugs.php.net/?id=16432&edit=1
Bug #16432 Updated: fwrite fails on long text string
ID: 16432 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Filesystem function related Operating System: Linux 2.2.18 PHP Version: 4.1.2 New Comment: Can't reproduce. Just wrote about 300 megs in one call :) I'm runnig Linux 2.4.17. Can you try 4.2.0RC2 from www.php.net/~derick ? Previous Comments: [2002-04-04 13:28:06] [EMAIL PROTECTED] fwrite appears to fail when the input string is too long (on the order of 160k). I've been creating dynamic stats pages from a database and writing them to a file. Recently the text to write has exceed some threshold that caused fwrite to not write to the fill and to not return an error code. Writing the files in chunks fixes the problem. However, there is nothing in the documentation about max length of strings to write. -- Edit this bug report at http://bugs.php.net/?id=16432&edit=1
Bug #14044 Updated: GD(PNG) support stops working
ID: 14044 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: GD related Operating System: Solaris 2.8 (Sparc) PHP Version: 4.0.6 New Comment: It is working for me with PHP 4.1.2 and Apache 1.3.22, and zlib 1.1.3 png and jpeg libs installed under /usr/local/ These were my configure options> ./configure --with-apache=../apache_1.3.22 --with-mm=/usr/local --with-openssl=/usr/local/ssl --with-imap=../imap-2001a --with-imap-ssl=/usr/local/ssl --with-xml --with-mysql=/usr/local/mysql --with-pgsql=/export/pgsql --enable-track-vars --enable-versioning --with-mcrypt --with-gd --with-png-dir=/usr/local --with-jpeg-dir=/usr/local --enable-ftp --enable-sysvsem --enable-sysvshm --with-zlib It compiles and works OK under Solaris8/Sparc Previous Comments: [2002-04-04 13:28:01] [EMAIL PROTECTED] compiling PHP 4.1.2 with apache 1.3.19 with gcc under solaris 8 sparc 64 bit also refuses to enable png support under gd. I have tryed all the good options (--with-png-dir=, --with-gd, etc.) all avalable gd, png, zlib versions that compiles fine under many directories... Always the same result: it compiles fine without errors or warnings, it works fine for everything exept for png or even jpeg support under gd (I can see that under phpinfo, or when I try to use png functions)... What the hell is wrong... I have made the same build under linux RedHat 6.2 or RedHat 7.2 and it works... Aaaahhh [2001-11-14 08:05:10] [EMAIL PROTECTED] OK. If it's works, let's close this one. [2001-11-14 07:40:19] [EMAIL PROTECTED] It works ok. I already used --with-zlib, apache wont compile without it. [2001-11-14 06:35:20] [EMAIL PROTECTED] Include --with-zlib also. Does it work? [2001-11-13 17:30:55] [EMAIL PROTECTED] --with-png-dir= --with-jpeg-dir= Use this configure commands to set PNGLIB and JPEG dir. I try'd you configure and its works nice for me under FreeBSD 4.4 Redhat 7.1 SuSE 7.x Tested PHP Versions 4.0.6 4.1.0RC1 + RC2 4.2.0... works nice with all The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/14044 -- Edit this bug report at http://bugs.php.net/?id=14044&edit=1
Bug #16432: fwrite fails on long text string
From: [EMAIL PROTECTED] Operating system: Linux 2.2.18 PHP version: 4.1.2 PHP Bug Type: Filesystem function related Bug description: fwrite fails on long text string fwrite appears to fail when the input string is too long (on the order of 160k). I've been creating dynamic stats pages from a database and writing them to a file. Recently the text to write has exceed some threshold that caused fwrite to not write to the fill and to not return an error code. Writing the files in chunks fixes the problem. However, there is nothing in the documentation about max length of strings to write. -- Edit bug report at http://bugs.php.net/?id=16432&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16432&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16432&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16432&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16432&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16432&r=support Expected behavior: http://bugs.php.net/fix.php?id=16432&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16432&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16432&r=submittedtwice
Bug #14044 Updated: GD(PNG) support stops working
ID: 14044 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: GD related Operating System: Solaris 2.8 (Sparc) PHP Version: 4.0.6 New Comment: compiling PHP 4.1.2 with apache 1.3.19 with gcc under solaris 8 sparc 64 bit also refuses to enable png support under gd. I have tryed all the good options (--with-png-dir=, --with-gd, etc.) all avalable gd, png, zlib versions that compiles fine under many directories... Always the same result: it compiles fine without errors or warnings, it works fine for everything exept for png or even jpeg support under gd (I can see that under phpinfo, or when I try to use png functions)... What the hell is wrong... I have made the same build under linux RedHat 6.2 or RedHat 7.2 and it works... Aaaahhh Previous Comments: [2001-11-14 08:05:10] [EMAIL PROTECTED] OK. If it's works, let's close this one. [2001-11-14 07:40:19] [EMAIL PROTECTED] It works ok. I already used --with-zlib, apache wont compile without it. [2001-11-14 06:35:20] [EMAIL PROTECTED] Include --with-zlib also. Does it work? [2001-11-13 17:30:55] [EMAIL PROTECTED] --with-png-dir= --with-jpeg-dir= Use this configure commands to set PNGLIB and JPEG dir. I try'd you configure and its works nice for me under FreeBSD 4.4 Redhat 7.1 SuSE 7.x Tested PHP Versions 4.0.6 4.1.0RC1 + RC2 4.2.0... works nice with all [2001-11-13 17:02:46] [EMAIL PROTECTED] Upgrading from PHP 4.0.5 to 4.0.6 will make gd support stop working. GD, libpng and libjpeg are installed under /usr/local. The error is: No PNG support in this PHP build I am adding the --with-gd configure option. A downgrade to 4.0.5 solved the problem without changing nothing else. I am using Apache 1.3.22 and installed with --with-apache=../apache_1.3.22 configure option. -- Edit this bug report at http://bugs.php.net/?id=14044&edit=1
Bug #15333 Updated: strndup access violation
ID: 15333
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: IIS related
Operating System: Windows 2000 Pro
PHP Version: 4.1.1
New Comment:
I think I've found the problem:
ZEND_API char *zend_strndup(const char *s, uint length)
{
char *p;
p = (char *) malloc(length+1);
if (!p) {
return (char *)NULL;
}
if (length) {
memcpy(p, s, length);
}
p[length] = 0;
return p;
}
If this is changed to
ZEND_API char *zend_strndup(const char *s, uint length)
{
char *p;
p = (char *) malloc(length+1);
if (!p) {
return (char *)NULL;
}
if (length) {
memcpy(p, s, length);
p[length] = 0;
}
return p;
}
does that break anything? I think the problem comes in when length==0.
I can't really reproduce this problem though. I saw it once a couple
of days ago, but havn't seen it since.
Also will one of you that's having this problem please check to see if
4.2.0 RC 2 still has this problem? Since 4.2.0 is going to be released
really soon now, I'd like to get this worked through (but if it doesn't
happen anymore under 4.2.0 then we're worrying about nothing).
Previous Comments:
[2002-04-04 10:27:27] [EMAIL PROTECTED]
I've been having the same problem.
Win2k (All security updates)
IIS 5.0
Pentium III 733
ISAPI Version 4.1.2
I switched security on each virtual directory to 'Low(IIS Process) and
haven't gotten the error since. This isn't a satisfactory fix, but
maybe it'll help figure out what is causing the problem.
[2002-04-04 10:09:46] [EMAIL PROTECTED]
Bug #16362 was marked a duplicate of this bug.
[2002-04-03 19:35:48] [EMAIL PROTECTED]
I got this error after aplying the lateste security updates on my win2k
server. It works fine at the begginig but after 5 mins I get this
error. It hangs all the IIS service.
This doesn't happen in CGI mode.
OS: Win2K Server
Patches: SP2 + Lateste Security updates
System: P3 @ 550 Mhz - 256 MB RAM
PHP VER: 4.1.2.
PHP Mode: ISAPI
[2002-02-19 09:06:12] [EMAIL PROTECTED]
Nope, I am not using Zend Encoder or Optimizer. Just running plain PHP
for now.
[2002-02-19 08:52:53] [EMAIL PROTECTED]
Are you using Zendencoder? I have the same problem on a machine running
Zendoptimizer with some pages that were Zendencoded. The server crashed
every 20-30 request or so. I took off the pages Zendencoded and its
working fine now... Seems that the problem stands there...
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/15333
--
Edit this bug report at http://bugs.php.net/?id=15333&edit=1
Bug #16417 Updated: session_id() not working
ID: 16417 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Session related Operating System: WinXP/Win2K PHP Version: 4.1.1 New Comment: It should not matter if you use an underscore. Reopening. Derick Previous Comments: [2002-04-04 12:29:33] [EMAIL PROTECTED] Aha! It appears that it is the underscore causing the problem. [2002-04-04 04:20:48] [EMAIL PROTECTED] No, it causes the same problem. I've tried it on Win2K/4.1.2, Win2K/4.2.0RC1 now too. I don't see how you can reset the session_id after calling session start anyway. When session_start() is called, the SID constant is set, cookie sent to the client etc. You must have to set a custom session_id before this happens. [2002-04-04 04:11:55] [EMAIL PROTECTED] Maybe you have to call session_id AFTER session_start()? This is what the docs say: "session_id() returns the session id for the current session. If id is specified, it will replace the current session id." If the session hasn't been started yet, there's no session id to replace. Does it work now? [2002-04-04 02:58:30] [EMAIL PROTECTED] How do you know I don't have a reason to change the session id? :-) Why claim to provide the functionality, then refuse to support it? I *do* need to change the session id. It is unavoidable. [2002-04-04 00:03:55] [EMAIL PROTECTED] You really don't have any reason to change the session id. 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/16417 -- Edit this bug report at http://bugs.php.net/?id=16417&edit=1
Bug #15218 Updated: file_exists ('') returns TRUE
ID: 15218
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Filesystem function related
Operating System: Windows XP
PHP Version: 4.1.0
New Comment:
$f = fopen ("php://stdin", "r");
Previous Comments:
[2002-04-04 11:40:45] [EMAIL PROTECTED]
As a side note, perhaps the current version is correct. Opening a
blank file name in most console languages (Turbo C/Turbo Pascal), opens
a handle to the console for input/output.
If you were planning on using PHP for console development, wouldn't you
want an easy way to open the stdio types?
[2002-01-25 01:44:07] [EMAIL PROTECTED]
The following will echo "I FOUND NOTHING!" on Windows XP running PHP
(version 4.1.0), but on linux PHP (Version 4.0.4) returns FALSE which
is correct.
--
Edit this bug report at http://bugs.php.net/?id=15218&edit=1
Bug #16423 Updated: Sess_* files don't store data
ID: 16423 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Session related Operating System: Windows NT / IIS4 PHP Version: 4.1.2 New Comment: I've downloaded the new php4apache.dll which was modified on the 20th of March.still did not solve the sess_ write over access problem. My $_SESSION[vars] still do not propagate across pages... Previous Comments: [2002-04-04 04:51:35] [EMAIL PROTECTED] Can you please try the windows binaries from www.php.net/~derick/php-4.2.0RC1/ ? Derick [2002-04-04 04:48:05] [EMAIL PROTECTED] It seems this bug has been reported yet, but maybe I give some other infos; session file sess_xx are created but NOT filled with vars values, so that $_SESSION[...] are not propagated between pages. I have two simple php pages using a $_SESSION["myvar"] variable that works fine on linux+apache; I can see vars stored in temp session file. The same 2 pages do not work on WinNT/IIS4; the sess_xxx file is empty and "Warning: Undefined index:..." is reported by the second page when I do a submit from the first. If I "cut and past" the sess_xxx entries from the linux box into sess_xxx on NT It works fine ! So I think it's a problem of file rights or something like that. I modified IIS guest account, temp dir rights... but without success. Hope to be helpful, regards, andrea -- Edit this bug report at http://bugs.php.net/?id=16423&edit=1
Bug #16417 Updated: session_id() not working
ID: 16417 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Session related Operating System: WinXP/Win2K PHP Version: 4.1.1 New Comment: Aha! It appears that it is the underscore causing the problem. Previous Comments: [2002-04-04 04:20:48] [EMAIL PROTECTED] No, it causes the same problem. I've tried it on Win2K/4.1.2, Win2K/4.2.0RC1 now too. I don't see how you can reset the session_id after calling session start anyway. When session_start() is called, the SID constant is set, cookie sent to the client etc. You must have to set a custom session_id before this happens. [2002-04-04 04:11:55] [EMAIL PROTECTED] Maybe you have to call session_id AFTER session_start()? This is what the docs say: "session_id() returns the session id for the current session. If id is specified, it will replace the current session id." If the session hasn't been started yet, there's no session id to replace. Does it work now? [2002-04-04 02:58:30] [EMAIL PROTECTED] How do you know I don't have a reason to change the session id? :-) Why claim to provide the functionality, then refuse to support it? I *do* need to change the session id. It is unavoidable. [2002-04-04 00:03:55] [EMAIL PROTECTED] You really don't have any reason to change the session id. [2002-04-03 18:10:21] [EMAIL PROTECTED] Using my own session id doesn't appear to work Causes Apache (1.3.22) to crash on Win2K/4.1.1 and produces "Warning: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (c:\\windows\\temp) in Unknown on line 0" on WinXP/4.2.0RC1 Without calling changing the session id, there are no problems -- Edit this bug report at http://bugs.php.net/?id=16417&edit=1
Bug #16430: phpinfo displaying wrong default include_path
From: [EMAIL PROTECTED] Operating system: Linux (Cobalt RaQ3) PHP version: 4.1.2 PHP Bug Type: PHP options/info functions Bug description: phpinfo displaying wrong default include_path Given a "php.ini" file with: include_path = ; UNIX:"/path1:/path2" Windows:"\path1;\path2" "phpinfo();" reports: include_path = .:/usr/local/lib/php "require_once 'DB.php';" fails: Fatal error: Failed opening required 'DB.php' (include_path='') in ... on line ... I believe that the "include_path" should just default to "." according to the PHP documentation. So "phpinfo()" seems to report a wrong default "include_path". (Everything works just fine when the "php.ini" "include_path" is actually set to ".:/usr/local/lib/php".) -- Edit bug report at http://bugs.php.net/?id=16430&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16430&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16430&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16430&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16430&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16430&r=support Expected behavior: http://bugs.php.net/fix.php?id=16430&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16430&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16430&r=submittedtwice
Bug #14748 Updated: ftp_put problems
ID: 14748
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: FTP related
Operating System: Unix
PHP Version: 4.0.5
New Comment:
Yes, I still have this problem. As a matter of fact, I have the same
problem when I use ftp_get. It won't recognize my local drive. It
thinks the directory path is part of the file name (i.e. local path is
"c:\\ftptesting\\testfile.csv". It thinks the file name is
"c"\\ftptesting\\testfile.csv").
My local machine is a Windows 2000 box and the ftp server is a Unix
box.
Previous Comments:
[2002-03-26 18:40:16] [EMAIL PROTECTED]
How can you have OS: "Unix" and a C: drive? That strikes me as odd.
The example you showed works for me on a windows box
with either forward slash or backslash if you get rid of the extra
closing ')' in the last line.
Do you still have this problem with php 4.1.2?
[2001-12-28 17:21:25] [EMAIL PROTECTED]
Okay, I've scoured the bug reports and the message lists and I'm not
convinced that it's even possible to upload from a local file to an ftp
server using ftp_put. No one seems to have a good answer to the
multiple listings of people having this problem. I don't believe my
problem is a security problem. My problem is that PHP wants to use the
directory that my PHP program is in as the default directory for
uploading. ftp_put won't recognize my C: drive as a local drive.
Here is the gist of the code that doesn't seem to be working:
$host = "ftp.cwplus.com";
$user = "username";
$password = "password";
$remotefile = "/www/cwplus/wendy/images/$filename";
$conn = ftp_connect("$host");
ftp_login($conn, $user, $password);
ftp_put($conn, $remotefile, "C:/test.txt", FTP_BINARY))
I've done all kinds of slash manipulation for the local file and none
seem to help.
Thanks,
Bob
--
Edit this bug report at http://bugs.php.net/?id=14748&edit=1
Bug #15218 Updated: file_exists ('') returns TRUE
ID: 15218 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Filesystem function related Operating System: Windows XP PHP Version: 4.1.0 New Comment: As a side note, perhaps the current version is correct. Opening a blank file name in most console languages (Turbo C/Turbo Pascal), opens a handle to the console for input/output. If you were planning on using PHP for console development, wouldn't you want an easy way to open the stdio types? Previous Comments: [2002-01-25 01:44:07] [EMAIL PROTECTED] The following will echo "I FOUND NOTHING!" on Windows XP running PHP (version 4.1.0), but on linux PHP (Version 4.0.4) returns FALSE which is correct. -- Edit this bug report at http://bugs.php.net/?id=15218&edit=1
Bug #16428 Updated: bzopen fails to open file
ID: 16428
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Bzip2 Related
Operating System: Linux
-PHP Version: 4.0CVS-2002-04-04
+PHP Version: 4.0CVS-2002-04-0
New Comment:
This bug has been fixed in CVS.
Thanks Wez!!!
Previous Comments:
[2002-04-04 08:24:29] [EMAIL PROTECTED]
This only applies to HEAD, not to 4.2.0.
bzopen("/full/path/to/file.bz2", "r");
results in
Warning - bzopen("Üøs F<") - No such file or directory
--
Edit this bug report at http://bugs.php.net/?id=16428&edit=1
Bug #16412 Updated: Using session_start() repeatedly (on different pages) causes HTTP 500
ID: 16412 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Windows XP PHP Version: 4.1.2 New Comment: Ok this is wierd but I've noticed that once I started getting the HTTP 500 errors I couldnt get even a simple script eg to work. I tried checking the "Check that file exists" on the application extension mapping in IIS and it all seems to work now. Odd. Previous Comments: [2002-04-03 12:04:53] [EMAIL PROTECTED] I've had this with a more complex script but here is a cut down version. When I call session_start() in my script then link to another page that calls session_start() I eventually get HTTP 500 internal server error. This usually happens after 3 or 4 links. Its fine for the first few links usually. I'm running on the version of IIS that comes with XP Pro. I changed none of the php.ini setting during installation apart from the session var directory which is now f:\data\websites\sessions. The version of PHP is the binary of v4.1.2 for windows downloaded from php.net. I'm running as CGI. Here is an example of the code that exhibits the problem. If I keep clicking the "Click me" link it throws the error after 3-4 clicks most of the time. Click me Rob -- Edit this bug report at http://bugs.php.net/?id=16412&edit=1
Bug #15333 Updated: strndup access violation
ID: 15333 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: IIS related Operating System: Windows 2000 Pro PHP Version: 4.1.1 New Comment: I've been having the same problem. Win2k (All security updates) IIS 5.0 Pentium III 733 ISAPI Version 4.1.2 I switched security on each virtual directory to 'Low(IIS Process) and haven't gotten the error since. This isn't a satisfactory fix, but maybe it'll help figure out what is causing the problem. Previous Comments: [2002-04-04 10:09:46] [EMAIL PROTECTED] Bug #16362 was marked a duplicate of this bug. [2002-04-03 19:35:48] [EMAIL PROTECTED] I got this error after aplying the lateste security updates on my win2k server. It works fine at the begginig but after 5 mins I get this error. It hangs all the IIS service. This doesn't happen in CGI mode. OS: Win2K Server Patches: SP2 + Lateste Security updates System: P3 @ 550 Mhz - 256 MB RAM PHP VER: 4.1.2. PHP Mode: ISAPI [2002-02-19 09:06:12] [EMAIL PROTECTED] Nope, I am not using Zend Encoder or Optimizer. Just running plain PHP for now. [2002-02-19 08:52:53] [EMAIL PROTECTED] Are you using Zendencoder? I have the same problem on a machine running Zendoptimizer with some pages that were Zendencoded. The server crashed every 20-30 request or so. I took off the pages Zendencoded and its working fine now... Seems that the problem stands there... [2002-02-01 15:41:48] [EMAIL PROTECTED] I am getting an access violation in php4ts!zend_strndup + 0x2B + 0xA05CB1AD. It is reproducable after about 20 or 30 requests, but it isn't a certain page that causes it. A page refresh may or may not display the page without error. Eventually the server will no longer serve pages at all and only a reboot will bring the web server back. Stopping IIS just sits there attempting to stop the service. Details: Windows 2000 Pro with service pack 2 and all critical and security updates from windowsupdate.microsoft.com K6-2 500MHz with 192Meg RAM I have the exact setup on my machine using an Athlon 1.2GHz with 512Meg RAM without any problem. However on two machines with an AMD K6-2 (configured identically) the web server will stop responding to requests consistently. I have also tested this on my Dell laptop with an Intel PIII/700MHz 256 Meg RAM with same Windows 2000 pro w/sp2 and all updates without any problem. When the server does stop serving pages the DLLHOST.EXE process virtual memory size goes to the max for the machine. I have installed php as an ISAPI module. I have also tried installing PHP as a CGI and have the same problem. I have tested this with php 4.0.6, 4.1.0, and 4.1.1 and have the same problem in zend_strndup with all three. I am using the windows zip file from the php.net download page. Also I am using the Interbase extension. No other extensions are being used. I hope I included enough info here. Thanks. -- Edit this bug report at http://bugs.php.net/?id=15333&edit=1
Bug #15333 Updated: strndup access violation
ID: 15333 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: IIS related Operating System: Windows 2000 Pro PHP Version: 4.1.1 New Comment: Bug #16362 was marked a duplicate of this bug. Previous Comments: [2002-04-03 19:35:48] [EMAIL PROTECTED] I got this error after aplying the lateste security updates on my win2k server. It works fine at the begginig but after 5 mins I get this error. It hangs all the IIS service. This doesn't happen in CGI mode. OS: Win2K Server Patches: SP2 + Lateste Security updates System: P3 @ 550 Mhz - 256 MB RAM PHP VER: 4.1.2. PHP Mode: ISAPI [2002-02-19 09:06:12] [EMAIL PROTECTED] Nope, I am not using Zend Encoder or Optimizer. Just running plain PHP for now. [2002-02-19 08:52:53] [EMAIL PROTECTED] Are you using Zendencoder? I have the same problem on a machine running Zendoptimizer with some pages that were Zendencoded. The server crashed every 20-30 request or so. I took off the pages Zendencoded and its working fine now... Seems that the problem stands there... [2002-02-01 15:41:48] [EMAIL PROTECTED] I am getting an access violation in php4ts!zend_strndup + 0x2B + 0xA05CB1AD. It is reproducable after about 20 or 30 requests, but it isn't a certain page that causes it. A page refresh may or may not display the page without error. Eventually the server will no longer serve pages at all and only a reboot will bring the web server back. Stopping IIS just sits there attempting to stop the service. Details: Windows 2000 Pro with service pack 2 and all critical and security updates from windowsupdate.microsoft.com K6-2 500MHz with 192Meg RAM I have the exact setup on my machine using an Athlon 1.2GHz with 512Meg RAM without any problem. However on two machines with an AMD K6-2 (configured identically) the web server will stop responding to requests consistently. I have also tested this on my Dell laptop with an Intel PIII/700MHz 256 Meg RAM with same Windows 2000 pro w/sp2 and all updates without any problem. When the server does stop serving pages the DLLHOST.EXE process virtual memory size goes to the max for the machine. I have installed php as an ISAPI module. I have also tried installing PHP as a CGI and have the same problem. I have tested this with php 4.0.6, 4.1.0, and 4.1.1 and have the same problem in zend_strndup with all three. I am using the windows zip file from the php.net download page. Also I am using the Interbase extension. No other extensions are being used. I hope I included enough info here. Thanks. -- Edit this bug report at http://bugs.php.net/?id=15333&edit=1
Bug #16362 Updated: IIS stops serving .php pages after a time period
ID: 16362 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Duplicate Bug Type: IIS related Operating System: Win2k build 2195/XP PHP Version: 4.1.2 New Comment: The second error has nothing to do with PHP. The first error has been reported already (#15333). So I'm marking this bug closed as a duplicate. Please make all further comments on that bug. Previous Comments: [2002-04-03 19:41:22] [EMAIL PROTECTED] Checked my Error Log (Thanks for the help) Event: 204 Source: WAM The HTTP server encountered an unhandled exception while processing the ISAPI Application ' php4ts!zend_strndup + 0x2B + 0xA05CB1AD '. Also have this error occuring frequently... as frequently as the other, but have no idea what it is. Event: 105 Source: W3SVC The server was unable to register the administration tool discovery information. The administration tool may not be able to see this server. The data is the error code. For additional information specific to this message please visit the Microsoft Online Support site located at: http://www.microsoft.com/contentredirect.asp. I hope this information helps you help me. Thanks very much for your assistance. -js [2002-04-02 19:54:02] [EMAIL PROTECTED] I'm not really sure how to check the log files for IIS. Where are they located usually? I already tried uninstall/reinstall to no avail and I guess I have all of the IIS updates. I'll check again. Thanks for the tip. I really want PHP to work for me cause I am deciding whether or not we should install it onto the servers at the ISP I work for. off topic: I ran 'test.php' yesterday (April 1st) and the PHP logo had some guy with pencils in his mouth. I guess as an April fools joke... That's a big plus in my book. It's gone today. Is there a few things that this problem may be steming from that I can check off the list by looking over? Or could it be a ton of things? [2002-04-02 10:37:37] [EMAIL PROTECTED] See if you can narrow it down some more. What does the message log say when it dies for you? If it's not serving ASP pages correctly, it may be IIS: perhaps an uninstall/reinstall cycle is needed. Do you have all of the IIS updates installed? The error that I reported may not be the same because it goes away when I restart IIS; I don't need to reboot my computer. Also, try this: serve up an asp page. Then wait "a while" and see if it behaves the same way. [2002-04-02 10:37:19] [EMAIL PROTECTED] See if you can narrow it down some more. What does the message log say when it dies for you? If it's not serving ASP pages correctly, it may be IIS: perhaps an uninstall/reinstall cycle is needed. Do you have all of the IIS updates installed? The error that I reported may not be the same because it goes away when I restart IIS; I don't need to reboot my computer. Also, try this: serve up an asp page. Then wait "a while" and see if it behaves the same way. [2002-04-02 09:11:10] [EMAIL PROTECTED] so does this mean that there is nothing I can do, or can this problem be remedied by changing something in IIS or in the php.ini? I can't find anything very helpful at microsoft. Which I can't understand. Why wouldn't they offer help to someone wanting to use a product that is in direct competition with one of theirs? 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/16362 -- Edit this bug report at http://bugs.php.net/?id=16362&edit=1
Bug #16429: strtotime fails when crossing Daylight Saving Time
From: [EMAIL PROTECTED] Operating system: Solaris/Linux PHP version: 4.1.2 PHP Bug Type: Date/time related Bug description: strtotime fails when crossing Daylight Saving Time [sveinp@ws195 ~]$ php -q Fri Mar 29 23:00:00 2002 [sveinp@ws195 ~]$ -- Edit bug report at http://bugs.php.net/?id=16429&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16429&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16429&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16429&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16429&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16429&r=support Expected behavior: http://bugs.php.net/fix.php?id=16429&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16429&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16429&r=submittedtwice
Bug #11491 Updated: When using ob_start("ob_gzhandler") transient SID gets broken
ID: 11491
Updated by: [EMAIL PROTECTED]
-Reported By: [EMAIL PROTECTED]
+Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Feature/Change Request
Operating System: Windows 2000 Server
PHP Version: 4.0.5
New Comment:
I think we are better to make ob_gzhandler obsolete.
1) zlib.output_compression does the compression.
2) zlib.output_compression is more efficient.
3) laest output control code prevents compression buffer deletion.
(Deleting it does not make sense)
4) ob_gzhandler will also have problem with trans_sid, but
zlib.output_compression does not have such problem.
Previous Comments:
[2002-04-04 08:47:34] [EMAIL PROTECTED]
reopen as feature request
[2002-04-04 08:41:00] [EMAIL PROTECTED]
Please reopen - the very same bug is still alive in PHP 4.1.1
(Win32/Apache).
Problem: Any user-defined output handler MUST be called before
trans-sid's are applied since they may very well modify the HTML
output.
Suggestion: add another (opt) parameter to ob_start, specifying a
first-pass handler which will be called _before_ trans-sid's are
applied. The original first parameter specifies the handler that will
be called _after_ applying the trans-sid's.
BEFORE CHANGE (trans-sid's are broken):
string ob_start('my_handler');
function my_handler($buffer, $mode)
{
// do something useful with $buffer
return ob_gzhandler($buffer, $mode);
}
AFTER CHANGE (trans-sid's should work):
string ob_start('ob_gzhandler','my_handler');
function my_handler($buffer, $mode)
{
// do something useful with $buffer
return $buffer;
}
The PHP engine would first call my_handler(), apply trans-sid's next,
and finally call ob_gzhandler(). This solution seems to be a reasonable
change and shouldn't break existing code.
Thanks for consideration!
Ernest E Vogelsinger
[2001-12-22 08:40:31] [EMAIL PROTECTED]
No feedback. Closing.
[2001-12-22 08:40:26] [EMAIL PROTECTED]
No feedback. Closing.
[2001-12-01 12:15:00] [EMAIL PROTECTED]
This should be fixed, please try a recent version 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/11491
--
Edit this bug report at http://bugs.php.net/?id=11491&edit=1
Bug #11491 Updated: When using ob_start("ob_gzhandler") transient SID gets broken
ID: 11491
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
-Bug Type: Documentation problem
+Bug Type: Feature/Change Request
Operating System: Windows 2000 Server
PHP Version: 4.0.5
New Comment:
reopen as feature request
Previous Comments:
[2002-04-04 08:41:00] [EMAIL PROTECTED]
Please reopen - the very same bug is still alive in PHP 4.1.1
(Win32/Apache).
Problem: Any user-defined output handler MUST be called before
trans-sid's are applied since they may very well modify the HTML
output.
Suggestion: add another (opt) parameter to ob_start, specifying a
first-pass handler which will be called _before_ trans-sid's are
applied. The original first parameter specifies the handler that will
be called _after_ applying the trans-sid's.
BEFORE CHANGE (trans-sid's are broken):
string ob_start('my_handler');
function my_handler($buffer, $mode)
{
// do something useful with $buffer
return ob_gzhandler($buffer, $mode);
}
AFTER CHANGE (trans-sid's should work):
string ob_start('ob_gzhandler','my_handler');
function my_handler($buffer, $mode)
{
// do something useful with $buffer
return $buffer;
}
The PHP engine would first call my_handler(), apply trans-sid's next,
and finally call ob_gzhandler(). This solution seems to be a reasonable
change and shouldn't break existing code.
Thanks for consideration!
Ernest E Vogelsinger
[2001-12-22 08:40:31] [EMAIL PROTECTED]
No feedback. Closing.
[2001-12-22 08:40:26] [EMAIL PROTECTED]
No feedback. Closing.
[2001-12-01 12:15:00] [EMAIL PROTECTED]
This should be fixed, please try a recent version of PHP.
[2001-06-21 14:24:22] [EMAIL PROTECTED]
This should be mentioned in the manual?
Reclassified as docu prob.
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/11491
--
Edit this bug report at http://bugs.php.net/?id=11491&edit=1
Bug #11491 Updated: When using ob_start("ob_gzhandler") transient SID gets broken
ID: 11491
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Documentation problem
Operating System: Windows 2000 Server
PHP Version: 4.0.5
New Comment:
Please reopen - the very same bug is still alive in PHP 4.1.1
(Win32/Apache).
Problem: Any user-defined output handler MUST be called before
trans-sid's are applied since they may very well modify the HTML
output.
Suggestion: add another (opt) parameter to ob_start, specifying a
first-pass handler which will be called _before_ trans-sid's are
applied. The original first parameter specifies the handler that will
be called _after_ applying the trans-sid's.
BEFORE CHANGE (trans-sid's are broken):
string ob_start('my_handler');
function my_handler($buffer, $mode)
{
// do something useful with $buffer
return ob_gzhandler($buffer, $mode);
}
AFTER CHANGE (trans-sid's should work):
string ob_start('ob_gzhandler','my_handler');
function my_handler($buffer, $mode)
{
// do something useful with $buffer
return $buffer;
}
The PHP engine would first call my_handler(), apply trans-sid's next,
and finally call ob_gzhandler(). This solution seems to be a reasonable
change and shouldn't break existing code.
Thanks for consideration!
Ernest E Vogelsinger
Previous Comments:
[2001-12-22 08:40:31] [EMAIL PROTECTED]
No feedback. Closing.
[2001-12-22 08:40:26] [EMAIL PROTECTED]
No feedback. Closing.
[2001-12-01 12:15:00] [EMAIL PROTECTED]
This should be fixed, please try a recent version of PHP.
[2001-06-21 14:24:22] [EMAIL PROTECTED]
This should be mentioned in the manual?
Reclassified as docu prob.
[2001-06-20 17:05:01] [EMAIL PROTECTED]
output buffering takes place before the transient sid
mechanism, which is the last thing to happen before
the actual script output is passed on to the webserver
so the trans-sid parser will not recognize the URLs
in the already compressed output, thats it
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/11491
--
Edit this bug report at http://bugs.php.net/?id=11491&edit=1
Bug #16428: bzopen fails to open file
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.0CVS-2002-04-04
PHP Bug Type: Bzip2 Related
Bug description: bzopen fails to open file
This only applies to HEAD, not to 4.2.0.
bzopen("/full/path/to/file.bz2", "r");
results in
Warning - bzopen("Üøs F<") - No such file or directory
--
Edit bug report at http://bugs.php.net/?id=16428&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16428&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16428&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16428&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16428&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16428&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16428&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16428&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16428&r=submittedtwice
Bug #16305 Updated: curl post doesn't behave as per the manual
ID: 16305
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: cURL related
Operating System: Any
PHP Version: 4.1.2
New Comment:
Reopen if this doesn't work in PHP 4.2.0.
(works fine here)
Previous Comments:
[2002-04-04 07:44:27] [EMAIL PROTECTED]
Unfortunately, like 90% of people using PHP I am reliant on my host for
compiling and installing PHP, so I can't test it :-(
[2002-04-04 07:34:52] [EMAIL PROTECTED]
PHP 4.2.0-dev does not use curl_formparse..please try
the RC2 from http://www.php.net/~derick/
[2002-03-27 03:49:03] [EMAIL PROTECTED]
The curl extension is not behaving as described in the manual.
If you set CURLOPT_POST to 1, and then pass an array to
CURLOPT_POSTFIELDS, it sets Content-type to multipart/form-data instead
of application/x-www-form-urlencoded. This is wrong: the multipart
header should only be used when CURLOPT_PUT is set. To quote the PHP
manual:
{{{CURLOPT_POST: Set this option to a non-zero value if you want PHP to
do a regular HTTP POST. This POST is a normal
application/x-www-form-urlencoded kind, most commonly used by HTML
forms.}}}
Here is what the author of curl (Daniel Stenberg) says - full message
at :
{{{I took a tour into the inner workings of the php curl wrapper code
and I've now returned to tell about my findings! ;-)
When you pass an array to CURLOPT_POSTFIELDS, it is passed as a
multipart/form-data post exactly as you describe. The problem with this
is that it uses the libcurl function curl_formparse() to accomplish
this, and that is a lame function(*).
It does not support newlines in the contents like you tried here.
The wrapper should instead use the new (and much better) curl_formadd()
function for this purpose. It does not have this newline problem.
(*) = yet it was the only available one for a very long time.}}}
I think there is enough evidence here to change the behaviour of the
extension - I think it can be done without breaking backwards
compatibility. The extension was never meant to behave like this, as
the manual testifies.
Regards,
Peter Bowyer.
--
Edit this bug report at http://bugs.php.net/?id=16305&edit=1
Bug #14558 Updated: not worked ibase_connection(..)
ID: 14558 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: InterBase related Operating System: win xp,2000,98 PHP Version: 4.1.0 New Comment: sorry for wrong bug number report ... same as bug: #15419 and #14558 Previous Comments: [2002-04-04 07:00:04] [EMAIL PROTECTED] fixed -> closed [2002-04-04 03:37:48] [EMAIL PROTECTED] Should be fixed in today CVS (4.3.0-dev) same as bug #1549 - #15992 you'll find an example about how to use ibase_close() at: http://www.php.net/manual/en/function.ibase-close.php [2002-02-18 10:57:47] [EMAIL PROTECTED] finally tried it with PHP 4.2.0-dev fresh out of CVS, but did not help. ibase_connect crashes PHP with seg.fault - not always, but quite often. [2002-02-18 08:32:12] [EMAIL PROTECTED] does not seem to be a problem with the interbase-module code, compiling and using PHP 4.1.1 with interbase-module-code of PHP 4.0.6 results in the same error described above! [2002-02-18 07:36:20] [EMAIL PROTECTED] here some more info: tried the above described situation with PHP 4.0.6 -> works fine. will now have a look at php-source changes in the interbase modul between version PHP 4.0.6 and PHP 4.1.1... The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/14558 -- Edit this bug report at http://bugs.php.net/?id=14558&edit=1
Bug #16305 Updated: curl post doesn't behave as per the manual
ID: 16305
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: cURL related
Operating System: Any
PHP Version: 4.1.2
New Comment:
Unfortunately, like 90% of people using PHP I am reliant on my host for
compiling and installing PHP, so I can't test it :-(
Previous Comments:
[2002-04-04 07:34:52] [EMAIL PROTECTED]
PHP 4.2.0-dev does not use curl_formparse..please try
the RC2 from http://www.php.net/~derick/
[2002-03-27 03:49:03] [EMAIL PROTECTED]
The curl extension is not behaving as described in the manual.
If you set CURLOPT_POST to 1, and then pass an array to
CURLOPT_POSTFIELDS, it sets Content-type to multipart/form-data instead
of application/x-www-form-urlencoded. This is wrong: the multipart
header should only be used when CURLOPT_PUT is set. To quote the PHP
manual:
{{{CURLOPT_POST: Set this option to a non-zero value if you want PHP to
do a regular HTTP POST. This POST is a normal
application/x-www-form-urlencoded kind, most commonly used by HTML
forms.}}}
Here is what the author of curl (Daniel Stenberg) says - full message
at :
{{{I took a tour into the inner workings of the php curl wrapper code
and I've now returned to tell about my findings! ;-)
When you pass an array to CURLOPT_POSTFIELDS, it is passed as a
multipart/form-data post exactly as you describe. The problem with this
is that it uses the libcurl function curl_formparse() to accomplish
this, and that is a lame function(*).
It does not support newlines in the contents like you tried here.
The wrapper should instead use the new (and much better) curl_formadd()
function for this purpose. It does not have this newline problem.
(*) = yet it was the only available one for a very long time.}}}
I think there is enough evidence here to change the behaviour of the
extension - I think it can be done without breaking backwards
compatibility. The extension was never meant to behave like this, as
the manual testifies.
Regards,
Peter Bowyer.
--
Edit this bug report at http://bugs.php.net/?id=16305&edit=1
Bug #15992 Updated: Segmentation fault (11)
ID: 15992 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: InterBase related Operating System: RH 7.2 PHP Version: 4.1.2 New Comment: Fixed in today CVS (4.3.0-dev) same as bug #15419 - #14558 you will find an example about how to use ibase_close() at: http://www.php.net/manual/en/function.ibase-close.php Previous Comments: [2002-03-11 09:32:02] [EMAIL PROTECTED] Apache does not have en --enable-debug option but I compiled it with -g option in gcc and it still did not work. I only get 2 lines of backtrace info :( [2002-03-11 08:13:46] [EMAIL PROTECTED] Try compiling Apache with --enable-debug too. [2002-03-11 06:51:55] [EMAIL PROTECTED] As before i did: ./configure --without-mysql --with-imap --with-imap-ssl --with-interbase --with-pgsql --with-kerberos --with-gettext --with-xml --with-apache=../apache_1.3.23/ --enable-track-vars --enable-debug > .log Backtrace only outputs the same 2 lines after httpd crashes [2002-03-11 06:33:13] [EMAIL PROTECTED] Recompile php and the module (if not static already) with the configure line '--enable-debug'. [2002-03-11 06:25:10] [EMAIL PROTECTED] No symbol table info available. What else can I do to help? 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/15992 -- Edit this bug report at http://bugs.php.net/?id=15992&edit=1
Bug #16424 Updated: dba_*open "c" mode broken again
ID: 16424 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: DBM/DBA related Operating System: trustix (rh 6.2 based) PHP Version: 4.1.2 New Comment: The problem is that our firm policy is only to use stable release on production servers. And as I found some complaint on newsgroup about this bug since upgrading php lately (~10 of march), I thought it may have passed through. Maybe the 3.x to 4.x BerkeleyDB code changed again, as described in #13629. Because copy/paste of the example given in #13629 fail on the second access, and succeed again when the db file is erased on my dev box. For myself, I already wrote a small check lib which give me back the access type to use. So this issue isn't a big one, and if it works with the next release, nothing to worry about. Beside, I haven't tried to downgrade my DB3 lib to 3.x, I prefer stay up to date with today libs. Previous Comments: [2002-04-04 07:19:13] [EMAIL PROTECTED] I just tried the example code found in #13629 and it works fine with PHP 4.2.0RC2 (found at http://www.php.net/~derick/) But I've compiled PHP with db-3.3.11. [2002-04-04 07:11:20] [EMAIL PROTECTED] sorry, forgot it. It was referenced by n°10380 and 13629. Both are refernced as closed. [2002-04-04 07:04:46] [EMAIL PROTECTED] And what was the bug number where it says this is fixed? [2002-04-04 06:40:14] [EMAIL PROTECTED] I've found reply as this bug has been fixed in 4.0.6, but it isn't anymore. Using a dba_open in mode "c" will create the file if it doesn't exists, but will fail in opening an existing file. I'm using 4.1.2 stable with an compiled sleepycat 4.0.14 db3 implementation. php configure command: //--- ./configure --with-apxs=/usr/local/apache/bin/apxs --with-openssl --enable-bcmath --enable-calendar --enable-ctype --enable-ftp --enable-imgstrttf --with-ttf --with-imap --with-imap-ssl --enable-trans-sid --enable-shmop --enable-sockets --enable-sysvshm --with-pgsql=/usr/local/pgsql --with-gd=/usr/local --with-mysql --with-mcrypt=/usr/lib/libmcrypt --with-mssql=/usr/local/freetds --with-sybase=/usr/local/freetds --with-gdbm --with-db3=/usr/local/BerkeleyDB.4.0/ --enable-dba //--- [2002-04-04 04:59:40] [EMAIL PROTECTED] I've found reply as this bug has been fixed in 4.0.6, but it isn't anymore. Using a dba_open in mode c will create the file if it doesn't exists, but will fail in opening an existing file. I'm using with an compiled sleepycat 4.0.14 db3 implementation. php configure command: //--- ./configure --with-apxs=/usr/local/apache/bin/apxs --with-openssl --enable-bcmath --enable-calendar --enable-ctype --enable-ftp --enable-imgstrttf --with-ttf --with-imap --with-imap-ssl --enable-trans-sid --enable-shmop --enable-sockets --enable-sysvshm --with-pgsql=/usr/local/pgsql --with-gd=/usr/local --with-mysql --with-mcrypt=/usr/lib/libmcrypt --with-mssql=/usr/local/freetds --with-sybase=/usr/local/freetds --with-gdbm --with-db3=/usr/local/BerkeleyDB.4.0/ --enable-dba //--- -- Edit this bug report at http://bugs.php.net/?id=16424&edit=1
Bug #16305 Updated: curl post doesn't behave as per the manual
ID: 16305
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: cURL related
Operating System: Any
PHP Version: 4.1.2
New Comment:
PHP 4.2.0-dev does not use curl_formparse..please try
the RC2 from http://www.php.net/~derick/
Previous Comments:
[2002-03-27 03:49:03] [EMAIL PROTECTED]
The curl extension is not behaving as described in the manual.
If you set CURLOPT_POST to 1, and then pass an array to
CURLOPT_POSTFIELDS, it sets Content-type to multipart/form-data instead
of application/x-www-form-urlencoded. This is wrong: the multipart
header should only be used when CURLOPT_PUT is set. To quote the PHP
manual:
{{{CURLOPT_POST: Set this option to a non-zero value if you want PHP to
do a regular HTTP POST. This POST is a normal
application/x-www-form-urlencoded kind, most commonly used by HTML
forms.}}}
Here is what the author of curl (Daniel Stenberg) says - full message
at :
{{{I took a tour into the inner workings of the php curl wrapper code
and I've now returned to tell about my findings! ;-)
When you pass an array to CURLOPT_POSTFIELDS, it is passed as a
multipart/form-data post exactly as you describe. The problem with this
is that it uses the libcurl function curl_formparse() to accomplish
this, and that is a lame function(*).
It does not support newlines in the contents like you tried here.
The wrapper should instead use the new (and much better) curl_formadd()
function for this purpose. It does not have this newline problem.
(*) = yet it was the only available one for a very long time.}}}
I think there is enough evidence here to change the behaviour of the
extension - I think it can be done without breaking backwards
compatibility. The extension was never meant to behave like this, as
the manual testifies.
Regards,
Peter Bowyer.
--
Edit this bug report at http://bugs.php.net/?id=16305&edit=1
Bug #15595 Updated: imap routines hang when "To" header is too large
ID: 15595 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: IMAP related Operating System: Solaris-i86 PHP Version: 4.1.1 New Comment: This is most likely a c-client bug. Try opening the same failing mail with Pine. --Jani Previous Comments: [2002-03-12 23:36:32] [EMAIL PROTECTED] I built php again with imap-2001a's c-client, and the problem still occurred. Other suggestions for things I could try? Thanks, Charles [2002-03-11 21:30:57] [EMAIL PROTECTED] Try the latest _c-client_ library, not PHP. As this is most likely not bug in PHP but in the c-client library itself. --Jani [2002-03-11 20:52:16] [EMAIL PROTECTED] We upgraded last week to 4.1.2, the problem still occurs. [2002-03-11 09:37:31] [EMAIL PROTECTED] First of all you should try with the latest c-client. --Jani [2002-03-11 04:47:56] [EMAIL PROTECTED] Is there anything I can do to help this along? We've been bitten twice by this in the last few days. 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/15595 -- Edit this bug report at http://bugs.php.net/?id=15595&edit=1
Bug #15112 Updated: failed to compile extension modules as a dso
ID: 15112 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: NetBSD/Alpha-1.5.2 PHP Version: 4.1.1 New Comment: Could you please try PHP 4.2.0RC2 from http://www.php.net/~derick/ and if it fails too, try debugging the crash with gdb. (configure with --enable-debug!) Previous Comments: [2002-03-11 16:19:06] [EMAIL PROTECTED] Build php using latest snapshot: php4-200203111200.tar.gz It's now building shared extensions fine. However, httpd refuses to run and exits without any error messages when attempting to run it. [2002-03-09 13:20:07] [EMAIL PROTECTED] Could you please try latest CVS snapshot from http://snaps.php.net/ ? [2002-02-28 09:57:47] [EMAIL PROTECTED] Seeing the same problems with php-4.1.2 [2002-01-19 04:29:24] [EMAIL PROTECTED] # NetBSD/Alpha 1.5.2 PHP-4.1.1 # # Building the CGI export LDFLAGS="-Wl,-R/usr/lib -L/usr/lib -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -Wl,-R/usr/local/lib -L/usr/local/lib -Wl,--export-dynamic -Wl,--whole-archive -Wl,-lgcc -Wl,--no-whole-archive" ./configure \ --prefix=/usr/local_install/php-4.1.1 \ --with-config-file-path=/usr/local/etc \ --with-regex=system \ --with-gettext=shared,/usr/pkg \ --with-pgsql=shared,/usr/local \ --with-mysql=shared,/usr/pkg \ --with-pcre-regex \ --with-gd=shared,/usr/local \ --with-jpeg-dir=shared,/usr/pkg \ --with-png-dir=shared,/usr/pkg \ --with-xpm-dir=shared,/usr/pkg \ --with-ttf=shared,/usr/pkg \ --with-freetype-dir=shared,/usr/pkg \ --with-zlib-dir=/usr \ --enable-gd-native-ttf \ --enable-sysvsem=shared \ --enable-sysvshm=shared \ --enable-sockets=shared \ --enable-xml=shared \ --enable-trans-sid \ --enable-discard-path \ --enable-force-cgi-redirect \ --enable-memory-limit \ --enable-track-vars \ --without-t1lib \ --disable-static \ --enable-shared Compiles fine and all that, but the modules aren't in *.so format, instead: # ls -l /usr/local_install/php-4.1.1/lib/php/20010901 total 1291 -rw-r--r-- 1 root wheel 312754 Jan 19 03:25 gd.a -rw-r--r-- 1 root wheel 42044 Jan 19 03:25 gettext.a -rw-r--r-- 1 root wheel 169096 Jan 19 03:25 mysql.a -rw-r--r-- 1 root wheel 263840 Jan 19 03:25 pcre.a -rw-r--r-- 1 root wheel 181726 Jan 19 03:25 pgsql.a -rw-r--r-- 1 root wheel 174484 Jan 19 03:25 sockets.a -rw-r--r-- 1 root wheel 49260 Jan 19 03:25 sysvsem.a -rw-r--r-- 1 root wheel 57342 Jan 19 03:25 sysvshm.a # Seems like libtool failed somewhere? -- Edit this bug report at http://bugs.php.net/?id=15112&edit=1
Bug #15886 Updated: rfc1867 file uploads should consider Content-length header
ID: 15886 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: Win2000 (also tested on Linux) PHP Version: 4.1.1 New Comment: This stuff should be fixed in PHP 4.2.0 (RCs can be found at http://www.php.net/~derick/ ) Previous Comments: [2002-03-05 15:14:41] [EMAIL PROTECTED] The RFC1867 compatible file upload feature in PHP is odd to use and has some shortcomings. Following are the issues that I would like to be changed (or maybe commented if I have just overlooked something): * Content-length header should be considered. When uploading a file, browsers usually supply a Content-length header with it, indicating the total size of posted data. The upload feature should consider it and compare it to post_max_size and upload_max_filesize configuration settings and maybe also the MAX_FILE_SIZE hidden field present in the form. When Content-length > (smallest of the three), the upload should terminate immediately and some sensible error returned to the user without ever receiving the full file. Also, when someone has played around with the incoming stream, upload should terminate IF content-length is small but the incoming byte stream is larger than the permitted values (i.e. limit is 2MB, and 2MB out of 100MB file has been uploaded, should terminate immediately and not wait until the end of 100MB). * MAX_FILE_SIZE has no effect It is said in the doc that the field is "advisory to the browser", but I have not found out what it is about. At least in case of IE 5.5 and Opera 6.01 it has NO effect. As said above, one application for this variable should be that when accepting an incoming upload, the engine should compare this variable to the value of the Content-length header and immediately terminate upload if Content-length > MAX_FILE_SIZE. -- Edit this bug report at http://bugs.php.net/?id=15886&edit=1
Bug #15912 Updated: thttpd: Trailing \r\n in last varible when doing POST request with IE
ID: 15912 Updated by: [EMAIL PROTECTED] -Summary: Trailing \r\n in last varible when doing POST request with IE Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Other web server Operating System: Linux PHP Version: 4.0CVS-2002-03-0 New Comment: updated subject. Previous Comments: [2002-04-04 07:22:20] [EMAIL PROTECTED] So this was thttpd specific? Reclassified. [2002-03-27 13:33:26] [EMAIL PROTECTED] Tried the CVS version of today (20002-03-27) and the bug is still there. But I think it only happens when useing thttpd as SAPI. There is some code in sapi/thttpd/thttpd.c around line 195 that is suppose to fixit. [2002-03-07 17:21:09] [EMAIL PROTECTED] The CVS version from yesterday (2002-03-06) [2002-03-07 14:29:04] [EMAIL PROTECTED] In what version it didn't work? [2002-03-07 09:40:47] [EMAIL PROTECTED] PHP 4.1.2 seams to handle it correctly 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/15912 -- Edit this bug report at http://bugs.php.net/?id=15912&edit=1
Bug #15912 Updated: Trailing \r\n in last varible when doing POST request with IE
ID: 15912 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: HTTP related +Bug Type: Other web server Operating System: Linux PHP Version: 4.0CVS-2002-03-0 New Comment: So this was thttpd specific? Reclassified. Previous Comments: [2002-03-27 13:33:26] [EMAIL PROTECTED] Tried the CVS version of today (20002-03-27) and the bug is still there. But I think it only happens when useing thttpd as SAPI. There is some code in sapi/thttpd/thttpd.c around line 195 that is suppose to fixit. [2002-03-07 17:21:09] [EMAIL PROTECTED] The CVS version from yesterday (2002-03-06) [2002-03-07 14:29:04] [EMAIL PROTECTED] In what version it didn't work? [2002-03-07 09:40:47] [EMAIL PROTECTED] PHP 4.1.2 seams to handle it correctly [2002-03-07 09:36:02] [EMAIL PROTECTED] Changed category to HTTP related 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/15912 -- Edit this bug report at http://bugs.php.net/?id=15912&edit=1
Bug #16424 Updated: dba_*open "c" mode broken again
ID: 16424 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: DBM/DBA related Operating System: trustix (rh 6.2 based) PHP Version: 4.1.2 New Comment: I just tried the example code found in #13629 and it works fine with PHP 4.2.0RC2 (found at http://www.php.net/~derick/) But I've compiled PHP with db-3.3.11. Previous Comments: [2002-04-04 07:11:20] [EMAIL PROTECTED] sorry, forgot it. It was referenced by n°10380 and 13629. Both are refernced as closed. [2002-04-04 07:04:46] [EMAIL PROTECTED] And what was the bug number where it says this is fixed? [2002-04-04 06:40:14] [EMAIL PROTECTED] I've found reply as this bug has been fixed in 4.0.6, but it isn't anymore. Using a dba_open in mode "c" will create the file if it doesn't exists, but will fail in opening an existing file. I'm using 4.1.2 stable with an compiled sleepycat 4.0.14 db3 implementation. php configure command: //--- ./configure --with-apxs=/usr/local/apache/bin/apxs --with-openssl --enable-bcmath --enable-calendar --enable-ctype --enable-ftp --enable-imgstrttf --with-ttf --with-imap --with-imap-ssl --enable-trans-sid --enable-shmop --enable-sockets --enable-sysvshm --with-pgsql=/usr/local/pgsql --with-gd=/usr/local --with-mysql --with-mcrypt=/usr/lib/libmcrypt --with-mssql=/usr/local/freetds --with-sybase=/usr/local/freetds --with-gdbm --with-db3=/usr/local/BerkeleyDB.4.0/ --enable-dba //--- [2002-04-04 04:59:40] [EMAIL PROTECTED] I've found reply as this bug has been fixed in 4.0.6, but it isn't anymore. Using a dba_open in mode c will create the file if it doesn't exists, but will fail in opening an existing file. I'm using with an compiled sleepycat 4.0.14 db3 implementation. php configure command: //--- ./configure --with-apxs=/usr/local/apache/bin/apxs --with-openssl --enable-bcmath --enable-calendar --enable-ctype --enable-ftp --enable-imgstrttf --with-ttf --with-imap --with-imap-ssl --enable-trans-sid --enable-shmop --enable-sockets --enable-sysvshm --with-pgsql=/usr/local/pgsql --with-gd=/usr/local --with-mysql --with-mcrypt=/usr/lib/libmcrypt --with-mssql=/usr/local/freetds --with-sybase=/usr/local/freetds --with-gdbm --with-db3=/usr/local/BerkeleyDB.4.0/ --enable-dba //--- -- Edit this bug report at http://bugs.php.net/?id=16424&edit=1
Bug #16426 Updated: $HTTP_POST_FILES['userfile']['tmp_name'] returns "n"
ID: 16426 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Filesystem function related Operating System: Sun raq4, RedHat PHP Version: 4.1.2 Assigned To: hholzgra New Comment: In PHP 4.2.0 (and above) there will be also an 'error' entry in the array which has some more info: /* Errors */ #define UPLOAD_ERROR_A 1 /* Uploaded file exceeded upload_max_filesize */ #define UPLOAD_ERROR_B 2 /* Uploaded file exceeded MAX_FILE_SIZE */ #define UPLOAD_ERROR_C 3 /* Only partiallly uploaded */ #define UPLOAD_ERROR_D 4 /* No file uploaded */ #define UPLOAD_ERROR_E 5 /* Uploaded file size 0 bytes */ It's 0 if the upload was succesful. Previous Comments: [2002-04-04 06:53:32] [EMAIL PROTECTED] I have had a file upload script working in 4.0.5, but I just upgraded to 4.1.2 and have been getting problems with the $HTTP_POST_FILES['userfile']['tmp_name'] variable. It seems that it always returns 'n' as the temporary filename. I have tried replacing $HTTP_POST_FILES with the new $_FILES variable, but I still get the same problem. It would be great if you can help!! Thanks guys [2002-04-04 06:12:04] [EMAIL PROTECTED] Hmm the thing is I can get the information from all of the other parts of the array, the original filename and file type all come out correct, but the temp name is still 'n'... [2002-04-04 06:05:04] [EMAIL PROTECTED] $HTTP_POST_FILES['userfile'] is "none" when an upload fails (eg. due to size restrictions) so you should check for is_array($HTTP_POST_FILES['userfile']) first changed to "Documentation problem" [2002-04-04 06:01:59] [EMAIL PROTECTED] I have had a file upload script working in 4.0.5, but I just upgraded to 4.1.2 and have been getting problems with the $HTTP_POST_FILES['userfile']['tmp_name'] variable. It seems that it always returns 'n' as the temporary filename. I have tried replacing $HTTP_POST_FILES with the new $_FILES variable, but I still get the same problem. It would be great if you can help!! Thanks guys -- Edit this bug report at http://bugs.php.net/?id=16426&edit=1
Bug #16424 Updated: dba_*open "c" mode broken again
ID: 16424 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: DBM/DBA related Operating System: trustix (rh 6.2 based) PHP Version: 4.1.2 New Comment: sorry, forgot it. It was referenced by n°10380 and 13629. Both are refernced as closed. Previous Comments: [2002-04-04 07:04:46] [EMAIL PROTECTED] And what was the bug number where it says this is fixed? [2002-04-04 06:40:14] [EMAIL PROTECTED] I've found reply as this bug has been fixed in 4.0.6, but it isn't anymore. Using a dba_open in mode "c" will create the file if it doesn't exists, but will fail in opening an existing file. I'm using 4.1.2 stable with an compiled sleepycat 4.0.14 db3 implementation. php configure command: //--- ./configure --with-apxs=/usr/local/apache/bin/apxs --with-openssl --enable-bcmath --enable-calendar --enable-ctype --enable-ftp --enable-imgstrttf --with-ttf --with-imap --with-imap-ssl --enable-trans-sid --enable-shmop --enable-sockets --enable-sysvshm --with-pgsql=/usr/local/pgsql --with-gd=/usr/local --with-mysql --with-mcrypt=/usr/lib/libmcrypt --with-mssql=/usr/local/freetds --with-sybase=/usr/local/freetds --with-gdbm --with-db3=/usr/local/BerkeleyDB.4.0/ --enable-dba //--- [2002-04-04 04:59:40] [EMAIL PROTECTED] I've found reply as this bug has been fixed in 4.0.6, but it isn't anymore. Using a dba_open in mode c will create the file if it doesn't exists, but will fail in opening an existing file. I'm using with an compiled sleepycat 4.0.14 db3 implementation. php configure command: //--- ./configure --with-apxs=/usr/local/apache/bin/apxs --with-openssl --enable-bcmath --enable-calendar --enable-ctype --enable-ftp --enable-imgstrttf --with-ttf --with-imap --with-imap-ssl --enable-trans-sid --enable-shmop --enable-sockets --enable-sysvshm --with-pgsql=/usr/local/pgsql --with-gd=/usr/local --with-mysql --with-mcrypt=/usr/lib/libmcrypt --with-mssql=/usr/local/freetds --with-sybase=/usr/local/freetds --with-gdbm --with-db3=/usr/local/BerkeleyDB.4.0/ --enable-dba //--- -- Edit this bug report at http://bugs.php.net/?id=16424&edit=1
Bug #16425 Updated: Undefined symbol in libphp4.so
ID: 16425 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Apache related Operating System: RH 6.2 PHP Version: 4.1.2 New Comment: Try PHP 4.2.0 RC2 from http://www.php.net/~derick/ Also, add the full configure line you have used. And how did you configure apache? Previous Comments: [2002-04-04 05:11:58] [EMAIL PROTECTED] I was trying to upgrade PHP from 3 to 4; downloaded php-4.1.2 from php.net, then did as was discribed in manual. Compilation/installation gave OK responce. Conf string: ./configure --with-apxs=... --with-pgsql=... Strting apache gave an error like Undefined symbol "pcre_XXX" in libphp4.so I've checked that i've got no pcre lib installed. So, i did install it. Then i've listed some reports here and tried the solution like updating Makefile after "./configure" adding parameter -lpcre to ld commandline. Nothing changed (just another "pcre_ was reported). I've added -lpcreposix - the same. I've adder --without-pcre-regex option to configure. Again the same, but now: php_pcre_replace reported as undefined symbol (was php_pcre_compile). I've downloaded the latest 1.x Apache (1.24) and installed it. Then tried again - nothing changed. What was i doing wrong ??? -- Edit this bug report at http://bugs.php.net/?id=16425&edit=1
Bug #13793 Updated: ibase_fetch_row function chokes on null column values
ID: 13793 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: InterBase related Operating System: Linux PHP Version: 4.0.6 New Comment: Glad to hear that it's fixed in the Concurrent Version System open-standard version. Can you notify me when this fix is rolled into a standard non-development version/update? Thanks, Steve Previous Comments: [2002-04-03 20:36:43] [EMAIL PROTECTED] Already fixed in CVS [2001-10-22 18:15:24] [EMAIL PROTECTED] It seems that, if there is a NULL field at the end of a query string, or TWO or more NULL fields in the MIDDLE of the QUERY string, ibase_fetch_row just DROPS the nulls, and any column data that follows them. For exampe, if I have a table with the columns: FNAME, LNAME, MI, PREFIX, SUFFIX, DOB, SEX, PASSWORD . . . IF MI, PREFIX, and SUFFIX all allow NULL values, and all are null, a SELECT * on this table would only return TWO values: FNAME and LNAME. It would leave out the PASSWORD! This is VERY BAD. It SHOULD return (like in any normal SQL query) null values for any null fields, and NOT skip or stop at any columns, just because the data is null. So . . . I have to populate every field with a default null value (a space, or the word "null", for example), if I want to make sure not to miss column date when I do a SELECT statement using ibase_fetch_row. If anyone knows a way around this, an explanation, or any other ideas, please post them. Thanks, Steve -- Edit this bug report at http://bugs.php.net/?id=13793&edit=1
Bug #16424 Updated: dba_*open "c" mode broken again
ID: 16424 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: DBM/DBA related Operating System: trustix (rh 6.2 based) PHP Version: 4.1.2 New Comment: And what was the bug number where it says this is fixed? Previous Comments: [2002-04-04 06:40:14] [EMAIL PROTECTED] I've found reply as this bug has been fixed in 4.0.6, but it isn't anymore. Using a dba_open in mode "c" will create the file if it doesn't exists, but will fail in opening an existing file. I'm using 4.1.2 stable with an compiled sleepycat 4.0.14 db3 implementation. php configure command: //--- ./configure --with-apxs=/usr/local/apache/bin/apxs --with-openssl --enable-bcmath --enable-calendar --enable-ctype --enable-ftp --enable-imgstrttf --with-ttf --with-imap --with-imap-ssl --enable-trans-sid --enable-shmop --enable-sockets --enable-sysvshm --with-pgsql=/usr/local/pgsql --with-gd=/usr/local --with-mysql --with-mcrypt=/usr/lib/libmcrypt --with-mssql=/usr/local/freetds --with-sybase=/usr/local/freetds --with-gdbm --with-db3=/usr/local/BerkeleyDB.4.0/ --enable-dba //--- [2002-04-04 04:59:40] [EMAIL PROTECTED] I've found reply as this bug has been fixed in 4.0.6, but it isn't anymore. Using a dba_open in mode c will create the file if it doesn't exists, but will fail in opening an existing file. I'm using with an compiled sleepycat 4.0.14 db3 implementation. php configure command: //--- ./configure --with-apxs=/usr/local/apache/bin/apxs --with-openssl --enable-bcmath --enable-calendar --enable-ctype --enable-ftp --enable-imgstrttf --with-ttf --with-imap --with-imap-ssl --enable-trans-sid --enable-shmop --enable-sockets --enable-sysvshm --with-pgsql=/usr/local/pgsql --with-gd=/usr/local --with-mysql --with-mcrypt=/usr/lib/libmcrypt --with-mssql=/usr/local/freetds --with-sybase=/usr/local/freetds --with-gdbm --with-db3=/usr/local/BerkeleyDB.4.0/ --enable-dba //--- -- Edit this bug report at http://bugs.php.net/?id=16424&edit=1
Bug #16422 Updated: utf8_encode/utf8_decode requires the XML extension
ID: 16422 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Feature/Change Request Operating System: All PHP Version: 4.1.2 New Comment: Why? Don't disable xml.. Previous Comments: [2002-04-04 04:34:51] [EMAIL PROTECTED] Currently, utf8_encode() and utf8_decode() are part of the XML extension and will not be available if PHP is configured with --disable-xml Would it be possible to make these functions "native" PHP functions, so that they always will be available? -- Edit this bug report at http://bugs.php.net/?id=16422&edit=1
Bug #14558 Updated: not worked ibase_connection(..)
ID: 14558
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Duplicate
+Status: Closed
Bug Type: InterBase related
Operating System: win xp,2000,98
PHP Version: 4.1.0
New Comment:
fixed -> closed
Previous Comments:
[2002-04-04 03:37:48] [EMAIL PROTECTED]
Should be fixed in today CVS (4.3.0-dev)
same as bug #1549 - #15992
you'll find an example about how to use ibase_close() at:
http://www.php.net/manual/en/function.ibase-close.php
[2002-02-18 10:57:47] [EMAIL PROTECTED]
finally tried it with PHP 4.2.0-dev fresh out of CVS, but did not help.
ibase_connect crashes PHP with seg.fault - not always, but quite often.
[2002-02-18 08:32:12] [EMAIL PROTECTED]
does not seem to be a problem with the interbase-module code, compiling
and using PHP 4.1.1 with interbase-module-code of PHP 4.0.6 results in
the same error described above!
[2002-02-18 07:36:20] [EMAIL PROTECTED]
here some more info:
tried the above described situation with PHP 4.0.6 -> works fine.
will now have a look at php-source changes in the interbase modul
between version PHP 4.0.6 and PHP 4.1.1...
[2002-02-18 07:13:52] [EMAIL PROTECTED]
I can confirm this bug! Appears under Debian Linux too.
One curious example:
a simple php-script that reads all records of a db-table and echo's
them works fine with e.g. table a,b and c. when I trie it with e.g.
table d and e, PHP crashes with a segmentation fault in the
apache-error-log.
I used the following script:
###
PHP/InterBase test
";
exit;
}
$result=ibase_query($conn, "select * from any_table");
if (!$result)
{
echo "Error executing query select count!";
exit;
}
while ($row=ibase_fetch_row ($result)) {
echo $row[0] . "";
}
ibase_close($conn);
?>
It happens only with ibase_connect after the execution of the following
ibase-function. ibase_pconnect seems to work fine.
If more info is needed, feel free to contact me via email.
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/14558
--
Edit this bug report at http://bugs.php.net/?id=14558&edit=1
Bug #15761 Updated: IMAP-SSL Bug
ID: 15761 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Bogus Bug Type: IMAP related Operating System: RedHat 7.2 PHP Version: 4.1.1 Previous Comments: [2002-04-04 00:00:05] [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-03-03 18:11:42] [EMAIL PROTECTED] You might wanna read the ./configure --help sometime.. You're using totally bogus paths there. /usr/local/lib won't work anywhere. Remove the '/lib' from those. Also, are you sure your c-client lib has been compiled with SSL support? --Jani [2002-03-03 13:54:08] [EMAIL PROTECTED] here is my ./configure: ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --with-mcrypt=/usr/local/lib --with-png-dir=/usr/local/lib --with-jpeg-dir=/usr/local/lib --with-curl=/usr/local/lib --with-unixODBC=/usr/local/lib --with-zlib=/usr/local --enable-ftp --with-hyperwave --with-ming --with-freetype-dir=/usr/local --with-gd --with-swf --with-ttf=/usr/local/lib --enable-gd-native-ttf --with-mhash=/usr/local/lib --enable-yp --enable-versioning --enable-ftp --enable-apc --enable-bcmath --with-tiff-dir=/usr/local/lib --with-t1lib=/usr/local/lib --enable-sysvshm=yes --enable-sysvsem=yes --enable-calendar --enable-trans-sid --enable-mbregex --enable-mbstring --enable-wddx --enable-shmop --enable-exif --enable-memory-limit --enable-freetype-4bit-antialias-hack --with-bz2 --with-gettext --with-xpm=/usr/X11R6 --with-openssl=/usr/local/openssl --with-pgsql=/usr/local/pgsql --disable-debug --with-microcode=shared --with-dom=/usr/local/lib --enable-gd-imgstrttf --enable-pdflib --with-pdflib --enable-xslt --with-xslt-sablot --enable-dbase --with-ldap --with-zip --with-zlib-dir=/usr/local/lib --with-pspell --with-rtfm=shared --with-kerberos --with-imap --with-imap-ssl=/usr/local/openssl [2002-03-03 12:56:53] [EMAIL PROTECTED] status -> feedback [2002-03-03 12:54:52] [EMAIL PROTECTED] Show us your entire ./configure line please. Do you have both --with-imap and --with-imap-ssl? 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/15761 -- Edit this bug report at http://bugs.php.net/?id=15761&edit=1
Bug #16426 Updated: $HTTP_POST_FILES['userfile']['tmp_name'] returns "n"
ID: 16426 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed -Bug Type: Documentation problem +Bug Type: Filesystem function related Operating System: Sun raq4, RedHat PHP Version: 4.1.2 Assigned To: hholzgra New Comment: I have had a file upload script working in 4.0.5, but I just upgraded to 4.1.2 and have been getting problems with the $HTTP_POST_FILES['userfile']['tmp_name'] variable. It seems that it always returns 'n' as the temporary filename. I have tried replacing $HTTP_POST_FILES with the new $_FILES variable, but I still get the same problem. It would be great if you can help!! Thanks guys Previous Comments: [2002-04-04 06:12:04] [EMAIL PROTECTED] Hmm the thing is I can get the information from all of the other parts of the array, the original filename and file type all come out correct, but the temp name is still 'n'... [2002-04-04 06:05:04] [EMAIL PROTECTED] $HTTP_POST_FILES['userfile'] is "none" when an upload fails (eg. due to size restrictions) so you should check for is_array($HTTP_POST_FILES['userfile']) first changed to "Documentation problem" [2002-04-04 06:01:59] [EMAIL PROTECTED] I have had a file upload script working in 4.0.5, but I just upgraded to 4.1.2 and have been getting problems with the $HTTP_POST_FILES['userfile']['tmp_name'] variable. It seems that it always returns 'n' as the temporary filename. I have tried replacing $HTTP_POST_FILES with the new $_FILES variable, but I still get the same problem. It would be great if you can help!! Thanks guys -- Edit this bug report at http://bugs.php.net/?id=16426&edit=1
Bug #16424 Updated: dba_*open "c" mode broken again
ID: 16424 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: DBM/DBA related -Operating System: custom (rh 6.2 based) +Operating System: trustix (rh 6.2 based) PHP Version: 4.1.2 New Comment: I've found reply as this bug has been fixed in 4.0.6, but it isn't anymore. Using a dba_open in mode "c" will create the file if it doesn't exists, but will fail in opening an existing file. I'm using 4.1.2 stable with an compiled sleepycat 4.0.14 db3 implementation. php configure command: //--- ./configure --with-apxs=/usr/local/apache/bin/apxs --with-openssl --enable-bcmath --enable-calendar --enable-ctype --enable-ftp --enable-imgstrttf --with-ttf --with-imap --with-imap-ssl --enable-trans-sid --enable-shmop --enable-sockets --enable-sysvshm --with-pgsql=/usr/local/pgsql --with-gd=/usr/local --with-mysql --with-mcrypt=/usr/lib/libmcrypt --with-mssql=/usr/local/freetds --with-sybase=/usr/local/freetds --with-gdbm --with-db3=/usr/local/BerkeleyDB.4.0/ --enable-dba //--- Previous Comments: [2002-04-04 04:59:40] [EMAIL PROTECTED] I've found reply as this bug has been fixed in 4.0.6, but it isn't anymore. Using a dba_open in mode c will create the file if it doesn't exists, but will fail in opening an existing file. I'm using with an compiled sleepycat 4.0.14 db3 implementation. php configure command: //--- ./configure --with-apxs=/usr/local/apache/bin/apxs --with-openssl --enable-bcmath --enable-calendar --enable-ctype --enable-ftp --enable-imgstrttf --with-ttf --with-imap --with-imap-ssl --enable-trans-sid --enable-shmop --enable-sockets --enable-sysvshm --with-pgsql=/usr/local/pgsql --with-gd=/usr/local --with-mysql --with-mcrypt=/usr/lib/libmcrypt --with-mssql=/usr/local/freetds --with-sybase=/usr/local/freetds --with-gdbm --with-db3=/usr/local/BerkeleyDB.4.0/ --enable-dba //--- -- Edit this bug report at http://bugs.php.net/?id=16424&edit=1
Bug #16415 Updated: mysql_query() function throws away entire variable if it contains "\0"
ID: 16415
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: MySQL related
Operating System: OpenBSD
PHP Version: 4.1.2
New Comment:
Hello,
sorry, but we can't provide QA for non-official versions. It is likely
that the audit version introduced this bug.
Please test php-4.2.0RC2 from www.php.net/~derick . If it still
inhibits this fault, please reopen this report.
Derick
Previous Comments:
[2002-04-03 13:35:51] [EMAIL PROTECTED]
actually running PHP 4.1.2-audit
_
configure command:
'./configure' '--without-db' '--with-apache=./apache'
'--with-mysql=/usr/local' '--with-mcrypt=/usr/local'
'--with-zlib=/usr' '--with-db3=/usr/local'
'--disable-debug'
_
I was doing something unnecessary with preg_replace to a
variable --
$var = preg_replace("[\(|\)]","\0",$var);
-- before using it in an INSERT query, like so:
$SQL = "INSERT into theTable (theField) VALUES
('".$var."')";
mysql_query($SQL,$conn);
and all I got was a blank entry for the field insert.
Basically, the preg was stripping out "()" parenthesis and
leaving me with the string inside the parenthesis. the
mysql_query must have seen the "\0" null terminator and
thrown away the entire string. When I changed the preg
function to:
$var = preg_replace("[\(|\)]","",$var);
everything worked the way it was supposed to.
I know there was no good reason for me to replace with a
null terminator but maybe this is a bug? when I printed
the variable out to debug I could see the string, minus the
parenthesis, as I intended. this is what left me confused
for quite some time. maybe this isn't a bug but it's
definitely only happening in the mysql_query function, not
PHP, so I thought I should report it.
--
Edit this bug report at http://bugs.php.net/?id=16415&edit=1
Bug #16427 Updated: Fatal error: Call to undefined function: ocilogon()
ID: 16427 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Oracle related Operating System: windows 2000 PHP Version: 4.1.2 New Comment: The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Previous Comments: [2002-04-04 06:10:26] [EMAIL PROTECTED] how can i connect to oracle using php I have installed a php in IIS. I got this error on browsing the site Fatal error: Call to undefined function: ocilogon() in C:\abc\php\try.php on line 3 I wrote this code: my oracle is in D drive what i have to to please suggest me -- Edit this bug report at http://bugs.php.net/?id=16427&edit=1
Bug #9991 Updated: Registry-Access denied?
ID: 9991 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Win2000 PHP Version: 4.0.4pl1 New Comment: This is not support forum for any other programs than PHP. Previous Comments: [2001-03-26 05:40:54] [EMAIL PROTECTED] Hello I use $PassThru = "C:\\Inetpub\\Scripts\\mp3encdemo31.exe -br 32000 -qual 0 -if C:\\Inetpub\\Scripts\\mann.wav -of C:\\Inetpub\\Scripts\\mann.mp3"; Exec($PassThru); System($PassThru); PassThru($PassThru); This works. BUT with mp3enc31 it does not work anymore (the lizense key is set in the Registry HKEY_CURRENT_USE and HKEY_USERS) Is this a bug or what can I do? Thanks for any help B. Rotondi -- Edit this bug report at http://bugs.php.net/?id=9991&edit=1
Bug #16426 Updated: $HTTP_POST_FILES['userfile']['tmp_name'] returns "n"
ID: 16426 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Documentation problem Operating System: Sun raq4, RedHat PHP Version: 4.1.2 Assigned To: hholzgra New Comment: Hmm the thing is I can get the information from all of the other parts of the array, the original filename and file type all come out correct, but the temp name is still 'n'... Previous Comments: [2002-04-04 06:05:04] [EMAIL PROTECTED] $HTTP_POST_FILES['userfile'] is "none" when an upload fails (eg. due to size restrictions) so you should check for is_array($HTTP_POST_FILES['userfile']) first changed to "Documentation problem" [2002-04-04 06:01:59] [EMAIL PROTECTED] I have had a file upload script working in 4.0.5, but I just upgraded to 4.1.2 and have been getting problems with the $HTTP_POST_FILES['userfile']['tmp_name'] variable. It seems that it always returns 'n' as the temporary filename. I have tried replacing $HTTP_POST_FILES with the new $_FILES variable, but I still get the same problem. It would be great if you can help!! Thanks guys -- Edit this bug report at http://bugs.php.net/?id=16426&edit=1
Bug #16427: Fatal error: Call to undefined function: ocilogon()
From: [EMAIL PROTECTED] Operating system: windows 2000 PHP version: 4.1.2 PHP Bug Type: Oracle related Bug description: Fatal error: Call to undefined function: ocilogon() how can i connect to oracle using php I have installed a php in IIS. I got this error on browsing the site Fatal error: Call to undefined function: ocilogon() in C:\abc\php\try.php on line 3 I wrote this code: my oracle is in D drive what i have to to please suggest me -- Edit bug report at http://bugs.php.net/?id=16427&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16427&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16427&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16427&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16427&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16427&r=support Expected behavior: http://bugs.php.net/fix.php?id=16427&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16427&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16427&r=submittedtwice
Bug #16426 Updated: $HTTP_POST_FILES['userfile']['tmp_name'] returns "n"
ID: 16426 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed -Bug Type: Filesystem function related +Bug Type: Documentation problem Operating System: Sun raq4, RedHat PHP Version: 4.1.2 -Assigned To: +Assigned To: hholzgra New Comment: $HTTP_POST_FILES['userfile'] is "none" when an upload fails (eg. due to size restrictions) so you should check for is_array($HTTP_POST_FILES['userfile']) first changed to "Documentation problem" Previous Comments: [2002-04-04 06:01:59] [EMAIL PROTECTED] I have had a file upload script working in 4.0.5, but I just upgraded to 4.1.2 and have been getting problems with the $HTTP_POST_FILES['userfile']['tmp_name'] variable. It seems that it always returns 'n' as the temporary filename. I have tried replacing $HTTP_POST_FILES with the new $_FILES variable, but I still get the same problem. It would be great if you can help!! Thanks guys -- Edit this bug report at http://bugs.php.net/?id=16426&edit=1
Bug #16426: $HTTP_POST_FILES['userfile']['tmp_name'] returns "n"
From: [EMAIL PROTECTED] Operating system: Sun raq4, RedHat PHP version: 4.1.2 PHP Bug Type: Filesystem function related Bug description: $HTTP_POST_FILES['userfile']['tmp_name'] returns "n" I have had a file upload script working in 4.0.5, but I just upgraded to 4.1.2 and have been getting problems with the $HTTP_POST_FILES['userfile']['tmp_name'] variable. It seems that it always returns 'n' as the temporary filename. I have tried replacing $HTTP_POST_FILES with the new $_FILES variable, but I still get the same problem. It would be great if you can help!! Thanks guys -- Edit bug report at http://bugs.php.net/?id=16426&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16426&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16426&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16426&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16426&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16426&r=support Expected behavior: http://bugs.php.net/fix.php?id=16426&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16426&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16426&r=submittedtwice
Bug #9962 Updated: php.ini-dist is setup for unix.
ID: 9962 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: Windows NT PHP Version: 4.0.4pl1 New Comment: there are examples for paths in php.ini-dist. Previous Comments: [2001-03-26 04:40:17] [EMAIL PROTECTED] Note: The session.cookie_path is a URL path not a filesystem path. Reclassified as feature/change request. --Jani [2001-03-23 17:02:48] [EMAIL PROTECTED] Just noticed that all of the paths in the [session] section of the php.ini-dist file are set to unix paths. I downloaded the Win32 binary distribution and couldn't get anything using a session_start() working because of these file paths for the session.cookie_domain and session.save_path are set to unix path names. This might be nit picky, but shouldn't a binary Win32 distribution be configured to run with Windows path names? -- Edit this bug report at http://bugs.php.net/?id=9962&edit=1
Bug #9962 Updated: php.ini-dist is setup for unix.
ID: 9962 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: Windows NT PHP Version: 4.0.4pl1 Previous Comments: [2001-03-26 04:40:17] [EMAIL PROTECTED] Note: The session.cookie_path is a URL path not a filesystem path. Reclassified as feature/change request. --Jani [2001-03-23 17:02:48] [EMAIL PROTECTED] Just noticed that all of the paths in the [session] section of the php.ini-dist file are set to unix paths. I downloaded the Win32 binary distribution and couldn't get anything using a session_start() working because of these file paths for the session.cookie_domain and session.save_path are set to unix path names. This might be nit picky, but shouldn't a binary Win32 distribution be configured to run with Windows path names? -- Edit this bug report at http://bugs.php.net/?id=9962&edit=1
Bug #8717 Updated: feature request: have ftp_rawlist add extra params to the LIST command
ID: 8717 Updated by: [EMAIL PROTECTED] -Summary: feature request: ftp_rawlist Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed Bug Type: Feature/Change Request -Operating System: Win2k +Operating System: * -PHP Version: 4.0.4pl1 +PHP Version: * New Comment: Updated the topic and other fields. Previous Comments: [2001-01-15 12:40:07] [EMAIL PROTECTED] ftp_rawlist execs the command "LIST" on the server, an important feature is to make it possible to add command parameters (esp. to list hidden files, etc), like "LIST -al" -- Edit this bug report at http://bugs.php.net/?id=8717&edit=1
Bug #8681 Updated: Function arguments in 'global'
ID: 8681
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: Linux/FreeBSD
PHP Version: 4.0.4
New Comment:
There is no request for any change or feature here.
Previous Comments:
[2002-01-06 12:53:34] [EMAIL PROTECTED]
so what is this anyway?
[2001-02-22 10:52:15] [EMAIL PROTECTED]
Not a bug.
[2001-01-12 13:11:42] [EMAIL PROTECTED]
function foo ($bar)
{
global $bar;
# ...
}
Opposite to php3, php4 doesn't warn you. This is now documented.
--
Edit this bug report at http://bugs.php.net/?id=8681&edit=1
Bug #8728 Updated: Patch: usleep() working on win32 platforms
ID: 8728
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Feature/Change Request
Operating System: Any Windows OS
PHP Version: 4.0.4pl1
New Comment:
This is fixed already. Please try PHP 4.2.0RC2 from
http://www.php.net/~derick/
Previous Comments:
[2001-01-15 18:40:10] [EMAIL PROTECTED]
oops... my previous patch was incorrect, let me start over:
in main/config.w32.h, line 93:
/* Define if you have the usleep function. */
#undef HAVE_USLEEP
change it to:
/* Define if you have the usleep function. */
#define HAVE_USLEEP 1
in win32/time.c, line 53:
void usleep(unsigned int useconds)
{
__int64 mstimer, freq;
long now, then;
if (QueryPerformanceFrequency((LARGE_INTEGER *) & freq)) {
QueryPerformanceCounter((LARGE_INTEGER *) & mstimer);
now = (long) (((__int64) (mstimer * .8)) % 0x0FFF);
then = now + useconds;
while (now < then) {
QueryPerformanceCounter((LARGE_INTEGER *) & mstimer);
now = (long) (((__int64) (mstimer * .8)) % 0x0FFF);
}
} else {
/*workaround for systems without performance counter
this is actualy a millisecond sleep */
Sleep((int) (useconds / 1000));
}
}
change it to:
void usleep(unsigned int useconds)
{
#if 0
__int64 mstimer, freq;
long now, then;
if (QueryPerformanceFrequency((LARGE_INTEGER *) & freq)) {
QueryPerformanceCounter((LARGE_INTEGER *) & mstimer);
now = (long) (((__int64) (mstimer * .8)) % 0x0FFF);
then = now + useconds;
while (now < then) {
QueryPerformanceCounter((LARGE_INTEGER *) & mstimer);
now = (long) (((__int64) (mstimer * .8)) % 0x0FFF);
}
} else {
/*workaround for systems without performance counter
this is actualy a millisecond sleep */
Sleep((int) (useconds / 1000));
}
#else
Sleep((DWORD) useconds);
#endif
}
and now it works great :)
can someone reflect this patch in the cvs tree?
-Christophe Thibault
Nullsoft (www.nullsoft.com/www.winamp.com)
[2001-01-15 18:22:56] [EMAIL PROTECTED]
usleep exists on Win32 as the Sleep command (it takes a millisecond
value as parameter) so here is the patch for making the usleep() php
function to work on win32 platforms:
in main/win95nt.h, line 27:
#define php_sleep(t)Sleep(t*1000)
add the following line so it looks like:
#define php_sleep(t)Sleep(t*1000)
#define usleep(t) Sleep(t)
and in config.w32.h, line 93:
/* Define if you have the usleep function. */
#undef HAVE_USLEEP
change it to:
/* Define if you have the usleep function. */
#define HAVE_USLEEP 1
-Christophe Thibault
Nullsoft (www.nullsoft.com/www.winamp.com)
--
Edit this bug report at http://bugs.php.net/?id=8728&edit=1
Bug #16425: Undefined symbol in libphp4.so
From: [EMAIL PROTECTED] Operating system: RH 6.2 PHP version: 4.1.2 PHP Bug Type: Apache related Bug description: Undefined symbol in libphp4.so I was trying to upgrade PHP from 3 to 4; downloaded php-4.1.2 from php.net, then did as was discribed in manual. Compilation/installation gave OK responce. Conf string: ./configure --with-apxs=... --with-pgsql=... Strting apache gave an error like Undefined symbol "pcre_XXX" in libphp4.so I've checked that i've got no pcre lib installed. So, i did install it. Then i've listed some reports here and tried the solution like updating Makefile after "./configure" adding parameter -lpcre to ld commandline. Nothing changed (just another "pcre_ was reported). I've added -lpcreposix - the same. I've adder --without-pcre-regex option to configure. Again the same, but now: php_pcre_replace reported as undefined symbol (was php_pcre_compile). I've downloaded the latest 1.x Apache (1.24) and installed it. Then tried again - nothing changed. What was i doing wrong ??? -- Edit bug report at http://bugs.php.net/?id=16425&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16425&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16425&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16425&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16425&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16425&r=support Expected behavior: http://bugs.php.net/fix.php?id=16425&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16425&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16425&r=submittedtwice
Bug #16424: dba_*open "c" mode broken again
From: [EMAIL PROTECTED] Operating system: custom (rh 6.2 based) PHP version: 4.1.2 PHP Bug Type: DBM/DBA related Bug description: dba_*open "c" mode broken again I've found reply as this bug has been fixed in 4.0.6, but it isn't anymore. Using a dba_open in mode c will create the file if it doesn't exists, but will fail in opening an existing file. I'm using with an compiled sleepycat 4.0.14 db3 implementation. php configure command: //--- ./configure --with-apxs=/usr/local/apache/bin/apxs --with-openssl --enable-bcmath --enable-calendar --enable-ctype --enable-ftp --enable-imgstrttf --with-ttf --with-imap --with-imap-ssl --enable-trans-sid --enable-shmop --enable-sockets --enable-sysvshm --with-pgsql=/usr/local/pgsql --with-gd=/usr/local --with-mysql --with-mcrypt=/usr/lib/libmcrypt --with-mssql=/usr/local/freetds --with-sybase=/usr/local/freetds --with-gdbm --with-db3=/usr/local/BerkeleyDB.4.0/ --enable-dba //--- -- Edit bug report at http://bugs.php.net/?id=16424&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16424&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16424&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16424&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16424&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16424&r=support Expected behavior: http://bugs.php.net/fix.php?id=16424&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16424&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16424&r=submittedtwice
Bug #16423 Updated: Sess_* files don't store data
ID: 16423 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Session related Operating System: Windows NT / IIS4 PHP Version: 4.1.2 New Comment: Can you please try the windows binaries from www.php.net/~derick/php-4.2.0RC1/ ? Derick Previous Comments: [2002-04-04 04:48:05] [EMAIL PROTECTED] It seems this bug has been reported yet, but maybe I give some other infos; session file sess_xx are created but NOT filled with vars values, so that $_SESSION[...] are not propagated between pages. I have two simple php pages using a $_SESSION["myvar"] variable that works fine on linux+apache; I can see vars stored in temp session file. The same 2 pages do not work on WinNT/IIS4; the sess_xxx file is empty and "Warning: Undefined index:..." is reported by the second page when I do a submit from the first. If I "cut and past" the sess_xxx entries from the linux box into sess_xxx on NT It works fine ! So I think it's a problem of file rights or something like that. I modified IIS guest account, temp dir rights... but without success. Hope to be helpful, regards, andrea -- Edit this bug report at http://bugs.php.net/?id=16423&edit=1
Bug #16423: Sess_* files don't store data
From: [EMAIL PROTECTED] Operating system: Windows NT / IIS4 PHP version: 4.1.2 PHP Bug Type: Session related Bug description: Sess_* files don't store data It seems this bug has been reported yet, but maybe I give some other infos; session file sess_xx are created but NOT filled with vars values, so that $_SESSION[...] are not propagated between pages. I have two simple php pages using a $_SESSION["myvar"] variable that works fine on linux+apache; I can see vars stored in temp session file. The same 2 pages do not work on WinNT/IIS4; the sess_xxx file is empty and "Warning: Undefined index:..." is reported by the second page when I do a submit from the first. If I "cut and past" the sess_xxx entries from the linux box into sess_xxx on NT It works fine ! So I think it's a problem of file rights or something like that. I modified IIS guest account, temp dir rights... but without success. Hope to be helpful, regards, andrea -- Edit bug report at http://bugs.php.net/?id=16423&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16423&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16423&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16423&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16423&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16423&r=support Expected behavior: http://bugs.php.net/fix.php?id=16423&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16423&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16423&r=submittedtwice
Bug #16421 Updated: ImageCopyResampled() only with 72dpi
ID: 16421 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: GD related Operating System: php 4.1.1 PHP Version: 4.1.2 New Comment: It seems that GD doesn't suppport other resolutions than 72 dpi. Not a PHP-problem. Previous Comments: [2002-04-04 04:20:45] [EMAIL PROTECTED] When I create Images with the new function imagecopyresampled(), I always get jpeg-results with 72dpi. The pixel hight and width is correct, but instead of 30cm with 72 dpi I would like to get 7,1cm with 304dpi (which is technical the same). I think it should be possible to set the dpi-rate in this function. -- Edit this bug report at http://bugs.php.net/?id=16421&edit=1
Bug #16422: utf8_encode/utf8_decode requires the XML extension
From: [EMAIL PROTECTED] Operating system: All PHP version: 4.1.2 PHP Bug Type: Feature/Change Request Bug description: utf8_encode/utf8_decode requires the XML extension Currently, utf8_encode() and utf8_decode() are part of the XML extension and will not be available if PHP is configured with --disable-xml Would it be possible to make these functions "native" PHP functions, so that they always will be available? -- Edit bug report at http://bugs.php.net/?id=16422&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16422&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16422&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16422&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16422&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16422&r=support Expected behavior: http://bugs.php.net/fix.php?id=16422&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16422&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16422&r=submittedtwice
Bug #16417 Updated: session_id() not working
ID: 16417 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Session related Operating System: WinXP/Win2K PHP Version: 4.1.1 New Comment: No, it causes the same problem. I've tried it on Win2K/4.1.2, Win2K/4.2.0RC1 now too. I don't see how you can reset the session_id after calling session start anyway. When session_start() is called, the SID constant is set, cookie sent to the client etc. You must have to set a custom session_id before this happens. Previous Comments: [2002-04-04 04:11:55] [EMAIL PROTECTED] Maybe you have to call session_id AFTER session_start()? This is what the docs say: "session_id() returns the session id for the current session. If id is specified, it will replace the current session id." If the session hasn't been started yet, there's no session id to replace. Does it work now? [2002-04-04 02:58:30] [EMAIL PROTECTED] How do you know I don't have a reason to change the session id? :-) Why claim to provide the functionality, then refuse to support it? I *do* need to change the session id. It is unavoidable. [2002-04-04 00:03:55] [EMAIL PROTECTED] You really don't have any reason to change the session id. [2002-04-03 18:10:21] [EMAIL PROTECTED] Using my own session id doesn't appear to work Causes Apache (1.3.22) to crash on Win2K/4.1.1 and produces "Warning: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (c:\\windows\\temp) in Unknown on line 0" on WinXP/4.2.0RC1 Without calling changing the session id, there are no problems -- Edit this bug report at http://bugs.php.net/?id=16417&edit=1
Bug #16421: ImageCopyResampled() only with 72dpi
From: [EMAIL PROTECTED] Operating system: php 4.1.1 PHP version: 4.1.2 PHP Bug Type: GD related Bug description: ImageCopyResampled() only with 72dpi When I create Images with the new function imagecopyresampled(), I always get jpeg-results with 72dpi. The pixel hight and width is correct, but instead of 30cm with 72 dpi I would like to get 7,1cm with 304dpi (which is technical the same). I think it should be possible to set the dpi-rate in this function. -- Edit bug report at http://bugs.php.net/?id=16421&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16421&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16421&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16421&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16421&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16421&r=support Expected behavior: http://bugs.php.net/fix.php?id=16421&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16421&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16421&r=submittedtwice
Bug #16419 Updated: Mysql multiple Insert fails...
ID: 16419
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: MySQL related
Operating System: Linux redhat 7.2
PHP Version: 4.0CVS-2002-04-04
New Comment:
The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php
Previous Comments:
[2002-04-04 02:51:19] [EMAIL PROTECTED]
hi this is my script and it fails when I run it. Sometimes the first
one works and some times the second one..however if I run 1 by 1 both
of them work but if I run themn in the same script..It fails..
$connect = mysql_pconnect($dbhost, $dbuser, $dbpass);
$query = "INSERT INTO transactions
(fromid,toid,threadid,messageid,timesent,message,subject,new,unread)
VALUES
('$username','$toid','$threadid','$messageid',now(),'$message','$subject',
'1', '1')";
$what = "INSERT INTO status
(threadid,subject,fromid,toid,fromstatus,tostatus,dateposted) VALUES
('$threadid', '$subject', '$username', '$toid', '1', '1', now())";
$doit = mysql_db_query($dbname,$what);
$execute = mysql_db_query($dbname, $query);
Thank you
Best Regards,
Dhaval Desai
http://www.netage-me.com
--
Edit this bug report at http://bugs.php.net/?id=16419&edit=1
Bug #16417 Updated: session_id() not working
ID: 16417 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Session related Operating System: WinXP/Win2K PHP Version: 4.1.1 New Comment: Maybe you have to call session_id AFTER session_start()? This is what the docs say: "session_id() returns the session id for the current session. If id is specified, it will replace the current session id." If the session hasn't been started yet, there's no session id to replace. Does it work now? Previous Comments: [2002-04-04 02:58:30] [EMAIL PROTECTED] How do you know I don't have a reason to change the session id? :-) Why claim to provide the functionality, then refuse to support it? I *do* need to change the session id. It is unavoidable. [2002-04-04 00:03:55] [EMAIL PROTECTED] You really don't have any reason to change the session id. [2002-04-03 18:10:21] [EMAIL PROTECTED] Using my own session id doesn't appear to work Causes Apache (1.3.22) to crash on Win2K/4.1.1 and produces "Warning: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (c:\\windows\\temp) in Unknown on line 0" on WinXP/4.2.0RC1 Without calling changing the session id, there are no problems -- Edit this bug report at http://bugs.php.net/?id=16417&edit=1
Bug #16400 Updated: $_FILES array and mp3 files
ID: 16400
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Assigned
-Bug Type: HTTP related
+Bug Type: Documentation problem
Operating System: Linux RH7.1
PHP Version: 4.1.2
-Assigned To:
+Assigned To: sander
New Comment:
It is settable in a script, but it just doesn't have any effect.
Reopening as a documentation problem and assigning to myself.
Previous Comments:
[2002-04-03 17:26:09] [EMAIL PROTECTED]
So, you are saying that the max filesize for uploads cannot be set in
script? Perhaps the documentation is confusing me. Would you explain
what the ini_set parameter "upload_max_filesize" is used for? The
documentation for ini_set() says this parameter is settable via script
(PHP_INI_ALL).
Thanks.
[2002-04-03 12:31:35] [EMAIL PROTECTED]
PHP decides whether a file is accepted BEFORE your script runs. The
changes to php.ini with ini_set() are made AFTER the uploads are
processed by PHP, and thus have no effect on the the decision.
This is intended behaviour.
[2002-04-03 11:02:09] [EMAIL PROTECTED]
After further investigation, I have found that
ini_set("upload_max_filesize", "15M")
or
ini_set("upload_max_filesize", "1500")
or
ini_set("upload_max_filesize", 1500)
does not work. If I change the setting in php.ini, the uploads work.
So, ini_set seems to be the culprit. The cutoff size _was_ the default
2M in php.ini. If "upload_max_filesize" cannot be set via a script, it
is an unfortunate problem.
I also tried setting ini_set("memory_limit","15M") and wonder about
"post_max_size" (no detailed documentation). However, I didn't need to
change them to make things work.
[2002-04-03 01:40:02] [EMAIL PROTECTED]
Does it work with other file types of similar size to the
MP3s which you are uploading? i.e. are you sure it's not
a max_file_size problem?
Torben
[2002-04-02 17:06:52] [EMAIL PROTECTED]
I am using PHP4.2.0RC1. When referencing .mp3 file uploads, the
$_FILES[name]['tmp_name'] is empty, and $_FILES[name][size] is 0. When
referencing other file types, everything works fine.
Thanks.
--
Edit this bug report at http://bugs.php.net/?id=16400&edit=1
