#26103 [Fbk->Opn]: --with-mssql dies in compilation
ID: 26103 User updated by: freebsd at argentproductions dot com Reported By: freebsd at argentproductions dot com -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: FreeBSD 5.1-RELEASE PHP Version: 4.3.3 New Comment: Actually, I didn't delete the config.cache, but I did a "make clean" in between each time AND I tried it on three different completely clean source trees. So I'm certain that had nothing to do with it. :) Now, having just downloaded the file you specified, I can happily say -- your patch worked. :-D Looks like its all good now. Just to be fair, I ran it twice, with a make clean in between, just like the other source tars, and reordered a few of the options to make sure. Compiled perfectly both times. Don't know if the actual module is any different, but it *did* compile just fine. Unless this spontaneously pops up again when I go to compile and install the FreeBSD port for 4.3.4 (whenever it comes out), I'm happy. Will your patch make it into the actual 4.3.4 distribution file? Peace... Previous Comments: [2003-11-04 00:16:04] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip I just committed possible fix for this, so please try the snapshot in about 2 hours after you got this mail. [2003-11-03 23:53:17] [EMAIL PROTECTED] So it compiles with all the other options, as long as you don't enable mime-magic ? (I hope you remembered to delete config.cache when you tried different options. :) [2003-11-03 21:27:24] freebsd at argentproductions dot com Okay I've narrowed it down to this configure option: --with-mime-magic=/usr/share/misc/magic.mime If that's in the list it causes --with-mssql to die a horrible death. This file is rather large. I can post it if you want but its the standard distro magic.mime file that came with my system AFAICT. Its just interesting that it would cause --with-mssql to crash. Anything I can do to help figure out this problem? I'm not personally addicted to MIME magic, but I was looking forward to playing with it. I NEED the other options. Is this still bogus? Peace... [2003-11-03 19:41:44] freebsd at argentproductions dot com Description: After an extensive search that came up with nothing quite like this scenario, I figured I'd post this since its eating up all my time and I have to get this up ASAP. Any and all comments / suggestions are very welcome! When building mod_php4 from the FreeBSD port (using PHP 4.3.3 release) I get a compile error (listed in "Actual Result" section). So far I've had no other trouble with this system, and a previous compilation of 4.3.3 with mssql at one point did succeed, but since then I am not sure what has changed as its been almost two months now since I last compiled mod_php4. I have tried a number of things to fix this problem, but since I'm using the port management system, changing the actual PHP distribution code is all but impossible. I need the port management system for version tracking. An attempt to use 4.3.4RC1 failed with the same exact error. There is not yet a port for 4.3.4RC3. Environment is as follows: FreeBSD 5.1-RELEASE with latest security patches. FreeTDS 0.61.2 installed with --prefix=/usr/local --with-tdsver=7.0 --enable-msdblib Configure Options (note: I'm typing this by hand from the Makefile for the port, so forgive any misspellings I might accidentally do...) --enable-versioning --enable-memory-limit --with-layout=GNU --with-zlib-dir=/usr --disable-all -- with-pfpro=/usr/local --with-regex=php --enable-bcmath --enable-calendar --with-bz2=/usr --with-curl=/usr/local --with-dom=/usr/local --with-dom-xslt=/usr/local --with-dom-exslt=/usr/local --enable-ftp --with-gd --enable-gd-native-ttf --enable-gd-jis-conv --with-freetype-dir=/usr/local --with-jpeg-dir=/usr/local --with-png-dir=/usr/local --with-gettext=/usr/local --with-iconv=/usr/local --with-imap=/usr/local --with-imap-ssl=/usr/local --enable-mbstring --enable-mbregex --with-mcal=/usr/local --with-mcrypt=/usr/local --with-mhash=/usr/local --with-mime-magic=/usr/share/misc/magic.mime --with-mysql=/usr/local --with-openssl=/usr --enable-overload --with-pcre-regex=yes --enable-posix --enable-session --with-mssql=/usr/local --enable-tokenizer --enable-xml --with-expat-dir=/usr/local --with-zlib=yes Expected result: I expected a clean compile as it has done before (actually, it did it once before using an RC of 4.3.3 (It might have been the release, even). I am not sure why a r
#26106 [NEW]: different MD5 hash for tar.gz
From: icebird2000 at web dot de Operating system: Linux PHP version: 4.3.4 PHP Bug Type: *General Issues Bug description: different MD5 hash for tar.gz Description: the md5-hash for php-4.3.4.tar.gz downloaded on the german mirrors is wrong on my maschine the md5 hash is c0e7f7388fadacbf4948391c6d93dc5e the hash for php-4.3.4.tar.bz2 is correct -- Edit bug report at http://bugs.php.net/?id=26106&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26106&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26106&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26106&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26106&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26106&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26106&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26106&r=support Expected behavior: http://bugs.php.net/fix.php?id=26106&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26106&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26106&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26106&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26106&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26106&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26106&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26106&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26106&r=float
#25933 [Bgs->Fbk]: stream_select
ID: 25933 Updated by: [EMAIL PROTECTED] Reported By: flape at pobox dot sk -Status: Bogus +Status: Feedback Bug Type: Filesystem function related Operating System: Win2K PHP Version: 4.3.3 New Comment: It should work with file handles. Try removing the stream_set_blocking() call: stream_select() will give you an indication if an operation would block - if it is set to non-blocking, it is possible that your OS is telling you it has nothing to do. Previous Comments: [2003-11-03 07:44:41] flape at pobox dot sk According to the definition of a stream - in the very first paragraf of the topic Strem functions - the file is stream too, so the stream_select function should be able to handle the file handle too. [2003-10-30 21:07:03] [EMAIL PROTECTED] What use would this be with file handles? Not bug. [2003-10-21 08:30:43] flape at pobox dot sk Description: stream_select aplied on a file handle - that is told to be a stream too - emiadelly returns. Reproduce code: --- Expected result: It should prit the context of debug.txt and everithing what was added to that file after starting the script. Actual result: -- Warning: stream_select(): unable to select [0]: No error in c:\temp\htdocs\debug.php on line 7 -- Edit this bug report at http://bugs.php.net/?id=25933&edit=1
#26028 [Bgs]: Compilation error in libmysql.c
ID: 26028
User updated by: martin at ibuildings dot nl
Reported By: martin at ibuildings dot nl
Status: Bogus
Bug Type: Compile Failure
Operating System: Redhat 6.1
PHP Version: 4.3.3
New Comment:
/usr/local/jdk/jre/bin or other dirs from my java_home aren't listed in
ld.so.conf.
ldconfig -v doesn't show the libraries. Rebuilding the cache makes no
difference
Previous Comments:
[2003-10-29 12:40:20] [EMAIL PROTECTED]
See #22590. Make sure that your system doesn't use
/usr/local/jdk/jre/bin/libjpeg.so when it's not told to do so (i.e.
adjust your /etc/ld.so.conf and run ldconfig afterwards).
[2003-10-29 10:09:57] martin at ibuildings dot nl
I also tried PHP 4.3.2 with same results
[2003-10-29 09:35:21] martin at ibuildings dot nl
Description:
I try to compile PHP 4.3.3. It gives me an error at compilation.
My settings:
TARGET="/usr/local/apache_1.3.28"
./configure \
--prefix=$TARGET \
--with-apxs=$TARGET/bin/apxs \
--with-config-file-path=$TARGET/conf \
--enable-memory-limit \
--with-mysql \
--disable-cli \
--with-oci8 \
--with-gd=/usr/local/gd \
--with-png-dir=/usr \
--with-jpeg-dir=/usr \
--with-ttf=/usr \
--enable-gd-imgstrttf \
--enable-gd-native-ttf \
--with-gettext \
--enable-track-vars \
--enable-sigchild \
--with-xml \
--with-zlib \
--with-java=/usr/local/jdk
configures runs ok but, when i do a make it fails with this:
In file included from
/usr/local/src/php-4.3.3/ext/mysql/libmysql/libmysql.c:4:
/usr/local/src/php-4.3.3/ext/mysql/libmysql/global.h:260: warning:
redefinition of `uint'
/usr/include/sys/types.h:131: warning: `uint' previously declared here
/usr/local/src/php-4.3.3/ext/mysql/libmysql/global.h:261: warning:
redefinition of `ushort'
/usr/include/sys/types.h:130: warning: `ushort' previously declared
here
In file included from
/usr/local/src/php-4.3.3/ext/mysql/libmysql/libmysql.c:11:
/usr/local/src/php-4.3.3/ext/mysql/libmysql/m_string.h:183: parse error
before `__extension__'
/usr/local/src/php-4.3.3/ext/mysql/libmysql/m_string.h:183: parse error
before `&&'
make: *** [ext/mysql/libmysql/libmysql.lo] Error 1
config.log says for ushort and uint:
configure:51709: checking for type ushort
configure:51728: gcc -o conftest -g -O2 -Wl,-rpath,/usr/local/gd/lib
-L/usr/local/gd/lib -Wl,-rpath,/usr
/usr/local/jdk/jre/bin/libjpeg.so: undefined reference to
`JNU_ThrowByName'
/usr/local/jdk/jre/bin/libjpeg.so: undefined reference to
`JNU_NewObjectByName'
/usr/local/jdk/jre/bin/libjpeg.so: undefined reference to `JNU_GetEnv'
/usr/local/jdk/jre/bin/libjpeg.so: undefined reference to
`JNU_ThrowNullPointerException'
/usr/local/jdk/jre/bin/libjpeg.so: undefined reference to
`jio_snprintf'
/usr/local/jdk/jre/bin/libjpeg.so: undefined reference to
`JNU_CallMethodByName'
/usr/local/jdk/jre/bin/libjpeg.so: undefined reference to
`JNU_CallStaticMethodByName'
collect2: ld returned 1 exit status
configure: failed program was:
#line 51717 "configure"
#include "confdefs.h"
#include
#include
main()
{
ushort foo;
foo++;
exit(0);
}
configure:51666: checking for type uint
configure:51685: gcc -o conftest -g -O2 -Wl,-rpath,/usr/local/gd/lib
-L/usr/local/gd/lib -Wl,-rpath,/usr
/usr/local/jdk/jre/bin/libjpeg.so: undefined reference to
`JNU_ThrowByName'
/usr/local/jdk/jre/bin/libjpeg.so: undefined reference to
`JNU_NewObjectByName'
/usr/local/jdk/jre/bin/libjpeg.so: undefined reference to `JNU_GetEnv'
/usr/local/jdk/jre/bin/libjpeg.so: undefined reference to
`JNU_ThrowNullPointerException'
/usr/local/jdk/jre/bin/libjpeg.so: undefined reference to
`jio_snprintf'
/usr/local/jdk/jre/bin/libjpeg.so: undefined reference to
`JNU_CallMethodByName'
/usr/local/jdk/jre/bin/libjpeg.so: undefined reference to
`JNU_CallStaticMethodByName'
collect2: ld returned 1 exit status
configure: failed program was:
#line 51674 "configure"
#include "confdefs.h"
#include
#include
main()
{
uint foo;
foo++;
exit(0);
}
USHORT and UINT aren't defined in main/php_config.h
The problem looks a lot like bug 17809 and 12451
--
Edit this bug report at http://bugs.php.net/?id=26028&edit=1
#26107 [NEW]: user defined session handlers cropping output.
From: debug at libertas-solutions dot com Operating system: XP PHP version: 4.3.3 PHP Bug Type: Session related Bug description: user defined session handlers cropping output. Description: I have create a series of functions to manage the session information via a database. but for some reason the end of the produced html is cropped dropping from 20768 btyes to 20399 bytes. and I get a internal server error if I attempt to use header redirects. I have tracked it down to my session functions I believe that on the header redirects the output is trying to remove the tail if the output which is empty and is causeing php to crash I have globals turned off and have initialised my software engine to be held in $GLOBALS["engine"] the session functions can then call the database functions of the engine through the $GLOBAL variable, which are able to talk with multiple database types. mySql , msSQL , . these functions work but will crop the ends of the files. Also it does not seen to crop the same amount on different pages but does seem to crop the same amount on the same page ie with a refresh on page one it will crop to the same place each time, as I am using templates and the footer of the web page is the same on all pages but the crop position is different on different URI's -- Edit bug report at http://bugs.php.net/?id=26107&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26107&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26107&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26107&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26107&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26107&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26107&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26107&r=support Expected behavior: http://bugs.php.net/fix.php?id=26107&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26107&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26107&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26107&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26107&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26107&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26107&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26107&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26107&r=float
#25195 [Fbk->Csd]: Failed opening phpinfo.php ... in Unknown on line 0
ID: 25195 User updated by: mhawkins at ukeu dot com Reported By: mhawkins at ukeu dot com -Status: Feedback +Status: Closed Bug Type: Mail related Operating System: Solaris 8 PHP Version: 4.3.3 New Comment: Hmm... Sun didn't suggest a Solaris patch for the issue, and so I doubt there's one in existance (yet). We're currently building a new server environment based on Solaris 9 instead of 8, so it'll be interesting to see if we can replicate the problem on the latest SunOS or not. I'll update this ticket when there's any further information, but if there's nothing that can be done at the PHP end for now, I'll close the ticket. Previous Comments: [2003-11-03 18:50:23] [EMAIL PROTECTED] It works fine with modern operating systems, perhaps the kind people at Sun could come up with some patch? [2003-11-03 09:27:34] mhawkins at ukeu dot com After raising this issue with Sun, and having numerous engineers investigate the problem, the root cause has been traced back to the following (to quote their response): "In a blinding moment of clarity I believe I know what is causing the problems between iPlanet Web Server and PHP. Looking at the PHP source code I can see that sendmail is being invoked by the popen() function. This uses the standard I/O library (stdio) to communicate over a stream and pass information to sendmail. By choosing a stdio function the programmers have limited themselves to a maximum of 255 file descriptors. If you look at the stdio(3C) man page you can see this is clearly documented: The integer constant FOPEN_MAX specifies the minimum number of files that the implementation guarantees can be open simultaneously. Note that no more than 255 files may be opened using fopen(), and only file descriptors 0 through 255 can be used in a stream. In the truss you have supplied it's possible to see that popen is asking for and getting a couple of file descriptors, which are over this 255 limit: 2654/12: 14.7296 pipe() = 262 [263] 2654/12: 14.7301 close(263) = 0 2654/12: 14.7304 close(262) = 0 . . . 2654/12: 26.8940 pipe() = 265 [266] 2654/12: 26.8944 close(266) = 0 2654/12: 26.8947 close(265) = 0 The reason why this is failing is that the iPlanet Web Server has increased the soft file descriptor limit to 1024, thus allowing fd numbers > 255. Unfortunately this behaviour is detramental to popen() and breaks functions that depend upon the stdio library. Now then you won't see the problem initially as calls to popen() will return a file descriptor < 255, however over time as file descriptors are used up and processes hold open file descriptors you'll start to creap up to this 255 limit and that's when things will break." Their suggestions to resolve this were as follows: "I do have one workaround but the "cure" could be worse than the symptoms. I was talking with the iPlanet/SunONE folks about this yesterday. One of the main reasons that the Web Server increases the file descriptor limit is to allow more sockets to be created. By restricting the file descriptor limit to 256 you are seriously hampering the number of clients that can connect and will artificially limit the web server as it reaches 256 file descriptors and then stops serving pages, until a free descriptor becomes available. It's a difficult one to call but ultimately I believe PHP are at fault for using a programming method that is well known to have limitations on the number of file descriptors it can open. Seeing as this is supposed to be run within the confines of the web server it should not assume that there will only be 256 file descriptors available to it. The authors of PHP need to rewrite their code to work around this 256 fd limit." Any suggestions? [2003-08-27 18:37:19] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. On *nix systems when sending e-mail PHP uses popen() to open a pipe to the sendmail binary. In your case that appears to fail, as far as my man page can tell this can only happen if you are out of memory or reached the maximum process limit causing fork()/pipe() to fail. As such this is not a PHP issue. [2003-08-21 11:08:26] mhawkins at ukeu dot com Description: Solaris 8 on Sparc SunONE Webserver 6.0sp5 (AKA iplanet) PHP 4.3.3RC2 (yes, I know, I should upgrade to RC4 first, but this is a production system) Sendmail - default as per Solaris 8. Error: PHP Warning: mail(): Could not
#26064 [Bgs]: error msg without sense: Warning: mime_magic: invalid type 0 in mconvert(). in
ID: 26064
User updated by: e05 at freemails dot ch
-Summary: Warning: mime_magic: invalid type 0 in mconvert(). in
...
Reported By: e05 at freemails dot ch
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Linux 2.4.20 (Debian)
PHP Version: 4.3.3
New Comment:
well, it sounds like the mistake is mine but the error message is not
really usefull :(
I would preffer an error message that says "Hey, you´ve got a problem
magic file" (well, something like that; And I have to check that)
But the error messages is really useless!
Previous Comments:
[2003-11-02 15:59:04] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
Sounds like a problem with your magic file used by the mime_magic
extension.
[2003-11-01 04:09:05] e05 at freemails dot ch
m
1st this seems to happen to all files
2nd the avi is too large (190 MB)
but I tried to write a test script:
\n";
var_dump(mime_content_type('/home/e05/file2.mov'));
print "\n";
var_dump(mime_content_type('/home/e05/file3.zip'));
print "\n";
var_dump(mime_content_type('/home/e05/file4.rm'));
print "";
?>
The intresting point seems to be the output.
Warning: mime_magic: invalid type 0 in mconvert(). in
/home/ck/lamp/public_html/filemanager/bugtest1.php on line 2
(repeats about more than hundred times each line with a
mime_content_type call! while ignoring print "\n";)
the end is that the last mime_content_type returns a value after a lot
warnings:
string(19) "application/x-troff"
The only print "\n"; that seems to be executed works there.
[2003-10-31 16:43:39] [EMAIL PROTECTED]
Would it be possible for you to make the avi file in question
avaliable?
[2003-10-31 16:02:16] e05 at freemails dot ch
Description:
Well, there isn´t much to tell. The error message is:
Warning: mime_magic: invalid type 0 in mconvert(). in /foo/bar.php on
line 2
mconvert doesn´t seems to be a public funktion as
http://www.php.net/mconvert didn´t work.
Reproduce code:
---
--
Edit this bug report at http://bugs.php.net/?id=26064&edit=1
#26107 [Com]: user defined session handlers cropping output.
ID: 26107 Comment by: debug at libertas dot dot dot com Reported By: debug at libertas-solutions dot com Status: Open Bug Type: Session related Operating System: XP PHP Version: 4.3.3 New Comment: I have a uploaded a tidied up version of the session code. http://www.libertas-solutions.com/session.zip I removed the debug code. if you want it back in just create a Global variable and add your debug content to it then print the global variable after the functions. Adrian Sweeney Previous Comments: [2003-11-04 04:53:26] debug at libertas-solutions dot com Description: I have create a series of functions to manage the session information via a database. but for some reason the end of the produced html is cropped dropping from 20768 btyes to 20399 bytes. and I get a internal server error if I attempt to use header redirects. I have tracked it down to my session functions I believe that on the header redirects the output is trying to remove the tail if the output which is empty and is causeing php to crash I have globals turned off and have initialised my software engine to be held in $GLOBALS["engine"] the session functions can then call the database functions of the engine through the $GLOBAL variable, which are able to talk with multiple database types. mySql , msSQL , . these functions work but will crop the ends of the files. Also it does not seen to crop the same amount on different pages but does seem to crop the same amount on the same page ie with a refresh on page one it will crop to the same place each time, as I am using templates and the footer of the web page is the same on all pages but the crop position is different on different URI's -- Edit this bug report at http://bugs.php.net/?id=26107&edit=1
#26095 [Bgs]: ob_gzhandler
ID: 26095 User updated by: giuseppe dot costagliola at sanpaolowm dot com Reported By: giuseppe dot costagliola at sanpaolowm dot com Status: Bogus Bug Type: Output Control Operating System: os/400 PHP Version: 4.3.3 New Comment: I've tried with Explorer 6 sp1 and Nescape 7. On both browsers there is the same problem. Previous Comments: [2003-11-03 13:45:19] [EMAIL PROTECTED] Most likely the browser used doesn't work correctly. Not PHP bug. [2003-11-03 08:54:39] giuseppe dot costagliola at sanpaolowm dot com Description: If I leave parameter "output_handler" undefined, when php loads a new page it first clear the entire screen and then put the new page. If building a page with a big table or with a slow system takes some time, the user stays with a full blank page, and this is very nasty. However if I put "output_handler = ob_gzhandler", php leaves the old page on screen and just overwrites the new one smootly when ready. Is this a bug or is it working as expected ? Thanks. -- Edit this bug report at http://bugs.php.net/?id=26095&edit=1
#22474 [Com]: fwrite hangs on invalid connection
ID: 22474
Comment by: kxrm at hotmail dot com
Reported By: chuck at fuck dot org
Status: No Feedback
Bug Type: Filesystem function related
Operating System: FreeBSD 4.7
PHP Version: 5CVS-2003-02-28 (dev)
New Comment:
I am also experiencing this problem with Redhat 7.3
I do not have a debug install however but here are the results of the
backtrace.
Program received signal SIGPIPE, Broken pipe.
[Switching to Thread 1024 (LWP 11094)]
0x420e83b2 in send () from /lib/i686/libc.so.6
(gdb) bt full
#0 0x420e83b2 in send () from /lib/i686/libc.so.6
No symbol table info available.
#1 0x08176350 in php_sockop_write ()
No symbol table info available.
#2 0x0817296d in _php_stream_write ()
No symbol table info available.
#3 0x0811a67a in zif_fwrite ()
No symbol table info available.
#4 0x081a6321 in execute ()
No symbol table info available.
#5 0x08192ee8 in zend_execute_scripts ()
No symbol table info available.
#6 0x08169681 in php_execute_script ()
No symbol table info available.
#7 0x081b64bc in main ()
No symbol table info available.
#8 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
No symbol table info available.
It doesn't lockup when in gdb it just displays the broken pipe error,
but when running normally it does lockup.
Previous Comments:
[2003-03-16 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2003-02-28 10:31:45] [EMAIL PROTECTED]
Can you provide a bit more information?
I want to see a script like this:
But please fill in the $host and $port with addresses that I can use
from my machine(s) so that I can try and replicate.
Alternatively, please read the docs here
http://bugs.php.net/bugs-generating-backtrace.php
and generate a backtrace from within the fwrite() when it is eating up
the cpu:
Compile php with --enable-debug first then:
gdb ./sapi/cli/php
run myscript.php
[ wait for it to "hang" ]
[ press CTRL-C ]
bt full
Please post the backtrace at a URL and enter the link into this
report.
If you can provide a reproducing script AND a backtrace, that is even
more useful.
[2003-02-28 06:34:23] chuck at fuck dot org
When using a fsockopen resource that has been accepted, but is
non-responsive, fwrite will use as much cpu as it can before the
program is terminated by the time limit.
if(false===([EMAIL PROTECTED]("tcp://$a", 1080, $err, $errstr, 10)))
return false;
$conn=pack('ccnN', '4', 1, 25, ip2long($ip)) .pack('a',$socksusers);
stream_set_timeout($a, 15);
if(!socks_write($a,$conn,9)) return false;
function socks_write(&$a,$b,$c=false) {
$tmp=fwrite($a,$b,$c);
if($c != $tmp) return false;
return true;
}
This program will freeze at the fwrite command.
I've had this happen on PHP 4.3.0 and CVS
It only occurs when specific servers are addressed in the fsockopen.
While I understand the server may be responding with garbage data, the
fsockopen should not be returning the connection as success. Even with
that case, I don't see reason for the fwrite to hang with high cpu
usage.
--
Edit this bug report at http://bugs.php.net/?id=22474&edit=1
#22474 [Com]: fwrite hangs on invalid connection
ID: 22474
Comment by: kxrm at hotmail dot com
Reported By: chuck at fuck dot org
Status: No Feedback
Bug Type: Filesystem function related
Operating System: FreeBSD 4.7
PHP Version: 5CVS-2003-02-28 (dev)
New Comment:
I thought at first this would occur only with large fwrites but it also
occurs under any situation where the server on the other end closes the
connection.
To reproduce just fwrite a large amount of data to another TCP server
and while it's in the process of fwriting (in some while loop) close
the server on the other end.
Previous Comments:
[2003-11-04 07:29:09] kxrm at hotmail dot com
I am also experiencing this problem with Redhat 7.3
I do not have a debug install however but here are the results of the
backtrace.
Program received signal SIGPIPE, Broken pipe.
[Switching to Thread 1024 (LWP 11094)]
0x420e83b2 in send () from /lib/i686/libc.so.6
(gdb) bt full
#0 0x420e83b2 in send () from /lib/i686/libc.so.6
No symbol table info available.
#1 0x08176350 in php_sockop_write ()
No symbol table info available.
#2 0x0817296d in _php_stream_write ()
No symbol table info available.
#3 0x0811a67a in zif_fwrite ()
No symbol table info available.
#4 0x081a6321 in execute ()
No symbol table info available.
#5 0x08192ee8 in zend_execute_scripts ()
No symbol table info available.
#6 0x08169681 in php_execute_script ()
No symbol table info available.
#7 0x081b64bc in main ()
No symbol table info available.
#8 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
No symbol table info available.
It doesn't lockup when in gdb it just displays the broken pipe error,
but when running normally it does lockup.
[2003-03-16 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2003-02-28 10:31:45] [EMAIL PROTECTED]
Can you provide a bit more information?
I want to see a script like this:
But please fill in the $host and $port with addresses that I can use
from my machine(s) so that I can try and replicate.
Alternatively, please read the docs here
http://bugs.php.net/bugs-generating-backtrace.php
and generate a backtrace from within the fwrite() when it is eating up
the cpu:
Compile php with --enable-debug first then:
gdb ./sapi/cli/php
run myscript.php
[ wait for it to "hang" ]
[ press CTRL-C ]
bt full
Please post the backtrace at a URL and enter the link into this
report.
If you can provide a reproducing script AND a backtrace, that is even
more useful.
[2003-02-28 06:34:23] chuck at fuck dot org
When using a fsockopen resource that has been accepted, but is
non-responsive, fwrite will use as much cpu as it can before the
program is terminated by the time limit.
if(false===([EMAIL PROTECTED]("tcp://$a", 1080, $err, $errstr, 10)))
return false;
$conn=pack('ccnN', '4', 1, 25, ip2long($ip)) .pack('a',$socksusers);
stream_set_timeout($a, 15);
if(!socks_write($a,$conn,9)) return false;
function socks_write(&$a,$b,$c=false) {
$tmp=fwrite($a,$b,$c);
if($c != $tmp) return false;
return true;
}
This program will freeze at the fwrite command.
I've had this happen on PHP 4.3.0 and CVS
It only occurs when specific servers are addressed in the fsockopen.
While I understand the server may be responding with garbage data, the
fsockopen should not be returning the connection as success. Even with
that case, I don't see reason for the fwrite to hang with high cpu
usage.
--
Edit this bug report at http://bugs.php.net/?id=22474&edit=1
#25972 [Ana]: ODBC truncates multi-byte text (w/ MSSQL)
ID: 25972
Updated by: [EMAIL PROTECTED]
Reported By: phpbug at chipple dot net
Status: Analyzed
Bug Type: Feature/Change Request
Operating System: Win2K 5.00.2195 SP4
-PHP Version: 4.3.4RC2
+PHP Version: 4.3, 5
New Comment:
moriyoshi,
It's not as simple as you show it to be. First you must
realize that PHP's ODBC layer is written as an ODBC v2
compliant system, to just randomly add in support for
NVARCHAR (and friends) will break support for other
database systems.
The point of my post wasn't to say this isn't a bug
(hence why I marked it as verified), but rather to say
it's a known bug and the issue is the extension is in
need of updating.
Previous Comments:
[2003-11-03 17:13:35] [EMAIL PROTECTED]
I might be wrong, but I think this is a valid bug.
According to the documentation on msdn [1] [2], the fifth parameter of
SQLBindCol() expects the size of the buffer in byte, while the code
mentioned below appears to give it the number of characters allocated
for the column (display size) instead. This kind of confusion will most
likely cause unexpected behaviour like described in this report.
php_odbc.c 669:
--
default:
rc = SQLColAttributes(result->stmt, (UWORD)(i+1),
SQL_COLUMN_DISPLAY_SIZE, NULL, 0, NULL, &displaysize);
displaysize = displaysize <= result->longreadlen ? displaysize :
result->longreadlen;
result->values[i].value = (char *)emalloc(displaysize + 1);
rc = SQLBindCol(result->stmt, (UWORD)(i+1), SQL_C_CHAR,
result->values[i].value, displaysize + 1, &result->values[i].vallen);
break;
--
If the driver supports ODBCv3, we should use SQL_DESC_OCTET_LENGTH,
which can be used to determine the actual number of bytes. If not, we
may be able to safely calculate the maximum column size by simply
multiplying the display size by 2, as NVARCHAR columns are known to not
contain multi-byte strings, but double-byte strings.
[1]
http://msdn.microsoft.com/library/en-us/odbc/htm/odch04pr_13.asp?frame=true
[2]
http://msdn.microsoft.com/library/en-us/odbc/htm/odappdpr_24.asp?frame=true
[2003-10-31 09:26:28] [EMAIL PROTECTED]
Is this really a bug? The debate rages like so:
One the one hand ODBC does not support multi-byte
characters at all. On the other, the idea of multi-
byte characters didn't exist (or if it did, not very
prevailent) at the time of the original authoring of
the ODBC system.
Next question is, is there an easy fix. Nope. I've
had a fix in the works, I've just lost all time to work
upon it. Marking as verified, but not really sure it's
a bug. Maybe a feature request really...
Following the ODBCv2 specs, NVARCHAR is a type that
doesn't exist, nor does TEXT, NTEXT, and many of the
other wonderful types found today.
[2003-10-24 00:10:01] phpbug at chipple dot net
Sorry here's the MSSQL extension code that should have been in the 2nd
part of "Reproduce code".
// MSSQL EXTENSION, data retrieved correctly
$oConn = mssql_connect("localhost",C_Gen_sDbUser,C_Gen_sDbPassword);
mssql_select_db("icds",$oConn);
$oRs = mssql_query("SELECT * FROM T_Course WHERE aCourseID=1");
$aRow = mssql_fetch_array($oRs);
// GOOD: Complete title retrieved (60 chars=120 bytes)
echo $aRow["tTitle"];
mssql_close($oConn);
[2003-10-23 23:26:31] phpbug at chipple dot net
Description:
This bug has been observed with PHP 4.3.3 and 4.3.4RC2.
Database: MSSQL 2000 (8.00.760) SP3
I have a MSSQL database with a table containing a column tTitle of type
nvarchar(80) (which stands for 80 multi-byte characters).
When a string of 60 Japanese double-byte characters (120 bytes) stored
in column tTitle is retrieved using PHP's ODBC extension, the value is
truncated to 80 bytes.
The PHP MSSQL extension retrieves the data correctly.
Microsoft's ODBC driver (used from ASP) retrieves the data correctly.
MSSQL table structure:
CREATE TABLE [dbo].[T_Course] (
[aCourseID] [int] IDENTITY (1, 1) NOT NULL ,
[tTitle] [nvarchar] (80) COLLATE Japanese_CI_AS NOT NULL
) ON [PRIMARY]
GO
Test data (CSV):
aCourseID,tTitle
1,[string of 60 Japanese double-byte characters]
SQL query:
SELECT * FROM T_Course WHERE aCourseID=1
Reproduce code:
---
// ODBC EXTENSION, data truncated
$oConn = odbc_connect(C_Gen_sDbDSN,C_Gen_sDbUser,C_Gen_sDbPassword);
$oRs = odbc_exec($oConn,"SELECT * FROM T_Course WHERE aCourseID=1");
$aRow = odbc_fetch_array($oRs);
// BAD: Title truncated to 80 _bytes_
echo $aRow["tTitle"];
odbc_close($oConn);
// MSSQL EXTENSION, data retrieved correctly
$oConn = odbc_connect(C_Gen_sDbDSN,C_Gen_sDbUs
#26111 [NEW]: mktime returns wrong date
From: chris at astra dot net dot uk
Operating system: FreeBSD
PHP version: 4.3.3
PHP Bug Type: Date/time related
Bug description: mktime returns wrong date
Description:
mktime returns -3662 when given mktime(0,0,0,3,28,2004), i have tested
this on 4.3.4RC1 with the same result.
Reproduce code:
---
echo date("r", mktime(0,0,0,3,28,2004))."\n";
Expected result:
Sat, 28 Mar 2004 00:00:00 +
Actual result:
--
Wed, 31 Dec 1969 23:58:58 +0100
--
Edit bug report at http://bugs.php.net/?id=26111&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26111&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26111&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26111&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26111&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26111&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=26111&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26111&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26111&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26111&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26111&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26111&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26111&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26111&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26111&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26111&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26111&r=float
#26111 [Opn->Fbk]: mktime returns wrong date
ID: 26111
Updated by: [EMAIL PROTECTED]
Reported By: chris at astra dot net dot uk
-Status: Open
+Status: Feedback
Bug Type: Date/time related
Operating System: FreeBSD
PHP Version: 4.3.3
New Comment:
What do these output:
echo date("r", mktime(1,1,1,3,28,2004));
echo date("r", gmmktime(1,1,1,3,28,2004));
Previous Comments:
[2003-11-04 08:00:54] chris at astra dot net dot uk
Description:
mktime returns -3662 when given mktime(0,0,0,3,28,2004), i have tested
this on 4.3.4RC1 with the same result.
Reproduce code:
---
echo date("r", mktime(0,0,0,3,28,2004))."\n";
Expected result:
Sat, 28 Mar 2004 00:00:00 +
Actual result:
--
Wed, 31 Dec 1969 23:58:58 +0100
--
Edit this bug report at http://bugs.php.net/?id=26111&edit=1
#26111 [Fbk->Opn]: mktime returns wrong date
ID: 26111
User updated by: chris at astra dot net dot uk
Reported By: chris at astra dot net dot uk
-Status: Feedback
+Status: Open
Bug Type: Date/time related
Operating System: FreeBSD
PHP Version: 4.3.3
New Comment:
echo date("r", mktime(1,1,1,3,28,2004));
echo date("r", gmmktime(1,1,1,3,28,2004));
returns:
Thu, 1 Jan 1970 00:59:59 +0100
Thu, 1 Jan 1970 00:59:59 +0100
Previous Comments:
[2003-11-04 08:06:44] [EMAIL PROTECTED]
What do these output:
echo date("r", mktime(1,1,1,3,28,2004));
echo date("r", gmmktime(1,1,1,3,28,2004));
[2003-11-04 08:00:54] chris at astra dot net dot uk
Description:
mktime returns -3662 when given mktime(0,0,0,3,28,2004), i have tested
this on 4.3.4RC1 with the same result.
Reproduce code:
---
echo date("r", mktime(0,0,0,3,28,2004))."\n";
Expected result:
Sat, 28 Mar 2004 00:00:00 +
Actual result:
--
Wed, 31 Dec 1969 23:58:58 +0100
--
Edit this bug report at http://bugs.php.net/?id=26111&edit=1
#26111 [Opn->Fbk]: mktime returns wrong date
ID: 26111
Updated by: [EMAIL PROTECTED]
Reported By: chris at astra dot net dot uk
-Status: Open
+Status: Feedback
Bug Type: Date/time related
Operating System: FreeBSD
PHP Version: 4.3.3
New Comment:
Try this too:
echo mktime(12,1,1,3,28,2004);
echo gmmktime(12,1,1,3,28,2004);
Just to note: These all work just fine with Linux. :)
Previous Comments:
[2003-11-04 08:10:36] chris at astra dot net dot uk
echo date("r", mktime(1,1,1,3,28,2004));
echo date("r", gmmktime(1,1,1,3,28,2004));
returns:
Thu, 1 Jan 1970 00:59:59 +0100
Thu, 1 Jan 1970 00:59:59 +0100
[2003-11-04 08:06:44] [EMAIL PROTECTED]
What do these output:
echo date("r", mktime(1,1,1,3,28,2004));
echo date("r", gmmktime(1,1,1,3,28,2004));
[2003-11-04 08:00:54] chris at astra dot net dot uk
Description:
mktime returns -3662 when given mktime(0,0,0,3,28,2004), i have tested
this on 4.3.4RC1 with the same result.
Reproduce code:
---
echo date("r", mktime(0,0,0,3,28,2004))."\n";
Expected result:
Sat, 28 Mar 2004 00:00:00 +
Actual result:
--
Wed, 31 Dec 1969 23:58:58 +0100
--
Edit this bug report at http://bugs.php.net/?id=26111&edit=1
#26111 [Fbk]: mktime returns wrong date
ID: 26111
Updated by: [EMAIL PROTECTED]
Reported By: chris at astra dot net dot uk
Status: Feedback
Bug Type: Date/time related
Operating System: FreeBSD
PHP Version: 4.3.3
New Comment:
Also works fine with Freebsd 4.9-PRERELEASE (whatever that means)
Previous Comments:
[2003-11-04 08:14:27] [EMAIL PROTECTED]
Try this too:
echo mktime(12,1,1,3,28,2004);
echo gmmktime(12,1,1,3,28,2004);
Just to note: These all work just fine with Linux. :)
[2003-11-04 08:10:36] chris at astra dot net dot uk
echo date("r", mktime(1,1,1,3,28,2004));
echo date("r", gmmktime(1,1,1,3,28,2004));
returns:
Thu, 1 Jan 1970 00:59:59 +0100
Thu, 1 Jan 1970 00:59:59 +0100
[2003-11-04 08:06:44] [EMAIL PROTECTED]
What do these output:
echo date("r", mktime(1,1,1,3,28,2004));
echo date("r", gmmktime(1,1,1,3,28,2004));
[2003-11-04 08:00:54] chris at astra dot net dot uk
Description:
mktime returns -3662 when given mktime(0,0,0,3,28,2004), i have tested
this on 4.3.4RC1 with the same result.
Reproduce code:
---
echo date("r", mktime(0,0,0,3,28,2004))."\n";
Expected result:
Sat, 28 Mar 2004 00:00:00 +
Actual result:
--
Wed, 31 Dec 1969 23:58:58 +0100
--
Edit this bug report at http://bugs.php.net/?id=26111&edit=1
#26111 [Fbk->Opn]: mktime returns wrong date
ID: 26111
User updated by: chris at astra dot net dot uk
Reported By: chris at astra dot net dot uk
-Status: Feedback
+Status: Open
Bug Type: Date/time related
Operating System: FreeBSD
PHP Version: 4.3.3
New Comment:
echo mktime(12,1,1,3,28,2004);
echo gmmktime(12,1,1,3,28,2004);
both return 1080478861 (1969Sun, 28 Mar 2004 14:01:01 +0100)
Previous Comments:
[2003-11-04 08:18:59] [EMAIL PROTECTED]
Also works fine with Freebsd 4.9-PRERELEASE (whatever that means)
[2003-11-04 08:14:27] [EMAIL PROTECTED]
Try this too:
echo mktime(12,1,1,3,28,2004);
echo gmmktime(12,1,1,3,28,2004);
Just to note: These all work just fine with Linux. :)
[2003-11-04 08:10:36] chris at astra dot net dot uk
echo date("r", mktime(1,1,1,3,28,2004));
echo date("r", gmmktime(1,1,1,3,28,2004));
returns:
Thu, 1 Jan 1970 00:59:59 +0100
Thu, 1 Jan 1970 00:59:59 +0100
[2003-11-04 08:06:44] [EMAIL PROTECTED]
What do these output:
echo date("r", mktime(1,1,1,3,28,2004));
echo date("r", gmmktime(1,1,1,3,28,2004));
[2003-11-04 08:00:54] chris at astra dot net dot uk
Description:
mktime returns -3662 when given mktime(0,0,0,3,28,2004), i have tested
this on 4.3.4RC1 with the same result.
Reproduce code:
---
echo date("r", mktime(0,0,0,3,28,2004))."\n";
Expected result:
Sat, 28 Mar 2004 00:00:00 +
Actual result:
--
Wed, 31 Dec 1969 23:58:58 +0100
--
Edit this bug report at http://bugs.php.net/?id=26111&edit=1
#26103 [Opn->Csd]: --with-mssql dies in compilation
ID: 26103 Updated by: [EMAIL PROTECTED] Reported By: freebsd at argentproductions dot com -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: FreeBSD 5.1-RELEASE PHP Version: 4.3.3 New Comment: Unfortunately 4.3.4 was released already. This fix will be in PHP 4.3.5. Previous Comments: [2003-11-04 02:34:46] freebsd at argentproductions dot com Actually, I didn't delete the config.cache, but I did a "make clean" in between each time AND I tried it on three different completely clean source trees. So I'm certain that had nothing to do with it. :) Now, having just downloaded the file you specified, I can happily say -- your patch worked. :-D Looks like its all good now. Just to be fair, I ran it twice, with a make clean in between, just like the other source tars, and reordered a few of the options to make sure. Compiled perfectly both times. Don't know if the actual module is any different, but it *did* compile just fine. Unless this spontaneously pops up again when I go to compile and install the FreeBSD port for 4.3.4 (whenever it comes out), I'm happy. Will your patch make it into the actual 4.3.4 distribution file? Peace... [2003-11-04 00:16:04] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip I just committed possible fix for this, so please try the snapshot in about 2 hours after you got this mail. [2003-11-03 23:53:17] [EMAIL PROTECTED] So it compiles with all the other options, as long as you don't enable mime-magic ? (I hope you remembered to delete config.cache when you tried different options. :) [2003-11-03 21:27:24] freebsd at argentproductions dot com Okay I've narrowed it down to this configure option: --with-mime-magic=/usr/share/misc/magic.mime If that's in the list it causes --with-mssql to die a horrible death. This file is rather large. I can post it if you want but its the standard distro magic.mime file that came with my system AFAICT. Its just interesting that it would cause --with-mssql to crash. Anything I can do to help figure out this problem? I'm not personally addicted to MIME magic, but I was looking forward to playing with it. I NEED the other options. Is this still bogus? Peace... [2003-11-03 19:41:44] freebsd at argentproductions dot com Description: After an extensive search that came up with nothing quite like this scenario, I figured I'd post this since its eating up all my time and I have to get this up ASAP. Any and all comments / suggestions are very welcome! When building mod_php4 from the FreeBSD port (using PHP 4.3.3 release) I get a compile error (listed in "Actual Result" section). So far I've had no other trouble with this system, and a previous compilation of 4.3.3 with mssql at one point did succeed, but since then I am not sure what has changed as its been almost two months now since I last compiled mod_php4. I have tried a number of things to fix this problem, but since I'm using the port management system, changing the actual PHP distribution code is all but impossible. I need the port management system for version tracking. An attempt to use 4.3.4RC1 failed with the same exact error. There is not yet a port for 4.3.4RC3. Environment is as follows: FreeBSD 5.1-RELEASE with latest security patches. FreeTDS 0.61.2 installed with --prefix=/usr/local --with-tdsver=7.0 --enable-msdblib Configure Options (note: I'm typing this by hand from the Makefile for the port, so forgive any misspellings I might accidentally do...) --enable-versioning --enable-memory-limit --with-layout=GNU --with-zlib-dir=/usr --disable-all -- with-pfpro=/usr/local --with-regex=php --enable-bcmath --enable-calendar --with-bz2=/usr --with-curl=/usr/local --with-dom=/usr/local --with-dom-xslt=/usr/local --with-dom-exslt=/usr/local --enable-ftp --with-gd --enable-gd-native-ttf --enable-gd-jis-conv --with-freetype-dir=/usr/local --with-jpeg-dir=/usr/local --with-png-dir=/usr/local --with-gettext=/usr/local --with-iconv=/usr/local --with-imap=/usr/local --with-imap-ssl=/usr/local --enable-mbstring --enable-mbregex --with-mcal=/usr/local --with-mcrypt=/usr/local --with-mhash=/usr/local --with-mime-magic=/usr/share/misc/magic.mime --with-mysql=/usr/local --with-openssl=/usr --enable-overload --with-pcre-regex=yes --enable-posix --enable-session --with-mssql=/usr/local --enable-tokenizer --enable-xml --with-expat-dir=/usr/local --with-zlib=yes Expected re
#26112 [NEW]: EXTRA_LDFLAGS_PROGRAM not set up properly
From: ast at domdv dot de Operating system: Linux 2.4 PHP version: 4.3.4 PHP Bug Type: Compile Failure Bug description: EXTRA_LDFLAGS_PROGRAM not set up properly Description: The build of sapi/cli/php fails for the configuration given below due to missing setup of EXTRA_LDFLAGS_PROGRAM in the main Makefile. Instead of EXTRA_LDFLAGS_PROGRAM = the following change was needed to link sapi/cli/php: EXTRA_LDFLAGS_PROGRAM = -lcrypto -lssl ext/openssl/openssl.lo Reproduce code: --- ./configure --with-apxs=/usr/local/apache/bin/apxs --prefix=/usr/local/php --with-config-file-path=/usr/local/php/conf --disable-short-tags --enable-bcmath=shared --enable-calendar=shared --with-gdbm=/usr --with-db4=/usr/BerkeleyDB/4.1.25 --enable-dba=shared --enable-dbase=shared --with-dom=shared --enable-ftp=shared --with-gd=shared,/usr --with-ttf --with-gettext=shared --with-imap=shared,/usr/imap --with-imap-ssl=/usr --with-mcrypt=shared,/usr --with-mhash=shared --with-msql=shared --with-mysql=shared,/usr/local/mysql --with-png-dir=/usr --with-freetype-dir=/usr --enable-shmop=shared --enable-sockets=shared --enable-sysvsem=shared --enable-sysvshm=shared --with-zlib=shared --with-curl=shared,/usr --enable-xml=shared --enable-memory-limit --with-tsrm-pthreads --enable-shared --with-gnu-ld --with-jpeg-dir=/usr --with-openssl=shared,/usr --enable-yp=shared --with-pspell=shared,/usr --with-gmp=shared,/usr --with-bz2=/usr --enable-gd-imgstrttf --enable-gd-native-ttf --with-expat-dir=shared,/usr --enable-inline-optimization --with-dom-xslt=shared --with-dom-exslt=shared --with-cyrus=shared --with-expat-dir=/usr --with-mysql-sock=/var/mysql/socket --enable-mbstring --enable-mbregex -- Edit bug report at http://bugs.php.net/?id=26112&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26112&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26112&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26112&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26112&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26112&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26112&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26112&r=support Expected behavior: http://bugs.php.net/fix.php?id=26112&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26112&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26112&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26112&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26112&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26112&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26112&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26112&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26112&r=float
#26111 [Opn]: mktime returns wrong date
ID: 26111
User updated by: chris at astra dot net dot uk
Reported By: chris at astra dot net dot uk
Status: Open
Bug Type: Date/time related
Operating System: FreeBSD
PHP Version: 4.3.3
New Comment:
getting the same error on 4.7-RELEASE, 4.8-RELEASE and 5.0-RELEASE.
I will install 4.9-PRERELEASE and test it now.
Previous Comments:
[2003-11-04 08:20:30] chris at astra dot net dot uk
echo mktime(12,1,1,3,28,2004);
echo gmmktime(12,1,1,3,28,2004);
both return 1080478861 (1969Sun, 28 Mar 2004 14:01:01 +0100)
[2003-11-04 08:18:59] [EMAIL PROTECTED]
Also works fine with Freebsd 4.9-PRERELEASE (whatever that means)
[2003-11-04 08:14:27] [EMAIL PROTECTED]
Try this too:
echo mktime(12,1,1,3,28,2004);
echo gmmktime(12,1,1,3,28,2004);
Just to note: These all work just fine with Linux. :)
[2003-11-04 08:10:36] chris at astra dot net dot uk
echo date("r", mktime(1,1,1,3,28,2004));
echo date("r", gmmktime(1,1,1,3,28,2004));
returns:
Thu, 1 Jan 1970 00:59:59 +0100
Thu, 1 Jan 1970 00:59:59 +0100
[2003-11-04 08:06:44] [EMAIL PROTECTED]
What do these output:
echo date("r", mktime(1,1,1,3,28,2004));
echo date("r", gmmktime(1,1,1,3,28,2004));
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/26111
--
Edit this bug report at http://bugs.php.net/?id=26111&edit=1
#26112 [Opn]: EXTRA_LDFLAGS_PROGRAM not set up properly
ID: 26112 User updated by: ast at domdv dot de Reported By: ast at domdv dot de Status: Open Bug Type: Compile Failure Operating System: Linux 2.4 PHP Version: 4.3.4 New Comment: The problem continues with the apache php module: # /usr/local/apache/bin/httpsdctl start Syntax error on line 65 of /usr/local/apache/conf/httpsd.conf: Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/apache/ libexec/libphp4.so: undefined symbol: php_openssl_apply_verification_policy /usr/local/apache/bin/httpsdctl start: httpsd could not be started Previous Comments: [2003-11-04 08:23:26] ast at domdv dot de Description: The build of sapi/cli/php fails for the configuration given below due to missing setup of EXTRA_LDFLAGS_PROGRAM in the main Makefile. Instead of EXTRA_LDFLAGS_PROGRAM = the following change was needed to link sapi/cli/php: EXTRA_LDFLAGS_PROGRAM = -lcrypto -lssl ext/openssl/openssl.lo Reproduce code: --- ./configure --with-apxs=/usr/local/apache/bin/apxs --prefix=/usr/local/php --with-config-file-path=/usr/local/php/conf --disable-short-tags --enable-bcmath=shared --enable-calendar=shared --with-gdbm=/usr --with-db4=/usr/BerkeleyDB/4.1.25 --enable-dba=shared --enable-dbase=shared --with-dom=shared --enable-ftp=shared --with-gd=shared,/usr --with-ttf --with-gettext=shared --with-imap=shared,/usr/imap --with-imap-ssl=/usr --with-mcrypt=shared,/usr --with-mhash=shared --with-msql=shared --with-mysql=shared,/usr/local/mysql --with-png-dir=/usr --with-freetype-dir=/usr --enable-shmop=shared --enable-sockets=shared --enable-sysvsem=shared --enable-sysvshm=shared --with-zlib=shared --with-curl=shared,/usr --enable-xml=shared --enable-memory-limit --with-tsrm-pthreads --enable-shared --with-gnu-ld --with-jpeg-dir=/usr --with-openssl=shared,/usr --enable-yp=shared --with-pspell=shared,/usr --with-gmp=shared,/usr --with-bz2=/usr --enable-gd-imgstrttf --enable-gd-native-ttf --with-expat-dir=shared,/usr --enable-inline-optimization --with-dom-xslt=shared --with-dom-exslt=shared --with-cyrus=shared --with-expat-dir=/usr --with-mysql-sock=/var/mysql/socket --enable-mbstring --enable-mbregex -- Edit this bug report at http://bugs.php.net/?id=26112&edit=1
#26113 [NEW]: ftp_get on non-existen file creates a o byte file
From: jcastro at elnuevodia dot com Operating system: windows xp PHP version: 4.3.3 PHP Bug Type: FTP related Bug description: ftp_get on non-existen file creates a o byte file Description: If I use ftp_get and the $server_file does not exist on the server, I will get a zero byte file created in my machine with the name that I put in the $local_file variable. I am running php 4.3.3 on windows xp prof Reproduce code: --- @ftp_get($conn_id, $local_file, $server_file, FTP_BINARY)) Expected result: No file should be created since the server_file did not exits Actual result: -- a zero byte file is created -- Edit bug report at http://bugs.php.net/?id=26113&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26113&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26113&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26113&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26113&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26113&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26113&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26113&r=support Expected behavior: http://bugs.php.net/fix.php?id=26113&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26113&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26113&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26113&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26113&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26113&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26113&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26113&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26113&r=float
#26111 [Opn]: mktime returns wrong date
ID: 26111
User updated by: chris at astra dot net dot uk
Reported By: chris at astra dot net dot uk
Status: Open
Bug Type: Date/time related
Operating System: FreeBSD
PHP Version: 4.3.3
New Comment:
4.9-PRERELEASE gives the same error here, php was compiled from the
FreeBSD ports collection (PHP 4.3.4RC1).
I am now upgrading to 4.9-RELEASE...
Previous Comments:
[2003-11-04 08:28:17] chris at astra dot net dot uk
getting the same error on 4.7-RELEASE, 4.8-RELEASE and 5.0-RELEASE.
I will install 4.9-PRERELEASE and test it now.
[2003-11-04 08:20:30] chris at astra dot net dot uk
echo mktime(12,1,1,3,28,2004);
echo gmmktime(12,1,1,3,28,2004);
both return 1080478861 (1969Sun, 28 Mar 2004 14:01:01 +0100)
[2003-11-04 08:18:59] [EMAIL PROTECTED]
Also works fine with Freebsd 4.9-PRERELEASE (whatever that means)
[2003-11-04 08:14:27] [EMAIL PROTECTED]
Try this too:
echo mktime(12,1,1,3,28,2004);
echo gmmktime(12,1,1,3,28,2004);
Just to note: These all work just fine with Linux. :)
[2003-11-04 08:10:36] chris at astra dot net dot uk
echo date("r", mktime(1,1,1,3,28,2004));
echo date("r", gmmktime(1,1,1,3,28,2004));
returns:
Thu, 1 Jan 1970 00:59:59 +0100
Thu, 1 Jan 1970 00:59:59 +0100
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/26111
--
Edit this bug report at http://bugs.php.net/?id=26111&edit=1
#25972 [Ana]: ODBC truncates multi-byte text (w/ MSSQL)
ID: 25972
Updated by: [EMAIL PROTECTED]
Reported By: phpbug at chipple dot net
Status: Analyzed
Bug Type: Feature/Change Request
Operating System: Win2K 5.00.2195 SP4
PHP Version: 4.3, 5
New Comment:
Well, then how did you conclude NVARCHAR support will break some kinds
of compatibilities? I think I have already pointed out that we'd still
be able to handle it on ODBCv2.
(Sorry if this sounds offending. I don't mean so :)
Basically we don't have to check whether the column type is NVARCHAR or
not, but just allocate enough space for that type of characters. That
way we also got to take a slight loss of memory into account though.
Previous Comments:
[2003-11-04 07:56:51] [EMAIL PROTECTED]
moriyoshi,
It's not as simple as you show it to be. First you must
realize that PHP's ODBC layer is written as an ODBC v2
compliant system, to just randomly add in support for
NVARCHAR (and friends) will break support for other
database systems.
The point of my post wasn't to say this isn't a bug
(hence why I marked it as verified), but rather to say
it's a known bug and the issue is the extension is in
need of updating.
[2003-11-03 17:13:35] [EMAIL PROTECTED]
I might be wrong, but I think this is a valid bug.
According to the documentation on msdn [1] [2], the fifth parameter of
SQLBindCol() expects the size of the buffer in byte, while the code
mentioned below appears to give it the number of characters allocated
for the column (display size) instead. This kind of confusion will most
likely cause unexpected behaviour like described in this report.
php_odbc.c 669:
--
default:
rc = SQLColAttributes(result->stmt, (UWORD)(i+1),
SQL_COLUMN_DISPLAY_SIZE, NULL, 0, NULL, &displaysize);
displaysize = displaysize <= result->longreadlen ? displaysize :
result->longreadlen;
result->values[i].value = (char *)emalloc(displaysize + 1);
rc = SQLBindCol(result->stmt, (UWORD)(i+1), SQL_C_CHAR,
result->values[i].value, displaysize + 1, &result->values[i].vallen);
break;
--
If the driver supports ODBCv3, we should use SQL_DESC_OCTET_LENGTH,
which can be used to determine the actual number of bytes. If not, we
may be able to safely calculate the maximum column size by simply
multiplying the display size by 2, as NVARCHAR columns are known to not
contain multi-byte strings, but double-byte strings.
[1]
http://msdn.microsoft.com/library/en-us/odbc/htm/odch04pr_13.asp?frame=true
[2]
http://msdn.microsoft.com/library/en-us/odbc/htm/odappdpr_24.asp?frame=true
[2003-10-31 09:26:28] [EMAIL PROTECTED]
Is this really a bug? The debate rages like so:
One the one hand ODBC does not support multi-byte
characters at all. On the other, the idea of multi-
byte characters didn't exist (or if it did, not very
prevailent) at the time of the original authoring of
the ODBC system.
Next question is, is there an easy fix. Nope. I've
had a fix in the works, I've just lost all time to work
upon it. Marking as verified, but not really sure it's
a bug. Maybe a feature request really...
Following the ODBCv2 specs, NVARCHAR is a type that
doesn't exist, nor does TEXT, NTEXT, and many of the
other wonderful types found today.
[2003-10-24 00:10:01] phpbug at chipple dot net
Sorry here's the MSSQL extension code that should have been in the 2nd
part of "Reproduce code".
// MSSQL EXTENSION, data retrieved correctly
$oConn = mssql_connect("localhost",C_Gen_sDbUser,C_Gen_sDbPassword);
mssql_select_db("icds",$oConn);
$oRs = mssql_query("SELECT * FROM T_Course WHERE aCourseID=1");
$aRow = mssql_fetch_array($oRs);
// GOOD: Complete title retrieved (60 chars=120 bytes)
echo $aRow["tTitle"];
mssql_close($oConn);
[2003-10-23 23:26:31] phpbug at chipple dot net
Description:
This bug has been observed with PHP 4.3.3 and 4.3.4RC2.
Database: MSSQL 2000 (8.00.760) SP3
I have a MSSQL database with a table containing a column tTitle of type
nvarchar(80) (which stands for 80 multi-byte characters).
When a string of 60 Japanese double-byte characters (120 bytes) stored
in column tTitle is retrieved using PHP's ODBC extension, the value is
truncated to 80 bytes.
The PHP MSSQL extension retrieves the data correctly.
Microsoft's ODBC driver (used from ASP) retrieves the data correctly.
MSSQL table structure:
CREATE TABLE [dbo].[T_Course] (
[aCourseID] [int] IDENTITY (1, 1) NOT NULL ,
[tTitle] [nvarchar] (80) COLLATE Japanese_CI_AS NOT NULL
) ON [PRIMARY]
GO
Test data (CSV):
aCourse
#26114 [NEW]: mysql_errno() & mysql_error() not behaving right on a second connection
From: scouture at novo dot ca
Operating system: windows 2000
PHP version: 4.3.3
PHP Bug Type: MySQL related
Bug description: mysql_errno() & mysql_error() not behaving right on a second
connection
Description:
When openning 2 connections to a MySQL server using mysql_connect or
mysql_pconnect, if the first connection is valid and the second not (in my
code, the password for the second connection is wrong), then mysql_error()
return an empty string and mysql_errno return 0 witch is the errno saying
that there has been no problem.
Reproduce code:
---
echo "first connection";
$conn1 = mysql_connect($validIp&Port,$validUser,$validPassword);
if($conn1 == false)
{
echo "mysql_error : ".mysql_error()."";
echo "mysql_errno : ".mysql_errno()."";
}
else
echo "ok connected 1";
echo "second connection";
$conn2 = mysql_connect ($validIp&Port,$validUser,$NOTvalidPassword);
if($conn2 == false)
{
echo "mysql_error : ".mysql_error()."";
echo "mysql_errno : ".mysql_errno()."";
}
else
echo "ok connected 2";
Expected result:
mysql_error should be
Access denied for user: '[EMAIL PROTECTED]' (Using password: YES)
mysql_errno should be
1045
Actual result:
--
/**display**/
first connection
ok connected 1
second connection
Warning: mysql_connect(): Access denied for user: '[EMAIL PROTECTED]'
(Using password: YES) in D:\Program Files\Apache
Group\Apache2\htdocs\Intranet Novolog\tesMysql.php on line 20
mysql_error :
mysql_errno : 0
--
Edit bug report at http://bugs.php.net/?id=26114&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26114&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26114&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26114&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26114&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26114&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=26114&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26114&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26114&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26114&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26114&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26114&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26114&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26114&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26114&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26114&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26114&r=float
#24394 [Ver]: Serializing xref'd objects segfaults.
ID: 24394
Updated by: [EMAIL PROTECTED]
Reported By: hoesh at dorsum dot hu
Status: Verified
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5.0.0 Beta 2
New Comment:
The leaks have nothing to do with the serialization function. That's
due to circular references between two objects.
Previous Comments:
[2003-11-03 18:35:35] [EMAIL PROTECTED]
In addition to the crash, when the serialize call is commented out,
these leaks are reported:
/usr/src/web/php/php5/Zend/zend_hash.c(236) : Freeing 0x40E46D10 (37
bytes), script=t.php
Last leak repeated 1 time
/usr/src/web/php/php5/Zend/zend_execute.c(3098) : Freeing 0x40E46CAC
(44 bytes), script=t.php
/usr/src/web/php/php5/Zend/zend_API.c(713) : Actual location (location
was relayed)
Last leak repeated 1 time
/usr/src/web/php/php5/Zend/zend_objects.c(106) : Freeing 0x40E46C68
(12 bytes), script=t.php
Last leak repeated 1 time
/usr/src/web/php/php5/Zend/zend_execute.c(3097) : Freeing 0x40E46C24
(16 bytes), script=t.php
Last leak repeated 1 time
/usr/src/web/php/php5/Zend/zend_API.c(714) : Freeing 0x40E469B8 (32
bytes), script=t.php
/usr/src/web/php/php5/Zend/zend_hash.c(157) : Actual location (location
was relayed)
Last leak repeated 1 time
[2003-07-07 08:24:55] [EMAIL PROTECTED]
Works 'fine' in PHP_4_3 branch, segfaults with PHP 5:
#0 0x813de25 in fast_call_user_function (function_table=0x81c3338,
object_pp=0x4029b688, function_name=0xbfe021a8,
retval_ptr_ptr=0xbfe02178, param_count=0, params=0x0,
no_separation=1, symbol_table=0x0,
function_pointer=0xbfe020b4) at
/usr/src/web/php/php5/Zend/zend_execute_API.c:477
#1 0x813de10 in call_user_function_ex (function_table=0x81c3338,
object_pp=0x4029b688, function_name=0xbfe021a8,
retval_ptr_ptr=0xbfe02178, param_count=0, params=0x0,
no_separation=1, symbol_table=0x0)
at /usr/src/web/php/php5/Zend/zend_execute_API.c:476
#2 0x80fdd63 in php_var_serialize_intern (buf=0xbfffd024,
struc=0x4029b688, var_hash=0xbfffd030)
at /usr/src/web/php/php5/ext/standard/var.c:555
#3 0x80fe90e in php_var_serialize_intern (buf=0xbfffd024,
struc=0x4029b5a0, var_hash=0xbfffd030)
at /usr/src/web/php/php5/ext/standard/var.c:620
#4 0x80fe90e in php_var_serialize_intern (buf=0xbfffd024,
struc=0x4029b688, var_hash=0xbfffd030)
at /usr/src/web/php/php5/ext/standard/var.c:620
#5 0x80fe90e in php_var_serialize_intern (buf=0xbfffd024,
struc=0x4029b5a0, var_hash=0xbfffd030)
at /usr/src/web/php/php5/ext/standard/var.c:620
#6 0x80fe90e in php_var_serialize_intern (buf=0xbfffd024,
struc=0x4029b688, var_hash=0xbfffd030)
at /usr/src/web/php/php5/ext/standard/var.c:620
.
.
.
.
Frame #6 is repeated couple of thousand times.. :)
[2003-07-06 06:56:32] hos dot endre at axelero dot hu
Okay: The subjected problem was solved by un-double-quoting the
session.save_path and remove the backslash from the end of line.
Anyway, until this the engine was able to create the file. After that I
had to get familiar with the new php_dom exension, which I think is
great, but not documented yet. So then comes a serialization problem:
objects in my project held reference to each other, and the
last-time-workin-good serialization crashed on this extra. Right now I
solved the problem by unbuilding theese references before
serialization, and rebuilding them on wakeup. Now I can test the ZE2
editions new features, thank you for the help!
Also, here is a sample script that doesn't work for me:
b = new b;
}
function setupb()
{
$this->b->setupa($this);
}
}
class b
{
var $a;
function setupa($a)
{
$this->a = $a;
}
}
$a = new a;
$a->setupb();
echo "This workx!\r\n";
echo serialize($a);
?>
[2003-06-29 19:37:32] hoesh at dorsum dot hu
Description:
On request shutdown session file is created, but stay locked with zero
size. CPU have no load, and nothing happens. No crash. I've tried older
5CVS bins, and it seems to be an older bug. Serialization and anything
else works well for me. 5.0.0-Beta1 also contains this bug. Leaving out
session_start & session_register. :)
Reproduce code:
---
Expected result:
1, 2, 3... by refreshing the page.
--
Edit this bug report at http://bugs.php.net/?id=24394&edit=1
#26114 [Opn]: mysql_errno() & mysql_error() not behaving right on a second connection
ID: 26114
User updated by: scouture at novo dot ca
Reported By: scouture at novo dot ca
Status: Open
Bug Type: MySQL related
Operating System: windows 2000
PHP Version: 4.3.3
New Comment:
NOTE that mysql_error() & mysql_errno() are returning result has
expected if the first connection failed. So, if the first connection
and the second failed, both mysql_error() & mysql_errno() are ok for
the first and the second connection.
But, if there is already a valid connection to the dbserver, they are
not behaving right for the second in case of failling.
Hope that is clear enought...
Regards
Previous Comments:
[2003-11-04 09:39:44] scouture at novo dot ca
Description:
When openning 2 connections to a MySQL server using mysql_connect or
mysql_pconnect, if the first connection is valid and the second not (in
my code, the password for the second connection is wrong), then
mysql_error() return an empty string and mysql_errno return 0 witch is
the errno saying that there has been no problem.
Reproduce code:
---
echo "first connection";
$conn1 = mysql_connect($validIp&Port,$validUser,$validPassword);
if($conn1 == false)
{
echo "mysql_error : ".mysql_error()."";
echo "mysql_errno : ".mysql_errno()."";
}
else
echo "ok connected 1";
echo "second connection";
$conn2 = mysql_connect ($validIp&Port,$validUser,$NOTvalidPassword);
if($conn2 == false)
{
echo "mysql_error : ".mysql_error()."";
echo "mysql_errno : ".mysql_errno()."";
}
else
echo "ok connected 2";
Expected result:
mysql_error should be
Access denied for user: '[EMAIL PROTECTED]' (Using password: YES)
mysql_errno should be
1045
Actual result:
--
/**display**/
first connection
ok connected 1
second connection
Warning: mysql_connect(): Access denied for user: '[EMAIL PROTECTED]'
(Using password: YES) in D:\Program Files\Apache
Group\Apache2\htdocs\Intranet Novolog\tesMysql.php on line 20
mysql_error :
mysql_errno : 0
--
Edit this bug report at http://bugs.php.net/?id=26114&edit=1
#26114 [Opn->Bgs]: mysql_errno() & mysql_error() not behaving right on a second connection
ID: 26114
Updated by: [EMAIL PROTECTED]
Reported By: scouture at novo dot ca
-Status: Open
+Status: Bogus
Bug Type: MySQL related
Operating System: windows 2000
PHP Version: 4.3.3
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Always use the link parameter when doing multiple connects in same
scripts. This is no bug.
Previous Comments:
[2003-11-04 09:45:51] scouture at novo dot ca
NOTE that mysql_error() & mysql_errno() are returning result has
expected if the first connection failed. So, if the first connection
and the second failed, both mysql_error() & mysql_errno() are ok for
the first and the second connection.
But, if there is already a valid connection to the dbserver, they are
not behaving right for the second in case of failling.
Hope that is clear enought...
Regards
[2003-11-04 09:39:44] scouture at novo dot ca
Description:
When openning 2 connections to a MySQL server using mysql_connect or
mysql_pconnect, if the first connection is valid and the second not (in
my code, the password for the second connection is wrong), then
mysql_error() return an empty string and mysql_errno return 0 witch is
the errno saying that there has been no problem.
Reproduce code:
---
echo "first connection";
$conn1 = mysql_connect($validIp&Port,$validUser,$validPassword);
if($conn1 == false)
{
echo "mysql_error : ".mysql_error()."";
echo "mysql_errno : ".mysql_errno()."";
}
else
echo "ok connected 1";
echo "second connection";
$conn2 = mysql_connect ($validIp&Port,$validUser,$NOTvalidPassword);
if($conn2 == false)
{
echo "mysql_error : ".mysql_error()."";
echo "mysql_errno : ".mysql_errno()."";
}
else
echo "ok connected 2";
Expected result:
mysql_error should be
Access denied for user: '[EMAIL PROTECTED]' (Using password: YES)
mysql_errno should be
1045
Actual result:
--
/**display**/
first connection
ok connected 1
second connection
Warning: mysql_connect(): Access denied for user: '[EMAIL PROTECTED]'
(Using password: YES) in D:\Program Files\Apache
Group\Apache2\htdocs\Intranet Novolog\tesMysql.php on line 20
mysql_error :
mysql_errno : 0
--
Edit this bug report at http://bugs.php.net/?id=26114&edit=1
#24394 [Com]: Serializing xref'd objects segfaults.
ID: 24394
Comment by: jalonso at art3mis dot com
Reported By: hoesh at dorsum dot hu
Status: Verified
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5.0.0 Beta 2
New Comment:
Is there any workaround until this bug is resolved?
Thank you.
Previous Comments:
[2003-11-04 09:42:17] [EMAIL PROTECTED]
The leaks have nothing to do with the serialization function. That's
due to circular references between two objects.
[2003-11-03 18:35:35] [EMAIL PROTECTED]
In addition to the crash, when the serialize call is commented out,
these leaks are reported:
/usr/src/web/php/php5/Zend/zend_hash.c(236) : Freeing 0x40E46D10 (37
bytes), script=t.php
Last leak repeated 1 time
/usr/src/web/php/php5/Zend/zend_execute.c(3098) : Freeing 0x40E46CAC
(44 bytes), script=t.php
/usr/src/web/php/php5/Zend/zend_API.c(713) : Actual location (location
was relayed)
Last leak repeated 1 time
/usr/src/web/php/php5/Zend/zend_objects.c(106) : Freeing 0x40E46C68
(12 bytes), script=t.php
Last leak repeated 1 time
/usr/src/web/php/php5/Zend/zend_execute.c(3097) : Freeing 0x40E46C24
(16 bytes), script=t.php
Last leak repeated 1 time
/usr/src/web/php/php5/Zend/zend_API.c(714) : Freeing 0x40E469B8 (32
bytes), script=t.php
/usr/src/web/php/php5/Zend/zend_hash.c(157) : Actual location (location
was relayed)
Last leak repeated 1 time
[2003-07-07 08:24:55] [EMAIL PROTECTED]
Works 'fine' in PHP_4_3 branch, segfaults with PHP 5:
#0 0x813de25 in fast_call_user_function (function_table=0x81c3338,
object_pp=0x4029b688, function_name=0xbfe021a8,
retval_ptr_ptr=0xbfe02178, param_count=0, params=0x0,
no_separation=1, symbol_table=0x0,
function_pointer=0xbfe020b4) at
/usr/src/web/php/php5/Zend/zend_execute_API.c:477
#1 0x813de10 in call_user_function_ex (function_table=0x81c3338,
object_pp=0x4029b688, function_name=0xbfe021a8,
retval_ptr_ptr=0xbfe02178, param_count=0, params=0x0,
no_separation=1, symbol_table=0x0)
at /usr/src/web/php/php5/Zend/zend_execute_API.c:476
#2 0x80fdd63 in php_var_serialize_intern (buf=0xbfffd024,
struc=0x4029b688, var_hash=0xbfffd030)
at /usr/src/web/php/php5/ext/standard/var.c:555
#3 0x80fe90e in php_var_serialize_intern (buf=0xbfffd024,
struc=0x4029b5a0, var_hash=0xbfffd030)
at /usr/src/web/php/php5/ext/standard/var.c:620
#4 0x80fe90e in php_var_serialize_intern (buf=0xbfffd024,
struc=0x4029b688, var_hash=0xbfffd030)
at /usr/src/web/php/php5/ext/standard/var.c:620
#5 0x80fe90e in php_var_serialize_intern (buf=0xbfffd024,
struc=0x4029b5a0, var_hash=0xbfffd030)
at /usr/src/web/php/php5/ext/standard/var.c:620
#6 0x80fe90e in php_var_serialize_intern (buf=0xbfffd024,
struc=0x4029b688, var_hash=0xbfffd030)
at /usr/src/web/php/php5/ext/standard/var.c:620
.
.
.
.
Frame #6 is repeated couple of thousand times.. :)
[2003-07-06 06:56:32] hos dot endre at axelero dot hu
Okay: The subjected problem was solved by un-double-quoting the
session.save_path and remove the backslash from the end of line.
Anyway, until this the engine was able to create the file. After that I
had to get familiar with the new php_dom exension, which I think is
great, but not documented yet. So then comes a serialization problem:
objects in my project held reference to each other, and the
last-time-workin-good serialization crashed on this extra. Right now I
solved the problem by unbuilding theese references before
serialization, and rebuilding them on wakeup. Now I can test the ZE2
editions new features, thank you for the help!
Also, here is a sample script that doesn't work for me:
b = new b;
}
function setupb()
{
$this->b->setupa($this);
}
}
class b
{
var $a;
function setupa($a)
{
$this->a = $a;
}
}
$a = new a;
$a->setupb();
echo "This workx!\r\n";
echo serialize($a);
?>
[2003-06-29 19:37:32] hoesh at dorsum dot hu
Description:
On request shutdown session file is created, but stay locked with zero
size. CPU have no load, and nothing happens. No crash. I've tried older
5CVS bins, and it seems to be an older bug. Serialization and anything
else works well for me. 5.0.0-Beta1 also contains this bug. Leaving out
session_start & session_register. :)
Reproduce code:
---
Expected result:
1, 2, 3... by refreshing the page.
--
Edit this bug report at http://bugs.php.net/?id=24394&edit=1
#26114 [Bgs]: mysql_errno() & mysql_error() not behaving right on a second connection
ID: 26114
User updated by: scouture at novo dot ca
Reported By: scouture at novo dot ca
Status: Bogus
Bug Type: MySQL related
Operating System: windows 2000
PHP Version: 4.3.3
New Comment:
I've got the same result EVEN with the new_link parameter set to TRUE.
echo "first connection";
$conn1 = mysql_connect($validIp&Port,$validUser,$validPassword,
true);
if($conn1 == false)
{
echo "mysql_error : ".mysql_error()."";
echo "mysql_errno : ".mysql_errno()."";
}
else
echo "ok connected 1";
echo "second connection";
$conn2 = mysql_connect ($validIp&Port,$validUser,$NOTvalidPassword,
true);
if($conn2 == false)
{
echo "mysql_error : ".mysql_error()."";
echo "mysql_errno : ".mysql_errno()."";
}
else
echo "ok connected 2";
Previous Comments:
[2003-11-04 09:58:34] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Always use the link parameter when doing multiple connects in same
scripts. This is no bug.
[2003-11-04 09:45:51] scouture at novo dot ca
NOTE that mysql_error() & mysql_errno() are returning result has
expected if the first connection failed. So, if the first connection
and the second failed, both mysql_error() & mysql_errno() are ok for
the first and the second connection.
But, if there is already a valid connection to the dbserver, they are
not behaving right for the second in case of failling.
Hope that is clear enought...
Regards
[2003-11-04 09:39:44] scouture at novo dot ca
Description:
When openning 2 connections to a MySQL server using mysql_connect or
mysql_pconnect, if the first connection is valid and the second not (in
my code, the password for the second connection is wrong), then
mysql_error() return an empty string and mysql_errno return 0 witch is
the errno saying that there has been no problem.
Reproduce code:
---
echo "first connection";
$conn1 = mysql_connect($validIp&Port,$validUser,$validPassword);
if($conn1 == false)
{
echo "mysql_error : ".mysql_error()."";
echo "mysql_errno : ".mysql_errno()."";
}
else
echo "ok connected 1";
echo "second connection";
$conn2 = mysql_connect ($validIp&Port,$validUser,$NOTvalidPassword);
if($conn2 == false)
{
echo "mysql_error : ".mysql_error()."";
echo "mysql_errno : ".mysql_errno()."";
}
else
echo "ok connected 2";
Expected result:
mysql_error should be
Access denied for user: '[EMAIL PROTECTED]' (Using password: YES)
mysql_errno should be
1045
Actual result:
--
/**display**/
first connection
ok connected 1
second connection
Warning: mysql_connect(): Access denied for user: '[EMAIL PROTECTED]'
(Using password: YES) in D:\Program Files\Apache
Group\Apache2\htdocs\Intranet Novolog\tesMysql.php on line 20
mysql_error :
mysql_errno : 0
--
Edit this bug report at http://bugs.php.net/?id=26114&edit=1
#26115 [NEW]: Complie failure from zend.h
From: royw at imsi dot com Operating system: Solaris 8 PHP version: 4.3.4 PHP Bug Type: Compile Failure Bug description: Complie failure from zend.h Description: configure line: ./configure --with-mysql=/usr/local/mysql --with-apxs=/usr/local/apache/bin/apxs this is with apache 1.3.29 it configures fine, here is the configure output loading cache ./config.cache checking host system type... sparc-sun-solaris2.8 checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking whether gcc and cc understand -c and -o together... yes checking how to run the C preprocessor... gcc -E checking for AIX... no checking if compiler supports -R... yes checking for re2c... exit 0; checking for ranlib... ranlib checking whether ln -s works... yes checking for gawk... gawk checking for bison... bison -y checking bison version... configure: warning: You will need bison 1.28 1.34 (ok) checking for flex... flex checking for yywrap in -lfl... yes checking lex output file root... lex.yy checking whether yytext is a pointer... yes checking for working const... yes checking flex version... 2.5.4 (ok) checking for pthreads_cflags... -pthreads checking for pthreads_lib... Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... yes checking for member fd in BUFF *... yes checking for mod_charset compatibility option... no checking for Apache 2.0 filter-module support via DSO through APXS... no checking for Apache 2.0 handler-module support via DSO through APXS... no checking for Caudium support... no checking for CLI build... yes checking for embedded SAPI library support... no checking for Zeus ISAPI support... no checking for NSAPI support... no checking for PHTTPD support... no checking for Pi3Web support... no checking for Roxen/Pike support... no checking for Servlet support... no checking for thttpd... no checking for TUX... no checking for webjames... no checking for chosen SAPI module... apache Running system checks checking for missing declarations of reentrant functions... done checking for sendmail... /usr/lib/sendmail checking whether system uses EBCDIC... no checking for socket... no checking for __socket... no checking for socket in -lsocket... yes checking for htonl... yes checking for gethostname... yes checking for gethostbyaddr... yes checking for yp_get_default_domain... yes checking for dlopen... yes checking for sin in -lm... yes checking for res_search... no checking for __res_search... no checking for res_search in -lresolv... yes checking for inet_aton... yes checking for dn_skipname... yes checking for ANSI C header files... yes checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for fclose declaration... ok checking for dirent.h... yes checking for ApplicationServices/ApplicationServices.h... no checking for sys/param.h... yes checking for sys/types.h... yes checking for sys/time.h... yes checking for netinet/in.h... yes checking for alloca.h... yes checking for arpa/inet.h... yes checking for arpa/nameser.h... yes checking for assert.h... yes checking for crypt.h... yes checking for fcntl.h... yes checking for grp.h... yes checking for ieeefp.h... yes checking for langinfo.h... yes checking for limits.h... yes checking for locale.h... yes checking for monetary.h... yes checking for mach-o/dyld.h... no checking for netdb.h... yes checking for pwd.h... yes checking for resolv.h... yes checking for signal.h... yes checking for stdarg.h... yes checking for stdlib.h... yes checking for string.h... yes checking for syslog.h... yes checking for sysexits.h... yes checking for sys/file.h... yes checking for sys/mman.h... yes checking for sys/mount.h... yes checking for sys/poll.h... yes checking for sys/resource.h... yes checking for sys/select.h... yes checking for sys/socket.h... yes checking for sys/statfs.h... yes checking for sys/statvfs.h... yes checking for sys/vfs.h... yes checking for sys/sysexits.h... no checking for sys/varargs.h... yes checking for sys/wait.h... yes checking for unistd.h... yes checking for unix.h... no checking for utime.h... yes checking for sys/utsname.h... yes checking for sys/ipc.h... yes checking for dlfcn.h... yes checking for fopencookie... no checking for broken getcwd... yes checking for broken libc stdio... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for tm_zone in struct tm... no checking for tzname... yes checking for tm_gmtoff in struct tm... no checking for struct flock... yes checking for socklen_t... yes checking size of long... 4 checking size of int... 4 checking for st_blksize in struct stat... yes checking for st_blocks in struct stat... yes checking for st_rdev in struct stat... yes checking for size_t.
#26116 [NEW]: Unable to connect to ODBC database
From: andrew at howells-solicitors dot com Operating system: Windows NT 4 sp6a PHP version: 4.3.4 PHP Bug Type: ODBC related Bug description: Unable to connect to ODBC database Description: I am using PHP 4.3.4 & Apache 1.3.28 all on Windows NTT 4. I have a remote Progress database server that serves as backednd to a practice management and accounts suite we use in-house. I want to use PHP to provide a web based interface to this database but am having some entertaining problems. I've tried the progress supplied Merant ODBC drivers as well as the OpenLink ODBC drivers. Both connect fine, however, if I try connecting using PHP loaded as a module ito apache I cannot connect to the DB, the ODBC driver refuses to load. However, If I execute the script from the comand line "php E:\webpages\intranet\sostest2.php" The connection is established ok. Reproduce code: --- http://bugs.php.net/?id=26116&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26116&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26116&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26116&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26116&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26116&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26116&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26116&r=support Expected behavior: http://bugs.php.net/fix.php?id=26116&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26116&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26116&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26116&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26116&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26116&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26116&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26116&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26116&r=float
#26117 [NEW]: Persistent connection not reused
From: spam at vrana dot cz
Operating system: Linux
PHP version: 4.3.3
PHP Bug Type: MySQL related
Bug description: Persistent connection not reused
Description:
Configuration:
Apache 1.3.28
MySQL 4.0.15a
With Apache configuration directive MaxClients set to 150, the number of
database connection raised up to 466 (until MySQL denied connections with
Too many connections error). In all scripts I use the same
mysql_pconnect("localhost", "user", "pwd").
MySQL command SHOW PROCESSLIST showed that all 466 connections were made
with the same connection parameters. All connections were in state Sleep.
I am connecting to MySQL only from PHP module in Apache so I think this
behavior is caused by some bug in handling with connection pool in PHP.
--
Edit bug report at http://bugs.php.net/?id=26117&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26117&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26117&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26117&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26117&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26117&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=26117&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26117&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26117&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26117&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26117&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26117&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26117&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26117&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26117&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26117&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26117&r=float
#24394 [Ver->Csd]: Serializing xref'd objects segfaults.
ID: 24394
Updated by: [EMAIL PROTECTED]
Reported By: hoesh at dorsum dot hu
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5.0.0 Beta 2
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2003-11-04 10:24:10] jalonso at art3mis dot com
Is there any workaround until this bug is resolved?
Thank you.
[2003-11-04 09:42:17] [EMAIL PROTECTED]
The leaks have nothing to do with the serialization function. That's
due to circular references between two objects.
[2003-11-03 18:35:35] [EMAIL PROTECTED]
In addition to the crash, when the serialize call is commented out,
these leaks are reported:
/usr/src/web/php/php5/Zend/zend_hash.c(236) : Freeing 0x40E46D10 (37
bytes), script=t.php
Last leak repeated 1 time
/usr/src/web/php/php5/Zend/zend_execute.c(3098) : Freeing 0x40E46CAC
(44 bytes), script=t.php
/usr/src/web/php/php5/Zend/zend_API.c(713) : Actual location (location
was relayed)
Last leak repeated 1 time
/usr/src/web/php/php5/Zend/zend_objects.c(106) : Freeing 0x40E46C68
(12 bytes), script=t.php
Last leak repeated 1 time
/usr/src/web/php/php5/Zend/zend_execute.c(3097) : Freeing 0x40E46C24
(16 bytes), script=t.php
Last leak repeated 1 time
/usr/src/web/php/php5/Zend/zend_API.c(714) : Freeing 0x40E469B8 (32
bytes), script=t.php
/usr/src/web/php/php5/Zend/zend_hash.c(157) : Actual location (location
was relayed)
Last leak repeated 1 time
[2003-07-07 08:24:55] [EMAIL PROTECTED]
Works 'fine' in PHP_4_3 branch, segfaults with PHP 5:
#0 0x813de25 in fast_call_user_function (function_table=0x81c3338,
object_pp=0x4029b688, function_name=0xbfe021a8,
retval_ptr_ptr=0xbfe02178, param_count=0, params=0x0,
no_separation=1, symbol_table=0x0,
function_pointer=0xbfe020b4) at
/usr/src/web/php/php5/Zend/zend_execute_API.c:477
#1 0x813de10 in call_user_function_ex (function_table=0x81c3338,
object_pp=0x4029b688, function_name=0xbfe021a8,
retval_ptr_ptr=0xbfe02178, param_count=0, params=0x0,
no_separation=1, symbol_table=0x0)
at /usr/src/web/php/php5/Zend/zend_execute_API.c:476
#2 0x80fdd63 in php_var_serialize_intern (buf=0xbfffd024,
struc=0x4029b688, var_hash=0xbfffd030)
at /usr/src/web/php/php5/ext/standard/var.c:555
#3 0x80fe90e in php_var_serialize_intern (buf=0xbfffd024,
struc=0x4029b5a0, var_hash=0xbfffd030)
at /usr/src/web/php/php5/ext/standard/var.c:620
#4 0x80fe90e in php_var_serialize_intern (buf=0xbfffd024,
struc=0x4029b688, var_hash=0xbfffd030)
at /usr/src/web/php/php5/ext/standard/var.c:620
#5 0x80fe90e in php_var_serialize_intern (buf=0xbfffd024,
struc=0x4029b5a0, var_hash=0xbfffd030)
at /usr/src/web/php/php5/ext/standard/var.c:620
#6 0x80fe90e in php_var_serialize_intern (buf=0xbfffd024,
struc=0x4029b688, var_hash=0xbfffd030)
at /usr/src/web/php/php5/ext/standard/var.c:620
.
.
.
.
Frame #6 is repeated couple of thousand times.. :)
[2003-07-06 06:56:32] hos dot endre at axelero dot hu
Okay: The subjected problem was solved by un-double-quoting the
session.save_path and remove the backslash from the end of line.
Anyway, until this the engine was able to create the file. After that I
had to get familiar with the new php_dom exension, which I think is
great, but not documented yet. So then comes a serialization problem:
objects in my project held reference to each other, and the
last-time-workin-good serialization crashed on this extra. Right now I
solved the problem by unbuilding theese references before
serialization, and rebuilding them on wakeup. Now I can test the ZE2
editions new features, thank you for the help!
Also, here is a sample script that doesn't work for me:
b = new b;
}
function setupb()
{
$this->b->setupa($this);
}
}
class b
{
var $a;
function setupa($a)
{
$this->a = $a;
}
}
$a = new a;
$a->setupb();
echo "This workx!\r\n";
echo serialize($a);
?>
The remainder of the comments for this report are too lon
#26114 [Bgs]: mysql_errno() & mysql_error() not behaving right on a second connection
ID: 26114
User updated by: scouture at novo dot ca
Reported By: scouture at novo dot ca
Status: Bogus
Bug Type: MySQL related
Operating System: windows 2000
PHP Version: 4.3.3
New Comment:
Have you been able to reproduce the behavior with the new_link
parameter set to TRUE like I did ?
Previous Comments:
[2003-11-04 10:27:52] scouture at novo dot ca
I've got the same result EVEN with the new_link parameter set to TRUE.
echo "first connection";
$conn1 = mysql_connect($validIp&Port,$validUser,$validPassword,
true);
if($conn1 == false)
{
echo "mysql_error : ".mysql_error()."";
echo "mysql_errno : ".mysql_errno()."";
}
else
echo "ok connected 1";
echo "second connection";
$conn2 = mysql_connect ($validIp&Port,$validUser,$NOTvalidPassword,
true);
if($conn2 == false)
{
echo "mysql_error : ".mysql_error()."";
echo "mysql_errno : ".mysql_errno()."";
}
else
echo "ok connected 2";
[2003-11-04 09:58:34] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Always use the link parameter when doing multiple connects in same
scripts. This is no bug.
[2003-11-04 09:45:51] scouture at novo dot ca
NOTE that mysql_error() & mysql_errno() are returning result has
expected if the first connection failed. So, if the first connection
and the second failed, both mysql_error() & mysql_errno() are ok for
the first and the second connection.
But, if there is already a valid connection to the dbserver, they are
not behaving right for the second in case of failling.
Hope that is clear enought...
Regards
[2003-11-04 09:39:44] scouture at novo dot ca
Description:
When openning 2 connections to a MySQL server using mysql_connect or
mysql_pconnect, if the first connection is valid and the second not (in
my code, the password for the second connection is wrong), then
mysql_error() return an empty string and mysql_errno return 0 witch is
the errno saying that there has been no problem.
Reproduce code:
---
echo "first connection";
$conn1 = mysql_connect($validIp&Port,$validUser,$validPassword);
if($conn1 == false)
{
echo "mysql_error : ".mysql_error()."";
echo "mysql_errno : ".mysql_errno()."";
}
else
echo "ok connected 1";
echo "second connection";
$conn2 = mysql_connect ($validIp&Port,$validUser,$NOTvalidPassword);
if($conn2 == false)
{
echo "mysql_error : ".mysql_error()."";
echo "mysql_errno : ".mysql_errno()."";
}
else
echo "ok connected 2";
Expected result:
mysql_error should be
Access denied for user: '[EMAIL PROTECTED]' (Using password: YES)
mysql_errno should be
1045
Actual result:
--
/**display**/
first connection
ok connected 1
second connection
Warning: mysql_connect(): Access denied for user: '[EMAIL PROTECTED]'
(Using password: YES) in D:\Program Files\Apache
Group\Apache2\htdocs\Intranet Novolog\tesMysql.php on line 20
mysql_error :
mysql_errno : 0
--
Edit this bug report at http://bugs.php.net/?id=26114&edit=1
#26118 [NEW]: fdf-functions so not work
From: admin at evodot dot de Operating system: debian linux 3.0 PHP version: 4.3.3 PHP Bug Type: FDF related Bug description: fdf-functions so not work Description: On a debian linux 3.0 with all-standard packages the phplib is to be substituted by a self-compiled one incl. fdf-support. Got the sources of php 4.3.3 and FdfTk v5.0 and compiled without severe problems (only some develop-packages, which had to be added). But of the fdf-functions is actually available, i.e. any of 'fdf_open( $file )', 'fdf_open_string( "$HTTP_FDF_DATA" )' or even 'fdf_create()' fails without any further comment. In the log you can only find the complaints of 'fdf_close()', 'fdf_save()' and so on ... Btw. I tried both, fdf as shared object and statical linked into php: ./configure --prefix=/usr/local --with-exec-dir=/usr/local/lib/php --with-pgsql=no --with-mysql=shared,/usr --with-gd=shared,/usr --with-tiff-dir=shared,/usr --with-jpeg-dir=shared,/usr --with-png-dir=shared,/usr --with-xpm-dir=shared,/usr/X11R6 --with-pdflib=no --with-imap=no --with-ldap=no --with-zlib=yes --with-xml --with-ttf --with-sablot --with-readline --with-ftp --with-gettext=no --with-mm --with-freetype-dir=shared,/usr --enable-versioning --enable-yp=no --enable-bcmath --enable-trans-sid --enable-inline-optimization --enable-track-vars --enable-magic-quotes --enable-safe-mode --enable-sockets --enable-sysvsem --enable-sysvshm --enable-shmop --enable-exif --enable-ftp --enable-memory-limit --enable-wddx --enable-filepro --enable-dbase --with-config-file-path=/etc/php4/apache --with-apxs=/usr/bin/apxs --with-fdftk=/usr/local resp. --with-fdftk=shared,/usr/local Reproduce code: --- $fdf_doc = fdf_create () or error_log ( "test.php: \ fdf_create() failed", 0 ); fdf_save ( $fdf_doc, "/tmp/test.fdf" ) or error_log ( \ "test.php: fdf_save() failed", 0 ); fdf_close ( $fdf_doc ); Expected result: to have a fdf-file named /tmp/test.fdf ... sort of :-} Actual result: -- [04-Nov-2003 17:10:24] test.php: fdf_create() failed [04-Nov-2003 17:10:24] PHP Warning: fdf_save() expects \ parameter 1 to be resource, boolean given in \ /var/apache/htdocs/test.php on line 15 [04-Nov-2003 17:10:24] test.php: fdf_save() failed [04-Nov-2003 17:10:24] PHP Warning: fdf_close(): supplied \ argument is not a valid fdf resource in \ /var/apache/htdocs/test.php on line 17 -- Edit bug report at http://bugs.php.net/?id=26118&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26118&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26118&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26118&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26118&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26118&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26118&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26118&r=support Expected behavior: http://bugs.php.net/fix.php?id=26118&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26118&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26118&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26118&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26118&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26118&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26118&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26118&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26118&r=float
#26105 [Com]: argument format specified for non-function
ID: 26105 Comment by: php at dactar dot ch Reported By: simon dot boulet at divahost dot net Status: Open Bug Type: Compile Failure Operating System: Linux/gcc 3.0.4 PHP Version: 4.3.4 New Comment: I've the same problem on HP-UX 11.00 and gcc version 3.0.1 @++ JC Previous Comments: [2003-11-03 21:39:45] simon dot boulet at divahost dot net Description: The new version on PHP fails to compile. I was previously using version 4.3.3 and it was compiling fine. Configure flags: --with-mysql --with-apxs --with-gd -with-zlib --with-jpeg-dir=/usr --with-apxs=/usr/local/apache/bin/apxs `make` fails straight at the beginning with: /bin/sh /root/php-4.3.4/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/zlib/ -I/root/php-4.3.4/ext/zlib/ -DPHP_ATOM_INC -I/root/php-4.3.4/include -I/root/php-4.3.4/main -I/root/php-4.3.4 -I/root/php-4.3.4/Zend -I/root/php-4.3.4/ext/xml/expat -I/root/php-4.3.4/TSRM -g -O2 -prefer-pic -c /root/php-4.3.4/ext/zlib/zlib.c -o ext/zlib/zlib.lo In file included from /root/php-4.3.4/main/php.h:34, from /root/php-4.3.4/ext/zlib/zlib.c:28: /root/php-4.3.4/Zend/zend.h:311: argument format specified for non-function `error_function' /root/php-4.3.4/Zend/zend.h:312: argument format specified for non-function `printf_function' /root/php-4.3.4/Zend/zend.h:444: argument format specified for non-function `zend_printf' /root/php-4.3.4/Zend/zend.h:451: argument format specified for non-function `zend_error_cb' make: *** [ext/zlib/zlib.lo] Error 1 I am far from being a C expert, but I think it as something to do with GCC version checking in Zend/zend.h near line 155. I was able to compile just fine with: #define ZEND_ATTRIBUTE_PTR_FORMAT(type, idx, first) instead of: # define ZEND_ATTRIBUTE_PTR_FORMAT(type, idx, first) __attribute__ ((format(type, idx, first))) that would be defined with ZEND_GCC_VERSION >= 3000. -- Edit this bug report at http://bugs.php.net/?id=26105&edit=1
#25254 [Bgs]: Using /r/n in mailheaders causes mailbody to become currupt
ID: 25254 User updated by: ts at dreamcoder dot dk Reported By: ts at dreamcoder dot dk Status: Bogus Bug Type: Mail related Operating System: Linux PHP Version: 4.3.3 New Comment: This bug was fixed in 4.3.4, works for me now... Might also be because I switched to redhat, who knows Previous Comments: [2003-10-09 06:46:16] [EMAIL PROTECTED] Works fine with sendmail. [2003-10-08 13:52:16] ts at dreamcoder dot dk I just tested this with 4.3.4RC2-dev (as requested), it's exactly the same problem I also tried sending mail using PHPMailer (the class). Sending mails directly to the SMTP with \r\n works just fine However when using PHP's mail() and \r\n, it fails to send correctly, as described in the original bug I have PostFix 2.0.16 installed - if that has any relevance I cannot rule out this could be a bug in Postfix, but I doubt it [2003-10-07 19:16:11] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-08-27 01:13:50] ts at dreamcoder dot dk It's still an issue in terms of BC. As I mentioned, it worked fine in 4.3.2 [2003-08-26 23:50:45] [EMAIL PROTECTED] Either using \r\n or just \n works just fine for me. Not PHP bug. 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/25254 -- Edit this bug report at http://bugs.php.net/?id=25254&edit=1
#26117 [Opn->Bgs]: Persistent connection not reused
ID: 26117
Updated by: [EMAIL PROTECTED]
Reported By: spam at vrana dot cz
-Status: Open
+Status: Bogus
Bug Type: MySQL related
Operating System: Linux
PHP Version: 4.3.3
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
If you go mysql_select_db() then the persistent connection you've
created becomes specific to that particular database. Which may explain
why those connections are not re-used.
Also, persistent connections are per-child, meaning that if 1 Apache
child opens connections only that child has a pre-existing connection
avaliable. If a subsequent request is handled by another child, which
does not yet have a MySQL connection, it'll create a new connection.
Previous Comments:
[2003-11-04 11:00:20] spam at vrana dot cz
Description:
Configuration:
Apache 1.3.28
MySQL 4.0.15a
With Apache configuration directive MaxClients set to 150, the number
of database connection raised up to 466 (until MySQL denied connections
with Too many connections error). In all scripts I use the same
mysql_pconnect("localhost", "user", "pwd").
MySQL command SHOW PROCESSLIST showed that all 466 connections were
made with the same connection parameters. All connections were in state
Sleep.
I am connecting to MySQL only from PHP module in Apache so I think this
behavior is caused by some bug in handling with connection pool in PHP.
--
Edit this bug report at http://bugs.php.net/?id=26117&edit=1
#26115 [Opn->Fbk]: Complie failure from zend.h
ID: 26115 Updated by: [EMAIL PROTECTED] Reported By: royw at imsi dot com -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.3.4 New Comment: What is the version of your compiler? Previous Comments: [2003-11-04 10:33:21] royw at imsi dot com Description: configure line: ./configure --with-mysql=/usr/local/mysql --with-apxs=/usr/local/apache/bin/apxs this is with apache 1.3.29 it configures fine, here is the configure output loading cache ./config.cache checking host system type... sparc-sun-solaris2.8 checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking whether gcc and cc understand -c and -o together... yes checking how to run the C preprocessor... gcc -E checking for AIX... no checking if compiler supports -R... yes checking for re2c... exit 0; checking for ranlib... ranlib checking whether ln -s works... yes checking for gawk... gawk checking for bison... bison -y checking bison version... configure: warning: You will need bison 1.28 1.34 (ok) checking for flex... flex checking for yywrap in -lfl... yes checking lex output file root... lex.yy checking whether yytext is a pointer... yes checking for working const... yes checking flex version... 2.5.4 (ok) checking for pthreads_cflags... -pthreads checking for pthreads_lib... Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... yes checking for member fd in BUFF *... yes checking for mod_charset compatibility option... no checking for Apache 2.0 filter-module support via DSO through APXS... no checking for Apache 2.0 handler-module support via DSO through APXS... no checking for Caudium support... no checking for CLI build... yes checking for embedded SAPI library support... no checking for Zeus ISAPI support... no checking for NSAPI support... no checking for PHTTPD support... no checking for Pi3Web support... no checking for Roxen/Pike support... no checking for Servlet support... no checking for thttpd... no checking for TUX... no checking for webjames... no checking for chosen SAPI module... apache Running system checks checking for missing declarations of reentrant functions... done checking for sendmail... /usr/lib/sendmail checking whether system uses EBCDIC... no checking for socket... no checking for __socket... no checking for socket in -lsocket... yes checking for htonl... yes checking for gethostname... yes checking for gethostbyaddr... yes checking for yp_get_default_domain... yes checking for dlopen... yes checking for sin in -lm... yes checking for res_search... no checking for __res_search... no checking for res_search in -lresolv... yes checking for inet_aton... yes checking for dn_skipname... yes checking for ANSI C header files... yes checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for fclose declaration... ok checking for dirent.h... yes checking for ApplicationServices/ApplicationServices.h... no checking for sys/param.h... yes checking for sys/types.h... yes checking for sys/time.h... yes checking for netinet/in.h... yes checking for alloca.h... yes checking for arpa/inet.h... yes checking for arpa/nameser.h... yes checking for assert.h... yes checking for crypt.h... yes checking for fcntl.h... yes checking for grp.h... yes checking for ieeefp.h... yes checking for langinfo.h... yes checking for limits.h... yes checking for locale.h... yes checking for monetary.h... yes checking for mach-o/dyld.h... no checking for netdb.h... yes checking for pwd.h... yes checking for resolv.h... yes checking for signal.h... yes checking for stdarg.h... yes checking for stdlib.h... yes checking for string.h... yes checking for syslog.h... yes checking for sysexits.h... yes checking for sys/file.h... yes checking for sys/mman.h... yes checking for sys/mount.h... yes checking for sys/poll.h... yes checking for sys/resource.h... yes checking for sys/select.h... yes checking for sys/socket.h... yes checking for sys/statfs.h... yes checking for sys/statvfs.h... yes checking for sys/vfs.h... yes checking for sys/sysexits.h... no checking for sys/varargs.h... yes checking for sys/wait.h... yes checking for unistd.h... yes checking for unix.h... no checking for utime.h... yes checking for sys/utsname.h... yes checking for sys/ipc.h... yes checking for dlfcn.h... yes checking for fopencookie... no checking for broken getcwd... yes checking for broken libc stdio... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for tm_zone in struct tm... no checking for tzname... yes checking for tm_gmtoff in struct tm... no checkin
#26119 [NEW]: Random SESSION-ID given in URL is accepted for the session
From: glattfahrservice at web dot de Operating system: Windows XP Professional PHP version: 4.3.4 PHP Bug Type: Session related Bug description: Random SESSION-ID given in URL is accepted for the session Description: Normally PHP is using some clever algorithms to provide for safe and unique SESSION-IDs. However, when a simple session-id is passed to the script in which session_start() is called, a session with the given ID is generated. e.g.: www.test.com/index.php&PHPSESSID=blabla should not be accepted and a new SESSION-ID should be generated for the session. BUT: this session-ID (blabla) is obviously valid and not rejected. Functionality is not impaired, but right now a visitor is able to "choose" his own session-id. Not very safe, right? I have disabled cookies and turned off trans-sid. Ciao, Dan. -- Edit bug report at http://bugs.php.net/?id=26119&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26119&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26119&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26119&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26119&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26119&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26119&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26119&r=support Expected behavior: http://bugs.php.net/fix.php?id=26119&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26119&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26119&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26119&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26119&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26119&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26119&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26119&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26119&r=float
#26120 [NEW]: ERROR WHEN TRYING TO REMOVE EMAIL ADDRESS
From: gajarvis at iquest dot net Operating system: WIN 98 PHP version: Irrelevant PHP Bug Type: Feature/Change Request Bug description: ERROR WHEN TRYING TO REMOVE EMAIL ADDRESS Description: Warning: mysql_connect() [function.mysql-connect]: Host '200-206-184-38.dsl.telesp.net.br' is blocked because of many connection errors. Unblock with 'mysqladmin flush-hosts' in /home/generic/html/obg/vars.php on line 25 Warning: Cannot modify header information - headers already sent by (output started at /home/generic/html/obg/vars.php:25) in /home/generic/html/obg/post.php on line 54 RECEIVED THIS MESSAGE WHEN TRYING TO REMOVE EMAIL. Please remove [EMAIL PROTECTED] from all mailing lists. Reproduce code: --- Warning: mysql_connect() [function.mysql-connect]: Host '200-206-184-38.dsl.telesp.net.br' is blocked because of many connection errors. Unblock with 'mysqladmin flush-hosts' in /home/generic/html/obg/vars.php on line 25 Warning: Cannot modify header information - headers already sent by (output started at /home/generic/html/obg/vars.php:25) in /home/generic/html/obg/post.php on line 54 Expected result: Email address [EMAIL PROTECTED] will be removed. -- Edit bug report at http://bugs.php.net/?id=26120&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26120&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26120&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26120&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26120&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26120&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26120&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26120&r=support Expected behavior: http://bugs.php.net/fix.php?id=26120&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26120&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26120&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26120&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26120&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26120&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26120&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26120&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26120&r=float
#26121 [NEW]: Object defined before object - error
From: closer at netnitco dot net
Operating system: Redhat Linux 9.0 / Apache 2.0.46
PHP version: 5.0.0b2 (beta2)
PHP Bug Type: Class/Object related
Bug description: Object defined before object - error
Description:
With PHP 4 you could create the object variable before the actual object
was defined. This doesnt seem to be true in 5. If you move lines 2 and 3
of the code to the bottom the script oes work, but this does break
backward compatibility.
Reproduce code:
---
hello ();
class new_class
{
function hello ()
{
echo "Hello";
}
}
?>
Expected result:
Hello
Actual result:
--
Fatal error: Class 'new_class' not found in
/usr/local/apache2/htdocs/scripts/class_test.php on line 2
--
Edit bug report at http://bugs.php.net/?id=26121&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26121&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26121&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26121&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26121&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26121&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=26121&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26121&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26121&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26121&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26121&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26121&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26121&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26121&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26121&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26121&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26121&r=float
#24436 [Com]: isset() and empty() produce errors with non-existent variables in classes
ID: 24436
Comment by: hongnk at hotmail dot com
Reported By: Nico dot Laus dot 2002 at gmx dot de
Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: WinXP SP1
PHP Version: 5CVS-2003-07-01 (dev)
Assigned To: sterling
New Comment:
I don't know if the following is related to this bug:
class A {
function m(){
if(isset($this->x)){do nothing}
}
}
$t=new A();
var_dump($t);
expected: empty object
actual result: object(a)#1 (1) { ["x"]=> NULL }
Note that isset($this->x) not even need to be in constructor.
Tested with PHP5B2 as apache module under Windows.
Previous Comments:
[2003-07-22 08:50:14] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2003-07-09 06:42:30] [EMAIL PROTECTED]
Sterling, please explain this a bit better. (explain why it can't be
fixed and make this "Wont fix" then :)
This clearly is BC breakage at best..
[2003-07-09 06:26:47] Nico dot Laus dot 2002 at gmx dot de
it cannot be *correct* that it one time shows errors and the other time
it doesn't show any!
[2003-07-08 21:25:50] [EMAIL PROTECTED]
You are right, its not fixed, but it is *correct* due to the way the
new object model works. bogusing ...
[2003-07-08 20:44:24] [EMAIL PROTECTED]
No errors with PHP 4.3.3RC2-dev but with latest PHP 5 CVS I do get
errors. Bug NOT fixed, sterling.. :)
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/24436
--
Edit this bug report at http://bugs.php.net/?id=24436&edit=1
#26120 [Opn->Bgs]: ERROR WHEN TRYING TO REMOVE EMAIL ADDRESS
ID: 26120 Updated by: [EMAIL PROTECTED] Reported By: gajarvis at iquest dot net -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: WIN 98 PHP Version: Irrelevant New Comment: This is not a PHP bug, this a bug/feature on that hosts' mailing/spam list. J Previous Comments: [2003-11-04 14:07:24] gajarvis at iquest dot net Description: Warning: mysql_connect() [function.mysql-connect]: Host '200-206-184-38.dsl.telesp.net.br' is blocked because of many connection errors. Unblock with 'mysqladmin flush-hosts' in /home/generic/html/obg/vars.php on line 25 Warning: Cannot modify header information - headers already sent by (output started at /home/generic/html/obg/vars.php:25) in /home/generic/html/obg/post.php on line 54 RECEIVED THIS MESSAGE WHEN TRYING TO REMOVE EMAIL. Please remove [EMAIL PROTECTED] from all mailing lists. Reproduce code: --- Warning: mysql_connect() [function.mysql-connect]: Host '200-206-184-38.dsl.telesp.net.br' is blocked because of many connection errors. Unblock with 'mysqladmin flush-hosts' in /home/generic/html/obg/vars.php on line 25 Warning: Cannot modify header information - headers already sent by (output started at /home/generic/html/obg/vars.php:25) in /home/generic/html/obg/post.php on line 54 Expected result: Email address [EMAIL PROTECTED] will be removed. -- Edit this bug report at http://bugs.php.net/?id=26120&edit=1
#26105 [Opn->Csd]: argument format specified for non-function
ID: 26105 Updated by: [EMAIL PROTECTED] Reported By: simon dot boulet at divahost dot net -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: Linux/gcc 3.0.4 PHP Version: 4.3.4 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-11-04 12:38:15] php at dactar dot ch I've the same problem on HP-UX 11.00 and gcc version 3.0.1 @++ JC [2003-11-03 21:39:45] simon dot boulet at divahost dot net Description: The new version on PHP fails to compile. I was previously using version 4.3.3 and it was compiling fine. Configure flags: --with-mysql --with-apxs --with-gd -with-zlib --with-jpeg-dir=/usr --with-apxs=/usr/local/apache/bin/apxs `make` fails straight at the beginning with: /bin/sh /root/php-4.3.4/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/zlib/ -I/root/php-4.3.4/ext/zlib/ -DPHP_ATOM_INC -I/root/php-4.3.4/include -I/root/php-4.3.4/main -I/root/php-4.3.4 -I/root/php-4.3.4/Zend -I/root/php-4.3.4/ext/xml/expat -I/root/php-4.3.4/TSRM -g -O2 -prefer-pic -c /root/php-4.3.4/ext/zlib/zlib.c -o ext/zlib/zlib.lo In file included from /root/php-4.3.4/main/php.h:34, from /root/php-4.3.4/ext/zlib/zlib.c:28: /root/php-4.3.4/Zend/zend.h:311: argument format specified for non-function `error_function' /root/php-4.3.4/Zend/zend.h:312: argument format specified for non-function `printf_function' /root/php-4.3.4/Zend/zend.h:444: argument format specified for non-function `zend_printf' /root/php-4.3.4/Zend/zend.h:451: argument format specified for non-function `zend_error_cb' make: *** [ext/zlib/zlib.lo] Error 1 I am far from being a C expert, but I think it as something to do with GCC version checking in Zend/zend.h near line 155. I was able to compile just fine with: #define ZEND_ATTRIBUTE_PTR_FORMAT(type, idx, first) instead of: # define ZEND_ATTRIBUTE_PTR_FORMAT(type, idx, first) __attribute__ ((format(type, idx, first))) that would be defined with ZEND_GCC_VERSION >= 3000. -- Edit this bug report at http://bugs.php.net/?id=26105&edit=1
#26119 [Opn->Bgs]: Random SESSION-ID given in URL is accepted for the session
ID: 26119 Updated by: [EMAIL PROTECTED] Reported By: glattfahrservice at web dot de -Status: Open +Status: Bogus Bug Type: Session related Operating System: Windows XP Professional PHP Version: 4.3.4 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php The checks only validate the session id for special characters etc... You've come across the inherit vulnerability of URL session. Anyone can modify their value and should they stumble across a valid session id of another user become that user. Previous Comments: [2003-11-04 14:04:24] glattfahrservice at web dot de Description: Normally PHP is using some clever algorithms to provide for safe and unique SESSION-IDs. However, when a simple session-id is passed to the script in which session_start() is called, a session with the given ID is generated. e.g.: www.test.com/index.php&PHPSESSID=blabla should not be accepted and a new SESSION-ID should be generated for the session. BUT: this session-ID (blabla) is obviously valid and not rejected. Functionality is not impaired, but right now a visitor is able to "choose" his own session-id. Not very safe, right? I have disabled cookies and turned off trans-sid. Ciao, Dan. -- Edit this bug report at http://bugs.php.net/?id=26119&edit=1
#26113 [Opn->Csd]: ftp_get on non-existen file creates a o byte file
ID: 26113 Updated by: [EMAIL PROTECTED] Reported By: jcastro at elnuevodia dot com -Status: Open +Status: Closed Bug Type: FTP related Operating System: windows xp PHP Version: 4.3.3 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-11-04 09:02:41] jcastro at elnuevodia dot com Description: If I use ftp_get and the $server_file does not exist on the server, I will get a zero byte file created in my machine with the name that I put in the $local_file variable. I am running php 4.3.3 on windows xp prof Reproduce code: --- @ftp_get($conn_id, $local_file, $server_file, FTP_BINARY)) Expected result: No file should be created since the server_file did not exits Actual result: -- a zero byte file is created -- Edit this bug report at http://bugs.php.net/?id=26113&edit=1
#26104 [Opn->Fbk]: PHP page crash on imap_headerinfo
ID: 26104
Updated by: [EMAIL PROTECTED]
Reported By: flensbak at stofanet dot dk
-Status: Open
+Status: Feedback
Bug Type: IMAP related
Operating System: Linux 2.4.20
PHP Version: 4.3.3
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Previous Comments:
[2003-11-03 20:02:11] flensbak at stofanet dot dk
Description:
Information about the server can be found at www.yfunet.dk/binfo.php
Certain e-mails apparently crashes the current PHP session - nothing is
sent to the client beyond that point.
It seems the problem is with imap_headerinfo. At least when I disabled
the first imap_headerinfo in the script the echo-statements up until
the next imap_headerinfo were sent to the client.
The only actual clue I have to the problem is the header from the
e-mail generating the problem. It seems to me that the from-line is not
as it should be. I have included the header from the email that causes
the problem:
Received: from [80.63.53.30] by vmail1.wannafind.dk [80.63.53.30]
with SmartMax MailMax for [EMAIL PROTECTED]; Tue, 21 Oct 2003 04:31:31 +0200
Return-Path: <[EMAIL PROTECTED]>
Received: FROM backup-mx.wannafind.net BY vmail1.wannafind.dk ; Tue Oct
21 04:31:30 2003 +0200
Received: from sn2.cwihosting.com (hanz.campus.pinnaclebody.com
[66.216.127.33])
by backup-mx.wannafind.net (Postfix) with ESMTP id A29A92180B2
for <[EMAIL PROTECTED]>; Tue, 21 Oct 2003 04:31:07 +0200 (CEST)
Received: from 62-151-155-247.tp24.ya.com ([62.151.155.247]
helo=CLELAPTOP)
by sn2.cwihosting.com with smtp (Exim 4.24)
id 1ABmIr-0007KH-Pi
for [EMAIL PROTECTED]; Mon, 20 Oct 2003 21:31:22 -0500
Date: Tue, 21 Oct 2003 04:31:20 +0100
Subject: Trade Cards Online
To: [EMAIL PROTECTED]
From: news from tradecardsonline.com <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
X-Mailer: PHP/4.3.1
Message-Id: <[EMAIL PROTECTED]>
X-AntiAbuse: This header was added to track abuse, please include it
with any abuse report
X-AntiAbuse: Primary Hostname - sn2.cwihosting.com
X-AntiAbuse: Original Domain - yfu.dk
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - tradecardsonline.com
X-UM-Flags: \SEEN
Reproduce code:
---
$w_size = imap_num_msg($w_mbox);
for($i = 1; $i < $w_size + 1; $i++)
{
// comment the next line out and all is well
$w_header = imap_headerinfo($w_mbox, $i);
Expected result:
Parsing rest of the file
Actual result:
--
Nothing after imap_headerinfo
--
Edit this bug report at http://bugs.php.net/?id=26104&edit=1
#26122 [NEW]: Logical Operator "and" not functioning as expected
From: iam at nimajneb dot com Operating system: Mac OSX 10.2.6 PHP version: 4.3.2 PHP Bug Type: Math related Bug description: Logical Operator "and" not functioning as expected Description: Result of 'and' operator not what is expected. 1 and 0 and 1 => 1? Should be 0. See attached code sample. '&&' operator does function correctly however. Reproduce code: --- $primary_err_valid = (($_POST['primary_err'] != "category") and ($_POST['primary_err'] != "separator")); $secondary_err_valid = (($_POST['secondary_err'] != "category") and ($_POST['secondary_err'] != "separator")); $tertiary_err_valid = (($_POST['tertiary_err'] != "category") and ($_POST['tertiary_err'] != "separator")); $error_valid = ($primary_err_valid) and ($secondary_err_valid) and ($tertiary_err_valid); echo "Pri: $primary_err_valid "; echo "Sec: $secondary_err_valid "; echo "Tri: $tertiary_err_valid "; echo "Total Error: $error_valid "; Expected result: Pri: 1 Sec: Tri: 1 Total Error: Actual result: -- Pri: 1 Sec: Tri: 1 Total Error: 1 -- Edit bug report at http://bugs.php.net/?id=26122&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26122&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26122&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26122&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26122&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26122&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26122&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26122&r=support Expected behavior: http://bugs.php.net/fix.php?id=26122&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26122&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26122&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26122&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26122&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26122&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26122&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26122&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26122&r=float
#26118 [Opn->Fbk]: fdf-functions so not work
ID: 26118 Updated by: [EMAIL PROTECTED] Reported By: admin at evodot dot de -Status: Open +Status: Feedback Bug Type: FDF related Operating System: debian linux 3.0 PHP Version: 4.3.3 New Comment: Try this fdf_create() or die(fdf_error(fdf_errno())); That hopefully will return a human readable error from the fdf library telling you when the fdf_create() function failed. Previous Comments: [2003-11-04 11:45:05] admin at evodot dot de Description: On a debian linux 3.0 with all-standard packages the phplib is to be substituted by a self-compiled one incl. fdf-support. Got the sources of php 4.3.3 and FdfTk v5.0 and compiled without severe problems (only some develop-packages, which had to be added). But of the fdf-functions is actually available, i.e. any of 'fdf_open( $file )', 'fdf_open_string( "$HTTP_FDF_DATA" )' or even 'fdf_create()' fails without any further comment. In the log you can only find the complaints of 'fdf_close()', 'fdf_save()' and so on ... Btw. I tried both, fdf as shared object and statical linked into php: ./configure --prefix=/usr/local --with-exec-dir=/usr/local/lib/php --with-pgsql=no --with-mysql=shared,/usr --with-gd=shared,/usr --with-tiff-dir=shared,/usr --with-jpeg-dir=shared,/usr --with-png-dir=shared,/usr --with-xpm-dir=shared,/usr/X11R6 --with-pdflib=no --with-imap=no --with-ldap=no --with-zlib=yes --with-xml --with-ttf --with-sablot --with-readline --with-ftp --with-gettext=no --with-mm --with-freetype-dir=shared,/usr --enable-versioning --enable-yp=no --enable-bcmath --enable-trans-sid --enable-inline-optimization --enable-track-vars --enable-magic-quotes --enable-safe-mode --enable-sockets --enable-sysvsem --enable-sysvshm --enable-shmop --enable-exif --enable-ftp --enable-memory-limit --enable-wddx --enable-filepro --enable-dbase --with-config-file-path=/etc/php4/apache --with-apxs=/usr/bin/apxs --with-fdftk=/usr/local resp. --with-fdftk=shared,/usr/local Reproduce code: --- $fdf_doc = fdf_create () or error_log ( "test.php: \ fdf_create() failed", 0 ); fdf_save ( $fdf_doc, "/tmp/test.fdf" ) or error_log ( \ "test.php: fdf_save() failed", 0 ); fdf_close ( $fdf_doc ); Expected result: to have a fdf-file named /tmp/test.fdf ... sort of :-} Actual result: -- [04-Nov-2003 17:10:24] test.php: fdf_create() failed [04-Nov-2003 17:10:24] PHP Warning: fdf_save() expects \ parameter 1 to be resource, boolean given in \ /var/apache/htdocs/test.php on line 15 [04-Nov-2003 17:10:24] test.php: fdf_save() failed [04-Nov-2003 17:10:24] PHP Warning: fdf_close(): supplied \ argument is not a valid fdf resource in \ /var/apache/htdocs/test.php on line 17 -- Edit this bug report at http://bugs.php.net/?id=26118&edit=1
#26111 [Opn->Fbk]: mktime returns wrong date
ID: 26111 Updated by: [EMAIL PROTECTED] Reported By: chris at astra dot net dot uk -Status: Open +Status: Feedback Bug Type: Date/time related Operating System: FreeBSD PHP Version: 4.3.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Try using the snapshot avaliable from snaps.php.net. Previous Comments: [2003-11-04 09:11:19] chris at astra dot net dot uk 4.9-PRERELEASE gives the same error here, php was compiled from the FreeBSD ports collection (PHP 4.3.4RC1). I am now upgrading to 4.9-RELEASE... [2003-11-04 08:28:17] chris at astra dot net dot uk getting the same error on 4.7-RELEASE, 4.8-RELEASE and 5.0-RELEASE. I will install 4.9-PRERELEASE and test it now. [2003-11-04 08:20:30] chris at astra dot net dot uk echo mktime(12,1,1,3,28,2004); echo gmmktime(12,1,1,3,28,2004); both return 1080478861 (1969Sun, 28 Mar 2004 14:01:01 +0100) [2003-11-04 08:18:59] [EMAIL PROTECTED] Also works fine with Freebsd 4.9-PRERELEASE (whatever that means) [2003-11-04 08:14:27] [EMAIL PROTECTED] Try this too: echo mktime(12,1,1,3,28,2004); echo gmmktime(12,1,1,3,28,2004); Just to note: These all work just fine with Linux. :) 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/26111 -- Edit this bug report at http://bugs.php.net/?id=26111&edit=1
#26122 [Opn->Bgs]: Logical Operator "and" not functioning as expected
ID: 26122 Updated by: [EMAIL PROTECTED] Reported By: iam at nimajneb dot com -Status: Open +Status: Bogus Bug Type: Math related Operating System: Mac OSX 10.2.6 PHP Version: 4.3.2 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php 'and' is equivalent to &, which is a bitwise operator. && is something else entirely. Previous Comments: [2003-11-04 16:00:50] iam at nimajneb dot com Description: Result of 'and' operator not what is expected. 1 and 0 and 1 => 1? Should be 0. See attached code sample. '&&' operator does function correctly however. Reproduce code: --- $primary_err_valid = (($_POST['primary_err'] != "category") and ($_POST['primary_err'] != "separator")); $secondary_err_valid = (($_POST['secondary_err'] != "category") and ($_POST['secondary_err'] != "separator")); $tertiary_err_valid = (($_POST['tertiary_err'] != "category") and ($_POST['tertiary_err'] != "separator")); $error_valid = ($primary_err_valid) and ($secondary_err_valid) and ($tertiary_err_valid); echo "Pri: $primary_err_valid "; echo "Sec: $secondary_err_valid "; echo "Tri: $tertiary_err_valid "; echo "Total Error: $error_valid "; Expected result: Pri: 1 Sec: Tri: 1 Total Error: Actual result: -- Pri: 1 Sec: Tri: 1 Total Error: 1 -- Edit this bug report at http://bugs.php.net/?id=26122&edit=1
#26115 [Fbk->Opn]: Complie failure from zend.h
ID: 26115 User updated by: royw at imsi dot com Reported By: royw at imsi dot com -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.3.4 New Comment: Its gcc 3.0.3 Thanks -Roy Previous Comments: [2003-11-04 13:55:16] [EMAIL PROTECTED] What is the version of your compiler? [2003-11-04 10:33:21] royw at imsi dot com Description: configure line: ./configure --with-mysql=/usr/local/mysql --with-apxs=/usr/local/apache/bin/apxs this is with apache 1.3.29 it configures fine, here is the configure output loading cache ./config.cache checking host system type... sparc-sun-solaris2.8 checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking whether gcc and cc understand -c and -o together... yes checking how to run the C preprocessor... gcc -E checking for AIX... no checking if compiler supports -R... yes checking for re2c... exit 0; checking for ranlib... ranlib checking whether ln -s works... yes checking for gawk... gawk checking for bison... bison -y checking bison version... configure: warning: You will need bison 1.28 1.34 (ok) checking for flex... flex checking for yywrap in -lfl... yes checking lex output file root... lex.yy checking whether yytext is a pointer... yes checking for working const... yes checking flex version... 2.5.4 (ok) checking for pthreads_cflags... -pthreads checking for pthreads_lib... Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... yes checking for member fd in BUFF *... yes checking for mod_charset compatibility option... no checking for Apache 2.0 filter-module support via DSO through APXS... no checking for Apache 2.0 handler-module support via DSO through APXS... no checking for Caudium support... no checking for CLI build... yes checking for embedded SAPI library support... no checking for Zeus ISAPI support... no checking for NSAPI support... no checking for PHTTPD support... no checking for Pi3Web support... no checking for Roxen/Pike support... no checking for Servlet support... no checking for thttpd... no checking for TUX... no checking for webjames... no checking for chosen SAPI module... apache Running system checks checking for missing declarations of reentrant functions... done checking for sendmail... /usr/lib/sendmail checking whether system uses EBCDIC... no checking for socket... no checking for __socket... no checking for socket in -lsocket... yes checking for htonl... yes checking for gethostname... yes checking for gethostbyaddr... yes checking for yp_get_default_domain... yes checking for dlopen... yes checking for sin in -lm... yes checking for res_search... no checking for __res_search... no checking for res_search in -lresolv... yes checking for inet_aton... yes checking for dn_skipname... yes checking for ANSI C header files... yes checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for fclose declaration... ok checking for dirent.h... yes checking for ApplicationServices/ApplicationServices.h... no checking for sys/param.h... yes checking for sys/types.h... yes checking for sys/time.h... yes checking for netinet/in.h... yes checking for alloca.h... yes checking for arpa/inet.h... yes checking for arpa/nameser.h... yes checking for assert.h... yes checking for crypt.h... yes checking for fcntl.h... yes checking for grp.h... yes checking for ieeefp.h... yes checking for langinfo.h... yes checking for limits.h... yes checking for locale.h... yes checking for monetary.h... yes checking for mach-o/dyld.h... no checking for netdb.h... yes checking for pwd.h... yes checking for resolv.h... yes checking for signal.h... yes checking for stdarg.h... yes checking for stdlib.h... yes checking for string.h... yes checking for syslog.h... yes checking for sysexits.h... yes checking for sys/file.h... yes checking for sys/mman.h... yes checking for sys/mount.h... yes checking for sys/poll.h... yes checking for sys/resource.h... yes checking for sys/select.h... yes checking for sys/socket.h... yes checking for sys/statfs.h... yes checking for sys/statvfs.h... yes checking for sys/vfs.h... yes checking for sys/sysexits.h... no checking for sys/varargs.h... yes checking for sys/wait.h... yes checking for unistd.h... yes checking for unix.h... no checking for utime.h... yes checking for sys/utsname.h... yes checking for sys/ipc.h... yes checking for dlfcn.h... yes checking for fopencookie... no checking for broken getcwd... yes checking for broken libc stdio... yes checking whether struct tm is in
#26115 [Com]: Complie failure from zend.h
ID: 26115 Comment by: simon dot boulet at divahost dot net Reported By: royw at imsi dot com Status: Open Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.3.4 New Comment: Please see bug #26105. This problem has been fixed in CVS. http://bugs.php.net/bug.php?id=26105 Previous Comments: [2003-11-04 16:31:51] royw at imsi dot com Its gcc 3.0.3 Thanks -Roy [2003-11-04 13:55:16] [EMAIL PROTECTED] What is the version of your compiler? [2003-11-04 10:33:21] royw at imsi dot com Description: configure line: ./configure --with-mysql=/usr/local/mysql --with-apxs=/usr/local/apache/bin/apxs this is with apache 1.3.29 it configures fine, here is the configure output loading cache ./config.cache checking host system type... sparc-sun-solaris2.8 checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking whether gcc and cc understand -c and -o together... yes checking how to run the C preprocessor... gcc -E checking for AIX... no checking if compiler supports -R... yes checking for re2c... exit 0; checking for ranlib... ranlib checking whether ln -s works... yes checking for gawk... gawk checking for bison... bison -y checking bison version... configure: warning: You will need bison 1.28 1.34 (ok) checking for flex... flex checking for yywrap in -lfl... yes checking lex output file root... lex.yy checking whether yytext is a pointer... yes checking for working const... yes checking flex version... 2.5.4 (ok) checking for pthreads_cflags... -pthreads checking for pthreads_lib... Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... yes checking for member fd in BUFF *... yes checking for mod_charset compatibility option... no checking for Apache 2.0 filter-module support via DSO through APXS... no checking for Apache 2.0 handler-module support via DSO through APXS... no checking for Caudium support... no checking for CLI build... yes checking for embedded SAPI library support... no checking for Zeus ISAPI support... no checking for NSAPI support... no checking for PHTTPD support... no checking for Pi3Web support... no checking for Roxen/Pike support... no checking for Servlet support... no checking for thttpd... no checking for TUX... no checking for webjames... no checking for chosen SAPI module... apache Running system checks checking for missing declarations of reentrant functions... done checking for sendmail... /usr/lib/sendmail checking whether system uses EBCDIC... no checking for socket... no checking for __socket... no checking for socket in -lsocket... yes checking for htonl... yes checking for gethostname... yes checking for gethostbyaddr... yes checking for yp_get_default_domain... yes checking for dlopen... yes checking for sin in -lm... yes checking for res_search... no checking for __res_search... no checking for res_search in -lresolv... yes checking for inet_aton... yes checking for dn_skipname... yes checking for ANSI C header files... yes checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for fclose declaration... ok checking for dirent.h... yes checking for ApplicationServices/ApplicationServices.h... no checking for sys/param.h... yes checking for sys/types.h... yes checking for sys/time.h... yes checking for netinet/in.h... yes checking for alloca.h... yes checking for arpa/inet.h... yes checking for arpa/nameser.h... yes checking for assert.h... yes checking for crypt.h... yes checking for fcntl.h... yes checking for grp.h... yes checking for ieeefp.h... yes checking for langinfo.h... yes checking for limits.h... yes checking for locale.h... yes checking for monetary.h... yes checking for mach-o/dyld.h... no checking for netdb.h... yes checking for pwd.h... yes checking for resolv.h... yes checking for signal.h... yes checking for stdarg.h... yes checking for stdlib.h... yes checking for string.h... yes checking for syslog.h... yes checking for sysexits.h... yes checking for sys/file.h... yes checking for sys/mman.h... yes checking for sys/mount.h... yes checking for sys/poll.h... yes checking for sys/resource.h... yes checking for sys/select.h... yes checking for sys/socket.h... yes checking for sys/statfs.h... yes checking for sys/statvfs.h... yes checking for sys/vfs.h... yes checking for sys/sysexits.h... no checking for sys/varargs.h... yes checking for sys/wait.h... yes checking for unistd.h... yes checking for unix.h... no checking for utime.h... yes checking for sys/utsnam
#25987 [Bgs]: php and xml tag confusion
ID: 25987 User updated by: tkwright_233 at hotmail dot com Reported By: tkwright_233 at hotmail dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: * PHP Version: * New Comment: what just happened? it appears some comments were lost(about 2-4). __ Anyway, it DOES know the diffrence of '' to '?>'), from v.2 to v.4 . Previous Comments: [2003-10-26 15:24:32] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php It does recognize the difference, if you disable short_tags, which you should for exactly this reason. [2003-10-25 15:18:05] [EMAIL PROTECTED] Short tags = ''."\n";?> Reproduce code: --- Expected result: [no error],rest of page Actual result: -- Parse error: parse error, unexpected T_STRING in c:/apache/htdocs/xml.php on line 1 -- Edit this bug report at http://bugs.php.net/?id=25987&edit=1
#26115 [Opn->Bgs]: Complie failure from zend.h
ID: 26115 Updated by: [EMAIL PROTECTED] Reported By: royw at imsi dot com -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.3.4 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. Dup of bug #26105, which is fixed in CVS. Previous Comments: [2003-11-04 16:52:04] simon dot boulet at divahost dot net Please see bug #26105. This problem has been fixed in CVS. http://bugs.php.net/bug.php?id=26105 [2003-11-04 16:31:51] royw at imsi dot com Its gcc 3.0.3 Thanks -Roy [2003-11-04 13:55:16] [EMAIL PROTECTED] What is the version of your compiler? [2003-11-04 10:33:21] royw at imsi dot com Description: configure line: ./configure --with-mysql=/usr/local/mysql --with-apxs=/usr/local/apache/bin/apxs this is with apache 1.3.29 it configures fine, here is the configure output loading cache ./config.cache checking host system type... sparc-sun-solaris2.8 checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking whether gcc and cc understand -c and -o together... yes checking how to run the C preprocessor... gcc -E checking for AIX... no checking if compiler supports -R... yes checking for re2c... exit 0; checking for ranlib... ranlib checking whether ln -s works... yes checking for gawk... gawk checking for bison... bison -y checking bison version... configure: warning: You will need bison 1.28 1.34 (ok) checking for flex... flex checking for yywrap in -lfl... yes checking lex output file root... lex.yy checking whether yytext is a pointer... yes checking for working const... yes checking flex version... 2.5.4 (ok) checking for pthreads_cflags... -pthreads checking for pthreads_lib... Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... yes checking for member fd in BUFF *... yes checking for mod_charset compatibility option... no checking for Apache 2.0 filter-module support via DSO through APXS... no checking for Apache 2.0 handler-module support via DSO through APXS... no checking for Caudium support... no checking for CLI build... yes checking for embedded SAPI library support... no checking for Zeus ISAPI support... no checking for NSAPI support... no checking for PHTTPD support... no checking for Pi3Web support... no checking for Roxen/Pike support... no checking for Servlet support... no checking for thttpd... no checking for TUX... no checking for webjames... no checking for chosen SAPI module... apache Running system checks checking for missing declarations of reentrant functions... done checking for sendmail... /usr/lib/sendmail checking whether system uses EBCDIC... no checking for socket... no checking for __socket... no checking for socket in -lsocket... yes checking for htonl... yes checking for gethostname... yes checking for gethostbyaddr... yes checking for yp_get_default_domain... yes checking for dlopen... yes checking for sin in -lm... yes checking for res_search... no checking for __res_search... no checking for res_search in -lresolv... yes checking for inet_aton... yes checking for dn_skipname... yes checking for ANSI C header files... yes checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for fclose declaration... ok checking for dirent.h... yes checking for ApplicationServices/ApplicationServices.h... no checking for sys/param.h... yes checking for sys/types.h... yes checking for sys/time.h... yes checking for netinet/in.h... yes checking for alloca.h... yes checking for arpa/inet.h... yes checking for arpa/nameser.h... yes checking for assert.h... yes checking for crypt.h... yes checking for fcntl.h... yes checking for grp.h... yes checking for ieeefp.h... yes checking for langinfo.h... yes checking for limits.h... yes checking for locale.h... yes checking for monetary.h... yes checking for mach-o/dyld.h... no checking for netdb.h... yes checking for pwd.h... yes checking for resolv.h... yes checking for signal.h... yes checking for stdarg.h... yes checking for stdlib.h... yes checking for string.h... yes checking for syslog.h... yes checking for sysexits.h... yes checking for sys/file.h.
#25972 [Ana]: ODBC truncates multi-byte text (w/ MSSQL)
ID: 25972 Updated by: [EMAIL PROTECTED] Reported By: phpbug at chipple dot net Status: Analyzed Bug Type: Feature/Change Request Operating System: Win2K 5.00.2195 SP4 PHP Version: 4.3, 5 New Comment: I do not like the idea of introducing ODBCv3 based code/ options to a system predominately defined by ODBCv2 specifications. So I am against the inclusion of Moriyoshi's initial suggested fix for this. That being said, I did a bit more research on this today and think the following change should allow the double wide characters to work much better. I haven't tested it out yet myself, but if someone else has the time, it would be beneficial to all. Sorry about the bug system mangling. Essentially the SQL_COLUMNS_DISPLAY_SIZE lists the number of characters needed to display everything. This works fine but in the case of a double wide character array it doesn't (as explained my Moriyoshi). The SQL_COLUMN_LENGTH should return the number of bytes necessary for retrival of the column. WARNING: this change may fundamentally alter the functionality of the longreadlen variable comparisons as well. Use at your own risk right now. Index: php_odbc.c === RCS file: /repository/php-src/ext/odbc/php_odbc.c,v retrieving revision 1.176 diff -r1.176 php_odbc.c 671,672c671,672 < rc = SQLColAttributes(result->stmt, (UWORD)(i+1), SQL_COLUMN_DISPLAY_SIZE, < NULL, 0, NULL, &displaysize); --- > rc = SQLColAttributes(result->stmt, (UWORD)(i+1), > SQL_COLUMN_LENGTH, NULL, 0, NULL, &displaysize); Previous Comments: [2003-11-04 09:31:56] [EMAIL PROTECTED] Well, then how did you conclude NVARCHAR support will break some kinds of compatibilities? I think I have already pointed out that we'd still be able to handle it on ODBCv2. (Sorry if this sounds offending. I don't mean so :) Basically we don't have to check whether the column type is NVARCHAR or not, but just allocate enough space for that type of characters. That way we also got to take a slight loss of memory into account though. [2003-11-04 07:56:51] [EMAIL PROTECTED] moriyoshi, It's not as simple as you show it to be. First you must realize that PHP's ODBC layer is written as an ODBC v2 compliant system, to just randomly add in support for NVARCHAR (and friends) will break support for other database systems. The point of my post wasn't to say this isn't a bug (hence why I marked it as verified), but rather to say it's a known bug and the issue is the extension is in need of updating. [2003-11-03 17:13:35] [EMAIL PROTECTED] I might be wrong, but I think this is a valid bug. According to the documentation on msdn [1] [2], the fifth parameter of SQLBindCol() expects the size of the buffer in byte, while the code mentioned below appears to give it the number of characters allocated for the column (display size) instead. This kind of confusion will most likely cause unexpected behaviour like described in this report. php_odbc.c 669: -- default: rc = SQLColAttributes(result->stmt, (UWORD)(i+1), SQL_COLUMN_DISPLAY_SIZE, NULL, 0, NULL, &displaysize); displaysize = displaysize <= result->longreadlen ? displaysize : result->longreadlen; result->values[i].value = (char *)emalloc(displaysize + 1); rc = SQLBindCol(result->stmt, (UWORD)(i+1), SQL_C_CHAR, result->values[i].value, displaysize + 1, &result->values[i].vallen); break; -- If the driver supports ODBCv3, we should use SQL_DESC_OCTET_LENGTH, which can be used to determine the actual number of bytes. If not, we may be able to safely calculate the maximum column size by simply multiplying the display size by 2, as NVARCHAR columns are known to not contain multi-byte strings, but double-byte strings. [1] http://msdn.microsoft.com/library/en-us/odbc/htm/odch04pr_13.asp?frame=true [2] http://msdn.microsoft.com/library/en-us/odbc/htm/odappdpr_24.asp?frame=true [2003-10-31 09:26:28] [EMAIL PROTECTED] Is this really a bug? The debate rages like so: One the one hand ODBC does not support multi-byte characters at all. On the other, the idea of multi- byte characters didn't exist (or if it did, not very prevailent) at the time of the original authoring of the ODBC system. Next question is, is there an easy fix. Nope. I've had a fix in the works, I've just lost all time to work upon it. Marking as verif
#26125 [NEW]: php.ini location in phpinfo() is not where the php4sapi.dll looks for it
From: nickh at supportteam dot net Operating system: Windows Server 2003 PHP version: 4.3.3 PHP Bug Type: IIS related Bug description: php.ini location in phpinfo() is not where the php4sapi.dll looks for it Description: Under Windows Server 2003 when I run a phpinfo() it says the Configuration File Path is C:\WINDOWS. I was having trouble with the sessions path and when running a filemon capture (sysinternals filemon) I saw it was auctually looking for the ini in C:\Windows\system32\inetsrv. Placing the ini there fixed the problem. It appears that the ISAPI version of PHP4 .3.3 says the INI should be in one place but it looks for it elsewhere. I have tested this on 4 different Windows Server 2003 Standard servers that we have and it's the same on all 3. Reproduce code: --- N/A Expected result: N/A Actual result: -- N/A -- Edit bug report at http://bugs.php.net/?id=26125&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26125&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26125&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26125&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26125&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26125&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26125&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26125&r=support Expected behavior: http://bugs.php.net/fix.php?id=26125&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26125&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26125&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26125&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26125&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26125&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26125&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26125&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26125&r=float
#26126 [NEW]: You cannot assign recursive array references.
From: bens at effortlessis dot com
Operating system: All
PHP version: 4.3.2
PHP Bug Type: Feature/Change Request
Bug description: You cannot assign recursive array references.
Description:
It does not seem possible to reduce the following two statements into a
single statement.
'a', 2=>'b', 3=>array('aa', 'bb'));
$in[3]['cc']=&$in[3];
?>
I would suspect that this is the same or similar issue that causes the
following statement to fail:
Reproduce code:
---
'a', 2=>'b', 3=>array('aa', 'bb'));
$in[3]['cc']=&$in[3];
var_export($in);
?>
Expected result:
array(
1 => 'a',
2 => 'b',
3 => array(
0 => 'aa',
1 => 'bb',
'cc' => &$this->3,
)
);
/* Note: as I've said before, there doesn't seem to be a method to refer
to an element within the array being created at assignment time, I've used
object syntax instead */
Actual result:
--
array (
1 => 'a',
2 => 'b',
3 =>
array (
0 => 'aa',
1 => 'bb',
'cc' =>
array (
0 => 'aa',
1 => 'bb',
'cc' =>
array (
0 => 'aa',
1 => 'bb',
'cc' =>
array (
Fatal error: Nesting level too deep - recursive dependency? in
/home/bens/delete on line 4
--
Edit bug report at http://bugs.php.net/?id=26126&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26126&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26126&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26126&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26126&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26126&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=26126&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26126&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26126&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26126&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26126&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26126&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26126&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26126&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26126&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26126&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26126&r=float
#23467 [Com]: Showing incorrect Time Zone
ID: 23467
Comment by: danielc at analysisandsolutions dot com
Reported By: John at JGSystems dot net
Status: Verified
Bug Type: Date/time related
Operating System: win32
PHP Version: 4.3.4-dev, 5.0.0b2-dev
New Comment:
Um, sorry if I'm cluttering the list... This bug is half a year old so
I'm wondering if/when it's going to get fixed.
Y'all probably know what's going on, but allow me to clarify what I've
learned about this bug, perhaps it will help someone.
date('T') doesn't work under Windows during Daylight times and there's
no notation of this in the manual. I'll put a user comment in there.
Here's a test script:
";
putenv('TZ=EST5EDT');
echo 'EST5EDT: dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
echo "\n";
putenv('TZ=PST8PDT');
echo 'PST8PDT: dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
echo "\n";
putenv('TZ=GMT0BST');
echo 'GMT0BST: dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
echo "\n";
putenv('TZ=MST-3MDT');
echo 'MST-3MDT: dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
echo "\n";
putenv('TZ=GMT');
echo 'GMT: dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
?>
OUTPUT DURING EASTERN DAYLIGHT TIME
---
Local: dT=BST dO=-0400 sZ=Eastern Daylight Time
EST5EDT: dT=BST dO=-0400 sZ=EDT
PST8PDT: dT=BST dO=-0700 sZ=PDT
GMT0BST: dT=BST dO=+0100 sZ=BST
MST-3MDT: dT=BST dO=+0400 sZ=MDT
GMT: dT=GMT dO=+ sZ=GMT
OUTPUT DURING EASTERN STANDARD TIME
---
Local: dT=Eastern Standard Time dO=-0500 sZ=Eastern Standard Time
EST5EDT: dT=EST dO=-0500 sZ=EST
PST8PDT: dT=PST dO=-0800 sZ=PST
GMT0BST: dT=GMT dO=+ sZ=GMT
MST-3MDT: dT=MST dO=+0300 sZ=MST
GMT: dT=GMT dO=+ sZ=GMT
Previous Comments:
[2003-08-26 22:59:32] [EMAIL PROTECTED]
This is general win32 problem. No need to post anymore comments here,
we know about it.
[2003-08-20 20:35:39] John at JGSystems dot net
Here ya go:
Commands:
echo date("r"),"\n";
echo date("I"),"\n"; // uppercase "i"
echo date("T"),"\n";
Result:
Wed, 20 Aug 2003 19:33:34 -0600
1
BST
This what you wanted? (I hope)
[2003-08-19 23:12:26] John at JGSystems dot net
The time last modified was pasted in the reply.
This page was last modified:
Monday - May 19, 2003 at 4:22 PM BST.
I'll get the current time pasted in tomorrow...
The results of:
echo date("r"),"\n";
echo date("I"),"\n"; // uppercase "i"
Too late tonight...
[2003-08-19 22:48:30] [EMAIL PROTECTED]
I wanted to know the TIME...not the time zone..
[2003-08-19 21:12:06] John at JGSystems dot net
It's a local machine. Win XP. Nothings changed from the items listed
below in this thread or I would have mentioned it.
I downloaded the link, installed it after erasing the last version you
all had me try and the same result. I did tell you that it was
supposed to be --> MDT <-- not --> BST <--
Thanks...
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/23467
--
Edit this bug report at http://bugs.php.net/?id=23467&edit=1
#26127 [NEW]: IMAP compile fails!
From: herps at raqtweak dot com
Operating system: Sun Cobalt RAQ4
PHP version: 4.3.4
PHP Bug Type: IMAP related
Bug description: IMAP compile fails!
Description:
I compile my PHP with the option, --with-imap (or
--with-imap=/usr/lib/c-client.a , same result)
So the configure runs for a while, and then shows this:
I keep getting the following output:
checking for IMAP support... yes
checking for pam_start in -lpam... yes
checking for crypt in -lcrypt... (cached) yes
checking whether SSL libraries are needed for c-client... no
checking whether IMAP works... no
=
Note the 2 IMAP lines...
My config.log output:
configure:40552: checking whether IMAP works
configure:40585: gcc -o conftest -DEAPI -O2 -m486 -fno-strength-reduce
-L/usr/lib -ldb-3.0 conftest.c -lc-client -lcrypt -lpam -lttf -lpng -lz
-ljpeg -lz -lxml2 -ldb-3.0 -lgdbm -lz -lresolv -lm -ldl -lnsl 1>&5
/usr/lib/libc-client.a(mail.o): In function `mm_cache':
/home/redhat/BUILD/imap-2002d/c-client/mail.c:203: undefined reference to
`__canary_death_handler'
/usr/lib/libc-client.a(mail.o): In function `mail_parameters':
/home/redhat/BUILD/imap-2002d/c-client/mail.c:529: undefined reference to
`__canary_death_handler'
/usr/lib/libc-client.a(mail.o): In function `mail_valid':
/home/redhat/BUILD/imap-2002d/c-client/mail.c:568: undefined reference to
`__canary_death_handler'
/usr/lib/libc-client.a(mail.o): In function `mail_valid_net':
/home/redhat/BUILD/imap-2002d/c-client/mail.c:586: undefined reference to
`__canary_death_handler'
/usr/lib/libc-client.a(mail.o): In function `mail_valid_net_parse_work':
/home/redhat/BUILD/imap-2002d/c-client/mail.c:709: undefined reference to
`__canary_death_handler'
/usr/lib/libc-client.a(mail.o):/home/redhat/BUILD/imap-2002d/c-client/mail.c:745:
more undefined references to `__canary_death_handler' follow
collect2: ld returned 1 exit status
configure: failed program was:
#line 40560 "configure"
#include "confdefs.h"
void mm_log(void){}
void mm_dlog(void){}
void mm_flags(void){}
void mm_fatal(void){}
void mm_critical(void){}
void mm_nocritical(void){}
void mm_notify(void){}
void mm_login(void){}
void mm_diskerror(void){}
void mm_status(void){}
void mm_lsub(void){}
void mm_list(void){}
void mm_exists(void){}
void mm_searched(void){}
void mm_expunged(void){}
char mail_newbody();
int main() {
mail_newbody();
return 0;
}
Now, I recall this used to work before...
I use imap2002d, compiled with stackguard support...
Please advise... I've been looking and searching for quite a while now,
but can find nothing... Thus I concluded that it might be a bug
--
Edit bug report at http://bugs.php.net/?id=26127&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26127&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26127&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26127&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26127&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26127&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=26127&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26127&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26127&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26127&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26127&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26127&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26127&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26127&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26127&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26127&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26127&r=float
#26128 [NEW]: mbstring for GB,BIG-5 support disabled
From: patrick at patricktsang dot net Operating system: RH9 PHP version: 4.3.4 PHP Bug Type: *Compile Issues Bug description: mbstring for GB,BIG-5 support disabled Description: I have no problem to enable GB and BIG-5 support with mbstring in 4.3.3 The version 4.3.4 has changed something on mbstring and I don't know why phpinfo() reports me there is only Japanese supported. I use: --enable-mbstring=all --enable-mbregex The compile just ended with a minor warning on tempname Helps? Patrick -- Edit bug report at http://bugs.php.net/?id=26128&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26128&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26128&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26128&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26128&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26128&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26128&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26128&r=support Expected behavior: http://bugs.php.net/fix.php?id=26128&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26128&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26128&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26128&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26128&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26128&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26128&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26128&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26128&r=float
#26129 [NEW]: Unable to load dynamic module
From: gman at speakeasy dot net Operating system: WinXP Pro PHP version: 4.3.4 PHP Bug Type: Dynamic loading Bug description: Unable to load dynamic module Description: Unknown(): Unable to load dynamic library module c:\php\extensions\php_ldap.dll Unable to find the specified module -- Edit bug report at http://bugs.php.net/?id=26129&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26129&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26129&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26129&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26129&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26129&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26129&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26129&r=support Expected behavior: http://bugs.php.net/fix.php?id=26129&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26129&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26129&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26129&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26129&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26129&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26129&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26129&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26129&r=float
#26128 [Opn]: mbstring for GB,BIG-5 support disabled
ID: 26128 Updated by: [EMAIL PROTECTED] Reported By: patrick at patricktsang dot net Status: Open Bug Type: *Compile Issues Operating System: RH9 PHP Version: 4.3.4 New Comment: >From 4.3.4 on all language supports are enabled in mbstring no matter how it has been configured, whereas phpinfo() prints out wrong information. Previous Comments: [2003-11-04 22:38:59] patrick at patricktsang dot net Description: I have no problem to enable GB and BIG-5 support with mbstring in 4.3.3 The version 4.3.4 has changed something on mbstring and I don't know why phpinfo() reports me there is only Japanese supported. I use: --enable-mbstring=all --enable-mbregex The compile just ended with a minor warning on tempname Helps? Patrick -- Edit this bug report at http://bugs.php.net/?id=26128&edit=1
#26128 [Opn->Csd]: mbstring prints out wrong information on phpinfo()
ID: 26128 Updated by: [EMAIL PROTECTED] -Summary: mbstring for GB,BIG-5 support disabled Reported By: patrick at patricktsang dot net -Status: Open +Status: Closed -Bug Type: *Compile Issues +Bug Type: mbstring related Operating System: RH9 PHP Version: 4.3.4 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-11-04 23:20:22] [EMAIL PROTECTED] >From 4.3.4 on all language supports are enabled in mbstring no matter how it has been configured, whereas phpinfo() prints out wrong information. [2003-11-04 22:38:59] patrick at patricktsang dot net Description: I have no problem to enable GB and BIG-5 support with mbstring in 4.3.3 The version 4.3.4 has changed something on mbstring and I don't know why phpinfo() reports me there is only Japanese supported. I use: --enable-mbstring=all --enable-mbregex The compile just ended with a minor warning on tempname Helps? Patrick -- Edit this bug report at http://bugs.php.net/?id=26128&edit=1
#26129 [Opn]: Unable to load dynamic module
ID: 26129 User updated by: gman at speakeasy dot net Reported By: gman at speakeasy dot net Status: Open Bug Type: Dynamic loading Operating System: WinXP Pro PHP Version: 4.3.4 New Comment: This is not a bug simply followed the instructions from the manual as far as some dll's that are needed for php_ldap.dll to load sucessfully. And I quote " Note to Win32 Users: In order to enable this module on a Windows environment, you must copy several files from the DLL folder of the PHP/Win32 binary package to the SYSTEM folder of your windows machine. (Ex: C:\WINNT\SYSTEM32, C:\WINDOWS\SYSTEM32 or c:\WINDOWS\SYSTEM). For PHP <= 4.2.0 copy libsasl.dll, for PHP >= 4.3.0 copy libeay32.dll and ssleay32.dll to your SYSTEM folder. " Sorry to have wasted your time ... Previous Comments: [2003-11-04 23:01:52] gman at speakeasy dot net Description: Unknown(): Unable to load dynamic library module c:\php\extensions\php_ldap.dll Unable to find the specified module -- Edit this bug report at http://bugs.php.net/?id=26129&edit=1
#26129 [Opn->Bgs]: Unable to load dynamic module
ID: 26129 Updated by: [EMAIL PROTECTED] Reported By: gman at speakeasy dot net -Status: Open +Status: Bogus Bug Type: Dynamic loading Operating System: WinXP Pro PHP Version: 4.3.4 New Comment: RTFMBSBR. :) Previous Comments: [2003-11-04 23:36:15] gman at speakeasy dot net This is not a bug simply followed the instructions from the manual as far as some dll's that are needed for php_ldap.dll to load sucessfully. And I quote " Note to Win32 Users: In order to enable this module on a Windows environment, you must copy several files from the DLL folder of the PHP/Win32 binary package to the SYSTEM folder of your windows machine. (Ex: C:\WINNT\SYSTEM32, C:\WINDOWS\SYSTEM32 or c:\WINDOWS\SYSTEM). For PHP <= 4.2.0 copy libsasl.dll, for PHP >= 4.3.0 copy libeay32.dll and ssleay32.dll to your SYSTEM folder. " Sorry to have wasted your time ... [2003-11-04 23:01:52] gman at speakeasy dot net Description: Unknown(): Unable to load dynamic library module c:\php\extensions\php_ldap.dll Unable to find the specified module -- Edit this bug report at http://bugs.php.net/?id=26129&edit=1
#26118 [Fbk->Bgs]: fdf-functions so not work
ID: 26118 Updated by: [EMAIL PROTECTED] Reported By: admin at evodot dot de -Status: Feedback +Status: Bogus Bug Type: FDF related Operating System: debian linux 3.0 PHP Version: 4.3.3 New Comment: Please read the manual before submitting any bug reports. There is no bug here. Previous Comments: [2003-11-04 16:04:52] [EMAIL PROTECTED] Try this fdf_create() or die(fdf_error(fdf_errno())); That hopefully will return a human readable error from the fdf library telling you when the fdf_create() function failed. [2003-11-04 11:45:05] admin at evodot dot de Description: On a debian linux 3.0 with all-standard packages the phplib is to be substituted by a self-compiled one incl. fdf-support. Got the sources of php 4.3.3 and FdfTk v5.0 and compiled without severe problems (only some develop-packages, which had to be added). But of the fdf-functions is actually available, i.e. any of 'fdf_open( $file )', 'fdf_open_string( "$HTTP_FDF_DATA" )' or even 'fdf_create()' fails without any further comment. In the log you can only find the complaints of 'fdf_close()', 'fdf_save()' and so on ... Btw. I tried both, fdf as shared object and statical linked into php: ./configure --prefix=/usr/local --with-exec-dir=/usr/local/lib/php --with-pgsql=no --with-mysql=shared,/usr --with-gd=shared,/usr --with-tiff-dir=shared,/usr --with-jpeg-dir=shared,/usr --with-png-dir=shared,/usr --with-xpm-dir=shared,/usr/X11R6 --with-pdflib=no --with-imap=no --with-ldap=no --with-zlib=yes --with-xml --with-ttf --with-sablot --with-readline --with-ftp --with-gettext=no --with-mm --with-freetype-dir=shared,/usr --enable-versioning --enable-yp=no --enable-bcmath --enable-trans-sid --enable-inline-optimization --enable-track-vars --enable-magic-quotes --enable-safe-mode --enable-sockets --enable-sysvsem --enable-sysvshm --enable-shmop --enable-exif --enable-ftp --enable-memory-limit --enable-wddx --enable-filepro --enable-dbase --with-config-file-path=/etc/php4/apache --with-apxs=/usr/bin/apxs --with-fdftk=/usr/local resp. --with-fdftk=shared,/usr/local Reproduce code: --- $fdf_doc = fdf_create () or error_log ( "test.php: \ fdf_create() failed", 0 ); fdf_save ( $fdf_doc, "/tmp/test.fdf" ) or error_log ( \ "test.php: fdf_save() failed", 0 ); fdf_close ( $fdf_doc ); Expected result: to have a fdf-file named /tmp/test.fdf ... sort of :-} Actual result: -- [04-Nov-2003 17:10:24] test.php: fdf_create() failed [04-Nov-2003 17:10:24] PHP Warning: fdf_save() expects \ parameter 1 to be resource, boolean given in \ /var/apache/htdocs/test.php on line 15 [04-Nov-2003 17:10:24] test.php: fdf_save() failed [04-Nov-2003 17:10:24] PHP Warning: fdf_close(): supplied \ argument is not a valid fdf resource in \ /var/apache/htdocs/test.php on line 17 -- Edit this bug report at http://bugs.php.net/?id=26118&edit=1
#26036 [Fbk->Csd]: base64 encoding is wrong
ID: 26036
Updated by: [EMAIL PROTECTED]
Reported By: topitz at definiens dot com
-Status: Feedback
+Status: Closed
Bug Type: Mail related
Operating System: Win2k
PHP Version: 4.3.3
New Comment:
This is fixed in PHP 4.3.4.
Previous Comments:
[2003-10-30 08:20:03] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-10-30 06:22:00] topitz at definiens dot com
Description:
I use the SendMail() from the php.net (->[EMAIL PROTECTED]). Till now it
works fine, but now i updated the webserver to IIS5 on Win2k from IIS4
on NT4, and now the base64 encoding seems to work wrong (HTML and
Attachment part). The SMTP Server is Linux. Mail will received with
Outlook.
I tried already to change the charset from iso-8859-1 to utf-8, but it
doesn't becomes better.
This problem i got only with Win2k/IIS5!
Reproduce code:
---
$TEXT="Hallo, this a test for my email program. Hallo, this a test for
my email program. long text with breaks
test for my email program. Hallo, this a test for my email program.";
$HTML=false;
if (SendMail(
"[EMAIL PROTECTED]","PHP Apache Webmailer", //sender
"[EMAIL PROTECTED]","Tiberius Opitz", //recipient
"Testmail", //subject
$TEXT,$HTML,$ATTM)) echo "Mail send successfull.";
function
SendMail($From,$FromName,$To,$ToName,$Subject,$Text,$Html,$AttmFiles){
... see php.net
}
Expected result:
the script should send a mail with multipart data
(text/html/attachment) and print a success message after sending.
Actual result:
--
I got the email abreviated, but with additional characters (wrong
decoded)like: Ü^H[XZ[ ÙÜ[KO...
I've the same problem with attechments.
--
Edit this bug report at http://bugs.php.net/?id=26036&edit=1
#25978 [Fbk->NoF]: memory leak: pear/install-pear.php
ID: 25978 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Zend Engine 2 problem Operating System: Linux PHP Version: 5CVS-2003-10-24 (dev) New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-10-30 21:01:17] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2003-10-24 14:35:50] [EMAIL PROTECTED] Description: make install (--enable-debug) produce following error: /devage/php-src/Zend/zend_execute.c(410) : Freeing 0x43866CE8 (16 bytes), script=/devage/php-src/pear/install-pear.php === Total 1 memory leaks detected === -- Edit this bug report at http://bugs.php.net/?id=25978&edit=1
#25973 [Fbk->NoF]: object attributes & array mix up
ID: 25973
Updated by: [EMAIL PROTECTED]
Reported By: mike dot blamires at kingston-callcentres dot co dot
uk
-Status: Feedback
+Status: No Feedback
Bug Type: Zend Engine 2 problem
Operating System: Windows 2000
PHP Version: 5.0.0b1 (beta1)
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
Previous Comments:
[2003-10-30 20:57:54] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2003-10-24 04:23:26] mike dot blamires at kingston-callcentres dot co
dot uk
Description:
When I have set a list of the objects attributes from an array, after
successfully setting all the attributes to there values (and echoing
them as they should be, set to the correct values) all the attributes
take on that last value set.
In the example below the value last set to an attribute was element 2
of the array, the integer 4, now all attributes are set are set to 4.
this is the same if the last attribute set was element 8, all
attributes would refer to "aJobTitle"
I believe this to be similar to bug 25957, although I was not totally
sure of the actual bug highlighted there so i reported as a seperate
issue.
Reproduce code:
---
abstract class Person extends OwlObj {
private $name;
private $group;
public function initialize() {
$users = $this->dbQuery("SELECT fullname, group,
dateCreated, ammendedBy, dateAmmended, allowedReport, priorityReport,
description, onlinePass FROM tblUser WHERE
userID=".$_SESSION['userName']."");
//$users is a single dimension array filled with the
SQL results
print_r($users);
echo"";
$this->$name = $users[1];
echo "~ name: ".$this->$name."";
$this->$group = $users[2];
echo "~ group: ".$this->$group."";
echo "[".$this->$name." ".$this->$group."]";
echo "name: ".$this->$name."";
}
}
Expected result:
Array ( [1] => aName [2] => 4 [3] => 2001-10-13 00:00:00 [4] => System
[5] => 2003-07-22 00:00:00 [6] => 1 [7] => 1 [8] => aJobTitle [9] =>
password )
~ name: aName
~ group: 4
[aName 4]
name: aName
Actual result:
--
Array ( [1] => aName [2] => 4 [3] => 2001-10-13 00:00:00 [4] => System
[5] => 2003-07-22 00:00:00 [6] => 1 [7] => 1 [8] => aJobTitle [9] =>
aPassword )
~ name: 4
~ group: 4
[4 4]
name: 4
--
Edit this bug report at http://bugs.php.net/?id=25973&edit=1
#25916 [Fbk->Opn]: get_browser() -> PHP Fatal error: Nesting level too deep - recursive dependency?
ID: 25916
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: Solaris 9
PHP Version: 4.3.4RC1
Previous Comments:
[2003-10-31 13:14:25] [EMAIL PROTECTED]
I do not think so, because it happens only when a lot of requests are
done. So you cannot test it with CLI/CGI :(
I could debug it when the server goes into this error by attaching dbx
to PID. But to do this it would be good to check where this error could
come from.
[2003-10-30 21:05:20] [EMAIL PROTECTED]
Does this happen with CLI build with ZTS enabled?
[2003-10-20 04:30:58] [EMAIL PROTECTED]
Addendum: It is not a problem with wrong extension dir in php.ini
(because all extensions are linked static) like in other bugs.
The configuration phpinfo() can be found at:
http://134.1.2.11/test.php
[2003-10-20 03:39:01] [EMAIL PROTECTED]
Description:
The following error occurs sometimes on the ext/standard function
get_browser():
[20/Oct/2003:08:54:59] info (13034): for host
p5084725C.dip.t-dialin.net trying to GET /index.php, php4_execute
reports: PHP Fatal error: Nesting level too deep - recursive
dependency? in /pangaea/htdocs/www.pangaea.de/index.php on line 28
Line 28 contains the call to get_browser(). All other PHP functions do
not fail. In other scripts which use get_browser() the error also
occurs.
The problem is: You cannot reproduce it, because it happens only on
heavy server load and when it happens the first time it does not go
away until server restart.
PHP runs on SunONE with NSAPI, so compiled with ZTS.
I would debug the code and fix the error; but my problem is that I do
not know WHERE in get_browser the error occurs.
Uwe
Reproduce code:
---
http://www.google.de/search?sourceid=navclient&hl=de&q=%22age%2C+error%22+pangaea
//
http://www.google.de/search?q=%22age,+error%22+pangaea&hl=de&lr=&ie=UTF-8&filter=0
if (isset($_GET['query'])) {
$query=$_GET['query'];
} else {
if (isset($_SERVER['HTTP_REFERER']) &&
preg_match('/^http:\/\/.*?google\..*?\/search\?(.*?)$/i',
$_SERVER['HTTP_REFERER'], $matches)) {
$a = split ('&', $matches[1]);
for ($i=0; $icrawler) && isset($_SERVER['PATH_INFO'])) {
if (isset($query)) {
header("Location:
http://".$_SERVER['HTTP_HOST']."/?query=".urlencode($query));
} else {
header("Location: http://".$_SERVER['HTTP_HOST']."/");
}
exit();
}
// if a crawler like google is visiting: prepare keyword list to
display and extract page number
if ($browser->crawler) {
$page=0;
if (isset($_SERVER['PATH_INFO'])) {
if (preg_match('/^\/(.*?)\.html$/', $_SERVER['PATH_INFO'],
$matches)) {
$page=$matches[1];
} else {
header("HTTP/1.0 404 Not Found");
exit();
}
}
$lines=file("../globals/googlelist.txt");
if ($page*1000>=count($lines)) {
header("HTTP/1.0 404 Not Found");
exit();
}
}
?>
...
--
Edit this bug report at http://bugs.php.net/?id=25916&edit=1
#25757 [Fbk->NoF]: odbc_primarykeys error
ID: 25757 Updated by: [EMAIL PROTECTED] Reported By: dlaroche at nobug dot lu -Status: Feedback +Status: No Feedback Bug Type: ODBC related Operating System: Windows XP Professional PHP Version: 4.3.3 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-10-31 09:51:23] [EMAIL PROTECTED] Try using a NULL value instead of "" for the empty slots. That should solve the problem you're seeing. [2003-10-05 17:12:12] dlaroche at nobug dot lu Description: I'm trying to write a script to convert tables from a Microsoft Access (version from 97 to 2002) to MySQL. The first step is that I just want the structure of the tables, so I need several functions from odbc. But for the primary keys, the function odbc_primarykeys doesn't work. I read that I can get the key information of a table using the odbc_statistics function but this function doesn't work aswell. Reproduce code: --- $resAccessPrimaryKeyList = odbc_primarykeys($resAccessConnection, "", "", "tblManif"); echo(odbc_result_all($resAccessPrimaryKeyList)); Expected result: don't know the result but I want to get a list with the primary keys of the table. Actual result: -- Warning: odbc_primarykeys(): SQL error: , SQL state 0 in SQLPrimaryKeys in E:\htdocs\ltam\odbc.php on line 65 Warning: odbc_result_all(): supplied argument is not a valid ODBC result resource in E:\htdocs\ltam\odbc.php on line 66 -- Edit this bug report at http://bugs.php.net/?id=25757&edit=1
#24718 [Fbk->NoF]: odbc_result_all crashes on some results
ID: 24718 Updated by: [EMAIL PROTECTED] Reported By: psychosos at gmx dot at -Status: Feedback +Status: No Feedback Bug Type: ODBC related Operating System: Windows 2000 Professional PHP Version: 4.3.2 Assigned To: kalowsky New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-10-31 09:55:32] [EMAIL PROTECTED] You are correct that a LONGCHAR is not supported, although I haven't a clue what that would actually be. A CHAR, VARCHAR, VARBINARY, LONGVARBINARY would all be valid substitutions though. Can you try changing that and see if this solves your problem? [2003-07-28 07:14:47] psychosos at gmx dot at Hello, Here is a more exact schema of the table called Kommentare, created with odbc_columns: TABLE.COLUMN/DATA_TYPE/TYPE_NAME/COLUMN_SIZE Kommentare.ID/4/INTEGER/10 Kommentare.Kommentar/-1/LONGCHAR/1073741823 Kommentare.Kommentator/12/VARCHAR/50 Kommentare.Datum/11/DATETIME/19 Kommentare.IP/12/VARCHAR/15 So actually column Kommentator it is a VARCHAR, not a Text as I said before. (That's just how the German version of MS Access likes to call it.) I have to admit I am not sure whether LONGCHAR is supported though. Could this be the problem? You can get the zipped SQLLog for the query "SELECT Kommentar FROM Kommentare" at http://forum.geizhals.at/files/641/SQL.ZIP (around 4KB). I hope it helps. [2003-07-27 23:38:26] [EMAIL PROTECTED] Well the start is that type TEXT isn't really supported by ODBC v2 (which is what PHP uses). If you can change to a type VARCHAR that would work much better (I can't remember if Access cares about this or not). But for further debugging information, if you can turn on SQLLogging (under your ODBC Administrator) create the connection, run one of the queries that crashes everything, and post the results here that would help. You might need/want to ensure the removal of the site specific information (i.e. login and password) before you post it here though. [2003-07-24 16:17:10] psychosos at gmx dot at Sorry about the delay. The database I am experiencing the problem with is an Microsoft Access Database I created with MS Access XP. The problematic table has the following schema: Table Kommentare ID long integer DEFAULT 0 NOT NULL Kommentar Memo NOT NULL Kommentator Text (50) Datum Date/Time (standard date) IP Text(15) (sorry about non-SQL conformity; I tried to transcribe the MS Access information) "SELECT * FROM Kommentare" crashes PHP. "SELECT ID, Kommentator, Datum, IP FROM Kommentare" works fine. "SELECT Kommentar FROM Kommentare" crashes PHP. "SELECT TOP 200 Kommentar FROM Kommentare" works fine as well. But "SELECT Kommentar FROM Kommentare" crashes PHP. If needed/helpful I might try to determine the exact number of records (bytes) which crashes PHP. Unfortunately I am not experienced debugging applications. If I can be of any further help I'd be glad to follow your instructions :-) Cheers, johannes [2003-07-19 17:30:10] [EMAIL PROTECTED] A sample schema would help tremendiously. Also what database? 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/24718 -- Edit this bug report at http://bugs.php.net/?id=24718&edit=1
#26114 [Bgs]: mysql_errno() & mysql_error() not behaving right on a second connection
ID: 26114
Updated by: [EMAIL PROTECTED]
Reported By: scouture at novo dot ca
Status: Bogus
Bug Type: MySQL related
Operating System: windows 2000
PHP Version: 4.3.3
New Comment:
Please read the manual pages for mysql_errno() and mysql_error() about
what parameters they accept and you'll
find out what I meant..
Previous Comments:
[2003-11-04 11:20:44] scouture at novo dot ca
Have you been able to reproduce the behavior with the new_link
parameter set to TRUE like I did ?
[2003-11-04 10:27:52] scouture at novo dot ca
I've got the same result EVEN with the new_link parameter set to TRUE.
echo "first connection";
$conn1 = mysql_connect($validIp&Port,$validUser,$validPassword,
true);
if($conn1 == false)
{
echo "mysql_error : ".mysql_error()."";
echo "mysql_errno : ".mysql_errno()."";
}
else
echo "ok connected 1";
echo "second connection";
$conn2 = mysql_connect ($validIp&Port,$validUser,$NOTvalidPassword,
true);
if($conn2 == false)
{
echo "mysql_error : ".mysql_error()."";
echo "mysql_errno : ".mysql_errno()."";
}
else
echo "ok connected 2";
[2003-11-04 09:58:34] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Always use the link parameter when doing multiple connects in same
scripts. This is no bug.
[2003-11-04 09:45:51] scouture at novo dot ca
NOTE that mysql_error() & mysql_errno() are returning result has
expected if the first connection failed. So, if the first connection
and the second failed, both mysql_error() & mysql_errno() are ok for
the first and the second connection.
But, if there is already a valid connection to the dbserver, they are
not behaving right for the second in case of failling.
Hope that is clear enought...
Regards
[2003-11-04 09:39:44] scouture at novo dot ca
Description:
When openning 2 connections to a MySQL server using mysql_connect or
mysql_pconnect, if the first connection is valid and the second not (in
my code, the password for the second connection is wrong), then
mysql_error() return an empty string and mysql_errno return 0 witch is
the errno saying that there has been no problem.
Reproduce code:
---
echo "first connection";
$conn1 = mysql_connect($validIp&Port,$validUser,$validPassword);
if($conn1 == false)
{
echo "mysql_error : ".mysql_error()."";
echo "mysql_errno : ".mysql_errno()."";
}
else
echo "ok connected 1";
echo "second connection";
$conn2 = mysql_connect ($validIp&Port,$validUser,$NOTvalidPassword);
if($conn2 == false)
{
echo "mysql_error : ".mysql_error()."";
echo "mysql_errno : ".mysql_errno()."";
}
else
echo "ok connected 2";
Expected result:
mysql_error should be
Access denied for user: '[EMAIL PROTECTED]' (Using password: YES)
mysql_errno should be
1045
Actual result:
--
/**display**/
first connection
ok connected 1
second connection
Warning: mysql_connect(): Access denied for user: '[EMAIL PROTECTED]'
(Using password: YES) in D:\Program Files\Apache
Group\Apache2\htdocs\Intranet Novolog\tesMysql.php on line 20
mysql_error :
mysql_errno : 0
--
Edit this bug report at http://bugs.php.net/?id=26114&edit=1
#26116 [Opn->Fbk]: Unable to connect to ODBC database
ID: 26116 Updated by: [EMAIL PROTECTED] Reported By: andrew at howells-solicitors dot com -Status: Open +Status: Feedback Bug Type: ODBC related Operating System: Windows NT 4 sp6a PHP Version: 4.3.4 New Comment: My uneducated guess would be that the permissions for the apache user differ to the permission for the user as which you run the script on command line. Check those. Previous Comments: [2003-11-04 10:39:43] andrew at howells-solicitors dot com Description: I am using PHP 4.3.4 & Apache 1.3.28 all on Windows NTT 4. I have a remote Progress database server that serves as backednd to a practice management and accounts suite we use in-house. I want to use PHP to provide a web based interface to this database but am having some entertaining problems. I've tried the progress supplied Merant ODBC drivers as well as the OpenLink ODBC drivers. Both connect fine, however, if I try connecting using PHP loaded as a module ito apache I cannot connect to the DB, the ODBC driver refuses to load. However, If I execute the script from the comand line "php E:\webpages\intranet\sostest2.php" The connection is established ok. Reproduce code: --- http://bugs.php.net/?id=26116&edit=1
#26130 [NEW]: IBM DB2 Unique Key Problem
From: jay at nicwr dot mah dot nic dot in Operating system: Linux 8.0 PHP version: 4.3.2 PHP Bug Type: ODBC related Bug description: IBM DB2 Unique Key Problem Description: I have IBM DB2 V 7.2 EE Fix Pack 7 My Php is enabled with ibm-db2 support I have a table test (c1 int not null,c2 int,c3 int) I have a unique key on table test as (c1) with include options for (c2,C3) If I have a sample data 1,null,null 2,1,null, 3,null,1 4,1,2 If I access the data thru my php script I do not get desirable result. Reproduce code: --- "; } ?> Expected result: Expected Result is as follows - Record:1---End Record Record:2-1--End Record Record:3--1-End Record Record:4-1-2-End Record Actual result: -- Actual Results Appear as follows Record : ---End Record Record : ---End Record Record : ---End Record Record : 4-1-2-End Record -- Edit bug report at http://bugs.php.net/?id=26130&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26130&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26130&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26130&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26130&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26130&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26130&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26130&r=support Expected behavior: http://bugs.php.net/fix.php?id=26130&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26130&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26130&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26130&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26130&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26130&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26130&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26130&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26130&r=float
#26127 [Opn->Bgs]: IMAP compile fails!
ID: 26127
Updated by: [EMAIL PROTECTED]
Reported By: herps at raqtweak dot com
-Status: Open
+Status: Bogus
Bug Type: IMAP related
Operating System: Sun Cobalt RAQ4
PHP Version: 4.3.4
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.
Thank you for your interest in PHP.
See bug #22381
Previous Comments:
[2003-11-04 21:42:47] herps at raqtweak dot com
Description:
I compile my PHP with the option, --with-imap (or
--with-imap=/usr/lib/c-client.a , same result)
So the configure runs for a while, and then shows this:
I keep getting the following output:
checking for IMAP support... yes
checking for pam_start in -lpam... yes
checking for crypt in -lcrypt... (cached) yes
checking whether SSL libraries are needed for c-client... no
checking whether IMAP works... no
=
Note the 2 IMAP lines...
My config.log output:
configure:40552: checking whether IMAP works
configure:40585: gcc -o conftest -DEAPI -O2 -m486 -fno-strength-reduce
-L/usr/lib -ldb-3.0 conftest.c -lc-client -lcrypt -lpam -lttf -lpng
-lz -ljpeg -lz -lxml2 -ldb-3.0 -lgdbm -lz -lresolv -lm -ldl -lnsl
1>&5
/usr/lib/libc-client.a(mail.o): In function `mm_cache':
/home/redhat/BUILD/imap-2002d/c-client/mail.c:203: undefined reference
to `__canary_death_handler'
/usr/lib/libc-client.a(mail.o): In function `mail_parameters':
/home/redhat/BUILD/imap-2002d/c-client/mail.c:529: undefined reference
to `__canary_death_handler'
/usr/lib/libc-client.a(mail.o): In function `mail_valid':
/home/redhat/BUILD/imap-2002d/c-client/mail.c:568: undefined reference
to `__canary_death_handler'
/usr/lib/libc-client.a(mail.o): In function `mail_valid_net':
/home/redhat/BUILD/imap-2002d/c-client/mail.c:586: undefined reference
to `__canary_death_handler'
/usr/lib/libc-client.a(mail.o): In function
`mail_valid_net_parse_work':
/home/redhat/BUILD/imap-2002d/c-client/mail.c:709: undefined reference
to `__canary_death_handler'
/usr/lib/libc-client.a(mail.o):/home/redhat/BUILD/imap-2002d/c-client/mail.c:745:
more undefined references to `__canary_death_handler' follow
collect2: ld returned 1 exit status
configure: failed program was:
#line 40560 "configure"
#include "confdefs.h"
void mm_log(void){}
void mm_dlog(void){}
void mm_flags(void){}
void mm_fatal(void){}
void mm_critical(void){}
void mm_nocritical(void){}
void mm_notify(void){}
void mm_login(void){}
void mm_diskerror(void){}
void mm_status(void){}
void mm_lsub(void){}
void mm_list(void){}
void mm_exists(void){}
void mm_searched(void){}
void mm_expunged(void){}
char mail_newbody();
int main() {
mail_newbody();
return 0;
}
Now, I recall this used to work before...
I use imap2002d, compiled with stackguard support...
Please advise... I've been looking and searching for quite a while now,
but can find nothing... Thus I concluded that it might be a bug
--
Edit this bug report at http://bugs.php.net/?id=26127&edit=1
#26130 [Opn->Fbk]: IBM DB2 Unique Key Problem
ID: 26130 Updated by: [EMAIL PROTECTED] Reported By: jay at nicwr dot mah dot nic dot in -Status: Open +Status: Feedback Bug Type: ODBC related Operating System: Linux 8.0 PHP Version: 4.3.2 New Comment: Please upgrade first to PHP 4.3.4. And then try this script and paste the output here: Previous Comments: [2003-11-05 00:43:17] jay at nicwr dot mah dot nic dot in Description: I have IBM DB2 V 7.2 EE Fix Pack 7 My Php is enabled with ibm-db2 support I have a table test (c1 int not null,c2 int,c3 int) I have a unique key on table test as (c1) with include options for (c2,C3) If I have a sample data 1,null,null 2,1,null, 3,null,1 4,1,2 If I access the data thru my php script I do not get desirable result. Reproduce code: --- "; } ?> Expected result: Expected Result is as follows - Record:1---End Record Record:2-1--End Record Record:3--1-End Record Record:4-1-2-End Record Actual result: -- Actual Results Appear as follows Record : ---End Record Record : ---End Record Record : ---End Record Record : 4-1-2-End Record -- Edit this bug report at http://bugs.php.net/?id=26130&edit=1
#25972 [Ana]: ODBC truncates multi-byte text (w/ MSSQL)
ID: 25972 User updated by: phpbug at chipple dot net Reported By: phpbug at chipple dot net Status: Analyzed Bug Type: Feature/Change Request Operating System: Win2K 5.00.2195 SP4 PHP Version: 4.3, 5 New Comment: Thank you very much for the attention to my bug report. I gave the fix a try in my environment but then all field values received are empty (details below). Perhaps the SQL_COLUMN_LENGTH attribute always contains the value 0? // Test code $oOdbcConn = odbc_connect(C_Gen_sDbDSN,C_Gen_sDbUser,C_Gen_sDbPassword); $oOdbcRs = odbc_exec($oOdbcConn,$sSql); $aOdbcRow = odbc_fetch_array($oOdbcRs); for ($i = 1; $i <= odbc_num_fields($oOdbcRs); $i++) echo odbc_field_name($oOdbcRs,$i).": ". odbc_field_len($oOdbcRs,$i).": ". strlen($aOdbcRow[odbc_field_name($oOdbcRs,$i)]).": ". gettype($aOdbcRow[odbc_field_name($oOdbcRs,$i)]).""; // Result with php4-STABLE-200311050430 before change // (SQL_COLUMN_DISPLAY_SIZE) aCourseID: 10: 1: string tTitle: 80: 86: string // Result with php4-STABLE-200311050430 after change // (SQL_COLUMN_LENGTH) aCourseID: 10: 0: NULL tTitle: 80: 0: NULL Previous Comments: [2003-11-04 18:33:10] [EMAIL PROTECTED] I do not like the idea of introducing ODBCv3 based code/ options to a system predominately defined by ODBCv2 specifications. So I am against the inclusion of Moriyoshi's initial suggested fix for this. That being said, I did a bit more research on this today and think the following change should allow the double wide characters to work much better. I haven't tested it out yet myself, but if someone else has the time, it would be beneficial to all. Sorry about the bug system mangling. Essentially the SQL_COLUMNS_DISPLAY_SIZE lists the number of characters needed to display everything. This works fine but in the case of a double wide character array it doesn't (as explained my Moriyoshi). The SQL_COLUMN_LENGTH should return the number of bytes necessary for retrival of the column. WARNING: this change may fundamentally alter the functionality of the longreadlen variable comparisons as well. Use at your own risk right now. Index: php_odbc.c === RCS file: /repository/php-src/ext/odbc/php_odbc.c,v retrieving revision 1.176 diff -r1.176 php_odbc.c 671,672c671,672 < rc = SQLColAttributes(result->stmt, (UWORD)(i+1), SQL_COLUMN_DISPLAY_SIZE, < NULL, 0, NULL, &displaysize); --- > rc = SQLColAttributes(result->stmt, (UWORD)(i+1), > SQL_COLUMN_LENGTH, NULL, 0, NULL, &displaysize); [2003-11-04 09:31:56] [EMAIL PROTECTED] Well, then how did you conclude NVARCHAR support will break some kinds of compatibilities? I think I have already pointed out that we'd still be able to handle it on ODBCv2. (Sorry if this sounds offending. I don't mean so :) Basically we don't have to check whether the column type is NVARCHAR or not, but just allocate enough space for that type of characters. That way we also got to take a slight loss of memory into account though. [2003-11-04 07:56:51] [EMAIL PROTECTED] moriyoshi, It's not as simple as you show it to be. First you must realize that PHP's ODBC layer is written as an ODBC v2 compliant system, to just randomly add in support for NVARCHAR (and friends) will break support for other database systems. The point of my post wasn't to say this isn't a bug (hence why I marked it as verified), but rather to say it's a known bug and the issue is the extension is in need of updating. [2003-11-03 17:13:35] [EMAIL PROTECTED] I might be wrong, but I think this is a valid bug. According to the documentation on msdn [1] [2], the fifth parameter of SQLBindCol() expects the size of the buffer in byte, while the code mentioned below appears to give it the number of characters allocated for the column (display size) instead. This kind of confusion will most likely cause unexpected behaviour like described in this report. php_odbc.c 669: -- default: rc = SQLColAttributes(result->stmt, (UWORD)(i+1), SQL_COLUMN_DISPLAY_SIZE, NULL, 0, NULL, &displaysize); displaysize = displaysize <= result->longreadlen ? displaysize : result->longreadlen; result->values[i].value = (char *)emalloc(displaysize + 1); rc = SQLBindCol(result->stmt, (UWORD)(i+1), SQL_C_CHAR, result->values[i].value, displaysize + 1, &result->values[i].vallen); break; ---
