#46568 [Com]: Segfault on 64bit when chaining function calls that generate exceptions
ID: 46568
Comment by: bruno at ioda dot net
Reported By: phpbugs at colin dot guthr dot ie
Status: Open
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5.2.7RC3
New Comment:
I've try this on 3 differents openSUSE 10.3 all with the lastest
opensuse build services php version 5.2.6.
And the result was the expected exception
Fatal error: Uncaught exception 'Exception' with message 'Wibble' in
/tmp/bugs.php:10
Stack trace:
#0 /tmp/bugs.php(14): foo-wibble()
#1 /tmp/bugs.php(23): foo-bug()
#2 {main}
thrown in /tmp/bugs.php on line 10
PHP 5.2.6 with Suhosin-Patch 0.9.6.2 (cli) (built: Nov 5 2008
13:42:52)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH
For 10.3 gcc is :
Target: x86_64-suse-linux
Configuré avec: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.2.1
--enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--program-suffix=-4.2 --enable-version-specific-runtime-libs
--without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux
Modèle de thread: posix
version gcc 4.2.1 (SUSE Linux)
I've not yet try on the lastest 11.0 x64 which have the gcc
gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision
135036] (SUSE Linux)
Previous Comments:
[2008-11-13 22:41:05] phpbugs at colin dot guthr dot ie
Well I've confirmed this problem on three Mandriva systems with
Mandriva packages but for this bug report I built a fresh vanilla
version from the 5.2.7rc3 tarball on my own machine to ensure it was
nothing to do with any additional patches in the Mandriva package
causing the problem.
I do not have access to any non-Mandriva 64 bit build hosts here to do
more tests...
FWIW, the GCC version is 4.3.2.
I can tarball up the installed version if you want to give my build a
run and see if it crashes on your machine. If it does crash then I'd
expect the problem to be related to GCC.
[2008-11-13 22:23:05] [EMAIL PROTECTED]
I can't reproduce it on FreeBSD amd64.
[2008-11-13 16:18:13] phpbugs at colin dot guthr dot ie
Description:
I seem to have uncovered a bug that has been affecting me for a while
(e.g. it affects 5.2.6 as well) but that, until now, I have been able to
work around.
I have confirmed this bug on both 5.2.6 and 5.2.7RC3 on x86_64. I have
confirmed this bug does *not* occur on i586 with these same versions.
The reproduce code has two examples. It should be obvious which is
which ;)
I compiled up a fresh 5.2.7RC3 to produce the below backtrace.
Please remember that this bug affects x86_64 only.
I discovered this when using code in the Zend Framework in which this
scenario crops up in the natural flow of code.
Reproduce code:
---
?php
class foo
{
private function bar($x)
{
echo $x;
}
private function wibble()
{
throw new Exception(Wibble);
}
public function bug()
{
$this-bar($this-wibble());
}
public function nobug()
{
$wibble = $this-wibble();
$this-bar($wibble);
}
}
$foo = new foo;
$foo-bug();
//$foo-nobug();
Expected result:
PHP Fatal error: Uncaught exception 'Exception' with message 'Wibble'
in /home/colin/bug.php:10
Stack trace:
#0 /home/colin/bug.php(14): foo-wibble()
#1 /home/colin/bug.php(23): foo-bug()
#2 {main}
thrown in /home/colin/bug.php on line 10
Actual result:
--
[EMAIL PROTECTED] pfx]$ gdb bin/php
GNU gdb 6.8-2mdv2009.0 (Mandriva Linux release 2009.0)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show
copying
and show warranty for details.
This GDB was configured as x86_64-mandriva-linux-gnu...
(gdb) set args bug.php
(gdb) run
Starting program: /home/colin/php/pfx/bin/php bug.php
[Thread debugging using libthread_db enabled]
[New Thread 0x7f75d9a056f0 (LWP 18074)]
Program received signal SIGSEGV, Segmentation fault.
zend_do_fcall_common_helper_SPEC (execute_data=0x7fffe1a4fbd0) at
/home/colin/php/php-5.2.7RC3/Zend/zend_vm_execute.h:289
289
#46583 [NEW]: file - exhaust memory
From: noma4i at gmail dot com Operating system: WIN PHP version: 5.2.6 PHP Bug Type: Scripting Engine problem Bug description: file - exhaust memory Description: For my purpose I'am parsing into array of strings, 5mb file with near 3 lines. file Reads entire file into an array It exhaust memory while doing. Code like: file(here_goes_5mb_30k_lines_file.cvs); with 8mb opened for executing will produce: Fatal error: Allowed memory size of 8388608 bytes exhausted Reproduce code: --- file(here_goes_5mb_30k_lines_file.cvs); Actual result: -- Fatal error: Allowed memory size of 8388608 bytes exhausted -- Edit bug report at http://bugs.php.net/?id=46583edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46583r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46583r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46583r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46583r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46583r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46583r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46583r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46583r=needscript Try newer version: http://bugs.php.net/fix.php?id=46583r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46583r=support Expected behavior: http://bugs.php.net/fix.php?id=46583r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46583r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46583r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46583r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46583r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46583r=dst IIS Stability: http://bugs.php.net/fix.php?id=46583r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46583r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46583r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46583r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46583r=mysqlcfg
#45314 [Com]: wddx_serialize_value() does not handle unicode properly
ID: 45314
Comment by: mark at hell dot ne dot jp
Reported By: mikx at mikx dot de
Status: Open
Bug Type: WDDX related
Operating System: *
PHP Version: 5.2.6
New Comment:
This bug is related to bug #46496.
Bug #37571 indeed seems to be at the origin of the problem.
Previous Comments:
[2008-07-22 22:50:54] [EMAIL PROTECTED]
I guess (!) the fix for bug #37571 caused this problem.
[2008-06-19 12:48:52] mikx at mikx dot de
Description:
wddx_serialize_value does not deal as expected with unicode characters
in PHP 5.2.x or PHP 5.3.x. The function worked differently in PHP
5.1.6.
When serializing a string or a more complex objects any unicode
characters get again utf8 encoded - instead of getting in as is.
Reproduce code:
---
a href=?utf8=%E9%A1%B5Demo/a (some chinese character)
hr
form method=get action=?
input type=text name=utf8
input type=submit
/form
hr
?php
if (isset($_GET[utf8])) {
echo $_GET[utf8].br;
echo utf8_encode($_GET[utf8]).br;
echo wddx_serialize_value($_GET[utf8]).br;
}
?
Expected result:
The demo code is a little script that outputs the given query parameter
utf8 in three way:
1. Directly as recieved
2. utf8_encoded
3. serialized via wddx_serialize_value
In = 5.1.6 the resulting WDDX contained the utf8 characters excatly as
given. In = 5.2.0 the string gets UTF8 encoded again, just as if you
would have valled utf8_encode on it.
Actual result:
--
While the new behavior might make sense for data going forward
(although i am not sure what the expected behavior by WDDX spec is) this
breaks backward compatibility with old data.
As we have millons of database rows in unicode WDDX data this is a huge
issue (at least to us).
Can you please clarify if this is a bug, the expected behavior going
forward and how to deal with backward compatibility issues (maybe an
additional parameter to control the behavior)?
This might be related to bug #41722
--
Edit this bug report at http://bugs.php.net/?id=45314edit=1
#45037 [Com]: wddx_add_vars() does not convert variable names to UTF8
ID: 45037
Comment by: mark at hell dot ne dot jp
Reported By: JeanLuc dot TRIPLET at yahoo dot fr
Status: Open
Bug Type: WDDX related
Operating System: Windows
PHP Version: 5.2.6
New Comment:
This report is bogus, as WDDX is not supposed to convert content to
UTF-8 either.
Please see bug #46496 for more infos.
Previous Comments:
[2008-09-02 10:19:03] JeanLuc dot TRIPLET at yahoo dot fr
Modifying wddx.c as below solves the problem (php_wddx_serialize_var
also encode parameter names in addition to parameter values) :
Original wddx.c :
void php_wddx_serialize_var(wddx_packet *packet, zval *var, char *name,
int name
_len TSRMLS_DC)
{
char *tmp_buf;
char *name_esc;
int name_esc_len;
HashTable *ht;
if (name) {
name_esc = php_escape_html_entities(name, name_len,
name_esc_len, 0, ENT_QUOTES, NULL TSRMLS_CC);
tmp_buf = emalloc(name_esc_len + sizeof(WDDX_VAR_S));
snprintf(tmp_buf, name_esc_len + sizeof(WDDX_VAR_S),
WDDX_VAR_S, name_esc);
php_wddx_add_chunk(packet, tmp_buf);
efree(tmp_buf);
efree(name_esc);
}
Mofified wddx.c :
void php_wddx_serialize_var(wddx_packet *packet, zval *var, char *name,
int name
_len TSRMLS_DC)
{
char *tmp_buf;
char *enc;
char *name_esc;
int name_esc_len;
int enc_len;
HashTable *ht;
if (name) {
name_esc = php_escape_html_entities(name, name_len,
name_esc_len, 0, ENT_QUOTES, NULL TSRMLS_CC);
enc = xml_utf8_encode(name_esc, name_esc_len, enc_len,
ISO-8859-1);
tmp_buf = emalloc(enc_len + sizeof(WDDX_VAR_S));
snprintf(tmp_buf, enc_len + sizeof(WDDX_VAR_S),
WDDX_VAR_S, enc);
php_wddx_add_chunk(packet, tmp_buf);
efree(tmp_buf);
efree(name_esc);
efree(enc);
Could you, please, include some modification like this one in future
versions.
Thanks in advance.
[2008-05-19 10:13:11] JeanLuc dot TRIPLET at yahoo dot fr
Description:
wddx_add_vars() correctly converts values to UTF-8, but doesn't convert
var names to UTF-8, so wddx_deserialize() return an empty array as XML
packet contains var names with accent.
below is a script showing that string values are converted to UTF-8 by
wddx_add_vars, but var names are not converted. It also show that
wddx_deserialize() works fine when input packet contains UTF_8 encoded
var names manually, but doesn't work when var names are let accentuated
by wddx_add_vars().
Could you please, modify wddx_add_vars, to UTF_8 encode var names as
already done for string values ?
Thank for your help.
Reproduce code:
---
?php
// If varname is ascii, unserialize is OK //
$packet_id = wddx_packet_start(PHP);
$varname = value é;
wddx_add_vars($packet_id,varname);
$packet = wddx_packet_end($packet_id);
var_dump ($packet);
echo \n\n;
$result = wddx_deserialize($packet);
var_dump ($result);
// If varname is non_ascii, unserialize return array(0) {} //
$packet_id = wddx_packet_start(PHP);
$varnameé = value é;
wddx_add_vars($packet_id,varnameé);
$packet = wddx_packet_end($packet_id);
var_dump ($packet);
$result = wddx_deserialize($packet);
var_dump ($result);
// If packet contains non_ascii UTF-8 encoded varname, unserialize is
OK //
$packet = wddxPacket
version='1.0'headercommentPHP/comment/headerdatastructvar
name='varnameé'stringvalue
é/string/var/struct/data/wddxPacket;
var_dump ($packet);
$result = wddx_deserialize($packet);
var_dump ($result);
?
Expected result:
string(159) value é
array(1) { [varname]= string(7) value é }
string(160) value é
array(1) { [varnameé]= string(7) value é }
string(161) value é
array(1) { [varnameé]= string(7) value é }
Actual result:
--
string(159) value é
array(1) { [varname]= string(7) value é }
string(160) value é
array(0) { }
string(161) value é
array(1) { [varnameé]= string(7) value é }
--
Edit this bug report at http://bugs.php.net/?id=45037edit=1
#42060 [Com]: [PATCH] Add pagedResults support and more (PAT18 and PAT19 updated for 5.2.3)
ID: 42060 Comment by: aklmnop at gmail dot com Reported By: iarenuno at eteo dot mondragon dot edu Status: Assigned Bug Type: LDAP related Operating System: * PHP Version: 5CVS, 6CVS (2008-11-01) Assigned To: pajoye New Comment: It would be great to have this essential paging functionality, and it's about time to update PHP's ldap. LDAP isn't going anywhere, and this has been waiting for long enough. Just because a myopic maintainer doesn't use LDAP doesn't mean it's not extremely widespread, urgent and important. Thanks. Previous Comments: [2008-07-17 13:00:37] ando at sys-net dot it I didn't get any notification about this message, so I overlooked it; I was pointed here by a user (like many others) interested in the functionalities provided by the patch. In the meanwhile, I noticed that the code, after more than 2 years of inactivity, is now incompatible with the patch. Fixing it will require an amount of time that is incompatible with my current schedule. Feel free to fix it yourself. Cheers, p. [2008-06-05 19:10:08] [EMAIL PROTECTED] After a little discussions about windows with Howard, he pointed me to this bug report. It is now the right time to apply such patch (or any other new features) to ext/ldap as we are getting closer to the PHP 5.3 features freeze. Ando, do you have the time to work on it for php5.3? [2008-05-06 19:43:04] liveoutloud2day at gmail dot com This would be really helpful. Of course you could do the same thing with perl or python, and then interface to it with that, but that is really a pain. But I would think php could do anything python and maybe perl could do I have been following this patch for almost 3 years now, would be really nice to get it committed as the added functions just add to the functions use and don't change any of the existing code, except adding an additional optional parameter. [2008-04-17 10:59:03] [EMAIL PROTECTED] I'm too busy at work right now, and since I don't use LDAP stuff for anything anymore (or at least right now :), I'm not really keen on just applying the patch. I hope someone else with more time could look into this. [2007-11-21 11:33:02] avel+php at noc dot uoa dot gr I intend to write a wrapper function for PEAR::Pager and LDAP, to make paged results more accessible. Without this patch, paged results from LDAP are not possible. [Well, they _are_ possible, if one loads the entire result set in memory. :-| ] How come is this patch's status No Feedback? What is the PHP developers' stand on this patch as of now? Alexandros Vellis 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/42060 -- Edit this bug report at http://bugs.php.net/?id=42060edit=1
#42547 [Com]: ext/iconv/iconv.c:2426: undefined reference to `libiconv_open'
ID: 42547 Comment by: milind dot koyande at gmail dot com Reported By: dawidpachla at gmail dot com Status: No Feedback Bug Type: Compile Failure Operating System: CentOS 5 with DirectAdmin PHP Version: 5.2.4 New Comment: I have used --without-iconv with ./configure and make worked fine. Hope it will work for you too. -Milind ( http://trulymanaged.com ) Previous Comments: [2008-06-27 14:39:58] ranrig at gmail dot com Whenever you see undefined reference to `libiconv_open', try make CFLAGS=-liconv [2007-10-19 01:00:02] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, 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. [2007-10-11 14:06:27] [EMAIL PROTECTED] Is there some reason you have libiconv installed in /usr/local when your glibc provides the same stuff? Did something else require it? As the fix is to simply uninstall libiconv.. [2007-10-08 10:36:29] dawidpachla at gmail dot com Here's the output of # grep ICONV main/php_config.h after 'compilation': [EMAIL PROTECTED] php-5.2.4]# grep ICONV main/php_config.h /* #undef HAVE_LIBICONV */ /* #undef HAVE_GICONV_H */ /* #undef HAVE_LIBICONV */ #define HAVE_ICONV 1 #define PHP_ICONV_IMPL glibc /* #undef HAVE_BSD_ICONV */ #define PHP_ICONV_IMPL glibc #define HAVE_GLIBC_ICONV 1 #define PHP_ICONV_IMPL glibc #define ICONV_SUPPORTS_ERRNO 0 #define ICONV_SUPPORTS_ERRNO 0 #define ICONV_SUPPORTS_ERRNO 0 #define PHP_ICONV_H_PATH /usr/local/include/iconv.h /* #undef COMPILE_DL_ICONV */ /* #undef HAVE_LIBICONV */ /* #undef HAVE_GICONV_H */ /* #undef HAVE_LIBICONV */ #define HAVE_ICONV 1 [EMAIL PROTECTED] php-5.2.4]# [2007-09-21 09:15:14] [EMAIL PROTECTED] Try find that file first. It's $top_builddir/main/php_config.h 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/42547 -- Edit this bug report at http://bugs.php.net/?id=42547edit=1
#42060 [Asn]: [PATCH] Add pagedResults support and more (PAT18 and PAT19 updated for 5.2.3)
ID: 42060 Updated by: [EMAIL PROTECTED] Reported By: iarenuno at eteo dot mondragon dot edu Status: Assigned Bug Type: LDAP related Operating System: * PHP Version: 5CVS, 6CVS (2008-11-01) Assigned To: pajoye New Comment: Alexey has ported the patch to 5.3, it will committed in the next days. Previous Comments: [2008-11-16 14:24:12] aklmnop at gmail dot com It would be great to have this essential paging functionality, and it's about time to update PHP's ldap. LDAP isn't going anywhere, and this has been waiting for long enough. Just because a myopic maintainer doesn't use LDAP doesn't mean it's not extremely widespread, urgent and important. Thanks. [2008-07-17 13:00:37] ando at sys-net dot it I didn't get any notification about this message, so I overlooked it; I was pointed here by a user (like many others) interested in the functionalities provided by the patch. In the meanwhile, I noticed that the code, after more than 2 years of inactivity, is now incompatible with the patch. Fixing it will require an amount of time that is incompatible with my current schedule. Feel free to fix it yourself. Cheers, p. [2008-06-05 19:10:08] [EMAIL PROTECTED] After a little discussions about windows with Howard, he pointed me to this bug report. It is now the right time to apply such patch (or any other new features) to ext/ldap as we are getting closer to the PHP 5.3 features freeze. Ando, do you have the time to work on it for php5.3? [2008-05-06 19:43:04] liveoutloud2day at gmail dot com This would be really helpful. Of course you could do the same thing with perl or python, and then interface to it with that, but that is really a pain. But I would think php could do anything python and maybe perl could do I have been following this patch for almost 3 years now, would be really nice to get it committed as the added functions just add to the functions use and don't change any of the existing code, except adding an additional optional parameter. [2008-04-17 10:59:03] [EMAIL PROTECTED] I'm too busy at work right now, and since I don't use LDAP stuff for anything anymore (or at least right now :), I'm not really keen on just applying the patch. I hope someone else with more time could look into this. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/42060 -- Edit this bug report at http://bugs.php.net/?id=42060edit=1
#43224 [Opn]: support real graceful reload of fastcgi
ID: 43224 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee Status: Open Bug Type: Feature/Change Request Operating System: PLD Linux PHP Version: 5.2.5RC2 Assigned To: dmitry New Comment: ping? for now the patch only makes php-fcgi to close listening socket on SIGTERM, so if it continues to run, new processes are able to spawn to the same tcp port. http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-fcgi-graceful.patch?rev=1.8 Previous Comments: [2008-07-29 09:22:33] glen at delfi dot ee Didn't know about SIGQUIT, but ok, you can keep the signal handlers, but closing listening sockets on SIGTERM does not break process managers, it will do only good. as for original behaviour, if you have some long running request running and you terminate fcgi processes with SIGTERM you can not start new fcgi processes on same tcp port (as the socket is still in use) so to summarize signal handlers would be: SIGTERM, SIGUSR1 - graceful shutdown -- listening sockets are closed, processing continues until scripts finish SIGINT, SIGQUIT (, SIGKILL) - immediate shutdown -- listening sockets are closed, processes are terminated unconditionally whether they are idle or not. [2008-07-29 09:00:33] [EMAIL PROTECTED] FastCGI PHP SAPI supports only gracefull restart initiated by SIGTERM and SIGUSR1, however you still able to terminate worker processes with sending SIGINT/SIGQUIT to process group. I'm not going to change it as it may break behavior with some FastCGI managers. [2008-06-11 11:18:40] glen at delfi dot ee hi any progress with the patch? i can confirm that it works without problems since i initially created the patch. [2007-11-09 11:42:42] glen at delfi dot ee Description: currently (checked 5.3 and 5.2) php-fcgi when receiving terminating signal, finishes the request, ie does not terminate immedately. however it does not close the socket it is listening for incoming connections. and there's no way to make the process really terminate in a nice way. ie if you really want to terminate fcgi backend processes while not caring whether the request is finished or not you can do this only by sending SIGKILL, but it might be too brutal :) for the first problem i've created patch for unix (linux) platform, few testing shows that it really works. for the second problem i'd suggest to use SIGINT for graceful restart (close listening socket, end when php processing finishes) and SIGTERM would just close listening socket and abort php processing by making the child exit itself. patch for 5.2.4 (also 5.2.5RC2): http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-fcgi-graceful.patch?only_with_tag=MAIN patch for 5.3-snap: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-fcgi-graceful.patch?only_with_tag=DEVEL -- Edit this bug report at http://bugs.php.net/?id=43224edit=1
#46571 [Com]: Problem with variable...
ID: 46571 Comment by: sandel at ukr dot net Reported By: sandel at ukr dot net Status: Feedback Bug Type: Scripting Engine problem Operating System: Windows XP SP2 PHP Version: 5.2.6 New Comment: Sorry, I didn't answer for so long... here is my cut sources... just unzip, and lick button CLICK HERE without fill fields login and pass... Than appears error box with bug r http://u.log.kiev.ua/lite.7z there are some files that you should see: index.php data/language/ru.php data/account.php template/body.php Previous Comments: [2008-11-14 06:25:42] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2008-11-14 03:09:15] sandel at ukr dot net Description: I even don't know how describe it :( Please, just download movie where I show bug... http://u.log.kiev.ua/sss.avi ~76mb or zipped http://u.log.kiev.ua/bug.7z ~1mb Btw! If I put echo $lang['error']; in ru.php, it works correctly! Thanks for preview bug... Reproduce code: --- http://u.log.kiev.ua/sss.avi ~76mb or zipped http://u.log.kiev.ua/bug.7z ~1mb Expected result: http://u.log.kiev.ua/sss.avi ~76mb or zipped http://u.log.kiev.ua/bug.7z ~1mb Actual result: -- http://u.log.kiev.ua/sss.avi ~76mb or zipped http://u.log.kiev.ua/bug.7z ~1mb -- Edit this bug report at http://bugs.php.net/?id=46571edit=1
#46584 [NEW]: Invalid access to memory location.
From: jpetrula at hotmail dot com Operating system: xp pro SP3 PHP version: 5.2.6 PHP Bug Type: IIS related Bug description: Invalid access to memory location. Description: Windows XP Pro SP3 php-5.2.6-win32-installer.msi Installed using IIS ISAPI module Installed to C:\PHP Used defaults for features to install. Verified PATH has C:\PHP\;... I created C:\Inetpub\wwwroot\HelloWorld.php which contains html body ? php print Hello World; ? /body /html Typed in browser http://localhost/HelloWorld.php Browser displays following error: Invalid access to memory location. Typed in browser http://localhost/default.html This works fine so I know IIS is working. Why isn't HelloWorld.php working? Thank you for the feedback. -- Edit bug report at http://bugs.php.net/?id=46584edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46584r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46584r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46584r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46584r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46584r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46584r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46584r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46584r=needscript Try newer version: http://bugs.php.net/fix.php?id=46584r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46584r=support Expected behavior: http://bugs.php.net/fix.php?id=46584r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46584r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46584r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46584r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46584r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46584r=dst IIS Stability: http://bugs.php.net/fix.php?id=46584r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46584r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46584r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46584r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46584r=mysqlcfg
#46571 [Com]: Problem with variable...
ID: 46571 Comment by: sandel at ukr dot net Reported By: sandel at ukr dot net Status: Feedback Bug Type: Scripting Engine problem Operating System: Windows XP SP2 PHP Version: 5.2.6 New Comment: UPDATE SRC URL FROM 16 NOV 5:05pm UTC (for debug) http://u.log.kiev.ua/123/lite.tar.gz Previous Comments: [2008-11-16 16:37:43] sandel at ukr dot net Sorry, I didn't answer for so long... here is my cut sources... just unzip, and lick button CLICK HERE without fill fields login and pass... Than appears error box with bug r http://u.log.kiev.ua/lite.7z there are some files that you should see: index.php data/language/ru.php data/account.php template/body.php [2008-11-14 06:25:42] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2008-11-14 03:09:15] sandel at ukr dot net Description: I even don't know how describe it :( Please, just download movie where I show bug... http://u.log.kiev.ua/sss.avi ~76mb or zipped http://u.log.kiev.ua/bug.7z ~1mb Btw! If I put echo $lang['error']; in ru.php, it works correctly! Thanks for preview bug... Reproduce code: --- http://u.log.kiev.ua/sss.avi ~76mb or zipped http://u.log.kiev.ua/bug.7z ~1mb Expected result: http://u.log.kiev.ua/sss.avi ~76mb or zipped http://u.log.kiev.ua/bug.7z ~1mb Actual result: -- http://u.log.kiev.ua/sss.avi ~76mb or zipped http://u.log.kiev.ua/bug.7z ~1mb -- Edit this bug report at http://bugs.php.net/?id=46571edit=1
#46584 [Opn-Fbk]: Invalid access to memory location.
ID: 46584 Updated by: [EMAIL PROTECTED] Reported By: jpetrula at hotmail dot com -Status: Open +Status: Feedback Bug Type: IIS related Operating System: xp pro SP3 PHP Version: 5.2.6 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ I would also recommend to use the FCGI interface if you still use the ISAPI. Previous Comments: [2008-11-16 17:03:05] jpetrula at hotmail dot com Description: Windows XP Pro SP3 php-5.2.6-win32-installer.msi Installed using IIS ISAPI module Installed to C:\PHP Used defaults for features to install. Verified PATH has C:\PHP\;... I created C:\Inetpub\wwwroot\HelloWorld.php which contains html body ? php print Hello World; ? /body /html Typed in browser http://localhost/HelloWorld.php Browser displays following error: Invalid access to memory location. Typed in browser http://localhost/default.html This works fine so I know IIS is working. Why isn't HelloWorld.php working? Thank you for the feedback. -- Edit this bug report at http://bugs.php.net/?id=46584edit=1
#46585 [NEW]: PCRE minimum matching length
From: ms419 at freezone dot co dot uk
Operating system: Debian
PHP version: 5.2.6
PHP Bug Type: Feature/Change Request
Bug description: PCRE minimum matching length
Description:
I wish for a PCRE function to get the minimum matching length of a regular
expression. For example:
* preg_min_length('/^HTTP.*/'): 4
* preg_min_length('/^(?:HTTP)?.+/'): 1
* preg_min_length('/^(?:HTTP)?.*/'): 0
--
Edit bug report at http://bugs.php.net/?id=46585edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46585r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46585r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46585r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46585r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46585r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46585r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46585r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46585r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46585r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46585r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46585r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46585r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46585r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46585r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46585r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46585r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46585r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46585r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46585r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46585r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46585r=mysqlcfg
#42060 [Com]: [PATCH] Add pagedResults support and more (PAT18 and PAT19 updated for 5.2.3)
ID: 42060 Comment by: iarenuno at eteo dot mondragon dot edu Reported By: iarenuno at eteo dot mondragon dot edu Status: Assigned Bug Type: LDAP related Operating System: * PHP Version: 5CVS, 6CVS (2008-11-01) Assigned To: pajoye New Comment: pajoye, thanks a lot for your work to get this patch into core. This was a much needed feature in big LDAP installations. Saludos. Iñaki. Previous Comments: [2008-11-16 14:57:56] [EMAIL PROTECTED] Alexey has ported the patch to 5.3, it will committed in the next days. [2008-11-16 14:24:12] aklmnop at gmail dot com It would be great to have this essential paging functionality, and it's about time to update PHP's ldap. LDAP isn't going anywhere, and this has been waiting for long enough. Just because a myopic maintainer doesn't use LDAP doesn't mean it's not extremely widespread, urgent and important. Thanks. [2008-07-17 13:00:37] ando at sys-net dot it I didn't get any notification about this message, so I overlooked it; I was pointed here by a user (like many others) interested in the functionalities provided by the patch. In the meanwhile, I noticed that the code, after more than 2 years of inactivity, is now incompatible with the patch. Fixing it will require an amount of time that is incompatible with my current schedule. Feel free to fix it yourself. Cheers, p. [2008-06-05 19:10:08] [EMAIL PROTECTED] After a little discussions about windows with Howard, he pointed me to this bug report. It is now the right time to apply such patch (or any other new features) to ext/ldap as we are getting closer to the PHP 5.3 features freeze. Ando, do you have the time to work on it for php5.3? [2008-05-06 19:43:04] liveoutloud2day at gmail dot com This would be really helpful. Of course you could do the same thing with perl or python, and then interface to it with that, but that is really a pain. But I would think php could do anything python and maybe perl could do I have been following this patch for almost 3 years now, would be really nice to get it committed as the added functions just add to the functions use and don't change any of the existing code, except adding an additional optional parameter. 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/42060 -- Edit this bug report at http://bugs.php.net/?id=42060edit=1
#46127 [Asn-Csd]: [PATCH] php_openssl_tcp_sockop_accept forgets to set context on accepted stream
ID: 46127 Updated by: [EMAIL PROTECTED] Reported By: mark at hell dot ne dot jp -Status: Assigned +Status: Closed Bug Type: OpenSSL related Operating System: * PHP Version: 5.3CVS-2008-11-11 Assigned To: pajoye New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Fixed in 5.3, head, test added. Previous Comments: [2008-09-21 09:05:42] mark at hell dot ne dot jp This bug is fixed by the following patch. I found this out while reading the code and comparing the OpenSSL and non-OpenSSL versions of the connection accept process. This one-line-patch shouldn't require that much testing, and fixes this problem. NB: Even if the reference to the context wasn't done, the context's refcount was increased, causing a minor memoryleak if on a ssl server stream, at least one connection was attempted (and failed). Fix: http://ookoo.org/svn/snip/ssl_test/ssl_fix_5.3.0alpha2.diff [2008-09-19 15:50:36] mark at hell dot ne dot jp Description: A SSL socket created with stream_socket_server() isn't able to accept any connection. It returns an SSL_R_NO_SHARED_CIPHER error, as if the context wasn't passed from the listener socket to the created socket in stream_socket_accept() This is causing me some problems as I'm writing an application which needs SSL sockets. Reproduce code: --- http://ookoo.org/svn/snip/ssl_test/ssl_test.php Expected result: Running on 5.2.6-pl6-gentoo Linux Memol.ooKoo.org 2.6.25-gentoo-r1-tux #1 SMP Sat Apr 19 21:17:22 CEST 2008 x86_64 Actual result: -- Running on 5.3.0alpha2 Warning: stream_socket_accept(): SSL_R_NO_SHARED_CIPHER: no suitable shared cipher could be used. This could be because the server is missing an SSL certificate (local_cert context option) in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 14 Warning: stream_socket_accept(): Failed to enable crypto in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 14 Warning: stream_socket_accept(): accept failed: Success in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 14 Warning: fsockopen(): SSL operation failed with code 1. OpenSSL Error messages: error:14077410:SSL routines:func(119):reason(1040) in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 38 Warning: fsockopen(): Failed to enable crypto in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 38 Warning: fsockopen(): unable to connect to ssl://127.0.0.1:21673 (Unknown error) in /home/magicaltux/projects/snip/ssl_test/ssl_test.php on line 38 -- Edit this bug report at http://bugs.php.net/?id=46127edit=1
#46585 [Opn-Bgs]: PCRE minimum matching length
ID: 46585
Updated by: [EMAIL PROTECTED]
Reported By: ms419 at freezone dot co dot uk
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: Debian
PHP Version: 5.2.6
New Comment:
We wrap around the PCRE library and can only use whats available, so
this isn't possible
Previous Comments:
[2008-11-16 21:06:46] ms419 at freezone dot co dot uk
Description:
I wish for a PCRE function to get the minimum matching length of a
regular expression. For example:
* preg_min_length('/^HTTP.*/'): 4
* preg_min_length('/^(?:HTTP)?.+/'): 1
* preg_min_length('/^(?:HTTP)?.*/'): 0
--
Edit this bug report at http://bugs.php.net/?id=46585edit=1
#46586 [NEW]: Lower case method name casting for static __call(), not for dynamic
From: zerspam at mail dot ru
Operating system:
PHP version: 5.2.6
PHP Bug Type: Scripting Engine problem
Bug description: Lower case method name casting for static __call(), not for
dynamic
Description:
I think the method name shouldn't cast to lower case if static calling
used.
Reproduce code:
---
class a
{
function __call($name, $p)
{
echo $name . ' ';
}
function foo()
{
$this-BaR();
self::BaR();
}
}
$a = new a();
$a-BaZ();
$a-foo();
Expected result:
BaZ BaR BaR
Actual result:
--
BaZ BaR bar
--
Edit bug report at http://bugs.php.net/?id=46586edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46586r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46586r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46586r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46586r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46586r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46586r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46586r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46586r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46586r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46586r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46586r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46586r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46586r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46586r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46586r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46586r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46586r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46586r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46586r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46586r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46586r=mysqlcfg
#46587 [NEW]: mt_/rand produce out of range numbers when min = 0 and max get_randmax
From: atomo64 at gmail dot com Operating system: Debian sid PHP version: 5.2.6 PHP Bug Type: *Math Functions Bug description: mt_/rand produce out of range numbers when min = 0 and max get_randmax Description: Whenever min is set to 0 and max is set to anything greater than getrandmax (or the mt_ version) the returned PRN is always (despite the upper limit check in the example code) a number minor than 0. Reproduce code: --- define(UL, mt_getrandmax()+1000); $r=mt_rand(0, UL); if ($r 0 || $r UL) echo Random value out of range\n; Expected result: No output Actual result: -- Random value out of range -- Edit bug report at http://bugs.php.net/?id=46587edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46587r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46587r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46587r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46587r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46587r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46587r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46587r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46587r=needscript Try newer version: http://bugs.php.net/fix.php?id=46587r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46587r=support Expected behavior: http://bugs.php.net/fix.php?id=46587r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46587r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46587r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46587r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46587r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46587r=dst IIS Stability: http://bugs.php.net/fix.php?id=46587r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46587r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46587r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46587r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46587r=mysqlcfg
#46588 [NEW]: Support for ? ? within NOWDOC/HEREDOC syntax
From: vask at dmglobal dot net Operating system: Any PHP version: 5.2.6 PHP Bug Type: Feature/Change Request Bug description: Support for ? ? within NOWDOC/HEREDOC syntax Description: NOWDOC/HEREDOC only allows PHP values such as those allowed within a quoted string. Permitting PHP code (such as functions) within NOWDOC/HEREDOC will allow more flexibility for coding. Also, when using a text editor, syntax styling for PHP and syntax styling for another language specified by the NOWDOC/HEREDOC within the same file would be more readable as breaking apart the NOWDOC/HEREDOC for a function call would no longer be necessary. In the below examples I would like to reemphasize the importance of: - PHP code with PHP syntax styling - SQL code with SQL syntax styling $sql = SQL SELECT ?= get_it(); ? LIMIT 1 SQL; Instead of: $sql = SQL SELECT SQL; $sql .= get_it(); $sql .= SQL LIMIT 1 SQL; Reproduce code: --- $sql = SQL SELECT ?= get_it(); ? LIMIT 1 SQL; Expected result: $sql = SQL SELECT ?= get_it(); ? LIMIT 1 SQL; Actual result: -- Does NOT run. -- Edit bug report at http://bugs.php.net/?id=46588edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46588r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46588r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46588r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46588r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46588r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46588r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46588r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46588r=needscript Try newer version: http://bugs.php.net/fix.php?id=46588r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46588r=support Expected behavior: http://bugs.php.net/fix.php?id=46588r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46588r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46588r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46588r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46588r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46588r=dst IIS Stability: http://bugs.php.net/fix.php?id=46588r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46588r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46588r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46588r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46588r=mysqlcfg
#46589 [NEW]: am/pm issue
From: micah_blu at bluprintsmedia dot net Operating system: Linux PHP version: 5.2.6 PHP Bug Type: Date/time related Bug description: am/pm issue Description: date() function returns wrong am/pm, usually always outputs am instead of pm Reproduce code: --- echo date(Y-m-d h:i a); Expected result: //outputs: 2008-11-16 9:26 pm Actual result: -- //outputs: 2008-11-16 9:26 am -- Edit bug report at http://bugs.php.net/?id=46589edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46589r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46589r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46589r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46589r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46589r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46589r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46589r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46589r=needscript Try newer version: http://bugs.php.net/fix.php?id=46589r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46589r=support Expected behavior: http://bugs.php.net/fix.php?id=46589r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46589r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46589r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46589r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46589r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46589r=dst IIS Stability: http://bugs.php.net/fix.php?id=46589r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46589r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46589r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46589r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46589r=mysqlcfg
#46591 [NEW]: replace into syntax cannot null for PK in mysql
From: akbar6393222 at yahoo dot com Operating system: Windows Xp SP3 pro PHP version: 5.2.6 PHP Bug Type: MySQL related Bug description: replace into syntax cannot null for PK in mysql Description: I execute this directly on mysql 5.1.25-rc-community on command line, it's work REPLACE INTO qna_content (id,service_id,qna_id,service,sub_service,content,sub_content,publish_date,status,ctn_seq,first_ctn,last_update,update_by) VALUES ( '','1','1','alam', '','tes','','-00-00','1', '1', '0', NOW(), 'akbar' ) But in php 5.2.6, trigger error : Incorrect integer value: ' ' for column 'id' at row 1 error number 1366 Reproduce code: --- REPLACE INTO qna_content (id,service_id,qna_id,service,sub_service,content,sub_content,publish_date,status,ctn_seq,first_ctn,last_update,update_by) VALUES ( '','1','1','alam', '','tes','','-00-00','1', '1', '0', NOW(), 'akbar' ) Expected result: I need to be work for that code so I don't need to check another filter validation Actual result: -- Incorrect integer value: ' ' for column 'id' at row 1 error number 1366 -- Edit bug report at http://bugs.php.net/?id=46591edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46591r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46591r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46591r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46591r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46591r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46591r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46591r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46591r=needscript Try newer version: http://bugs.php.net/fix.php?id=46591r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46591r=support Expected behavior: http://bugs.php.net/fix.php?id=46591r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46591r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46591r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46591r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46591r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46591r=dst IIS Stability: http://bugs.php.net/fix.php?id=46591r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46591r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46591r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46591r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46591r=mysqlcfg
#46587 [Opn-Asn]: mt_/rand produce out of range numbers when min = 0 and max get_randmax
ID: 46587 Updated by: [EMAIL PROTECTED] Reported By: atomo64 at gmail dot com -Status: Open +Status: Assigned Bug Type: *Math Functions Operating System: Debian sid PHP Version: 5.2.6 -Assigned To: +Assigned To: pajoye Previous Comments: [2008-11-17 02:50:20] atomo64 at gmail dot com Description: Whenever min is set to 0 and max is set to anything greater than getrandmax (or the mt_ version) the returned PRN is always (despite the upper limit check in the example code) a number minor than 0. Reproduce code: --- define(UL, mt_getrandmax()+1000); $r=mt_rand(0, UL); if ($r 0 || $r UL) echo Random value out of range\n; Expected result: No output Actual result: -- Random value out of range -- Edit this bug report at http://bugs.php.net/?id=46587edit=1
