#21718 [NEW]: Segfault on pear installer script

2003-01-17 Thread spam
From: [EMAIL PROTECTED]
Operating system: Slackware Linux 8.1
PHP version:  4.3.0
PHP Bug Type: Reproducible crash
Bug description:  Segfault on pear installer script

Installed php-4.3.0 from source .tar.gz, then tried to install the 'Auth'
pear package:

berg@baboon:~$ pear install Auth
downloading Auth-1.1.1.tgz ...
...done: 11,005 bytes
Segmentation fault (core dumped)

I think the crash occurs in the zlib compression functions.

Backtrace follows:

(gdb) bt
#0  0x08187fdf in inflate_codes ()
#1  0x08186eb3 in inflate_blocks ()
#2  0x08186046 in inflate ()
#3  0x08181ff7 in gzread ()
#4  0x0806d4db in php_gziop_read (stream=0x846e904,
buf=0x847f424 "by Marko Karppinen, <[EMAIL PROTECTED]>)\n\n*
Added optional setLoginCallback() and setLogoutCallback() methods.\n 
(Patch by Marko Karppinen, <[EMAIL PROTECTED]>)\n\n* Added method
setIdle"..., count=512) at
/usr/local/src/php-4.3.0/ext/zlib/zlib_fopen_wrapper.c:36
#5  0x08147f53 in _php_stream_read (stream=0x846e904,
buf=0x847f424 "by Marko Karppinen, <[EMAIL PROTECTED]>)\n\n*
Added optional setLoginCallback() and setLogoutCallback() methods.\n 
(Patch by Marko Karppinen, <[EMAIL PROTECTED]>)\n\n* Added method
setIdle"..., size=512) at /usr/local/src/php-4.3.0/main/streams.c:589
#6  0x080e744c in zif_fread (ht=2, return_value=0x846fd2c, this_ptr=0x0,
return_value_used=1) at /usr/local/src/php-4.3.0/ext/standard/file.c:2083
#7  0x08178693 in execute (op_array=0x83786b4) at
/usr/local/src/php-4.3.0/Zend/zend_execute.c:1598
#8  0x0817880a in execute (op_array=0x835c22c) at
/usr/local/src/php-4.3.0/Zend/zend_execute.c:1640
#9  0x0817880a in execute (op_array=0x836090c) at
/usr/local/src/php-4.3.0/Zend/zend_execute.c:1640
#10 0x0817880a in execute (op_array=0x83c34f4) at
/usr/local/src/php-4.3.0/Zend/zend_execute.c:1640
#11 0x0817880a in execute (op_array=0x83a8ac4) at
/usr/local/src/php-4.3.0/Zend/zend_execute.c:1640
#12 0x0817880a in execute (op_array=0x83a465c) at
/usr/local/src/php-4.3.0/Zend/zend_execute.c:1640
#13 0x0817880a in execute (op_array=0x826bfb4) at
/usr/local/src/php-4.3.0/Zend/zend_execute.c:1640
#14 0x08166d9e in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /usr/local/src/php-4.3.0/Zend/zend.c:864
#15 0x0813fa8a in php_execute_script (primary_file=0xb828) at
/usr/local/src/php-4.3.0/main/main.c:1573
#16 0x0818128c in main (argc=8, argv=0xb8a4) at
/usr/local/src/php-4.3.0/sapi/cli/php_cli.c:746
#17 0x4020017d in __libc_start_main (main=0x81808dc , argc=8,
ubp_av=0xb8a4, init=0x80692fc <_init>, fini=0x8188b70 <_fini>,
rtld_fini=0x4000a534 <_dl_fini>, stack_end=0xb89c) at
../sysdeps/generic/libc-start.c:129

-- 
Edit bug report at http://bugs.php.net/?id=21718&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21718&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21718&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21718&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21718&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21718&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21718&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21718&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21718&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21718&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21718&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21718&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21718&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21718&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21718&r=gnused




#21718 [Fbk->Opn]: Segfault on pear installer script

2003-01-18 Thread spam
 ID:   21718
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Slackware Linux 8.1
 PHP Version:  4.3.0
 New Comment:

Same again. Using zlib-1.1.4. Configure command was './configure'
'--enable-sockets' '--with-pgsql' '--enable-pcntl' '--with-apxs'
'--with-gd' '--with-zlib-dir=/usr/local/include/zlib' '--with-jpeg-dir'
'--enable-exif' '--with-freetype-dir=/usr/local'
'--with-dom=/usr/include/libxml2/libxml''--prefix=/usr/local/test'



#0  0x0818861f in inflate_codes ()
#1  0x081874f3 in inflate_blocks ()
#2  0x08186686 in inflate ()
#3  0x08182637 in gzread ()
#4  0x0806d60b in php_gziop_read (stream=0x846f4e4,
buf=0x847ffdc "by Marko Karppinen,
<[EMAIL PROTECTED]>)\n\n* Added optional setLoginCallback() and
setLogoutCallback() methods.\n  (Patch by Marko Karppinen,
<[EMAIL PROTECTED]>)\n\n* Added method setIdle"..., count=512)
at
/usr/local/src/php4-STABLE-200301181030/ext/zlib/zlib_fopen_wrapper.c:36
#5  0x081485b3 in _php_stream_read (stream=0x846f4e4,
buf=0x847ffdc "by Marko Karppinen,
<[EMAIL PROTECTED]>)\n\n* Added optional setLoginCallback() and
setLogoutCallback() methods.\n  (Patch by Marko Karppinen,
<[EMAIL PROTECTED]>)\n\n* Added method setIdle"..., size=512)
at /usr/local/src/php4-STABLE-200301181030/main/streams.c:589
#6  0x080e765c in zif_fread (ht=2, return_value=0x8470974,
this_ptr=0x0, return_value_used=1)
at
/usr/local/src/php4-STABLE-200301181030/ext/standard/file.c:2083
#7  0x08178ca3 in execute (op_array=0x83797e4) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend_execute.c:1598
#8  0x08178e1a in execute (op_array=0x836155c) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend_execute.c:1640
#9  0x08178e1a in execute (op_array=0x83608ac) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend_execute.c:1640
#10 0x08178e1a in execute (op_array=0x83c3f94) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend_execute.c:1640
#11 0x08178e1a in execute (op_array=0x83a9554) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend_execute.c:1640
#12 0x08178e1a in execute (op_array=0x839657c) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend_execute.c:1640
#13 0x08178e1a in execute (op_array=0x826cfb4) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend_execute.c:1640
#14 0x081673ae in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend.c:864
#15 0x0813ff1a in php_execute_script (primary_file=0xb828) at
/usr/local/src/php4-STABLE-200301181030/main/main.c:1573
#16 0x081818cc in main (argc=8, argv=0xb8a4) at
/usr/local/src/php4-STABLE-200301181030/sapi/cli/php_cli.c:753
#17 0x4020017d in __libc_start_main (main=0x8180eec , argc=8,
ubp_av=0xb8a4, init=0x8069424 <_init>, fini=0x81891b0 <_fini>,
rtld_fini=0x4000a534 <_dl_fini>, stack_end=0xb89c) at
../sysdeps/generic/libc-start.c:129


Previous Comments:


[2003-01-17 19:56:52] [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-01-17 18:25:51] [EMAIL PROTECTED]

Installed php-4.3.0 from source .tar.gz, then tried to install the
'Auth' pear package:

berg@baboon:~$ pear install Auth
downloading Auth-1.1.1.tgz ...
...done: 11,005 bytes
Segmentation fault (core dumped)

I think the crash occurs in the zlib compression functions.

Backtrace follows:

(gdb) bt
#0  0x08187fdf in inflate_codes ()
#1  0x08186eb3 in inflate_blocks ()
#2  0x08186046 in inflate ()
#3  0x08181ff7 in gzread ()
#4  0x0806d4db in php_gziop_read (stream=0x846e904,
buf=0x847f424 "by Marko Karppinen,
<[EMAIL PROTECTED]>)\n\n* Added optional setLoginCallback() and
setLogoutCallback() methods.\n  (Patch by Marko Karppinen,
<[EMAIL PROTECTED]>)\n\n* Added method setIdle"..., count=512)
at /usr/local/src/php-4.3.0/ext/zlib/zlib_fopen_wrapper.c:36
#5  0x08147f53 in _php_stream_read (stream=0x846e904,
buf=0x847f424 "by Marko Karppinen,
<[EMAIL PROTECTED]>)\n\n* Added optional setLoginCallback() and
setLogoutCallback() methods.\n  (Patch by Marko Karppinen,
<[EMAIL PROTECTED]>)\n\n* Added method setIdle"..., size=512)
at /usr/local/src/php-4.3.0/main/streams.c:589
#6  0x080e744c in zif_fread (ht=2, return_value=0x846fd2c,
this_ptr=0x0, return_value_used=1) at
/usr/local/src/php-4.3.0/ext/standard/file.c:2083
#7  0x08178693 in execute (op_array=0x83786b4) at
/usr/local/src/php-4.3.0/Zend/zend_execute.c:1598
#8  0x0817880a in execute (op_array=0x835c22c) at
/usr/local/src/php-4.3.0/Zend/zend_execute.c:1640
#9  0x0817880a in execute (op_array=0x836090c) at
/usr/local/src/php-4.3.0/Zend/zend_execute.c:1640
#10 0x0817

#21718 [Opn]: Segfault on pear installer script

2003-01-18 Thread spam
 ID:   21718
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Slackware Linux 8.1
 PHP Version:  4.3.0
 New Comment:

Does this help? I don't know much about debugging c++!

(gdb) frame 3
#3  0x08182637 in gzread ()
(gdb) l
31  static size_t php_gziop_read(php_stream *stream, char *buf,
size_t count TSRMLS_DC)
32  {
33  struct php_gz_stream_data_t *self = (struct
php_gz_stream_data_t *)stream->abstract;
34  int read;
35
36  read = gzread(self->gz_file, buf, count);
37
38  if (gzeof(self->gz_file))
39  stream->eof = 1;
40
(gdb) p stream
$25 = (FILE *) 0x0
(gdb) up
#4  0x0806d60b in php_gziop_read (stream=0x846f1d4,
buf=0x846f444 "package.xml", count=512)
at
/usr/local/src/php4-STABLE-200301181030/ext/zlib/zlib_fopen_wrapper.c:36
36  read = gzread(self->gz_file, buf, count);
(gdb) l
31  static size_t php_gziop_read(php_stream *stream, char *buf,
size_t count TSRMLS_DC)
32  {
33  struct php_gz_stream_data_t *self = (struct
php_gz_stream_data_t *)stream->abstract;
34  int read;
35
36  read = gzread(self->gz_file, buf, count);
37
38  if (gzeof(self->gz_file))
39  stream->eof = 1;
40
(gdb) p stream
$26 = (php_stream *) 0x846f1d4
(gdb) p *stream
$27 = {ops = 0x81bc280, abstract = 0x84702a4, filterhead = 0x0,
  filtertail = 0x0, wrapper = 0x0, wrapperthis = 0x0, wrapperdata =
0x0,
  fgetss_state = 0, is_persistent = 0, mode = "rb", '\0' ,
  rsrc_id = 65, in_free = 0, fclose_stdiocast = 0, stdiocast = 0x0,
  context = 0x0, flags = 2, position = 0, readbuf = 0x0, readbuflen =
0,
  readpos = 0, writepos = 0, chunk_size = 8192, eof = 0}


Previous Comments:


[2003-01-18 06:36:12] [EMAIL PROTECTED]

Same again. Using zlib-1.1.4. Configure command was './configure'
'--enable-sockets' '--with-pgsql' '--enable-pcntl' '--with-apxs'
'--with-gd' '--with-zlib-dir=/usr/local/include/zlib' '--with-jpeg-dir'
'--enable-exif' '--with-freetype-dir=/usr/local'
'--with-dom=/usr/include/libxml2/libxml''--prefix=/usr/local/test'



#0  0x0818861f in inflate_codes ()
#1  0x081874f3 in inflate_blocks ()
#2  0x08186686 in inflate ()
#3  0x08182637 in gzread ()
#4  0x0806d60b in php_gziop_read (stream=0x846f4e4,
buf=0x847ffdc "by Marko Karppinen,
<[EMAIL PROTECTED]>)\n\n* Added optional setLoginCallback() and
setLogoutCallback() methods.\n  (Patch by Marko Karppinen,
<[EMAIL PROTECTED]>)\n\n* Added method setIdle"..., count=512)
at
/usr/local/src/php4-STABLE-200301181030/ext/zlib/zlib_fopen_wrapper.c:36
#5  0x081485b3 in _php_stream_read (stream=0x846f4e4,
buf=0x847ffdc "by Marko Karppinen,
<[EMAIL PROTECTED]>)\n\n* Added optional setLoginCallback() and
setLogoutCallback() methods.\n  (Patch by Marko Karppinen,
<[EMAIL PROTECTED]>)\n\n* Added method setIdle"..., size=512)
at /usr/local/src/php4-STABLE-200301181030/main/streams.c:589
#6  0x080e765c in zif_fread (ht=2, return_value=0x8470974,
this_ptr=0x0, return_value_used=1)
at
/usr/local/src/php4-STABLE-200301181030/ext/standard/file.c:2083
#7  0x08178ca3 in execute (op_array=0x83797e4) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend_execute.c:1598
#8  0x08178e1a in execute (op_array=0x836155c) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend_execute.c:1640
#9  0x08178e1a in execute (op_array=0x83608ac) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend_execute.c:1640
#10 0x08178e1a in execute (op_array=0x83c3f94) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend_execute.c:1640
#11 0x08178e1a in execute (op_array=0x83a9554) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend_execute.c:1640
#12 0x08178e1a in execute (op_array=0x839657c) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend_execute.c:1640
#13 0x08178e1a in execute (op_array=0x826cfb4) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend_execute.c:1640
#14 0x081673ae in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend.c:864
#15 0x0813ff1a in php_execute_script (primary_file=0xb828) at
/usr/local/src/php4-STABLE-200301181030/main/main.c:1573
#16 0x081818cc in main (argc=8, argv=0xb8a4) at
/usr/local/src/php4-STABLE-200301181030/sapi/cli/php_cli.c:753
#17 0x4020017d in __libc_start_main (main=0x8180eec , argc=8,
ubp_av=0xb8a4, init=0x8069424 <_init>, fini=0x81891b0 <_fini>,
rtld_fini=0x4000a534 <_dl_fini>, stack_end=0xb89c) at
../sysdeps/generic/libc-start.c:129



[2003-01-17 19:56:52] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://sn

#21718 [Opn->Csd]: Segfault on pear installer script

2003-02-03 Thread spam
 ID:   21718
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: Slackware Linux 8.1
 PHP Version:  4.3.0
 New Comment:

Turns out my zlib library was broken


Previous Comments:


[2003-01-18 07:24:31] [EMAIL PROTECTED]

Does this help? I don't know much about debugging c++!

(gdb) frame 3
#3  0x08182637 in gzread ()
(gdb) l
31  static size_t php_gziop_read(php_stream *stream, char *buf,
size_t count TSRMLS_DC)
32  {
33  struct php_gz_stream_data_t *self = (struct
php_gz_stream_data_t *)stream->abstract;
34  int read;
35
36  read = gzread(self->gz_file, buf, count);
37
38  if (gzeof(self->gz_file))
39  stream->eof = 1;
40
(gdb) p stream
$25 = (FILE *) 0x0
(gdb) up
#4  0x0806d60b in php_gziop_read (stream=0x846f1d4,
buf=0x846f444 "package.xml", count=512)
at
/usr/local/src/php4-STABLE-200301181030/ext/zlib/zlib_fopen_wrapper.c:36
36  read = gzread(self->gz_file, buf, count);
(gdb) l
31  static size_t php_gziop_read(php_stream *stream, char *buf,
size_t count TSRMLS_DC)
32  {
33  struct php_gz_stream_data_t *self = (struct
php_gz_stream_data_t *)stream->abstract;
34  int read;
35
36  read = gzread(self->gz_file, buf, count);
37
38  if (gzeof(self->gz_file))
39  stream->eof = 1;
40
(gdb) p stream
$26 = (php_stream *) 0x846f1d4
(gdb) p *stream
$27 = {ops = 0x81bc280, abstract = 0x84702a4, filterhead = 0x0,
  filtertail = 0x0, wrapper = 0x0, wrapperthis = 0x0, wrapperdata =
0x0,
  fgetss_state = 0, is_persistent = 0, mode = "rb", '\0' ,
  rsrc_id = 65, in_free = 0, fclose_stdiocast = 0, stdiocast = 0x0,
  context = 0x0, flags = 2, position = 0, readbuf = 0x0, readbuflen =
0,
  readpos = 0, writepos = 0, chunk_size = 8192, eof = 0}



[2003-01-18 06:36:12] [EMAIL PROTECTED]

Same again. Using zlib-1.1.4. Configure command was './configure'
'--enable-sockets' '--with-pgsql' '--enable-pcntl' '--with-apxs'
'--with-gd' '--with-zlib-dir=/usr/local/include/zlib' '--with-jpeg-dir'
'--enable-exif' '--with-freetype-dir=/usr/local'
'--with-dom=/usr/include/libxml2/libxml''--prefix=/usr/local/test'



#0  0x0818861f in inflate_codes ()
#1  0x081874f3 in inflate_blocks ()
#2  0x08186686 in inflate ()
#3  0x08182637 in gzread ()
#4  0x0806d60b in php_gziop_read (stream=0x846f4e4,
buf=0x847ffdc "by Marko Karppinen,
<[EMAIL PROTECTED]>)\n\n* Added optional setLoginCallback() and
setLogoutCallback() methods.\n  (Patch by Marko Karppinen,
<[EMAIL PROTECTED]>)\n\n* Added method setIdle"..., count=512)
at
/usr/local/src/php4-STABLE-200301181030/ext/zlib/zlib_fopen_wrapper.c:36
#5  0x081485b3 in _php_stream_read (stream=0x846f4e4,
buf=0x847ffdc "by Marko Karppinen,
<[EMAIL PROTECTED]>)\n\n* Added optional setLoginCallback() and
setLogoutCallback() methods.\n  (Patch by Marko Karppinen,
<[EMAIL PROTECTED]>)\n\n* Added method setIdle"..., size=512)
at /usr/local/src/php4-STABLE-200301181030/main/streams.c:589
#6  0x080e765c in zif_fread (ht=2, return_value=0x8470974,
this_ptr=0x0, return_value_used=1)
at
/usr/local/src/php4-STABLE-200301181030/ext/standard/file.c:2083
#7  0x08178ca3 in execute (op_array=0x83797e4) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend_execute.c:1598
#8  0x08178e1a in execute (op_array=0x836155c) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend_execute.c:1640
#9  0x08178e1a in execute (op_array=0x83608ac) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend_execute.c:1640
#10 0x08178e1a in execute (op_array=0x83c3f94) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend_execute.c:1640
#11 0x08178e1a in execute (op_array=0x83a9554) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend_execute.c:1640
#12 0x08178e1a in execute (op_array=0x839657c) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend_execute.c:1640
#13 0x08178e1a in execute (op_array=0x826cfb4) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend_execute.c:1640
#14 0x081673ae in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at
/usr/local/src/php4-STABLE-200301181030/Zend/zend.c:864
#15 0x0813ff1a in php_execute_script (primary_file=0xb828) at
/usr/local/src/php4-STABLE-200301181030/main/main.c:1573
#16 0x081818cc in main (argc=8, argv=0xb8a4) at
/usr/local/src/php4-STABLE-200301181030/sapi/cli/php_cli.c:753
#17 0x4020017d in __libc_start_main (main=0x8180eec , argc=8,
ubp_av=0xb8a4, init=0x8069424 <_init>, fini=0x81891b0 <_fini>,
rtld_fini=0x4000a534 <_dl_fini>, stack_end=0xb89c) at
../sysdeps/generic/libc-start.c:129

--

#22083 [NEW]: php-cli MySQL charset problem

2003-02-05 Thread spam
From: [EMAIL PROTECTED]
Operating system: Windows
PHP version:  4.3.0
PHP Bug Type: MySQL related
Bug description:  php-cli MySQL charset problem

When I set default-character-set=win1250 in my.ini, php-cli says:

File 'c:\mysql\\share\charsets\?.conf' not found (Errcode: 2)
Character set '#26' is not a compiled character set and is not specified
in the 'c:\mysql\\share\charsets\Index' file

The problem is, that php-cli ignores character-sets-dir= in my.ini and
uses its own hard-coded path c:\mysql\. If I move the share\charsets\
directory into c:\mysql\, the problem is still here because there are two
backslashes in path, where php-cli tries to find it.

When I hexa edited php4ts.dll and change c:/mysql/ to c:/mysql3 and move
share\charsets\ directory there, everything is working.

Solution:
1. Change the default path for finding charsets from "c:/mysql/" to
"c:/mysql"
2. If possible, read character-sets-dir= from C:\Windows\my.ini.

-- 
Edit bug report at http://bugs.php.net/?id=22083&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22083&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22083&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22083&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22083&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22083&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22083&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22083&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22083&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22083&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22083&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22083&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22083&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22083&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22083&r=gnused




#19538 [Com]: No way to identify source of email sent by mail()

2002-09-21 Thread spam

 ID:   19538
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: ALL
 PHP Version:  4.2.3
 New Comment:

I suggest to add also sender IP as example
X-php_sender_IP


Previous Comments:


[2002-09-21 07:54:29] [EMAIL PROTECTED]

The problem is that when any user sends email message from php script
it always comes from ,,http'' (or whatever) user.

There is no way to identify which script was used to send some mail.
User sets all headers as he wants ;/ Sender is http@fqdn.

On my systems users have a lot of php scripts and spammers use them to
spam through my server! Identifying which script was used is quite
problematic when there are tons of scripts. php currently doesn't give
any information about which script was that - there is no usefull
enviroment variables, there is no additional mail headers, working
directory when calling sendmail is ,,/'' so I can't even do pwd to
identify directory with php script.

I'm suggesting adding way to identify source script. I thing about two
ways of doing this:
1) set enviroment variable SCRIPT_FILENAME with same value as in php
(and other variables) before executing sendmail so It would be possible
to setup wrapper instead of sendmail and do whatever you want.
2) add option to php.ini like sendmail_id_header = yes|no
that would cause adding some header to message like
X-PHP-Script-Filename: /home/something/blah.php
or even sendmail_id_header = name of php variable
(that would cause to add X-Name-Of-PHP-Variable: it's value to mail
message).
Second is better because it works with SMTP, too.

Opinions?






-- 
Edit this bug report at http://bugs.php.net/?id=19538&edit=1




#22055 [Com]: Memory leak with references in objects

2003-02-16 Thread adey . spam
 ID:   22055
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: RedHat 7.2
 PHP Version:  4.3.1-dev
 New Comment:

I am experiencing this problem with Win2k/IIS 5.0.

Memory usage increases until the server starts to page and crawl to a
slow death.

I have helped this somewhat by writing an app to unload the ISAPI every
half an hour, but it is still causing problems about once a week (on a
very busy site).

Still preferable to using the CGI though


Previous Comments:


[2003-02-06 08:56:47] [EMAIL PROTECTED]

You are asking me to test PHP 5,
but the bug is open for for PHP 4



[2003-02-06 08:31:39] [EMAIL PROTECTED]

You were supposed to test this snapshot:

  http://snaps.php.net/php5-latest.tar.gz



[2003-02-05 13:41:08] [EMAIL PROTECTED]

Same result with PHP Version 4.3.1-dev
php4-STABLE-200302051830.tar.gz
Build Date  Feb 5 2003 20:08:24



[2003-02-04 14:37:20] [EMAIL PROTECTED]

oops!

you need to development snapshot from snaps.php.net, which should solve
this.

Derick



[2003-02-04 14:36:48] [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



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/22055

-- 
Edit this bug report at http://bugs.php.net/?id=22055&edit=1




#3672 [Com]: httpd crashes if MySQL-support is enabled

2002-12-04 Thread no-spam
 ID:   3672
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Reproducible Crash
 Operating System: Linux Red Hat 6.1 i686/SMP
 PHP Version:  3.0.15
 New Comment:

bug occurs with and without mysql support, reason is somewhere in
getservbyname (try to compile use php's getservbyname, it crashes too!)
which is a libc item. seems to be a libc bug or something, nothing
special about php.

if you need fast help with this: go to /ext/mysql, edit php_mysql.c,
search for OnMySQLPort, and comment out 3 lines starting with the lines
"if ((serv_ptr = getservbyname..."

moritz


Previous Comments:


[2001-02-10 15:28:55] [EMAIL PROTECTED]

closing. broken packages aren't our problem.



[2000-02-29 20:34:41] [EMAIL PROTECTED]

Compiling MySQL from a source tarball (mysql-3.22.32.tar.gz) cures 
the problem.

I haven't changed status to "closed" because I think that the situation

needs to be solved somehow:
Package based system administration is _very_ important in some 
organizations (preventing massive confusion if sysadm gets a new 
job...).

I wonder why is this only a problem with PHP 3.0.15 and not 3.0.13?



[2000-02-29 19:03:57] [EMAIL PROTECTED]

Problem summary: Apache instantly crashes.

Note: No problem with PHP 3.0.13 (everything else being equal).

Base system: Red Hat 6.1.
Kernel upgraded to Red Hat Rawhide's 2.2.14-1.1.0

glibc, gd, egcs as Red Hat 6.1 default

Hardware:
i686SMP (two equally clocked CPUs)

MySQL versions tried:
3.22.30
3.22.32
(both gave segfault)

Apache-version:
apache-mod_ssl (Apache 1.3.12, modssl 2.6.0.)
openssl version 0.9.5
Ordinary (non-modssl) Apache not tried.

Starting Apache with either ("httpd" or "httpd -DSSL" makes no
difference).

PHP configure options:
--with-apxs \
--prefix=/usr \
--with-config-file-path=/etc/httpd/conf \
--with-mysql \
--with-system-regex \
--with-memory-limit \
--with-gd \
--enable-url-includes \
--with-xml

Removing "--with-mysql" cures the problem.

Compiler optimization flags tried (trouble with both sets of options):

-O3 -march=pentiumpro -mcpu=pentiumpro -malign-loops=2 -malign-jumps=2
-malign-functions=2

-O2 -m486


Backtrace:
[root@developer SPECS]# httpd -X
Segmentation fault (core dumped)
[root@developer SPECS]# gdb /usr/sbin/httpd core 
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...(no debugging symbols
found)...
Core was generated by `httpd -X'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libcrypt.so.1...done.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libnss_files.so.2...done.
Reading symbols from /usr/lib/apache/mod_mmap_static.so...done.
Reading symbols from /usr/lib/apache/mod_vhost_alias.so...done.
Reading symbols from /usr/lib/apache/mod_env.so...done.
Reading symbols from /usr/lib/apache/mod_define.so...done.
Reading symbols from /usr/lib/apache/mod_log_config.so...done.
Reading symbols from /usr/lib/apache/mod_mime_magic.so...done.
Reading symbols from /usr/lib/apache/mod_mime.so...done.
Reading symbols from /usr/lib/apache/mod_negotiation.so...done.
Reading symbols from /usr/lib/apache/mod_status.so...done.
Reading symbols from /usr/lib/apache/mod_info.so...done.
Reading symbols from /usr/lib/apache/mod_include.so...done.
Reading symbols from /usr/lib/apache/mod_autoindex.so...done.
Reading symbols from /usr/lib/apache/mod_dir.so...done.
Reading symbols from /usr/lib/apache/mod_cgi.so...done.
Reading symbols from /usr/lib/apache/mod_asis.so...done.
Reading symbols from /usr/lib/apache/mod_imap.so...done.
Reading symbols from /usr/lib/apache/mod_actions.so...done.
Reading symbols from /usr/lib/apache/mod_userdir.so...done.
Reading symbols from /usr/lib/apache/mod_alias.so...done.
Reading symbols from /usr/lib/apache/mod_rewrite.so...done.
Reading symbols from /usr/lib/apache/mod_access.so...done.
Reading symbols from /usr/lib/apache/mod_auth.so...done.
Reading symbols from /usr/lib/apache/mod_digest.so...done.
Reading symbols from /usr/lib/apache/mod_cern_meta.so...done.
Reading symbols from /

Bug #16337 Updated: include() does not decode % correctly

2002-04-10 Thread tmorgan-spam

 ID:   16337
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: HTTP related
 Operating System: Unix based
 PHP Version:  4.1.0
 New Comment:

Correction: 
 PHP's fopen url wrapper doesn't appear to unencode ANY encodings at
all.  Since the HTTP spec only excludes ':' from the username (and
nothing at all from the password), this bug makes many
username:password pairs unusable.


Previous Comments:


[2002-03-28 18:12:28] [EMAIL PROTECTED]

When include() is called with the following syntax:

include("http://username:[EMAIL PROTECTED]/";);

It is the duty of the include call to tokenize the username and
password, and to urldecode each of them.  Why?  Because things would
break if a username contained 'www.example.com/?var='  or say a
password contained an @.  So, it is the duty of the caller to urlencode
these tokens, and the duty of include (or a sub function) to unencode
it after parsing.  

However, it has been observed in PHP 4.1.x that '%' characters (or
their equivalent '%25') are not decoded properly.  Prior use of this
feature leads us to believe the 4.0.x series of PHP does not have this
problem.  

We run websites with hundreds of users.  We would appreciate a quick
response, because we would rather not force all users with '%'s in
their passwords to change them.  Thank you.




-- 
Edit this bug report at http://bugs.php.net/?id=16337&edit=1




Bug #16337 Updated: include() does not decode anything in username:password@ pairs

2002-04-10 Thread tmorgan-spam

 ID:   16337
 Updated by:   [EMAIL PROTECTED]
-Summary:  include() does not decode % correctly
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: HTTP related
 Operating System: Unix based
 PHP Version:  4.1.0
 New Comment:

in case anyone wondered, the HTTP spec I am refering to, is at:
http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2068.html
(Section 11.1)
Since RFC 2616 doesn't specify user-pass strings, I assume this older
RFC still applies.


Previous Comments:


[2002-04-10 19:57:48] [EMAIL PROTECTED]

Correction: 
 PHP's fopen url wrapper doesn't appear to unencode ANY encodings at
all.  Since the HTTP spec only excludes ':' from the username (and
nothing at all from the password), this bug makes many
username:password pairs unusable.



[2002-03-28 18:12:28] [EMAIL PROTECTED]

When include() is called with the following syntax:

include("http://username:[EMAIL PROTECTED]/";);

It is the duty of the include call to tokenize the username and
password, and to urldecode each of them.  Why?  Because things would
break if a username contained 'www.example.com/?var='  or say a
password contained an @.  So, it is the duty of the caller to urlencode
these tokens, and the duty of include (or a sub function) to unencode
it after parsing.  

However, it has been observed in PHP 4.1.x that '%' characters (or
their equivalent '%25') are not decoded properly.  Prior use of this
feature leads us to believe the 4.0.x series of PHP does not have this
problem.  

We run websites with hundreds of users.  We would appreciate a quick
response, because we would rather not force all users with '%'s in
their passwords to change them.  Thank you.




-- 
Edit this bug report at http://bugs.php.net/?id=16337&edit=1




Bug #16337 Updated: include() does not decode % correctly

2002-04-15 Thread tmorgan-spam

 ID:   16337
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: HTTP related
 Operating System: Unix based
 PHP Version:  4.1.0
 New Comment:

Ok, so I think maybe I shouldn't have brought up the HTTP spec.  The
*only* reason I did that, was that HTTP has one small limitation on
username:password pairs.  As far as I could find, in all of new and old
RFCs (including 2617) was that ':' is disallowed from the username.  I
have read of no limitations on what the password can contain.

Based on the above, I am going to make the conjecture that if the
'http://USERNAME:PASSWORD@;...' syntax in PHP can't handle certain
'special' characters, then it is broken.  

The way I was trying to use this feature was like the following:
I was trying to include some headers and footers from my *local*
webserver into my PHP script when it is displayed.  Why am I using an
URL for this??  Well, because the script that dynamically generates
those headers and footers is written in a different language.  It is a
temporary fix for me while I port code.  In any case, the
authentication realm that my PHP script lives in, is the same realm as
the headers and footers.  So, when a user hits the PHP script, the
username and password variables are stuck together into a URL like:
"http://$username:$[EMAIL PROTECTED]/header.cgi";
Then I use an include() call to grab the header.  Make sense so far?  

The problem is, PHP bombs when the user's password contains any special
characters.  More specifically, if it contains characters that are
normally considered special in URL terms.

Just suppose for a minute, that my password contains an '@'.  How is
PHP to parse this?  Should it assume that the first or last @ found is
the delimiter?  What if the username was equal to
'www.example.org/evilscript.cgi?var='?  Then we have a Cross-Site
Scripting Vulnerability on our hands.

So, my reasoning for the urlencoding was that if the user was
responsible, they would urlencode the username and password
individually, thus making the URL actually parseable in any situation. 
The only way this would work though, is if PHP unencoded those tokens
after parsing them out of the URL.  Currently it does not.  Once again,
this escaping problem is between the caller and the include() function,
not between the PHP internals and HTTP.


Previous Comments:


[2002-04-13 19:11:18] [EMAIL PROTECTED]

RFC 2068 is obsoleted by RFC 2616, so your assumption that RFC 2068 is
still adhered to is incorrect.

The username:password string is base-64 encoded for Basic
Authentication, which I'm going to assume you're using, since you
didn't mention what type of authentication the server demands for
access to http://www.example.org/. It is not URL encoded.

Now, as for your bug report, why in the world would the include
function *decode* the username:password string? The content coming back
from the server doesn't specify the username and password to be used;
that's what *you* sent.

See RFC 2617 for more information about both Basic and Digest
Authentication over HTTP. http://ietf.org/rfc/rfc2617.txt will point
you there.

I think a better understanding of this might help you solve your
problem on your own. However, if this does not help, it should at least
allow you to better explain what the problem is, because your reports
have too many holes for me to understand what problem you are having,
whether a bug in PHP or not.



[2002-04-10 20:01:07] [EMAIL PROTECTED]

in case anyone wondered, the HTTP spec I am refering to, is at:
http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2068.html
(Section 11.1)
Since RFC 2616 doesn't specify user-pass strings, I assume this older
RFC still applies.



[2002-04-10 19:57:48] [EMAIL PROTECTED]

Correction: 
 PHP's fopen url wrapper doesn't appear to unencode ANY encodings at
all.  Since the HTTP spec only excludes ':' from the username (and
nothing at all from the password), this bug makes many
username:password pairs unusable.



[2002-03-28 18:12:28] [EMAIL PROTECTED]

When include() is called with the following syntax:

include("http://username:[EMAIL PROTECTED]/";);

It is the duty of the include call to tokenize the username and
password, and to urldecode each of them.  Why?  Because things would
break if a username contained 'www.example.com/?var='  or say a
password contained an @.  So, it is the duty of the caller to urlencode
these tokens, and the duty of include (or a sub function) to unencode
it after parsing.  

However, it has been observed in PHP 4.1.x that '%' characters (or
their equivalent '%25') are not decoded properly.  Prior use of

Bug #16337 Updated: include() does not decode % correctly

2002-05-13 Thread tmorgan-spam

 ID:   16337
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: HTTP related
 Operating System: Unix based
 PHP Version:  4.1.0
 New Comment:

We are still having issues with this.  If you require any additional
explanation, or examples, I can give them.  Some indication of whether
this is being worked on or not would be nice...


Previous Comments:


[2002-05-14 00:46:32] [EMAIL PROTECTED]

Feedback was given, but status not changed. Reopening.



[2002-05-14 00:00:04] [EMAIL PROTECTED]

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2002-04-15 14:04:07] [EMAIL PROTECTED]

Ok, so I think maybe I shouldn't have brought up the HTTP spec.  The
*only* reason I did that, was that HTTP has one small limitation on
username:password pairs.  As far as I could find, in all of new and old
RFCs (including 2617) was that ':' is disallowed from the username.  I
have read of no limitations on what the password can contain.

Based on the above, I am going to make the conjecture that if the
'http://USERNAME:PASSWORD@;...' syntax in PHP can't handle certain
'special' characters, then it is broken.  

The way I was trying to use this feature was like the following:
I was trying to include some headers and footers from my *local*
webserver into my PHP script when it is displayed.  Why am I using an
URL for this??  Well, because the script that dynamically generates
those headers and footers is written in a different language.  It is a
temporary fix for me while I port code.  In any case, the
authentication realm that my PHP script lives in, is the same realm as
the headers and footers.  So, when a user hits the PHP script, the
username and password variables are stuck together into a URL like:
"http://$username:$[EMAIL PROTECTED]/header.cgi";
Then I use an include() call to grab the header.  Make sense so far?  

The problem is, PHP bombs when the user's password contains any special
characters.  More specifically, if it contains characters that are
normally considered special in URL terms.

Just suppose for a minute, that my password contains an '@'.  How is
PHP to parse this?  Should it assume that the first or last @ found is
the delimiter?  What if the username was equal to
'www.example.org/evilscript.cgi?var='?  Then we have a Cross-Site
Scripting Vulnerability on our hands.

So, my reasoning for the urlencoding was that if the user was
responsible, they would urlencode the username and password
individually, thus making the URL actually parseable in any situation. 
The only way this would work though, is if PHP unencoded those tokens
after parsing them out of the URL.  Currently it does not.  Once again,
this escaping problem is between the caller and the include() function,
not between the PHP internals and HTTP.



[2002-04-13 19:11:18] [EMAIL PROTECTED]

RFC 2068 is obsoleted by RFC 2616, so your assumption that RFC 2068 is
still adhered to is incorrect.

The username:password string is base-64 encoded for Basic
Authentication, which I'm going to assume you're using, since you
didn't mention what type of authentication the server demands for
access to http://www.example.org/. It is not URL encoded.

Now, as for your bug report, why in the world would the include
function *decode* the username:password string? The content coming back
from the server doesn't specify the username and password to be used;
that's what *you* sent.

See RFC 2617 for more information about both Basic and Digest
Authentication over HTTP. http://ietf.org/rfc/rfc2617.txt will point
you there.

I think a better understanding of this might help you solve your
problem on your own. However, if this does not help, it should at least
allow you to better explain what the problem is, because your reports
have too many holes for me to understand what problem you are having,
whether a bug in PHP or not.



[2002-04-10 20:01:07] [EMAIL PROTECTED]

in case anyone wondered, the HTTP spec I am refering to, is at:
http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2068.html
(Section 11.1)
Since RFC 2616 doesn't specify user-pass strings, I assume this older
RFC still applies.



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/16337

-- 
Edit this

Bug #16337: include() does not decode % correctly

2002-03-28 Thread tmorgan-spam

From: [EMAIL PROTECTED]
Operating system: Unix based
PHP version:  4.1.0
PHP Bug Type: HTTP related
Bug description:  include() does not decode % correctly

When include() is called with the following syntax:

include("http://username:[EMAIL PROTECTED]/";);

It is the duty of the include call to tokenize the username and password,
and to urldecode each of them.  Why?  Because things would break if a
username contained 'www.example.com/?var='  or say a password contained an
@.  So, it is the duty of the caller to urlencode these tokens, and the
duty of include (or a sub function) to unencode it after parsing.  

However, it has been observed in PHP 4.1.x that '%' characters (or their
equivalent '%25') are not decoded properly.  Prior use of this feature
leads us to believe the 4.0.x series of PHP does not have this problem.  

We run websites with hundreds of users.  We would appreciate a quick
response, because we would rather not force all users with '%'s in their
passwords to change them.  Thank you.
-- 
Edit bug report at http://bugs.php.net/?id=16337&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16337&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16337&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16337&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16337&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16337&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16337&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16337&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16337&r=submittedtwice




Bug #54404 [Com]: Imagick::cropImage segfault

2012-02-14 Thread spam at spam dot com
Edit report at https://bugs.php.net/bug.php?id=54404&edit=1

 ID: 54404
 Comment by: spam at spam dot com
 Reported by:davidjmemmett at gmail dot com
 Summary:Imagick::cropImage segfault
 Status: Not a bug
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Ubuntu 10.10
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

I confirm, I have this error too in the latest PHP 5.3.3-7+squeeze3 with 
Suhosin-
Patch (cli) (built: Jun 28 2011 08:24:40)


Previous Comments:

[2011-03-28 00:01:31] davidjmemmett at gmail dot com

I've just run this again, and gotten a different error. Code is the same.

(gdb) run test.php 
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/bin/php test.php
[Thread debugging using libthread_db enabled]
[New Thread 0xb7d6eb70 (LWP 4252)]
[Thread 0xb7d6eb70 (LWP 4252) exited]
[New Thread 0xb7d6eb70 (LWP 4253)]
[New Thread 0xb6e32b70 (LWP 4254)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6e32b70 (LWP 4254)]
0x0144e8dd in do_wait (bar=0x89f15f0, state=4)
at ../../../src/libgomp/config/linux/wait.h:53
53  ../../../src/libgomp/config/linux/wait.h: No such file or directory.
in ../../../src/libgomp/config/linux/wait.h


[2011-03-27 23:33:13] paj...@php.net

Please report imagick bugs at pecl.php.net


[2011-03-27 23:31:17] davidjmemmett at gmail dot com

Description:

Calls to Imagick::cropImage fail. I've tried the OS-shipped imagick.so and I've 
also installed it via pecl (after uninstalling the OS-shipped one).

Test script:
---
cropImage(8,8,0,0);

Expected result:

I expect no segmentation fault.

Actual result:
--
david@icecap:~/mario-images$ gdb php
GNU gdb (GDB) 7.2-ubuntu
Copyright (C) 2010 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 "i686-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/php...Reading symbols from 
/usr/lib/debug/usr/bin/php5...done.
done.
(gdb) run test.php 
Starting program: /usr/bin/php test.php
[Thread debugging using libthread_db enabled]
[New Thread 0xb7d6eb70 (LWP 3597)]
[Thread 0xb7d6eb70 (LWP 3597) exited]
[New Thread 0xb7d6eb70 (LWP 3598)]
[New Thread 0xb6e32b70 (LWP 3599)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6e32b70 (LWP 3599)]
0x0144e8da in ?? ()
(gdb)






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=54404&edit=1


Bug #54404 [Com]: Imagick::cropImage segfault

2012-02-14 Thread spam at spam dot com
Edit report at https://bugs.php.net/bug.php?id=54404&edit=1

 ID: 54404
 Comment by: spam at spam dot com
 Reported by:davidjmemmett at gmail dot com
 Summary:Imagick::cropImage segfault
 Status: Not a bug
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Ubuntu 10.10
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

This problem can be cured by setting the number of used threads to 1:

$img->setResourceLimit(6, 1); // 6 means THREAD_LIMIT (unfortunately, there is 
no 
such constant defined, so u have to use this integer value);


Previous Comments:

[2012-02-14 20:37:54] spam at spam dot com

I confirm, I have this error too in the latest PHP 5.3.3-7+squeeze3 with 
Suhosin-
Patch (cli) (built: Jun 28 2011 08:24:40)


[2011-03-28 00:01:31] davidjmemmett at gmail dot com

I've just run this again, and gotten a different error. Code is the same.

(gdb) run test.php 
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/bin/php test.php
[Thread debugging using libthread_db enabled]
[New Thread 0xb7d6eb70 (LWP 4252)]
[Thread 0xb7d6eb70 (LWP 4252) exited]
[New Thread 0xb7d6eb70 (LWP 4253)]
[New Thread 0xb6e32b70 (LWP 4254)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6e32b70 (LWP 4254)]
0x0144e8dd in do_wait (bar=0x89f15f0, state=4)
at ../../../src/libgomp/config/linux/wait.h:53
53  ../../../src/libgomp/config/linux/wait.h: No such file or directory.
in ../../../src/libgomp/config/linux/wait.h


[2011-03-27 23:33:13] paj...@php.net

Please report imagick bugs at pecl.php.net


[2011-03-27 23:31:17] davidjmemmett at gmail dot com

Description:

Calls to Imagick::cropImage fail. I've tried the OS-shipped imagick.so and I've 
also installed it via pecl (after uninstalling the OS-shipped one).

Test script:
---
cropImage(8,8,0,0);

Expected result:

I expect no segmentation fault.

Actual result:
--
david@icecap:~/mario-images$ gdb php
GNU gdb (GDB) 7.2-ubuntu
Copyright (C) 2010 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 "i686-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/php...Reading symbols from 
/usr/lib/debug/usr/bin/php5...done.
done.
(gdb) run test.php 
Starting program: /usr/bin/php test.php
[Thread debugging using libthread_db enabled]
[New Thread 0xb7d6eb70 (LWP 3597)]
[Thread 0xb7d6eb70 (LWP 3597) exited]
[New Thread 0xb7d6eb70 (LWP 3598)]
[New Thread 0xb6e32b70 (LWP 3599)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6e32b70 (LWP 3599)]
0x0144e8da in ?? ()
(gdb)






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=54404&edit=1


#19587 [NEW]: no PATH_INFO

2002-09-24 Thread michaels . php . spam

From: [EMAIL PROTECTED]
Operating system: Apache2.0.40 on Win2k pro
PHP version:  4.2.3
PHP Bug Type: Apache2 related
Bug description:  no PATH_INFO

when i enter the URL www.domain.com/dir/file.php?value=1 the script work
fine, but when i enter www.domain.com/dir/file.php/value/1 i become a 404
error.

but on win2k pro with apache 1.3.20 & php4.0.6 i did not have this
problem.

php is loaded as module.
-- 
Edit bug report at http://bugs.php.net/?id=19587&edit=1
-- 
Try a CVS snapshot:  http://bugs.php.net/fix.php?id=19587&r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19587&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19587&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=19587&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=19587&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19587&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=19587&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=19587&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=19587&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=19587&r=globals




#19587 [Opn]: no PATH_INFO

2002-09-24 Thread michaels . php . spam

 ID:   19587
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Apache2 related
 Operating System: Apache2.0.40 on Win2k pro
 PHP Version:  4.2.3
 New Comment:

PS: on the phpinfo(); i also can't find any $PATH_INFO


Previous Comments:


[2002-09-25 00:33:50] [EMAIL PROTECTED]

when i enter the URL www.domain.com/dir/file.php?value=1 the script
work fine, but when i enter www.domain.com/dir/file.php/value/1 i
become a 404 error.

but on win2k pro with apache 1.3.20 & php4.0.6 i did not have this
problem.

php is loaded as module.




-- 
Edit this bug report at http://bugs.php.net/?id=19587&edit=1




#19587 [Opn]: no $PATH_INFO by using URLs with "*.php/value" and not "*.php?value"

2002-09-26 Thread michaels . php . spam

 ID:   19587
 User updated by:  [EMAIL PROTECTED]
-Summary:  no PATH_INFO
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Apache2 related
-Operating System: Apache2.0.40 on Win2k pro
+Operating System: Apache2.0.40 on Windows 2000
 PHP Version:  4.2.3
 New Comment:

did any one know about this problem, becouse all my apps are based on
this feature, and when i using CGI files at apache2 i can use the /


Previous Comments:


[2002-09-25 00:35:31] [EMAIL PROTECTED]

PS: on the phpinfo(); i also can't find any $PATH_INFO



[2002-09-25 00:33:50] [EMAIL PROTECTED]

when i enter the URL www.domain.com/dir/file.php?value=1 the script
work fine, but when i enter www.domain.com/dir/file.php/value/1 i
become a 404 error.

but on win2k pro with apache 1.3.20 & php4.0.6 i did not have this
problem.

php is loaded as module.




-- 
Edit this bug report at http://bugs.php.net/?id=19587&edit=1




#19587 [Opn->Csd]: no $PATH_INFO by using URLs with "*.php/value" and not "*.php?value"

2002-10-07 Thread michaels . php . spam

 ID:   19587
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Apache2 related
 Operating System: Apache2.0.40 on Windows 2000
 PHP Version:  4.2.3
 New Comment:

ok here i found the solution, the AcceptPathInfo must be switched on in
apache2..

http://httpd.apache.org/docs-2.0/mod/core.html#acceptpathinfo


Previous Comments:


[2002-09-26 13:52:04] [EMAIL PROTECTED]

did any one know about this problem, becouse all my apps are based on
this feature, and when i using CGI files at apache2 i can use the /



[2002-09-25 00:35:31] [EMAIL PROTECTED]

PS: on the phpinfo(); i also can't find any $PATH_INFO



[2002-09-25 00:33:50] [EMAIL PROTECTED]

when i enter the URL www.domain.com/dir/file.php?value=1 the script
work fine, but when i enter www.domain.com/dir/file.php/value/1 i
become a 404 error.

but on win2k pro with apache 1.3.20 & php4.0.6 i did not have this
problem.

php is loaded as module.




-- 
Edit this bug report at http://bugs.php.net/?id=19587&edit=1




#19404 [Com]: phpMyAdmin does not work properly anymore

2002-10-20 Thread ck . No . Spam
 ID:   19404
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: mbstring related
 Operating System: SuSE Linux 8.0
 PHP Version:  4.2.3
 New Comment:

Hello!!

I have the same problem for phpmyadmin and php 4.2.3 such that:

There seems to be an error in your SQL query. The MySQL server error
output below, if there is any, may also help you in diagnosing the
problem

ERROR: Unclosed quote @ 58
STR: '
SQL: UPDATE `log_activity` SET `hits` = '765' WHERE `month` = \'10\'
AND `day` = \'5\' AND `year` = \'2002\' AND `hits` = \'764\' AND
`topics` = \'2\' AND `posts` = \'6\' AND `registers` = \'2\' AND
`mostOn` = \'9\' LIMIT 1;

Hata

SQL-sorgusu :  

UPDATE `log_activity` SET `hits` = '765' WHERE `month` = \'10\' AND
`day` = \'5\' AND `year` = \'2002\' AND `hits` = \'764\' AND `topics` =
\'2\' AND `posts` = \'6\' AND `registers` = \'2\' AND `mostOn` = \'9\'
LIMIT 1; 

MySQL çýktýsý: 


You have an error in your SQL syntax near '\'10\' AND `day` = \'5\' AND
`year` = \'2002\' AND `hits` = \'764\' AND `topics`' at line 1


Previous Comments:


[2002-10-16 06:05:26] [EMAIL PROTECTED]

i want to make a good forum for my homepage



[2002-10-12 10:51:56] [EMAIL PROTECTED]

This is the same issue which was reported here
http://bugs.php.net/bug.php?id=19460
I was advised to take latest PHP from CVS. I did and the problem was
solved.



[2002-09-14 11:33:54] [EMAIL PROTECTED]

Reclassify



[2002-09-14 11:32:01] [EMAIL PROTECTED]

This was a problem with mbstring that has been fixed in CVS.
The workaround is not to use --enable-mbstr-enc-trans
when configuring PHP. (You won't miss it, because the
chances are that you don't even know what it does :-)



[2002-09-14 11:19:10] [EMAIL PROTECTED]

Hm, but its a strange behaviour of PHP if the same script worked from
Version 4.0.0 up to 4.2.2 and just stopped with 4.2.3. I don't believe
this is because of the script :) Even the configuration file has been
adapeted (MagicQuoting, SafeMode, RegisterGlobals etc)



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/19404

-- 
Edit this bug report at http://bugs.php.net/?id=19404&edit=1




Bug #16417 Updated: session_id() not working

2002-04-03 Thread tonalsiren . HATES-SPAM

 ID:   16417
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Session related
 Operating System: WinXP/Win2K
 PHP Version:  4.1.1
 New Comment:

You really don't have any reason to change the session id.


Previous Comments:


[2002-04-03 18:10:21] [EMAIL PROTECTED]

Using my own session id doesn't appear to work



Causes Apache (1.3.22) to crash on Win2K/4.1.1 and produces "Warning:
Failed to write session data (files). Please verify that the current
setting of session.save_path is correct (c:\\windows\\temp) in Unknown
on line 0" on WinXP/4.2.0RC1

Without calling changing the session id, there are no problems





-- 
Edit this bug report at http://bugs.php.net/?id=16417&edit=1




#22305 [Com]: Compile Fails - OpenSSL Related

2003-02-19 Thread spam at digitalstreams dot net
 ID:   22305
 Comment by:   spam at digitalstreams dot net
 Reported By:  dave at socrates dot thinkhost dot com
 Status:   Open
 Bug Type: Compile Failure
 Operating System: FreeBSD 4.7-RELEASE-p2
 PHP Version:  4.3.1
 New Comment:

This is also occuring on slackware 8.1 with openssl 0.9.7a!

ext/openssl/openssl.o: In function `zm_startup_openssl':
/root/apps/installed/ssl+php/php-4.3.1/ext/openssl/openssl.c:541:
undefined reference to `OPENSSL_add_all_algorithms_noconf'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

This is against a 4.3.1 php.


Previous Comments:


[2003-02-19 15:44:49] dave at socrates dot thinkhost dot com

I just updated OpenSSL to 0.9.7a, and then after that I attempted to
build the latest PHP-4.3.1. The configuration script completes without
error, however, during the compile it dies in the following fatel
error:

ext/openssl/openssl.lo: In function `zm_startup_openssl':
/usr/local/src/php-4.3.1/ext/openssl/openssl.c(.text+0xb69): undefined
reference to `OPENSSL_add_all_algorithms_noconf'
*** Error code 1

Stop in /usr/local/src/php-4.3.1.

Any idea how to fix this?




-- 
Edit this bug report at http://bugs.php.net/?id=22305&edit=1




#26381 [NEW]: rand() without srand() doesn't work

2003-11-24 Thread spam at vrana dot cz
From: spam at vrana dot cz
Operating system: Windows XP
PHP version:  4.3.3
PHP Bug Type: Math related
Bug description:  rand() without srand() doesn't work

Description:

Function rand() without setting random seed by srand() returns always the
same value. It doesn't work only on Windows PHP-CLI. As Windows Apache
module and also on Linux PHP-CLI it works as it should.

Reproduce code:
---
echo rand();

Expected result:

(random value)

Actual result:
--
24849

-- 
Edit bug report at http://bugs.php.net/?id=26381&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=26381&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=26381&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=26381&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=26381&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26381&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=26381&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26381&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=26381&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26381&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26381&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=26381&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26381&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=26381&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=26381&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26381&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26381&r=float


#26381 [Bgs->Opn]: rand() without srand() doesn't work

2003-11-25 Thread spam at vrana dot cz
 ID:   26381
 User updated by:  spam at vrana dot cz
 Reported By:  spam at vrana dot cz
-Status:   Bogus
+Status:   Open
 Bug Type: Math related
 Operating System: Windows XP
 PHP Version:  4.3.3
 New Comment:

So this is a documentation problem because in rand() function
documentation is written:

As of PHP 4.2.0, there is no need to seed the random number generator
with srand() or mt_srand() as this is now done automatically.

Anyway, I think it's not a documentation bug because in other
environments it works as stated.


Previous Comments:


[2003-11-24 20:01:53] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

if you want trully random numbers you MUST call srand before rand().



[2003-11-24 08:21:33] spam at vrana dot cz

Description:

Function rand() without setting random seed by srand() returns always
the same value. It doesn't work only on Windows PHP-CLI. As Windows
Apache module and also on Linux PHP-CLI it works as it should.

Reproduce code:
---
echo rand();

Expected result:

(random value)

Actual result:
--
24849





-- 
Edit this bug report at http://bugs.php.net/?id=26381&edit=1


#26381 [Fbk->Opn]: rand() without srand() doesn't work

2003-11-25 Thread spam at vrana dot cz
 ID:   26381
 User updated by:  spam at vrana dot cz
 Reported By:  spam at vrana dot cz
-Status:   Feedback
+Status:   Open
 Bug Type: Math related
 Operating System: Windows XP
 PHP Version:  4.3.3
 New Comment:

Unfortunately it behaves the same with Windows snapshots.

For case it's not obvious from my fist comment - if I call srand()
before rand() it works well.


Previous Comments:


[2003-11-25 04:24:32] [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

Works fine for me within Windows XP, within Apache and CLI.




[2003-11-24 08:21:33] spam at vrana dot cz

Description:

Function rand() without setting random seed by srand() returns always
the same value. It doesn't work only on Windows PHP-CLI. As Windows
Apache module and also on Linux PHP-CLI it works as it should.

Reproduce code:
---
echo rand();

Expected result:

(random value)

Actual result:
--
24849





-- 
Edit this bug report at http://bugs.php.net/?id=26381&edit=1


#26381 [Bgs->Opn]: rand() without srand() doesn't work

2003-11-25 Thread spam at vrana dot cz
 ID:   26381
 User updated by:  spam at vrana dot cz
 Reported By:  spam at vrana dot cz
-Status:   Bogus
+Status:   Open
 Bug Type: Math related
 Operating System: Windows XP
 PHP Version:  4.3.3
 New Comment:

iliaa, please read the manual yourself before stating bugs as bogus. As
I already wrote here, the manual says:

As of PHP 4.2.0, there is no need to seed the random number generator
with srand() or mt_srand() as this is now done automatically.


Previous Comments:


[2003-11-25 08:41:49] [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

For random numbers you MUST call srand() before rand().



[2003-11-25 04:53:44] spam at vrana dot cz

Unfortunately it behaves the same with Windows snapshots.

For case it's not obvious from my fist comment - if I call srand()
before rand() it works well.



[2003-11-25 04:24:32] [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

Works fine for me within Windows XP, within Apache and CLI.




[2003-11-24 08:21:33] spam at vrana dot cz

Description:

Function rand() without setting random seed by srand() returns always
the same value. It doesn't work only on Windows PHP-CLI. As Windows
Apache module and also on Linux PHP-CLI it works as it should.

Reproduce code:
---
echo rand();

Expected result:

(random value)

Actual result:
--
24849





-- 
Edit this bug report at http://bugs.php.net/?id=26381&edit=1


#26381 [Opn]: rand() without srand() doesn't work

2003-11-28 Thread spam at vrana dot cz
 ID:   26381
 User updated by:  spam at vrana dot cz
 Reported By:  spam at vrana dot cz
 Status:   Open
-Bug Type: Documentation problem
+Bug Type: Math related
 Operating System: Windows XP
 PHP Version:  4.3.3
 New Comment:

The behavior of rand() really changed in PHP 4.2.0, it is stated in
Changelog. The documentation is correct. And there is coded this
feature in source codes (php-src/ext/standard/rand.c, line 327 in
current CVS). I don't know where the problem is, I don't understand PHP
internals. I can only see that there is global variable rand_is_seeded
set on line 58 and checked on line 326. Maybe the problem is that this
variable wasn't initialized. I'm just guessing because as I wrote, I
don't understand PHP internals.


Previous Comments:


[2003-11-25 08:57:29] [EMAIL PROTECTED]

Manual is wrong.

----

[2003-11-25 08:46:41] spam at vrana dot cz

iliaa, please read the manual yourself before stating bugs as bogus. As
I already wrote here, the manual says:

As of PHP 4.2.0, there is no need to seed the random number generator
with srand() or mt_srand() as this is now done automatically.



[2003-11-25 08:41:49] [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

For random numbers you MUST call srand() before rand().

----

[2003-11-25 04:53:44] spam at vrana dot cz

Unfortunately it behaves the same with Windows snapshots.

For case it's not obvious from my fist comment - if I call srand()
before rand() it works well.



[2003-11-25 04:24:32] [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

Works fine for me within Windows XP, within Apache and CLI.




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/26381

-- 
Edit this bug report at http://bugs.php.net/?id=26381&edit=1


#26381 [Opn]: rand() without srand() doesn't work with certain php.ini

2003-12-02 Thread spam at vrana dot cz
 ID:   26381
 User updated by:  spam at vrana dot cz
-Summary:  rand() without srand() doesn't work
 Reported By:  spam at vrana dot cz
 Status:   Open
-Bug Type: Documentation problem
+Bug Type: Scripting Engine problem
 Operating System: Windows XP
 PHP Version:  4.3.3
 New Comment:

I can't believe myself, the problem is caused by something completely
different. I discovered that the problem occurs only under this
circumstances:

1. Lines in php.ini file ends by CRLF.

2. Windows Extensions part in php.ini is longer than 503 characters
(including new-lines).

I don't know what is it but it looks like buffer overflow or something
like that. So the problem is probably in   php-src/main/php_ini.c or
somewhere near.


Previous Comments:


[2003-12-02 10:22:37] nunoplopes at sapo dot pt

This bug is solved!

I have the latest windows snapshot on windows xp and cli returns a
random value without the need to use srand.



[2003-11-28 04:26:47] spam at vrana dot cz

The behavior of rand() really changed in PHP 4.2.0, it is stated in
Changelog. The documentation is correct. And there is coded this
feature in source codes (php-src/ext/standard/rand.c, line 327 in
current CVS). I don't know where the problem is, I don't understand PHP
internals. I can only see that there is global variable rand_is_seeded
set on line 58 and checked on line 326. Maybe the problem is that this
variable wasn't initialized. I'm just guessing because as I wrote, I
don't understand PHP internals.



[2003-11-25 08:57:29] [EMAIL PROTECTED]

Manual is wrong.



[2003-11-25 08:46:41] spam at vrana dot cz

iliaa, please read the manual yourself before stating bugs as bogus. As
I already wrote here, the manual says:

As of PHP 4.2.0, there is no need to seed the random number generator
with srand() or mt_srand() as this is now done automatically.



[2003-11-25 08:41:49] [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

For random numbers you MUST call srand() before rand().



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/26381

-- 
Edit this bug report at http://bugs.php.net/?id=26381&edit=1


#26381 [Fbk->Opn]: rand() without srand() doesn't work with certain php.ini

2003-12-02 Thread spam at vrana dot cz
 ID:   26381
 User updated by:  spam at vrana dot cz
 Reported By:  spam at vrana dot cz
-Status:   Feedback
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Windows XP
-PHP Version:  4.3.3
+PHP Version:  4.3.5-dev
 New Comment:

Yes. The problem occurs also with CVS snapshot.


Previous Comments:


[2003-12-02 11:04:40] [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-12-02 10:57:15] spam at vrana dot cz

I can't believe myself, the problem is caused by something completely
different. I discovered that the problem occurs only under this
circumstances:

1. Lines in php.ini file ends by CRLF.

2. Windows Extensions part in php.ini is longer than 503 characters
(including new-lines).

I don't know what is it but it looks like buffer overflow or something
like that. So the problem is probably in   php-src/main/php_ini.c or
somewhere near.



[2003-12-02 10:22:37] nunoplopes at sapo dot pt

This bug is solved!

I have the latest windows snapshot on windows xp and cli returns a
random value without the need to use srand.



[2003-11-28 04:26:47] spam at vrana dot cz

The behavior of rand() really changed in PHP 4.2.0, it is stated in
Changelog. The documentation is correct. And there is coded this
feature in source codes (php-src/ext/standard/rand.c, line 327 in
current CVS). I don't know where the problem is, I don't understand PHP
internals. I can only see that there is global variable rand_is_seeded
set on line 58 and checked on line 326. Maybe the problem is that this
variable wasn't initialized. I'm just guessing because as I wrote, I
don't understand PHP internals.



[2003-11-25 08:57:29] [EMAIL PROTECTED]

Manual is wrong.



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/26381

-- 
Edit this bug report at http://bugs.php.net/?id=26381&edit=1


#26381 [Fbk->Opn]: rand() without srand() doesn't work with certain php.ini

2003-12-02 Thread spam at vrana dot cz
 ID:   26381
 User updated by:  spam at vrana dot cz
 Reported By:  spam at vrana dot cz
-Status:   Feedback
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Windows XP
 PHP Version:  4CVS-2003-12-2
 New Comment:

Everything is written on http://bugs.php.net/?id=26381.

It seems that by some problem in processing php.ini is caused that
"rand() without srand() doesn't work". It's most probably only
side-effect of something wrong (like buffer-overflow).


Previous Comments:


[2003-12-02 12:51:13] [EMAIL PROTECTED]

What problem?
How can we reproduce this?




[2003-12-02 11:18:28] spam at vrana dot cz

Yes. The problem occurs also with CVS snapshot.



[2003-12-02 11:04:40] [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-12-02 10:57:15] spam at vrana dot cz

I can't believe myself, the problem is caused by something completely
different. I discovered that the problem occurs only under this
circumstances:

1. Lines in php.ini file ends by CRLF.

2. Windows Extensions part in php.ini is longer than 503 characters
(including new-lines).

I don't know what is it but it looks like buffer overflow or something
like that. So the problem is probably in   php-src/main/php_ini.c or
somewhere near.



[2003-12-02 10:22:37] nunoplopes at sapo dot pt

This bug is solved!

I have the latest windows snapshot on windows xp and cli returns a
random value without the need to use srand.



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/26381

-- 
Edit this bug report at http://bugs.php.net/?id=26381&edit=1


#26381 [Fbk->Opn]: rand() without srand() doesn't work with certain php.ini

2003-12-02 Thread spam at vrana dot cz
 ID:   26381
 User updated by:  spam at vrana dot cz
 Reported By:  spam at vrana dot cz
-Status:   Feedback
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Windows XP
 PHP Version:  4CVS-2003-12-2
 New Comment:

I really don't know which additional information you need. Can you tell
me?

I described the wrong behaviour on 24 Nov 8:21am EST.

I found that the wrong behaviour is most probably bounded with
processing of php.ini and described it on 2 Dec 10:57am EST.

I tested everything on CVS snapshot on 25 Nov 4:53am EST and on 2 Dec
11:18am EST with the same result.

I want to give you all information which you need to fix this bug but I
don't know about anything what wasn't already written here.


Previous Comments:


[2003-12-02 14:28:31] [EMAIL PROTECTED]

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.




----

[2003-12-02 13:10:29] spam at vrana dot cz

Everything is written on http://bugs.php.net/?id=26381.

It seems that by some problem in processing php.ini is caused that
"rand() without srand() doesn't work". It's most probably only
side-effect of something wrong (like buffer-overflow).



[2003-12-02 12:51:13] [EMAIL PROTECTED]

What problem?
How can we reproduce this?


----

[2003-12-02 11:18:28] spam at vrana dot cz

Yes. The problem occurs also with CVS snapshot.



[2003-12-02 11:04:40] [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





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/26381

-- 
Edit this bug report at http://bugs.php.net/?id=26381&edit=1


#26381 [Fbk->Opn]: rand() without srand() doesn't work with certain php.ini

2003-12-03 Thread spam at vrana dot cz
 ID:   26381
 User updated by:  spam at vrana dot cz
 Reported By:  spam at vrana dot cz
-Status:   Feedback
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Windows XP
 PHP Version:  4CVS-2003-12-2
 New Comment:

It behaves like that with php.ini-dist. It doesn't with
php.ini-recommended. If I remove part Dynamic Extensions in
php.ini-dist, it disappears. I mean part from

;;
; Dynamic Extensions ;
;;

to

;;;
; Module Settings ;
;;;

You know that everything is commented in this part in php.ini-dist.


Previous Comments:


[2003-12-02 17:11:37] [EMAIL PROTECTED]

We need the php.ini file causing the problems.




[2003-12-02 10:57:15] spam at vrana dot cz

I can't believe myself, the problem is caused by something completely
different. I discovered that the problem occurs only under this
circumstances:

1. Lines in php.ini file ends by CRLF.

2. Windows Extensions part in php.ini is longer than 503 characters
(including new-lines).

I don't know what is it but it looks like buffer overflow or something
like that. So the problem is probably in   php-src/main/php_ini.c or
somewhere near.



[2003-11-24 08:21:33] spam at vrana dot cz

Description:

Function rand() without setting random seed by srand() returns always
the same value. It doesn't work only on Windows PHP-CLI. As Windows
Apache module and also on Linux PHP-CLI it works as it should.

Reproduce code:
---
echo rand();

Expected result:

(random value)

Actual result:
--
24849





-- 
Edit this bug report at http://bugs.php.net/?id=26381&edit=1


#25703 [Com]: openssl Library not found

2003-12-16 Thread spam at doofer dot org
 ID:   25703
 Comment by:   spam at doofer dot org
 Reported By:  phpnet at wspse dot de
 Status:   Closed
 Bug Type: *Configuration Issues
 Operating System: Redhat Linux 7.3
 PHP Version:  4.3.4RC1
 New Comment:

For anyone else arriving at this page in the hope of information,
simply leaving the config directive at '--with-openssl' instead of
'--with-openssl=' works great on the same system that I
was experiencing this problem on. So, just one other thing to try in
case you have this error.


Previous Comments:


[2003-12-10 09:09:03] x-itec at freenet dot de

I copied /usr/lib/libopenssl* /usr/local/lib/

that works for me. Maybe u should add /usr/lib for search-path in
configure script?



[2003-12-10 08:58:43] x-itec at freenet dot de

./configure will not succeed on SuSe 8.1 ifopenssl is enabled (I have
installed the latest available version)


Configuring extensions
checking for OpenSSL support... yes
checking for pkg-config... no
configure: error: Cannot find OpenSSL's libraries
make: *** No targets specified and no makefile found.  Stop.



[2003-11-20 16:39:50] Greg dot Kresko at nrc-cnrc dot gc dot ca

(My apologies if this should be posted to a discussion list.)

This is still broken in the source code (4.3.4 downloaded
on 07 Nov 2003).
On IRIX 6.5.21f, using gcc 3.3.2, using openssl-0.9.7c:
-
./configure --prefix=/usr/local/apache --with-mysql
--with-apxs=/usr/local/apache/bin/apxs --with-openssl=../openssl-0.9.7c
--with-mm=../mm-1.3.0
-
ends with
-
Configuring extensions
checking for OpenSSL support... yes
checking for pkg-config... no
configure: error: Cannot find OpenSSL's libraries
-
I have "setenv LDFLAGS -L/usr/local/ssl/lib".

(The openssl installation completes with
-
cp openssl.pc /usr/local/ssl/lib/pkgconfig
chmod 644 /usr/local/ssl/lib/pkgconfig
-
Why "644"?  This makes it hard for non-roots to access.
Configuring as root or changing to "755" doesn't help.)



[2003-09-30 14:06:46] [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-09-30 10:57:12] phpnet at wspse dot de

Description:

./configure will not succeed on Redhat 7.3 if openssl is enabled (the
shipped openssl-rpm [0.9.6b] does not include a pkgconfig-file).

This became broken in 4.3.4RC1 (4.3.3 worked fine). I quick checked
that the config-script was changed to use pkg-config for detecting the
library. I could fix it by copying the openssl.pc-file from redhat 9.0
and editing the version information in it.

However, since that file is not there in RH7.3 you should either use
the old behavior or document it and saying how to fix it.






-- 
Edit this bug report at http://bugs.php.net/?id=25703&edit=1


#22083 [Csd]: php-cli MySQL charset problem

2004-01-02 Thread spam at vrana dot cz
 ID:   22083
 User updated by:  spam at vrana dot cz
 Reported By:  spam at vrana dot cz
 Status:   Closed
 Bug Type: MySQL related
 Operating System: Windows
 PHP Version:  4.3.0
 New Comment:

It's OK in 4.3.4. my.ini is still ignored, but there are no double
backslash.


Previous Comments:


[2004-01-02 12:31:37] selfman at netax dot sk

The bug reappears in PHP 4.3.4 Win32 ISAPI Module for apache.



[2003-03-27 07:29:35] [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-02-05 15:52:19] spam at vrana dot cz

When I set default-character-set=win1250 in my.ini, php-cli says:

File 'c:\mysql\\share\charsets\?.conf' not found (Errcode: 2)
Character set '#26' is not a compiled character set and is not
specified in the 'c:\mysql\\share\charsets\Index' file

The problem is, that php-cli ignores character-sets-dir= in my.ini and
uses its own hard-coded path c:\mysql\. If I move the share\charsets\
directory into c:\mysql\, the problem is still here because there are
two backslashes in path, where php-cli tries to find it.

When I hexa edited php4ts.dll and change c:/mysql/ to c:/mysql3 and
move share\charsets\ directory there, everything is working.

Solution:
1. Change the default path for finding charsets from "c:/mysql/" to
"c:/mysql"
2. If possible, read character-sets-dir= from C:\Windows\my.ini.





-- 
Edit this bug report at http://bugs.php.net/?id=22083&edit=1


#22605 [Com]: session_start() generates headers

2004-01-12 Thread dont at like dot spam
 ID:   22605
 Comment by:   dont at like dot spam
 Reported By:  johnpage at ipng dot net
 Status:   Bogus
 Bug Type: Session related
 Operating System: Yahoo (Unix)
 PHP Version:  5CVS-2003-03-08 (dev)
 New Comment:

Instead of telling him its not your problem while misunderstanding what
he is saying you could try to help him. He was trying to say that he
cannot upgrade and he has that problem. He is not asking you to make
yahoo upgrade their servers.

Maybe its not a bug but he certainly wasn't asking about an upgrage. He
was asking about a problem. 

If i got such an reaction from a company of which i was paying a client
and find another one. Unless there isn't any choice of course :) 

bottom line.. a bit nicer service wouldn't hurt. Or what about a forum
to post your questions on. Then several users could determine a problem
as a bug bofore submitting it.


Previous Comments:


[2003-03-08 10:03:45] [EMAIL PROTECTED]

There's no use to report this here either.
It's not our problem if your hosting site has old PHP version.




[2003-03-08 04:16:14] johnpage at ipng dot net



Does not work on the Yahoo web hosting.
The session_start() generates a full set of headers.
They are running PHP 4.1.2 ( I am not able to force an upgrade at Yahoo
!!)on Apache/1.3.26 (Unix) 

phpinfo() does not report any details for the OS.




-- 
Edit this bug report at http://bugs.php.net/?id=22605&edit=1


#26937 [NEW]: Warning in xml.c

2004-01-16 Thread spam at pasher dot org
From: spam at pasher dot org
Operating system: Debian Linux 2.4.20
PHP version:  4.3.5RC1
PHP Bug Type: Compile Warning
Bug description:  Warning in xml.c

Description:

When compiling PHP (even as of 4.3.5RC1), it outputs the following
warning:
/php-4.3.5RC1/ext/xml/xml.c: In function `xml_utf8_encode': 
/php-4.3.5RC1/ext/xml/xml.c:489: warning: comparison is always true due to
limited range of data type 
/php-4.3.5RC1/ext/xml/xml.c:493: warning: comparison is always true due to
limited range of data type

It looks like the variable in question (c) is declared as unsigned short.
It is later being compared to 0x1 and 0x20, which is two large for
a short.

I would assume an unsigned int would be enough.


-- 
Edit bug report at http://bugs.php.net/?id=26937&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=26937&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=26937&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=26937&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=26937&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26937&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=26937&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=26937&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26937&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=26937&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26937&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26937&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=26937&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26937&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=26937&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=26937&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26937&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26937&r=float


#26381 [Csd]: rand() without srand() doesn't work with certain php.ini

2004-01-20 Thread spam at vrana dot cz
 ID:   26381
 User updated by:  spam at vrana dot cz
 Reported By:  spam at vrana dot cz
 Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: win32 only
 PHP Version:  4CVS-2003-12-7
 New Comment:

I'm curious where the problem was. Can you please tell me?


Previous Comments:


[2004-01-19 14:04:45] [EMAIL PROTECTED]

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.





[2003-12-07 13:54:15] [EMAIL PROTECTED]

Indeed, this does happen with the php.ini-dist..
but doesn't if you do 'php -n' (no ini file)




[2003-12-03 03:31:52] spam at vrana dot cz

It behaves like that with php.ini-dist. It doesn't with
php.ini-recommended. If I remove part Dynamic Extensions in
php.ini-dist, it disappears. I mean part from

;;
; Dynamic Extensions ;
;;

to

;;;
; Module Settings ;
;;;

You know that everything is commented in this part in php.ini-dist.



[2003-12-02 17:11:37] [EMAIL PROTECTED]

We need the php.ini file causing the problems.


----

[2003-12-02 10:57:15] spam at vrana dot cz

I can't believe myself, the problem is caused by something completely
different. I discovered that the problem occurs only under this
circumstances:

1. Lines in php.ini file ends by CRLF.

2. Windows Extensions part in php.ini is longer than 503 characters
(including new-lines).

I don't know what is it but it looks like buffer overflow or something
like that. So the problem is probably in   php-src/main/php_ini.c or
somewhere near.



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/26381

-- 
Edit this bug report at http://bugs.php.net/?id=26381&edit=1


#22083 [Com]: php-cli MySQL charset problem

2004-02-09 Thread spam at eMeidi dot com
 ID:   22083
 Comment by:   spam at eMeidi dot com
 Reported By:  spam at vrana dot cz
 Status:   Closed
 Bug Type: MySQL related
 Operating System: Windows
 PHP Version:  4.3.0
 New Comment:

This error persists in 4.3.4-dev.


Previous Comments:


[2004-01-04 17:02:35] selfman at netax dot sk

My APACHE error log is full of this:
File 'c:\mysql\share\charsets\?.conf' not found (Errcode: 2)
Character set '#26' is not a compiled character set and is not
specified in the 'c:\mysql\share\charsets\Index' file

The mysql is not located in the default directory.
I am using the my.cnf to configure the mysql deamon.

[mysqld]
port=3306
skip-locking
set-variable = key_buffer=16M
set-variable = lower_case_table_names=0
set-variable = max_allowed_packet=1M
set-variable = thread_stack=128K
set-variable = flush_time=1800
default-character-set=win1250
skip-innodb
basedir = C:/WWW/MySQL/

----

[2004-01-02 12:39:21] spam at vrana dot cz

It's OK in 4.3.4. my.ini is still ignored, but there are no double
backslash.



[2004-01-02 12:31:37] selfman at netax dot sk

The bug reappears in PHP 4.3.4 Win32 ISAPI Module for apache.



[2003-03-27 07:29:35] [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-02-05 15:52:19] spam at vrana dot cz

When I set default-character-set=win1250 in my.ini, php-cli says:

File 'c:\mysql\\share\charsets\?.conf' not found (Errcode: 2)
Character set '#26' is not a compiled character set and is not
specified in the 'c:\mysql\\share\charsets\Index' file

The problem is, that php-cli ignores character-sets-dir= in my.ini and
uses its own hard-coded path c:\mysql\. If I move the share\charsets\
directory into c:\mysql\, the problem is still here because there are
two backslashes in path, where php-cli tries to find it.

When I hexa edited php4ts.dll and change c:/mysql/ to c:/mysql3 and
move share\charsets\ directory there, everything is working.

Solution:
1. Change the default path for finding charsets from "c:/mysql/" to
"c:/mysql"
2. If possible, read character-sets-dir= from C:\Windows\my.ini.





-- 
Edit this bug report at http://bugs.php.net/?id=22083&edit=1


#27198 [NEW]: 'Charset not found'-warning when using CGI

2004-02-09 Thread spam at eMeidi dot com
From: spam at eMeidi dot com
Operating system: Windows 2003
PHP version:  4.3.5RC2
PHP Bug Type: MySQL related
Bug description:  'Charset not found'-warning when using CGI

Description:

PHP doesn't parse C:\WINDOWS\my.ini, where charset informations would have
been specified for the current webserver. Instead, it tries to locate them
somewhere in C:\MySQL\ ... - seems to be hardcoded. It would make more
sense to look after C:\WINDOWS\my.ini, and only afterwards trying to hit
the charsets directly.

Output while running php.exe when having MySQL-function calls in
PHP-Script:

File 'c:\mysql\share\charsets\?.conf' not found (Errcode: 2)
Character set '#5' is not a compiled character set and is not specified in
the 'c:\mysql\share\charsets\Index' file

Reproduce code:
---
$res_db_conn =
mysql_connect($arr_user_data[0],$arr_user_data[1],$arr_user_data[2]);

Expected result:

File 'c:\mysql\share\charsets\?.conf' not found (Errcode: 2)
Character set '#5' is not a compiled character set and is not specified in
the 'c:\mysql\share\charsets\Index' file

Except of this warning (and a disgusting beep), everything works out fine.
Very bad when running cron-jobs ;-)


-- 
Edit bug report at http://bugs.php.net/?id=27198&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=27198&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=27198&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=27198&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=27198&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27198&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=27198&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=27198&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27198&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=27198&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27198&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27198&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=27198&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27198&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=27198&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=27198&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27198&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27198&r=float


#22083 [Csd]: php-cli MySQL charset problem

2004-02-10 Thread spam at vrana dot cz
 ID:   22083
 User updated by:  spam at vrana dot cz
 Reported By:  spam at vrana dot cz
 Status:   Closed
 Bug Type: MySQL related
 Operating System: Windows
 PHP Version:  4.3.0
 New Comment:

my.ini is still ignored - it will not be fixed. You must have charsets
directory in c:\mysql\share\charsets.


Previous Comments:


[2004-01-04 17:02:35] selfman at netax dot sk

My APACHE error log is full of this:
File 'c:\mysql\share\charsets\?.conf' not found (Errcode: 2)
Character set '#26' is not a compiled character set and is not
specified in the 'c:\mysql\share\charsets\Index' file

The mysql is not located in the default directory.
I am using the my.cnf to configure the mysql deamon.

[mysqld]
port=3306
skip-locking
set-variable = key_buffer=16M
set-variable = lower_case_table_names=0
set-variable = max_allowed_packet=1M
set-variable = thread_stack=128K
set-variable = flush_time=1800
default-character-set=win1250
skip-innodb
basedir = C:/WWW/MySQL/

----

[2004-01-02 12:39:21] spam at vrana dot cz

It's OK in 4.3.4. my.ini is still ignored, but there are no double
backslash.



[2004-01-02 12:31:37] selfman at netax dot sk

The bug reappears in PHP 4.3.4 Win32 ISAPI Module for apache.



[2003-03-27 07:29:35] [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-02-05 15:52:19] spam at vrana dot cz

When I set default-character-set=win1250 in my.ini, php-cli says:

File 'c:\mysql\\share\charsets\?.conf' not found (Errcode: 2)
Character set '#26' is not a compiled character set and is not
specified in the 'c:\mysql\\share\charsets\Index' file

The problem is, that php-cli ignores character-sets-dir= in my.ini and
uses its own hard-coded path c:\mysql\. If I move the share\charsets\
directory into c:\mysql\, the problem is still here because there are
two backslashes in path, where php-cli tries to find it.

When I hexa edited php4ts.dll and change c:/mysql/ to c:/mysql3 and
move share\charsets\ directory there, everything is working.

Solution:
1. Change the default path for finding charsets from "c:/mysql/" to
"c:/mysql"
2. If possible, read character-sets-dir= from C:\Windows\my.ini.





-- 
Edit this bug report at http://bugs.php.net/?id=22083&edit=1


#24054 [NEW]: Assignment Operateors (*=)

2003-06-06 Thread spam at oops dot org
From: spam at oops dot org
Operating system: Linux
PHP version:  4.3.2
PHP Bug Type: Scripting Engine problem
Bug description:  Assignment Operateors (*=)

4.3.2 has assignment operateors problem.



upper code returns "1421485473408".

but



upper code is success return "1001000".

*= operator has not always problem.

if about bigger than 10, problem is occured. :-)

P.S
sorry for my poor english.
-- 
Edit bug report at http://bugs.php.net/?id=24054&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24054&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=24054&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=24054&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24054&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=24054&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24054&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=24054&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24054&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24054&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=24054&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24054&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=24054&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=24054&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24054&r=gnused



#24054 [Csd]: Assignment Operateors (*=)

2003-06-06 Thread spam at oops dot org
 ID:   24054
 User updated by:  spam at oops dot org
 Reported By:  spam at oops dot org
 Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  4.3.2
 New Comment:

I want patch to solve this problem on 4.3.2 :-)


Previous Comments:


[2003-06-06 06:49:33] [EMAIL PROTECTED]

Fixed in CVS



[2003-06-06 06:10:42] [EMAIL PROTECTED]

PHP 4.2.3:
---
float(1001000)
float(1001000)

PHP 4.3.1:
--
float(1.001E+10)
float(1.001E+10)

PHP 4.3.2:
--
float(1421485473408)
float(1.001E+10)

I've added a test case for this and this has to be fixed before 4.3.3.





[2003-06-06 05:20:57] [EMAIL PROTECTED]

It seems that something goes wrong when casting to float on integer
overflow.

$ php -r '$i=1000; $i*=1001; var_dump($i);'
float(1421485473408)

$ php -r '$i=1000*1001; var_dump$i);'   
float(1.001E+10)

----

[2003-06-06 04:25:26] spam at oops dot org

4.3.2 has assignment operateors problem.



upper code returns "1421485473408".

but



upper code is success return "1001000".

*= operator has not always problem.

if about bigger than 10, problem is occured. :-)

P.S
sorry for my poor english.




-- 
Edit this bug report at http://bugs.php.net/?id=24054&edit=1



#33088 [NEW]: Output Buffering + Callback method = unable to change object properties

2005-05-20 Thread spam at cimmanon dot org
From: spam at cimmanon dot org
Operating system: OpenBSD
PHP version:  4.3.11
PHP Bug Type: Output Control
Bug description:  Output Buffering + Callback method = unable to change object 
properties

Description:

For some reason output buffering inside a callback method prevents an
object's properties from being modified outside of the object.  Using
output buffering without a callback works as expected, though.

Reproduce code:
---
var = 'rar';
print 'foo started';
ob_start(array(&$this, 'bar'));
}

function bar() {
print $this->var . "";
$this->var = 'asdf';
print $this->var;
}
}

$foo = new foo;
$foo->var = 'rarar';
?>

Expected result:

I expected $foo->var to be set to 'rarar' after the initial object
creation via constructor, then 'asdf'.  Instead, it remains set to 'rar',
then 'asdf'.


-- 
Edit bug report at http://bugs.php.net/?id=33088&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=33088&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=33088&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=33088&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33088&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33088&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=33088&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=33088&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=33088&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33088&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=33088&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=33088&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=33088&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33088&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=33088&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33088&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=33088&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33088&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=33088&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=33088&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=33088&r=mysqlcfg


#33088 [Fbk->Opn]: Output Buffering + Callback method = unable to change object properties

2005-05-22 Thread spam at cimmanon dot org
 ID:   33088
 User updated by:  spam at cimmanon dot org
 Reported By:  spam at cimmanon dot org
-Status:   Feedback
+Status:   Open
 Bug Type: Output Control
 Operating System: OpenBSD
 PHP Version:  4.3.11
 New Comment:

In the constructor, $this->var gets set to 'rar'.  Output buffering is
started using foo::bar as the callback.  I attempt to set $this->var to
'rarar' from outside of the object, which fails because of the output
buffering callback method.  The script finishes executing and the
callback method is executed, prints $this->var (which is supposed to be
set to 'rarar' at this point, but is still just 'rar'), sets $this->var
to 'asdf' (successfully), then prints $this->var yet again.

If I attempt to print $foo->var right after I modify it on line #20, it
displays exactly what I expect:  'rarar'.

This problem does not exist if I use a callback that is a function, nor
does it happen if I start output buffering without a callback and just
manually call foo::bar() at the end of the script.  Also, PHP 5 doesn't
have this problem, for whatever reason, and performs exactly as I
expect.

PHP 5.0.4:
http://www.sketchdiary.com/testcases/buffertest.php
http://www.sketchdiary.com/testcases/viewsource.php?file=buffertest.php

Modified source (forgot 1 line):
var = 'rar';
print 'foo started';
ob_start(array(&$this, 'bar'));
}

function bar() {
print $this->var . "";
$this->var = 'asdf';
print $this->var;
return ob_get_contents(); // missing line from example
}
}

$foo = new foo;
$foo->var = 'rarar';
?>


Previous Comments:


[2005-05-22 15:34:39] [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 ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.

Please provide a more real-life example with expected and actual
results.



[2005-05-21 02:10:51] spam at cimmanon dot org

Description:

For some reason output buffering inside a callback method prevents an
object's properties from being modified outside of the object.  Using
output buffering without a callback works as expected, though.

Reproduce code:
---
var = 'rar';
print 'foo started';
ob_start(array(&$this, 'bar'));
}

function bar() {
print $this->var . "";
$this->var = 'asdf';
print $this->var;
}
}

$foo = new foo;
$foo->var = 'rarar';
?>

Expected result:

I expected $foo->var to be set to 'rarar' after the initial object
creation via constructor, then 'asdf'.  Instead, it remains set to
'rar', then 'asdf'.






-- 
Edit this bug report at http://bugs.php.net/?id=33088&edit=1


#27792 [Com]: Functions fail on large files (filesize,is_file,is_dir)

2005-07-01 Thread no at spam dot net
 ID:   27792
 Comment by:   no at spam dot net
 Reported By:  kode at kodekrash dot com
 Status:   Assigned
 Bug Type: Filesystem function related
 Operating System: * (LFS)
 PHP Version:  5.1*
 Assigned To:  wez
 New Comment:

is_link also fails on large files >2GB


Previous Comments:


[2005-06-30 06:40:29] dan at baximus dot com

Gee I hope it's included in PHP 5.1. IMHO this is a pretty 
important feature to have. But then, not everyone is in the 
business of serving up such large files from a PHP-driven 
website.



[2004-03-31 07:14:18] [EMAIL PROTECTED]

PHP does not currently support LFS.
This is something to be addressed in PHP 5.1



[2004-03-31 03:27:56] kode at kodekrash dot com

Description:

Error:
 (errno=75 - Value too large for defined data type)

Functions:
 is_file
 is_dir
 filesize

Premise:
 size of file is greater than 2GB.

--

I have been able to reproduce this error on 4 different PHP
installations (all on RedHat 7.3 machines), using 12 different files
for each test.

--

This bug has been submitted before, but is marked as BOGUS, which it is
certainly not.

Reproduce code:
---
filesize( $fname );
or
is_file( $fname )
or
is_dir( $fname )

where filesize( $fname ) > 2GB

Expected result:

Function: filesize
Expected: numeric value matching size of file

Function: is_file
Expected: boolean value

Function: is_dir
Expected: boolean value

Actual result:
--
(errno=75 - Value too large for defined data type)





-- 
Edit this bug report at http://bugs.php.net/?id=27792&edit=1


#30789 [NEW]: New Session created for every session_start() call.

2004-11-14 Thread spam at taylorw dot com
From: spam at taylorw dot com
Operating system: Linux - 2.6.8-gentoo-r3
PHP version:  Irrelevant
PHP Bug Type: Session related
Bug description:  New Session created for every session_start() call.

Description:

I have tried 4.3.9 and 5.0.2 (both emerged via gentoo) with various Apache
2.0.5x versions (currently using 2.0.52)... none seem to solve this
problem. Anytime session_start(); is called a new session is created,
along with a new session_id. I have verified that /tmp is where the
sessions are being stored, and have watched the directory as I refreshed a
page with nothing but session_start(); in it, and a new session is created
each time. And session autostart is not on in php.ini.

Relevant php.ini information:

session.save_handler = files
session.save_path = /tmp
session.use_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain = 
session.serialize_handler = php
session.gc_probability = 1
session.gc_divisor = 100
session.gc_maxlifetime = 1440
session.bug_compat_42 = 1
session.bug_compat_warn = 1
session.referer_check =
session.entropy_length = 0
session.entropy_file =
;session.entropy_length = 16
;session.entropy_file = /dev/urandom
session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 0


Reproduce code:
---
/* Page One (page1.php)*/

click here for page 2

/* Page Two (page2.php)*/

click here for page one

Expected result:

The echo'ed session_id()'s should be the same for both pages, and no new
session file should exist in /tmp .

Actual result:
--
The session id's differ, and a new session file has been created in /tmp .
Refreshing either page creates another session file in /tmp as well.

-- 
Edit bug report at http://bugs.php.net/?id=30789&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=30789&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=30789&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=30789&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30789&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30789&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=30789&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=30789&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=30789&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30789&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=30789&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=30789&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=30789&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30789&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=30789&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30789&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=30789&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30789&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=30789&r=float
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=30789&r=mysqlcfg


#30789 [Fbk->Opn]: New Session created for every session_start() call.

2004-11-14 Thread spam at taylorw dot com
 ID:   30789
 User updated by:  spam at taylorw dot com
 Reported By:  spam at taylorw dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Session related
 Operating System: Linux - 2.6.8-gentoo-r3
 PHP Version:  Irrelevant
 New Comment:

Changed, and checked using two different machines, and browsers... same
problem. I did note something of interest. After changing that setting,
I echo'ed phpinfo() and it does not show the updated setting in the
php.ini... So then I noticed something else (compared to another system
with exact same Apache and mod_php versions)...

For the box it wont work on:
--with-config-file-path=/etc/php/apache2-php4
Configuration File (php.ini) Path  /php.ini  

For the box it does work on:
--with-config-file-path=/etc/php/apache2-php4
Configuration File (php.ini) Path  /etc/php/apache2-php4/php.ini  

The second one has the correct path despite the fact that they both
have the same --with-configure lines. I'm not sure if that has anything
to do with the session issue?


Previous Comments:


[2004-11-15 07:45:17] [EMAIL PROTECTED]

Try to set session.use_trans_sid to 1 and check if cookies are enabled
in your browser.



[2004-11-15 07:08:41] spam at taylorw dot com

Description:

I have tried 4.3.9 and 5.0.2 (both emerged via gentoo) with various
Apache 2.0.5x versions (currently using 2.0.52)... none seem to solve
this problem. Anytime session_start(); is called a new session is
created, along with a new session_id. I have verified that /tmp is
where the sessions are being stored, and have watched the directory as
I refreshed a page with nothing but session_start(); in it, and a new
session is created each time. And session autostart is not on in
php.ini.

Relevant php.ini information:

session.save_handler = files
session.save_path = /tmp
session.use_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain = 
session.serialize_handler = php
session.gc_probability = 1
session.gc_divisor = 100
session.gc_maxlifetime = 1440
session.bug_compat_42 = 1
session.bug_compat_warn = 1
session.referer_check =
session.entropy_length = 0
session.entropy_file =
;session.entropy_length = 16
;session.entropy_file = /dev/urandom
session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 0


Reproduce code:
---
/* Page One (page1.php)*/

click here for page 2

/* Page Two (page2.php)*/

click here for page one

Expected result:

The echo'ed session_id()'s should be the same for both pages, and no
new session file should exist in /tmp .

Actual result:
--
The session id's differ, and a new session file has been created in
/tmp . Refreshing either page creates another session file in /tmp as
well.





-- 
Edit this bug report at http://bugs.php.net/?id=30789&edit=1


#30789 [Bgs]: New Session created for every session_start() call.

2004-11-14 Thread spam at taylorw dot com
 ID:   30789
 User updated by:  spam at taylorw dot com
 Reported By:  spam at taylorw dot com
 Status:   Bogus
 Bug Type: Session related
 Operating System: Linux - 2.6.8-gentoo-r3
 PHP Version:  Irrelevant
 New Comment:

Not sure what you mean "put it to the right place" ? I understand that
it's trying to read it from /php.ini but I havent been able to find
where that is set?

I also used 'locate' to find all php.ini files and updated the two it
found to turn on the trans_sid, but still having the same issue.


Previous Comments:


[2004-11-15 08:05:12] [EMAIL PROTECTED]

No, put your php.ini to the right place first.

----

[2004-11-15 07:56:01] spam at taylorw dot com

Changed, and checked using two different machines, and browsers... same
problem. I did note something of interest. After changing that setting,
I echo'ed phpinfo() and it does not show the updated setting in the
php.ini... So then I noticed something else (compared to another system
with exact same Apache and mod_php versions)...

For the box it wont work on:
--with-config-file-path=/etc/php/apache2-php4
Configuration File (php.ini) Path  /php.ini  

For the box it does work on:
--with-config-file-path=/etc/php/apache2-php4
Configuration File (php.ini) Path  /etc/php/apache2-php4/php.ini  

The second one has the correct path despite the fact that they both
have the same --with-configure lines. I'm not sure if that has anything
to do with the session issue?



[2004-11-15 07:45:17] [EMAIL PROTECTED]

Try to set session.use_trans_sid to 1 and check if cookies are enabled
in your browser.

----

[2004-11-15 07:08:41] spam at taylorw dot com

Description:

I have tried 4.3.9 and 5.0.2 (both emerged via gentoo) with various
Apache 2.0.5x versions (currently using 2.0.52)... none seem to solve
this problem. Anytime session_start(); is called a new session is
created, along with a new session_id. I have verified that /tmp is
where the sessions are being stored, and have watched the directory as
I refreshed a page with nothing but session_start(); in it, and a new
session is created each time. And session autostart is not on in
php.ini.

Relevant php.ini information:

session.save_handler = files
session.save_path = /tmp
session.use_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain = 
session.serialize_handler = php
session.gc_probability = 1
session.gc_divisor = 100
session.gc_maxlifetime = 1440
session.bug_compat_42 = 1
session.bug_compat_warn = 1
session.referer_check =
session.entropy_length = 0
session.entropy_file =
;session.entropy_length = 16
;session.entropy_file = /dev/urandom
session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 0


Reproduce code:
---
/* Page One (page1.php)*/

click here for page 2

/* Page Two (page2.php)*/

click here for page one

Expected result:

The echo'ed session_id()'s should be the same for both pages, and no
new session file should exist in /tmp .

Actual result:
--
The session id's differ, and a new session file has been created in
/tmp . Refreshing either page creates another session file in /tmp as
well.





-- 
Edit this bug report at http://bugs.php.net/?id=30789&edit=1


#30789 [Bgs]: New Session created for every session_start() call.

2004-11-14 Thread spam at taylorw dot com
 ID:   30789
 User updated by:  spam at taylorw dot com
 Reported By:  spam at taylorw dot com
 Status:   Bogus
 Bug Type: Session related
 Operating System: Linux - 2.6.8-gentoo-r3
 PHP Version:  Irrelevant
 New Comment:

Yeah it did, removed that one (which I know remember I copied off the
other box to compare with this boxes). The correct ini file is now
reported... but nothing else new to report.


Previous Comments:


[2004-11-15 08:16:36] [EMAIL PROTECTED]

I mean delete /php.ini and use /etc/php/apache2-php4/php.ini instead.
Does `ls -l /php.ini` report that there is no such file ?



[2004-11-15 08:13:27] spam at taylorw dot com

Not sure what you mean "put it to the right place" ? I understand that
it's trying to read it from /php.ini but I havent been able to find
where that is set?

I also used 'locate' to find all php.ini files and updated the two it
found to turn on the trans_sid, but still having the same issue.



[2004-11-15 08:05:12] [EMAIL PROTECTED]

No, put your php.ini to the right place first.

----

[2004-11-15 07:56:01] spam at taylorw dot com

Changed, and checked using two different machines, and browsers... same
problem. I did note something of interest. After changing that setting,
I echo'ed phpinfo() and it does not show the updated setting in the
php.ini... So then I noticed something else (compared to another system
with exact same Apache and mod_php versions)...

For the box it wont work on:
--with-config-file-path=/etc/php/apache2-php4
Configuration File (php.ini) Path  /php.ini  

For the box it does work on:
--with-config-file-path=/etc/php/apache2-php4
Configuration File (php.ini) Path  /etc/php/apache2-php4/php.ini  

The second one has the correct path despite the fact that they both
have the same --with-configure lines. I'm not sure if that has anything
to do with the session issue?



[2004-11-15 07:45:17] [EMAIL PROTECTED]

Try to set session.use_trans_sid to 1 and check if cookies are enabled
in your browser.



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/30789

-- 
Edit this bug report at http://bugs.php.net/?id=30789&edit=1


#30789 [Bgs]: New Session created for every session_start() call.

2004-11-14 Thread spam at taylorw dot com
 ID:   30789
 User updated by:  spam at taylorw dot com
 Reported By:  spam at taylorw dot com
 Status:   Bogus
 Bug Type: Session related
 Operating System: Linux - 2.6.8-gentoo-r3
 PHP Version:  Irrelevant
 New Comment:

Not sure why this got changed to bogus, when the session issue is still
happening?


Previous Comments:


[2004-11-15 08:19:51] spam at taylorw dot com

Yeah it did, removed that one (which I know remember I copied off the
other box to compare with this boxes). The correct ini file is now
reported... but nothing else new to report.



[2004-11-15 08:16:36] [EMAIL PROTECTED]

I mean delete /php.ini and use /etc/php/apache2-php4/php.ini instead.
Does `ls -l /php.ini` report that there is no such file ?



[2004-11-15 08:13:27] spam at taylorw dot com

Not sure what you mean "put it to the right place" ? I understand that
it's trying to read it from /php.ini but I havent been able to find
where that is set?

I also used 'locate' to find all php.ini files and updated the two it
found to turn on the trans_sid, but still having the same issue.



[2004-11-15 08:05:12] [EMAIL PROTECTED]

No, put your php.ini to the right place first.

----

[2004-11-15 07:56:01] spam at taylorw dot com

Changed, and checked using two different machines, and browsers... same
problem. I did note something of interest. After changing that setting,
I echo'ed phpinfo() and it does not show the updated setting in the
php.ini... So then I noticed something else (compared to another system
with exact same Apache and mod_php versions)...

For the box it wont work on:
--with-config-file-path=/etc/php/apache2-php4
Configuration File (php.ini) Path  /php.ini  

For the box it does work on:
--with-config-file-path=/etc/php/apache2-php4
Configuration File (php.ini) Path  /etc/php/apache2-php4/php.ini  

The second one has the correct path despite the fact that they both
have the same --with-configure lines. I'm not sure if that has anything
to do with the session issue?



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/30789

-- 
Edit this bug report at http://bugs.php.net/?id=30789&edit=1


#16263 [Com]: session.start() create new empty session file and not resume existing session

2004-12-07 Thread spam at taylorw dot com
 ID:   16263
 Comment by:   spam at taylorw dot com
 Reported By:  kur at natur dot cuni dot cz
 Status:   No Feedback
 Bug Type: Session related
 Operating System: ANY
 PHP Version:  4.3.0-dev
 New Comment:

I have this same issue. Just did a clean install of Apache 2.0.52 and
PHP/4.3.9 ... and I have the same issues. A new session is created, and
yes, the php.ini is correct (the one that installed with the Gentoo
ebuild).


Previous Comments:


[2004-10-28 15:43:58] kovalchuk at dopomoga dot org dot ua

I got simmilar problem with PHP 5.0.2, Apache 2.0.52 
(Linux, kernel 2.6.8.1). 
The session files are apeared in the session.save_path 
directory and they contains correct entryes, but each time 
I call session_start() a new file is apeared and $_SESSION 
array does not contain anything.



[2002-11-14 14:42:28] murray dot rennie at ec dot gc dot ca

Redhat 7.2 or 7.3.  PhP 4.1.2, Apache 1.3.23.

I get something similar to this when I change session.cookie_lifetime
to something other than zero, and only when connecting with IE (my
version 5.5).  PHP generates two session files, one has all the info I
initialized with, the second just has the sessionId in it.
It's as if it ignores the first session it created and makes a new one.
 Netscape 4.79 works properly, and when I set session.cookie_lifetime to
0 the problem goes away on IE.



[2002-04-15 20:27:19] [EMAIL PROTECTED]

once again, whenever you update/downgrade PHP remember
to replace ALL the dlls and other binaries in your systems
with the ones found in the release packages.





[2002-04-10 05:17:06] alex at netflex dot nl

Hi,

It is fixed in PHP 4.2.0

Look for PHP 4.2.0 at:
http://www.php.net/~derick/



[2002-04-06 08:13:00] [EMAIL PROTECTED]

When updating PHP, remember to always replace the php4ts.dll 
with the one found in the release package.




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/16263

-- 
Edit this bug report at http://bugs.php.net/?id=16263&edit=1


#31022 [NEW]: Using '_' in a hostname causes sessions to break

2004-12-08 Thread spam at taylorw dot com
From: spam at taylorw dot com
Operating system: Gentoo Linux
PHP version:  4.3.9
PHP Bug Type: *Configuration Issues
Bug description:  Using '_' in a hostname causes sessions to break

Description:

Previously I submitted a bug report about sessions not working, in the
sense that every session_start() call created a new session, and a new
file in /tmp. I have concluded that the host name "spare_ribs" was the
issue. By changing the hostname to "spareribs" (no '_') the session issue
is fixed. I am not sure if using '_' in a hostname is against some RFC and
thus this is not really a bug, but I think that since bind accepted it, and
the two browsers I tried with it worked fine, this is not breaking protocol
and should work fine.

(Apache 2.0.52 being used here.)

Reproduce code:
---
Set hostname to anything with _ such as "spare_ribs". Then reboot box and
browse to page one which includes the following code.

/* Page 1 */

click here for page 2';

?>

/* Page 2 */

click here for page 1';

?>



Expected result:

Page one should say 'this is a test', and page two should say 'You should
see this is a test: this is a test'. 

Actual result:
--
However page two only says 'You should see this is a test'. And a new
session id has been assigned, as well as a new session created in /tmp.

-- 
Edit bug report at http://bugs.php.net/?id=31022&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=31022&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=31022&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=31022&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31022&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31022&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=31022&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=31022&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=31022&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31022&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=31022&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=31022&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=31022&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31022&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=31022&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31022&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=31022&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31022&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=31022&r=float
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=31022&r=mysqlcfg


#26117 [NEW]: Persistent connection not reused

2003-11-04 Thread spam at vrana dot cz
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


#26117 [Bgs->Opn]: Persistent connection not reused

2003-11-05 Thread spam at vrana dot cz
 ID:   26117
 User updated by:  spam at vrana dot cz
 Reported By:  spam at vrana dot cz
-Status:   Bogus
+Status:   Open
 Bug Type: MySQL related
 Operating System: Linux
 PHP Version:  4.3.3
 New Comment:

This is not the case. Believe me that I have read all similar bugs and
this is different. I also have read carefuly the manual and I
understand everything written there about persistent connections.

There is written in the Persistent Database Connections chapter of
manual: An 'identical' connection is a connection that was opened to
the same host, with the same username and the same password (where
applicable). So it's not true that by mysql_select_db() with different
database name the connection can't be reused. Anyway I use the same
database in all scripts.

I know that connection is persistent only over the child. Thus I wrote
that Apache configuration directive MaxClients is set to 150.


Previous Comments:


[2003-11-04 13:53:56] [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

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.

----

[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


#26117 [Fbk->Opn]: Persistent connection not reused

2003-11-05 Thread spam at vrana dot cz
 ID:   26117
 User updated by:  spam at vrana dot cz
 Reported By:  spam at vrana dot cz
-Status:   Feedback
+Status:   Open
 Bug Type: MySQL related
 Operating System: Linux
 PHP Version:  4.3.3
 New Comment:

Yes. There were 466 processes with the same user, host and db. All
processes were in state Sleep.


Previous Comments:


[2003-11-05 11:21:33] [EMAIL PROTECTED]

When the "too many connections" problem occurs, have you tried running
"show full processlist;" query to see if infact all connections use the
same database?



[2003-11-05 03:24:59] spam at vrana dot cz

This is not the case. Believe me that I have read all similar bugs and
this is different. I also have read carefuly the manual and I
understand everything written there about persistent connections.

There is written in the Persistent Database Connections chapter of
manual: An 'identical' connection is a connection that was opened to
the same host, with the same username and the same password (where
applicable). So it's not true that by mysql_select_db() with different
database name the connection can't be reused. Anyway I use the same
database in all scripts.

I know that connection is persistent only over the child. Thus I wrote
that Apache configuration directive MaxClients is set to 150.



[2003-11-04 13:53:56] [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

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.

----

[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


#24393 [Com]: Can't find iconv.dll

2003-11-09 Thread spam at infeer dot com
 ID:   24393
 Comment by:   spam at infeer dot com
 Reported By:  zarxos at yahoo dot com
 Status:   Bogus
 Bug Type: *General Issues
 Operating System: Windows XP
 PHP Version:  5CVS-2003-06-29 (dev)
 New Comment:

To [EMAIL PROTECTED]:
Very bad suggestion !!!
Do you realy expect ppl to copy all *.dll to the system32 folder when
trying to use a beta PHP5 (or other version)? How do you expect Ppl do
any testing?  

What I usually did in V4.x is to copy the apache API-dll
 C:/php4/sapi/php4apache.dll to C:/php4/ 
That did the trick so far. 

But in PHP V5 Apache complains it can't load php4apache.dll (even if
it's there). I found out that PHP5 requires an additional DLL: the
C:/php4/dlls/iconv.dll for some reson.
So I also copy 
C:/php5/dlls/iconv.dll  to C:/php5/ 
and everything works so far again.


Previous Comments:


[2003-06-29 20:07:40] [EMAIL PROTECTED]

If you read install.txt that comes with PHP it would tell you to copy
dlls\*.dll to system32 folder.



[2003-06-29 19:33:01] zarxos at yahoo dot com

Description:

In Windows XP and Apache 1.3.27, when you try to load a php page, it
says PHP could not be loaded because iconv.dll could not be found. This
is fixable by moving it to C:\Windows\System32 but I thought I would
just let you guys know.

Reproduce code:
---
Any PHP Code

Expected result:

Whatever PHP page I'm trying to load.

Actual result:
--
500 - Internal Server Error





-- 
Edit this bug report at http://bugs.php.net/?id=24393&edit=1


#26238 [NEW]: flush() doesn't work with output_buffering = 4096

2003-11-13 Thread spam at vrana dot cz
From: spam at vrana dot cz
Operating system: Windows XP
PHP version:  4.3.3
PHP Bug Type: Output Control
Bug description:  flush() doesn't work with output_buffering = 4096

Description:

I have set output_buffering = 4096 and flush(), ob_implicit_flush(),
ob_flush() and similar functions doesn't work. This is reproducible in PHP
Apache module, in PHP-CLI and also on Linux.

Reproduce code:
---
while (true) {
echo ".";
flush();
sleep(1);
}


Expected result:

. (1 second) . (1 second) ...

Actual result:
--
nothing (for output_buffering seconds)

-- 
Edit bug report at http://bugs.php.net/?id=26238&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=26238&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=26238&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=26238&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=26238&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26238&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=26238&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26238&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=26238&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26238&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26238&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=26238&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26238&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=26238&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=26238&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26238&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26238&r=float


#26117 [Bgs->Opn]: Persistent connection not reused

2003-11-18 Thread spam at vrana dot cz
 ID:   26117
 User updated by:  spam at vrana dot cz
 Reported By:  spam at vrana dot cz
-Status:   Bogus
+Status:   Open
 Bug Type: MySQL related
 Operating System: Linux
 PHP Version:  4.3.3
 New Comment:

Can you please read my bug report carefuly before stating bug as bogus?
Persistent connection in PHP should reuse previous persistent
connection with the same host, user and password. The bug is that it
doesn't.


Previous Comments:


[2003-11-17 18:21:48] [EMAIL PROTECTED]

And this is PHP bug in where..?




[2003-11-05 12:20:11] spam at vrana dot cz

Yes. There were 466 processes with the same user, host and db. All
processes were in state Sleep.



[2003-11-05 11:21:33] [EMAIL PROTECTED]

When the "too many connections" problem occurs, have you tried running
"show full processlist;" query to see if infact all connections use the
same database?

----

[2003-11-05 03:24:59] spam at vrana dot cz

This is not the case. Believe me that I have read all similar bugs and
this is different. I also have read carefuly the manual and I
understand everything written there about persistent connections.

There is written in the Persistent Database Connections chapter of
manual: An 'identical' connection is a connection that was opened to
the same host, with the same username and the same password (where
applicable). So it's not true that by mysql_select_db() with different
database name the connection can't be reused. Anyway I use the same
database in all scripts.

I know that connection is persistent only over the child. Thus I wrote
that Apache configuration directive MaxClients is set to 150.



[2003-11-04 13:53:56] [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

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.



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/26117

-- 
Edit this bug report at http://bugs.php.net/?id=26117&edit=1


#26117 [Bgs->Opn]: Persistent connection not reused

2003-11-19 Thread spam at vrana dot cz
 ID:   26117
 User updated by:  spam at vrana dot cz
 Reported By:  spam at vrana dot cz
-Status:   Bogus
+Status:   Open
 Bug Type: MySQL related
 Operating System: Linux
 PHP Version:  4.3.3
 New Comment:

Do you think that there is no problem if it works for YOU and doesn't
work for others?


Previous Comments:


[2003-11-18 15:07:14] [EMAIL PROTECTED]

Well, it does work fine for me. 




[2003-11-18 07:33:03] spam at vrana dot cz

Can you please read my bug report carefuly before stating bug as bogus?
Persistent connection in PHP should reuse previous persistent
connection with the same host, user and password. The bug is that it
doesn't.



[2003-11-17 18:21:48] [EMAIL PROTECTED]

And this is PHP bug in where..?




[2003-11-05 12:20:11] spam at vrana dot cz

Yes. There were 466 processes with the same user, host and db. All
processes were in state Sleep.



[2003-11-05 11:21:33] [EMAIL PROTECTED]

When the "too many connections" problem occurs, have you tried running
"show full processlist;" query to see if infact all connections use the
same 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/26117

-- 
Edit this bug report at http://bugs.php.net/?id=26117&edit=1


#26354 [NEW]: forced to lower case

2003-11-21 Thread spam at tkz dot net
From: spam at tkz dot net
Operating system: linux & windows xp
PHP version:  4.3.3
PHP Bug Type: Output Control
Bug description:   forced to lower case

Description:

blah";
echo "blah";
echo "blah";
?>

displays:
blahblahblah

I can't seem to find a way to display Address as an XML tag.  Somehow it
is automatically forced to be lower case! This is like a magic number.  If
I mispell it then it comes through without modification, so Address is a
special case.  I understand that functions are case insensitive, but text
shouldn't be case lowercase a magic word.

Reproduce code:
---
blah";
echo "blah";
echo "blah";
?>

Expected result:

blahblahblah

Actual result:
--
blahblahblah

-- 
Edit bug report at http://bugs.php.net/?id=26354&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=26354&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=26354&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=26354&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=26354&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26354&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=26354&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26354&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=26354&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26354&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26354&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=26354&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26354&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=26354&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=26354&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26354&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26354&r=float


#26354 [Opn]: forced to lower case

2003-11-21 Thread spam at tkz dot net
 ID:   26354
 User updated by:  spam at tkz dot net
 Reported By:  spam at tkz dot net
 Status:   Open
 Bug Type: Output Control
 Operating System: linux & windows xp
 PHP Version:  4.3.3
 New Comment:

accidently switched expected and actual results.


Previous Comments:


[2003-11-21 14:45:23] spam at tkz dot net

Description:

blah";
echo "blah";
echo "blah";
?>

displays:
blahblahblah

I can't seem to find a way to display Address as an XML tag.  Somehow
it is automatically forced to be lower case! This is like a magic
number.  If I mispell it then it comes through without modification, so
Address is a special case.  I understand that functions are case
insensitive, but text shouldn't be case lowercase a magic word.

Reproduce code:
---
blah";
echo "blah";
echo "blah";
?>

Expected result:

blahblahblah

Actual result:
--
blahblahblah





-- 
Edit this bug report at http://bugs.php.net/?id=26354&edit=1


#27642 [Com]: mysqli_prop.c: In function `stmt_affected_rows_read'

2004-03-19 Thread spam at 8304 dot ch
 ID:   27642
 Comment by:   spam at 8304 dot ch
 Reported By:  josh at trutwins dot homeip dot net
 Status:   Bogus
 Bug Type: Compile Failure
 Operating System: Linux SuSE 8.1
 PHP Version:  5.0.0RC1
 New Comment:

same problem under suse 9.0. 

5.0.0b4 compiled perfectely, but with the same config.nice build of
5.0.0rc1 fails:



#! /bin/sh

#

# Created by configure



'./configure' \

'--prefix=/usr/local/php5' \

'--with-apxs2=/usr/local/apache2/bin/apxs' \

'--with-iconv' \

'--enable-mbstring' \

'--enable-track-vars' \

'--enable-safe-mode' \

'--with-gd' \

'--with-curl' \

'--with-ttf' \

'--with-mysql=/usr/local/mysql500' \

'--with-mysqli=/usr/local/mysql500/bin/mysql_config' \

'--with-xml' \

'--enable-memory-limit' \

'--with-png-dir=/usr/lib' \

'--with-jpeg-dir=/usr/lib' \

'--with-freetype-dir=/usr/lib' \

'--with-zlib' \

'--enable-ftp' \

'--with-openssl' \

'--with-ldap' \

'--enable-mbstring' \

'--with-mssql=/usr/local/freetds' \

"$@"



/usr/local/src/php-5.0.0RC1/ext/mysqli/mysqli_prop.c: In function
`stmt_affected_rows_read':

/usr/local/src/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189: error:
structure has no member named `affected_rows'

/usr/local/src/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189: error:
structure has no member named `affected_rows'

/usr/local/src/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189: error:
structure has no member named `affected_rows'

make: *** [ext/mysqli/mysqli_prop.lo] Error 1


Previous Comments:


[2004-03-19 01:16:37] [EMAIL PROTECTED]

MySQL 5.0 is a preview version for SP's. 

Fixes and changes in 4.1 are currently not merged in 5.0 

tree, this will probably happen when 4.1.3-beta will come 

out. 



[2004-03-18 19:23:43] josh at trutwins dot homeip dot net

Oops, bad subject.



[2004-03-18 19:15:26] josh at trutwins dot homeip dot net

Description:

Attempting to compile PHP-5.0.0RC1 with MySQL 5.0.0 alpha built from
source using --with-mysqli



Here is the error:



cc1: warning: changing search order for system directory
"/usr/local/include"

cc1: warning:   as it has already been specified as a non-system
directory

/usr/local/source/php/php-5.0.0RC1/ext/mysqli/mysqli_prop.c: In
function `stmt_affected_rows_read':

/usr/local/source/php/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189:
structure has no member named `affected_rows'

/usr/local/source/php/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189:
structure has no member named `affected_rows'

/usr/local/source/php/php-5.0.0RC1/ext/mysqli/mysqli_prop.c:189:
structure has no member named `affected_rows'

make: *** [ext/mysqli/mysqli_prop.lo] Error 1



Here is the configure script:



./configure \

--with-config-file-path=/etc/httpd \

--enable-libgcc \

--enable-sigchild \

--enable-track-vars \

--disable-ipv6 \

\

--with-apxs2=/usr/local/apache/bin/apxs \

\

--enable-exif \

--enable-ftp \

--enable-sockets \

--with-mcrypt \

--with-mhash \

--with-openssl \

--with-iconv \

--with-ncurses \

--with-readline \

--with-curl \

\

--with-bz2 \

--with-zip \

--with-zlib \

\

--with-mysqli=/usr/local/mysql/bin/mysql_config \

--with-mysql-sock=/usr/local/mysql/mysql.sock \

\

--with-pgsql=/usr/local/pgsql \

\

--with-oci8 \

\

--with-sqlite \

\

--with-gd \

--with-ttf \

--with-freetype \

--with-freetype-dir=/usr/X11/lib \

--with-png-dir=/usr \

--with-jpeg-dir=/usr \

--with-tiff-dir=/usr \

--with-xpm-dir=/usr \

\

--enable-xml \

--enable-wddx \

--with-xsl \

--with-expat-dir=/usr \

--with-libxml-dir=/usr/local \

--with-xmlrpc \

--with-dom \

--with-qtdom \

\

--with-java=/usr/local/java/ \

| tee config.out



System is SuSE 8.1 with gcc 3.2












-- 
Edit this bug report at http://bugs.php.net/?id=27642&edit=1


#27848 [NEW]: stripslashes removes single trailing slash

2004-04-02 Thread spam at pasher dot org
From: spam at pasher dot org
Operating system: Debian (Linux 2.4.18-bf2.4)
PHP version:  4.3.4
PHP Bug Type: Strings related
Bug description:  stripslashes removes single trailing slash

Description:

The stripslashes() function strips off a single trailing \ when altering a
string. I can see that according to bug report
http://bugs.php.net/bug.php?id=19947 , this function is not supposed to be
an exact opposite of addslashes(), but it seems as thought a string that
ends in a single \ should not have that slash removed, as the slash is not
actually backslashing any part of the string. The only reasoning I could
see behind this is that either any slash is stripped by stripslashes, or
the \0 stored at the end of the C code string to terminate it (but not
actually part of the PHP code string) is considered a character being
"escaped".



If stripslashes() is designed to simple strip any slash from a string, it
seems like the design should be rethought a bit, as it can potentially
produced undesired results.

Reproduce code:
---


Expected result:

Displays "this is a test\"

Actual result:
--
Displays "this is a test"

-- 
Edit bug report at http://bugs.php.net/?id=27848&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=27848&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=27848&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=27848&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=27848&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27848&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=27848&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=27848&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27848&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=27848&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27848&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27848&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=27848&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27848&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=27848&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=27848&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27848&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27848&r=float


#27848 [Bgs->Opn]: stripslashes removes single trailing slash

2004-04-03 Thread spam at pasher dot org
 ID:   27848
 User updated by:  spam at pasher dot org
 Reported By:  spam at pasher dot org
-Status:   Bogus
+Status:   Open
 Bug Type: Strings related
 Operating System: Debian (Linux 2.4.18-bf2.4)
 PHP Version:  4.3.4
 New Comment:

I don't think you quite understand the reasoning I am giving. I
understand that the \\ gets converted in the string to \. The problem
is the following string



this is a test\



ends up becoming



this is a test



after a run through stripslashes. Where is the logic in stripslashes
stripping out ANY slash that it finds, instead of only stripping out
slashes that are used to backslash another character? According to the
documentation, the purpose of stripslashes is the following:



"Un-quote string quoted with addslashes()"



Why would stripslashes remove a trailing \ when there is NO way the
addslashes() function would ever produce a string that ends in a single
trailing \ ? This appears to be a logic error (or really an
over-assumption) on the part of stripslashes().


Previous Comments:


[2004-04-03 13:15:57] [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

When you create the string \\ gets converted to \, which is 

why the slash gets stripped by stripslashes(). 



[2004-04-02 20:50:23] spam at pasher dot org

Description:

The stripslashes() function strips off a single trailing \ when
altering a string. I can see that according to bug report
http://bugs.php.net/bug.php?id=19947 , this function is not supposed to
be an exact opposite of addslashes(), but it seems as thought a string
that ends in a single \ should not have that slash removed, as the
slash is not actually backslashing any part of the string. The only
reasoning I could see behind this is that either any slash is stripped
by stripslashes, or the \0 stored at the end of the C code string to
terminate it (but not actually part of the PHP code string) is
considered a character being "escaped".



If stripslashes() is designed to simple strip any slash from a string,
it seems like the design should be rethought a bit, as it can
potentially produced undesired results.

Reproduce code:
---


Expected result:

Displays "this is a test\"

Actual result:
--
Displays "this is a test"





-- 
Edit this bug report at http://bugs.php.net/?id=27848&edit=1


#30458 [NEW]: glob() overlooks broken symlinks

2004-10-16 Thread spam at ww981 dot net
From: spam at ww981 dot net
Operating system: Linux
PHP version:  5.0.2
PHP Bug Type: Directory function related
Bug description:  glob() overlooks broken symlinks

Description:

 If a symlink doesn't point to a existing file/dir, glob
overlooks it. I'm pretty sure this is a bug because glob
should return everything existing in the pattern. glob in
php 4.3.9 has the same bug.


-- 
Edit bug report at http://bugs.php.net/?id=30458&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=30458&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30458&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30458&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30458&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30458&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=30458&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=30458&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=30458&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30458&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=30458&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30458&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30458&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30458&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=30458&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30458&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=30458&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30458&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=30458&r=float
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=30458&r=mysqlcfg


#30281 [NEW]: returned size for WBMP is always 1x0

2004-09-29 Thread spam at batz dot org
From: spam at batz dot org
Operating system: Windows XP
PHP version:  5.0.1
PHP Bug Type: GetImageSize related
Bug description:  returned size for WBMP is always 1x0

Description:

getimagesize returns always 1 as width and 0 as height for WBMP pictures.
problem occurs on 4.3.8 and 4.3.9 as well.
WBMP/ICO can hold multiple frames with different sizes.


Reproduce code:
---
$imageinfo = getimagesize('favicon.ico');
echo "width:{$imageinfo[0]}";
echo "height:{$imageinfo[1]}";
echo "imagetype:{$imageinfo[2]}";
echo "to show that the size is wrong:";
echo "";

Expected result:

width:16
height:16
imagetype:15
to show that the size is wrong:
IMAGE

Actual result:
--
width:1
height:0
imagetype:15
to show that the size is wrong:
IMAGE

-- 
Edit bug report at http://bugs.php.net/?id=30281&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=30281&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30281&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30281&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30281&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30281&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=30281&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=30281&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=30281&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30281&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=30281&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30281&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30281&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30281&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=30281&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30281&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=30281&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30281&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=30281&r=float
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=30281&r=mysqlcfg


#30281 [Fbk->Opn]: returned size for WBMP is always 1x0

2004-10-04 Thread spam at batz dot org
 ID:   30281
 User updated by:  spam at batz dot org
 Reported By:  spam at batz dot org
-Status:   Feedback
+Status:   Open
 Bug Type: GetImageSize related
 Operating System: Windows XP
 PHP Version:  5.0.1
 New Comment:

Any file in ICO-format should do it. But you can just use
http://www.favicon.com/favicon.ico as sample.


Previous Comments:


[2004-09-30 03:16:00] [EMAIL PROTECTED]

Please supply the image used.



[2004-09-29 21:25:49] spam at batz dot org

Description:

getimagesize returns always 1 as width and 0 as height for WBMP
pictures. problem occurs on 4.3.8 and 4.3.9 as well.
WBMP/ICO can hold multiple frames with different sizes.


Reproduce code:
---
$imageinfo = getimagesize('favicon.ico');
echo "width:{$imageinfo[0]}";
echo "height:{$imageinfo[1]}";
echo "imagetype:{$imageinfo[2]}";
echo "to show that the size is wrong:";
echo "";

Expected result:

width:16
height:16
imagetype:15
to show that the size is wrong:
IMAGE

Actual result:
--
width:1
height:0
imagetype:15
to show that the size is wrong:
IMAGE





-- 
Edit this bug report at http://bugs.php.net/?id=30281&edit=1


#29032 [Com]: Session are closed before all object destructors executed.

2005-04-10 Thread spam at cimmanon dot org
 ID:   29032
 Comment by:   spam at cimmanon dot org
 Reported By:  antonr at game dot permonline dot ru
 Status:   No Feedback
 Bug Type: Session related
 Operating System: Irrelevant
 PHP Version:  5CVS-2004-07-06 (dev)
 New Comment:

This bug still persists in PHP 5.0.4 (my problem is related to output
buffers being cleared before destructors are executed).  Is the "latest
CVS snapshot" mentioned by [EMAIL PROTECTED] [6 Mar 8:35pm CET] reflected
in the 5.0.4 release [31 Mar]?


Previous Comments:


[2005-03-14 01:00:10] 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".



[2005-03-06 20:35:59] [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





[2004-12-06 05:34:29] anthony at ectrolinux dot com

For reference, this bug appears to be synonymous to bug #30578, with
the same cause but a different effect.



[2004-10-26 02:40:15] auroraeosrose at hotmail dot com

Modifying $_SESSION in the destructor ONLY works if you call
unset($object) before the end of your script, however this is a pain in
the rear - and if you have references to that object elsewhere it
doesn't work properly.

There is a workaround... You CAN use register_shutdown_function in the
constructor of your class

  public function __construct()
{ 
register_shutdown_function(array($this, '__destruct');
} 

and then the destruct is called early enough that you can modify
$_SESSION. But this defeats the whole purpose of a destructor - I could
do that in every class if php5 didn't support destructors (in fact I did
in php4) but I thought the point was to eliminate messy workarounds. 
Now why in the world the sessions are closed in between when shutdown
functions and destructors are called is beyond me.



[2004-07-06 16:58:15] antonr at game dot permonline dot ru

Description:

Session are closed before all object destructors executed. It seems to
be wrong, cause objects desctructors may save information in opened
session.


Reproduce code:
---
number = @$_SESSION["number"];
}
  public function Process()
{ $this->number++;
}
  public function __destruct()
{ $_SESSION["number"] = $this->number;
  session_write_close();
}
}

  $ss = new MySession();
  $ss->Process();
  echo $ss->number;

?>


Expected result:

With every page reloading number in the page must increase by 1.

Actual result:
--
Everytime number is equal 1.





-- 
Edit this bug report at http://bugs.php.net/?id=29032&edit=1


#32686 [NEW]: Require/include file in destructor causes segfault

2005-04-12 Thread spam at cimmanon dot org
From: spam at cimmanon dot org
Operating system: OpenBSD
PHP version:  5.0.4
PHP Bug Type: Reproducible crash
Bug description:  Require/include file in destructor causes segfault

Description:

Including a file inside the destructor of a class causes Apache to
segfault, if the file is attempting to print properties of the object. 
This did not happen in 5.0.3 (stable).

The problem seems to be in the included file itself.  Setting and printing
local variables seems to work just fine, it's the printing of the object's
properties that causes the segfault.

Reproduce code:
---
foo = 5;
$this->bar = 'boo';
}

function __destruct() {
print $this->bar;
include('include.php');
}
}

$test = new a;
?>

foo;
?>

Expected result:

This should print "boo", then "5".

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
0x09d63402 in yy_push_state (new_state=6) at
Zend/zend_language_scanner.c:5990 5990   
yy_start_stack[yy_start_stack_ptr++] = YY_START;(gdb) bt
#0  0x09d63402 in yy_push_state (new_state=6) at
Zend/zend_language_scanner.c:5990#1  0x09d6025f in lex_scan
(zendlval=0xcfbf40c4) at Zend/zend_language_scanner.c:4021#2  
0x09d6d975
in zendlex (zendlval=0xcfbf40c0)at
/usr/ports/www/php5/core/w-php5-core-5.0.4/php-5.0.4/Zend/
zend_compile.
c:3688#3  0x09d5effd in zendparse () at Zend/
zend_language_parser.c:2221
#4  0x09d5f4a2 in compile_file (file_handle=,
 type=2)
at Zend/zend_language_scanner.c:3157
#5  0x09d5f632 in compile_filename (type=2, 
filename=0x3c147324) at
Zend/zend_language_scanner.c:3202#6  0x09da0dad in
zend_include_or_eval_handler (execute_data=0xcfbf4310,
opline=0x3c147308, op_array=0x3c082f24) at
/usr/ports/www/php5/core/w-php5-core-5.0.4/php-5.0.4/Zend/
zend_execute.
c:3551#7  0x09d9b2ea in execute (op_array=0x3c082f24)
at
/usr/ports/www/php5/core/w-php5-core-5.0.4/php-5.0.4/Zend/
zend_execute.
c:1406#8  0x09d701b0 in zend_call_function (fci=0xcfbf44b0,
fci_cache=0xcfbf4490)at
/usr/ports/www/php5/core/w-php5-core-5.0.4/php-5.0.4/Zend/
zend_execute_
API.c:852#9  0x09d890b6 in zend_call_method 
(object_pp=0xcfbf453c,
obj_ce=0x3c111c24, fn_proxy=0x0, function_name=0x29c61fb6
"__destruct", function_name_len=10, retval_ptr_ptr=0x0, 
param_count=0,  
  arg1=0x0, arg2=0x0) at
/usr/ports/www/php5/core/w-php5-core-5.0.4/php-5.0.4/Zend/
zend_interfac
es.c:86#10 0x09d8cf64 in zend_objects_destroy_object 
(object=0x3c137ce4,
handle=1)at
/usr/ports/www/php5/core/w-php5-core-5.0.4/php-5.0.4/Zend/
zend_objects.
c:78#11 0x09d8f218 in zend_objects_store_call_destructors
(objects=0x29c874d0)at
/usr/ports/www/php5/core/w-php5-core-5.0.4/php-5.0.4/Zend/
zend_objects_
API.c:54#12 0x09d6ecbd in shutdown_executor ()
at
/usr/ports/www/php5/core/w-php5-core-5.0.4/php-5.0.4/Zend/
zend_execute_
API.c:207#13 0x09d79ede in zend_deactivate ()
at
/usr/ports/www/php5/core/w-php5-core-5.0.4/php-5.0.4/Zend/
zend.c:817#14
0x09d40077 in php_request_shutdown (dummy=0x0)at
/usr/ports/www/php5/core/w-php5-core-5.0.4/php-5.0.4/main/
main.c:1216#15
0x09da5d0a in apache_php_module_main (r=0x3c07b034,
display_source_mode=0)at
/usr/ports/www/php5/core/w-php5-core-5.0.4/php-5.0.4/sapi/
apache/sapi_a
pache.c:60#16 0x09da679e in send_php (r=0x3c07b034,
display_source_mode=0, filename=0x0)at
/usr/ports/www/php5/core/w-php5-core-5.0.4/php-5.0.4/sapi/
apache/mod_ph
p5.c:622#17 0x09da6932 in send_parsed_php (r=0x3c07b034)
at
/usr/ports/www/php5/core/w-php5-core-5.0.4/php-5.0.4/sapi/
apache/mod_ph
p5.c:637#18 0x1c036732 in ap_invoke_handler ()
---Type  to continue, or q  to quit---
#19 0x1c046e57 in ap_some_auth_required ()
#20 0x1c047007 in ap_process_request ()
#21 0xcfbf4bb0 in ?? ()
#22 0x0003 in ?? ()
#23 0x3c07b034 in ?? ()
#24 0x3c07b034 in ?? ()
#25 0x3c078044 in ?? ()
#26 0xcfbf4be8 in ?? ()
#27 0x1c03fdbd in ap_child_terminate ()

-- 
Edit bug report at http://bugs.php.net/?id=32686&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=32686&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=32686&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=32686&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32686&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32686&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=32686&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=32686&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=32686&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32686&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=32686&r=notwrong
Not enough info:

#24131 [Com]: session_start() warns about failed read

2003-07-02 Thread dont at spam dot me
 ID:   24131
 Comment by:   dont at spam dot me "manfred at yumyum dot at"
 Reported By:  meat at reed dot edu
 Status:   Bogus
 Bug Type: Session related
 Operating System: Linux 2.2.16-22 SMP
 PHP Version:  4.3.2
 New Comment:

ok, i also had this bug with 4.3.2 on a RH 6.2 system and could
reproduce it.

the php source code for this shows in 4.2.2:
-
if (n != sbuf.st_size) {
efree(*val);
return FAILURE;
}
-

while in 4.3.2:
-
if (n != sbuf.st_size) {
if (n == -1)
php_error_docref(NULL TSRMLS_CC, E_WARNING, "read failed:
%s (%d)", strerror(errno), errno);
else
php_error_docref(NULL TSRMLS_CC, E_WARNING, "read returned
less bytes than requested");

efree(*val);
return FAILURE;
}
-
so basically its the same code as in 4.2.2 just with
some warning-messages added.

so i assume the reason for the warnings was also there in 4.2.2. but
with 4.2.2 the whole stuff worked, so maybe that
warning should be safe to ignore.

i just commented the 2 warnings out in the source code, works for me
now (altough not a clean solution;)

i think the whole stuff might be caused by some 32/64 bit troubles in
the system. this is what i found somewhere else:


At a glance I'd say an lstat limit. There's an lstat64() call whose
returned structure has wider size fields. That's the core reason for
this ugly open64/lseek64/... fiasco - binary compatability :-(
Given that system calls are a binary API you're pretty much stuck with
this.
---


Previous Comments:


[2003-06-12 05:39:31] [EMAIL PROTECTED]

Since even you can't reproduce it on another box, we should
assume it's just problem with the system, not PHP.




[2003-06-11 23:13:23] meat at reed dot edu

I certainly hope that I can't reproduce this bug, since 
all it takes is a call to session_start()--all configs 
are out-of-the-box defaults.  No, I am not sure it's 
not a kernel bug, but the same scripts work flawlessly 
on my FreeBSD box.  I guess I will keep it as 
@session_start() and see if the admin will upgrade the 
kernel (and the Apache installation).



[2003-06-11 18:42:38] [EMAIL PROTECTED]

Can you reproduce this within some other machine?
And are you sure it's not just some bug in that kernel?
(latest is 2.2.25 already.. :)




[2003-06-11 17:41:59] meat at reed dot edu

This occurs both when session.save_path is the default 
(/tmp) and when I set it to something else.  The 
session files are created successfully.  Like I said in 
the original submissions, the sessions appear to work 
just fine, and the warning only happens when starting a 
fresh session.  It's totally possible that something is 
broken on the system, but that would seem to be at odds 
with the apparent functionality despite the warning.



[2003-06-11 17:33:46] [EMAIL PROTECTED]

What is the session.save_path set to? And on what kind
of partition does that exist? (never seen this before, might be
something broken in your system..)





The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/24131

-- 
Edit this bug report at http://bugs.php.net/?id=24131&edit=1



#6791 [Com]: PHP.EXE Application Error with a simple timeout

2004-06-24 Thread spam at pasoft dot org
 ID:   6791
 Comment by:   spam at pasoft dot org
 Reported By:  mikebp at gallery-software dot com
 Status:   Closed
 Bug Type: Reproducible Crash
 Operating System: Windows NT 4.0 SP5
 PHP Version:  4.0.2
 New Comment:

I've got a very similar problem with my current project.  I get the
php.exe Application Error, but in my case the error is completely
random.  It will happen on one page of my project one day, and a
totally different page the next, which makes it nearly impossible to
track down and to replicate easily.
An interesting thing about this error is that it occurs in both windows
and linux versions of PHP with absolutley no extensions installed, and
is present in all versions of PHP I've trade to date.

The error reads as fallows on my windows machine:
php.exe - Application Error
The instruction at "0x100bec17" referenced memory at "0x6526176".  The
memory could not be "written".

Click on OK to terminate the program
Click on CANCEL to debug the program

On my linux machine, I just get a blank page when the error occurs (no
real error message)

I'm unsure of what to do to help you guys find the problem, this
project is a fairly large and depending on the bugs mood, it could
occur anywhere.

I don't think my configuration is a problem, but I do think it has
something to do with the rewrite of my XML Parser.

I would greatly appreciate some instruction that would better help you
track down this problem.

Its been driving me nuts for over a year, and any help you could
provide would help me sleep better at night

Thanks
-Sarev0k


Previous Comments:


[2000-12-30 14:02:52] [EMAIL PROTECTED]

No feedback. Reopen this bug report if problem still exists with
PHP4.0.4
or later releases.

--Jani



[2000-11-21 04:27:19] [EMAIL PROTECTED]

Could you try a latest snapshot from http://snaps.php.net/
to verify this is still happening?

--Jani



[2000-09-17 11:57:14] mikebp at gallery-software dot com

I've come across a problem that occurs on my NT 4.0 SP5 PC, that
happens on someone elses but not the same way. Before you write this
off as a configuration issue let me continue...

I've compiled my own (oh no I here you say) php.exe Thread Safe program
with NO extra extensions added. Just the core PHP stuff. I've also
downloaded and used the php4win.de pre-compiled binary and extensions
and the same occurs.

So what is it that occurs? Basically if there is an error of some type
(e.g. a timeout set in the php.ini file, or some other "fatal" error it
will generate on my PC an "OleMainThreadWndName: php.exe - Application
Error" message saying that "The instruction at0x41249623 reference
memory at 0x41249623. The memory could not be read. Click on OK to
terminate the application. Click on CANCEL to debug the application". I
can get this to occur with a simple 3 second timeout within my php.ini
file and running something that takes a little longer.

Now, I have Microsoft Visual C++ 6.0 Sp4 installed on my PC, hence the
message to DEBUG the application. In particular I have a bit of code
that will interegate an ODBC data source that will generate an error
when it hits a certain database table (this is not the issue). An ODBC
error will generate from PHP that again causes the application error.
However, on a friends PC that is almost identical in configuration (NT
4.0 SP5) but WITHOUT MS Visual C++ 6.0 installed on his PC. Using the
same php4win.de binaries his won't cause an application error for the
timeout, but DOES cause a Dr. Watson error for the others. This leads
me to believe that perhaps the PHP WIN32 version doesn't "cleanup" too
well when an error occurs. Could someone try a simple timeout with
MSVC60 installed? I'm very much open to suggestions there is some
configuration issue, but given what I've explained above it would
appear there is perhaps more to it than just that.

Any help would be greatly appreciated.

Regards,

Mike Berry-Porter
[EMAIL PROTECTED]





-- 
Edit this bug report at http://bugs.php.net/?id=6791&edit=1


#28915 [NEW]: php.exe - Application Error

2004-06-24 Thread spam at pasoft dot org
From: spam at pasoft dot org
Operating system: Windows/Linux
PHP version:  Irrelevant
PHP Bug Type: Unknown/Other Function
Bug description:  php.exe - Application Error

Description:

 get the
php.exe Application Error, but in my case the error is completely
random.  It will happen on one page of my project one day, and a totally
different page the next, which makes it nearly impossible to track down
and to replicate easily.
An interesting thing about this error is that it occurs in both windows
and linux versions of PHP with absolutley no extensions installed, and
is present in all versions of PHP I've trade to date.

The error reads as fallows on my windows machine:
php.exe - Application Error
The instruction at "0x100bec17" referenced memory at "0x6526176".  The
memory could not be "written".

Click on OK to terminate the program
Click on CANCEL to debug the program

On my linux machine, I just get a blank page when the error occurs (no
real error message)

I'm unsure of what to do to help you guys find the problem, this project
is a fairly large and depending on the bugs mood, it could occur
anywhere.

I'm sure its not a configuration problem.

My project makes use of:
Object Oriented Design
Sessions
MySQL
Expat (XML)
File I/O

It all started after I rewrote my XML parser, so I've enclosed the link to
it, for inspection.

I would greatly appreciate some instruction that would better help you
track down this problem.

Its been driving me nuts for over a year, and any help you could provide
would help me sleep better at night

Thanks
-Sarev0k

Reproduce code:
---
http://www.pasoft.org/temp/parser.txt


-- 
Edit bug report at http://bugs.php.net/?id=28915&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=28915&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=28915&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=28915&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=28915&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28915&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=28915&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=28915&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28915&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=28915&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28915&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28915&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=28915&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28915&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=28915&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=28915&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28915&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28915&r=float


#28915 [Opn]: php.exe - Application Error

2004-06-24 Thread spam at pasoft dot org
 ID:   28915
 User updated by:  spam at pasoft dot org
 Reported By:  spam at pasoft dot org
 Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: Windows/Linux
 PHP Version:  Irrelevant
 New Comment:

I get a php.exe Application Error, but unlike other cases, I get the
error at
random.  It will happen on one page of my project one day, and a
totally
different page the next, which makes it nearly impossible to track
down
and to replicate easily.
An interesting thing about this error is that it occurs in both
windows
and linux versions of PHP with absolutley no extensions installed, and
is present in all versions of PHP I've trade to date.

The error reads as fallows on my windows machine:
php.exe - Application Error
The instruction at "0x100bec17" referenced memory at "0x6526176".  The
memory could not be "written".

Click on OK to terminate the program
Click on CANCEL to debug the program

On my linux machine, I just get a blank page when the error occurs (no
real error message)

I'm unsure of what to do to help you guys find the problem, this
project
is a fairly large and depending on the bugs mood, it could occur
anywhere.

I'm sure its not a configuration problem.

My project makes use of:
Object Oriented Design
Sessions
MySQL
Expat (XML)
File I/O

It all started after I rewrote my XML parser, so I've enclosed the
link
to it, for inspection.

I would greatly appreciate some instruction that would better help you
track down this problem.

Its been driving me nuts for over a year, and any help you could
provide
would help me sleep better at night

Thanks
-Sarev0k

Reproduce code:
---
http://www.pasoft.org/temp/parser.txt


Previous Comments:
----

[2004-06-25 04:19:06] spam at pasoft dot org

Description:

 get the
php.exe Application Error, but in my case the error is completely
random.  It will happen on one page of my project one day, and a
totally
different page the next, which makes it nearly impossible to track
down
and to replicate easily.
An interesting thing about this error is that it occurs in both
windows
and linux versions of PHP with absolutley no extensions installed, and
is present in all versions of PHP I've trade to date.

The error reads as fallows on my windows machine:
php.exe - Application Error
The instruction at "0x100bec17" referenced memory at "0x6526176".  The
memory could not be "written".

Click on OK to terminate the program
Click on CANCEL to debug the program

On my linux machine, I just get a blank page when the error occurs (no
real error message)

I'm unsure of what to do to help you guys find the problem, this
project
is a fairly large and depending on the bugs mood, it could occur
anywhere.

I'm sure its not a configuration problem.

My project makes use of:
Object Oriented Design
Sessions
MySQL
Expat (XML)
File I/O

It all started after I rewrote my XML parser, so I've enclosed the link
to it, for inspection.

I would greatly appreciate some instruction that would better help you
track down this problem.

Its been driving me nuts for over a year, and any help you could
provide
would help me sleep better at night

Thanks
-Sarev0k

Reproduce code:
---
http://www.pasoft.org/temp/parser.txt






-- 
Edit this bug report at http://bugs.php.net/?id=28915&edit=1



#29137 [NEW]: php_gettext.dll missing from Win distribution

2004-07-14 Thread spam at dubbekarl dot dk
From: spam at dubbekarl dot dk
Operating system: Windows
PHP version:  4.3.8
PHP Bug Type: Unknown/Other Function
Bug description:  php_gettext.dll missing from Win distribution

Description:

The file extensions/php_gettext.dll is missing from php-4.3.8-Win32.zip
distribution.


-- 
Edit bug report at http://bugs.php.net/?id=29137&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=29137&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=29137&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=29137&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=29137&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29137&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=29137&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=29137&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=29137&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=29137&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=29137&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=29137&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=29137&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29137&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=29137&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=29137&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=29137&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29137&r=float


#29155 [Com]: switch odd behaviour with mixed int/string variables

2004-07-14 Thread no at spam dot forme
 ID:   29155
 Comment by:   no at spam dot forme
 Reported By:  phpbug at bart dot w-wa dot pl
 Status:   Bogus
 Bug Type: Variables related
 Operating System: Linux
 PHP Version:  4.3.7
 New Comment:

you test one integer 0 against a string, which causes php to cast your
string into an integer, which results in 0 for the string  'something'.
thus, the first case comparison looks like 0 == 'something' <=> 0 == 0
<=> true, the program prints 'something' and breaks the switch. Your
result is the expected result. I think this should be more explicitly
empathized in the php manual.


Previous Comments:


[2004-07-14 16:49: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

.



[2004-07-14 16:46:21] phpbug at bart dot w-wa dot pl

Description:

Due to FU typecasting switch produces unexpected results when one of
the cases is string, but variable passed to switch is int. 
 

Reproduce code:
---
$x = 0;
switch($x) {
case 'something': echo 'something'; break;
case 0:   echo 'zero'; break;
default:  echo 'something else';
};


Expected result:

zero

Actual result:
--
something





-- 
Edit this bug report at http://bugs.php.net/?id=29155&edit=1


#27674 [Com]: getimagesize eat up hundreds of memory, can't do with a good swf

2004-07-19 Thread spam at vano dot org
 ID:   27674
 Comment by:   spam at vano dot org
 Reported By:  xuefer at 21cn dot com
 Status:   Bogus
 Bug Type: GetImageSize related
 Operating System: *
 PHP Version:  4.3.5
 New Comment:

I have the same problem on RH9 + Apache 2.0.49 + PHP5.0.0
on some (all) .swf files getimagesize() function crashes the Apache2.
in the error log it sais:

FATAL:  erealloc():  Unable to allocate -2067465216 bytes

PHP compilled with:

./configure --prefix=/php5 --with-config-file-path=/php5
--with-apxs2=/apache2/bin/apxs --with-mod_charset --enable-embed
--with-zlib --enable-dbx --enable-dio --enable-exif --enable-ftp
--with-iconv --with-gdbm --with-gmp --with-ncurses --with-mcrypt
--with-crypt --with-gd=/usr/local --with-freetype-dir=/usr/lib
--with-gif-dir=/usr/local --enable-gd-native-ttf --with-ttf
--with-gettext --with-zip=/usr/lib --enable-calendar --enable-mbstring
--with-kerberos --with-mysql
--with-mysql-sock=/var/lib/mysql/mysql.sock --enable-sockets
--with-pear --enable-shared=all


Previous Comments:


[2004-04-09 12:37:34] [EMAIL PROTECTED]

The flash file you provided is corrupted, here's same file, uncorrupted
which works fine:

http://www.miniclip.com/gamefiles0304/bushshootout_game.swf



[2004-04-09 04:00:39] xuefer at 21cn dot com

reoped and updated changed
cos 125-bad.swf is really "fine playing in flashplayer" swf



[2004-03-27 06:16:22] xuefer at 21cn dot com

yes, just a guess
because no matter how much memory it alloc, uncompress() just return
Z_BUF_ERROR

i don't know why this swf is bad, it plays ok in stand alone
flashplayer and ie browser

by the way, when i test it with a "good" swf, the part of erealloc()
don't even executed. In another word, the first uncompress:
if (uncompress(b, &len, a, sizeof(a)) != Z_OK) {
is Z_OK



[2004-03-27 05:58:53] [EMAIL PROTECTED]

Where does the 50MByte const come from, a guess?



[2004-03-26 22:09:42] xuefer at 21cn dot com

this bug may be "can't reproduce" not "closed"

this is the "fix" with testing code
Index: ext/standard/image.c
===
RCS file: /repository/php-src/ext/standard/image.c,v
retrieving revision 1.72.2.13
diff -u -r1.72.2.13 image.c
--- ext/standard/image.c12 Nov 2003 22:56:09 - 
1.72.2.13
+++ ext/standard/image.c27 Mar 2004 03:11:00 -
@@ -196,8 +196,8 @@
 
long bits;
unsigned char a[64];
-   unsigned long len=64, szlength;
-   int factor=1,maxfactor=16;
+   unsigned long len=64, szlength, maxlength = 50*1024*1024;
+   int factor=1,maxfactor=8;
int slength, status=0;
char *b, *buf=NULL, *bufz=NULL;
 
@@ -226,8 +226,13 @@

do {
szlength=slength*(1< maxlength) {
+   break;
+   }
+   printf("szlength: %d\n", szlength);
buf = (char *) erealloc(buf,szlength);
status = uncompress(buf, &szlength, bufz,
slength);
+   printf("status: %d\n", (int) (status ==
Z_BUF_ERROR));
} while ((status==Z_BUF_ERROR)&&(factorhttp://bugs.php.net/27674

-- 
Edit this bug report at http://bugs.php.net/?id=27674&edit=1


[PHP-BUG] Bug #65809 [NEW]: interface, abstract static function

2013-10-02 Thread spam at krol dot me
From: spam at krol dot me
Operating system: 
PHP version:  Irrelevant
Package:  Class/Object related
Bug Type: Bug
Bug description:interface, abstract static function

Description:

abstract static function in class isn't allowed,
but you can define static function in interface

This leads to funny inconsistency where you can create abstract static
function using interfaces



Test script:
---
//abstract class A { abstract static function a(); } //invalid

interface I { static function i(); } //valid
abstract class B implements I {} //valid
//class C extends B{} // invalid
//Fatal error: Class C contains 1 abstract method and must therefore be
declared abstract or implement the remaining methods (I::i) in php shell
code on line 1

class D extends B{
static function i(){echo "I have to be implemented"; }
}


-- 
Edit bug report at https://bugs.php.net/bug.php?id=65809&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=65809&r=trysnapshot54
Try a snapshot (PHP 5.5):   
https://bugs.php.net/fix.php?id=65809&r=trysnapshot55
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=65809&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=65809&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=65809&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65809&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=65809&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=65809&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65809&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=65809&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65809&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65809&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=65809&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65809&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=65809&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=65809&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65809&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65809&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65809&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=65809&r=mysqlcfg



Bug #65809 [Opn]: interface, abstract static function

2013-10-02 Thread spam at krol dot me
Edit report at https://bugs.php.net/bug.php?id=65809&edit=1

 ID: 65809
 User updated by:spam at krol dot me
 Reported by:spam at krol dot me
 Summary:interface, abstract static function
 Status: Open
 Type:   Bug
 Package:Class/Object related
-PHP Version:Irrelevant
+PHP Version:5.3.15
 Block user comment: N
 Private report: N

 New Comment:

I changed PHP version as it IS revelant

According to this

http://php.net/manual/en/migration52.incompatible.php

Dropped abstract static class functions. Due to an oversight, PHP 5.0.x and 
5.1.x allowed abstract static functions in classes. As of PHP 5.2.x, only 
interfaces can have them.


Previous Comments:

[2013-10-02 23:43:36] phpmpan at mpan dot pl

Abstract static methods are allowed. Abstract static *constructors* aren't.


[2013-10-02 10:58:34] spam at krol dot me

Description:

abstract static function in class isn't allowed,
but you can define static function in interface

This leads to funny inconsistency where you can create abstract static function 
using interfaces



Test script:
---
//abstract class A { abstract static function a(); } //invalid

interface I { static function i(); } //valid
abstract class B implements I {} //valid
//class C extends B{} // invalid
//Fatal error: Class C contains 1 abstract method and must therefore be 
declared abstract or implement the remaining methods (I::i) in php shell code 
on line 1

class D extends B{
static function i(){echo "I have to be implemented"; }
}







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65809&edit=1


Bug #65809 [Opn]: interface, abstract static function

2013-10-02 Thread spam at krol dot me
Edit report at https://bugs.php.net/bug.php?id=65809&edit=1

 ID: 65809
 User updated by:spam at krol dot me
 Reported by:spam at krol dot me
 Summary:interface, abstract static function
 Status: Open
 Type:   Bug
 Package:Class/Object related
 PHP Version:5.3.15
 Block user comment: N
 Private report: N

 New Comment:

And use this test case. It don't make use of constructor

Test script:
---

abstract class A { abstract static function aa(); } //invalid
//Strict Standards: Static function A::aa() should not be abstract in php shell 
code on line 1

interface I { static function ii(); } //valid
abstract class B implements I {} //valid
//class C extends B{} // invalid
//Fatal error: Class C contains 1 abstract method and must therefore be 
declared abstract or implement the remaining methods (I::i) in php shell code 
on line 1

class D extends B{
static function ii(){echo "I have to be implemented"; }
}


Previous Comments:

[2013-10-03 05:10:24] spam at krol dot me

I changed PHP version as it IS revelant

According to this

http://php.net/manual/en/migration52.incompatible.php

Dropped abstract static class functions. Due to an oversight, PHP 5.0.x and 
5.1.x allowed abstract static functions in classes. As of PHP 5.2.x, only 
interfaces can have them.


[2013-10-02 23:43:36] phpmpan at mpan dot pl

Abstract static methods are allowed. Abstract static *constructors* aren't.

----
[2013-10-02 10:58:34] spam at krol dot me

Description:

abstract static function in class isn't allowed,
but you can define static function in interface

This leads to funny inconsistency where you can create abstract static function 
using interfaces



Test script:
---
//abstract class A { abstract static function a(); } //invalid

interface I { static function i(); } //valid
abstract class B implements I {} //valid
//class C extends B{} // invalid
//Fatal error: Class C contains 1 abstract method and must therefore be 
declared abstract or implement the remaining methods (I::i) in php shell code 
on line 1

class D extends B{
static function i(){echo "I have to be implemented"; }
}







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65809&edit=1


Bug #40417 [Com]: Suddenly binding as many vars as there are *identical* prepared tokens

2011-12-26 Thread spam at shishnet dot org
Edit report at https://bugs.php.net/bug.php?id=40417&edit=1

 ID: 40417
 Comment by: spam at shishnet dot org
 Reported by:exaton at free dot fr
 Summary:Suddenly binding as many vars as there are
 *identical* prepared tokens
 Status: Closed
 Type:   Bug
 Package:PDO related
 Operating System:   Windows XP Pro SP2
 PHP Version:5.2.1
 Block user comment: N
 Private report: N

 New Comment:

Can someone clarify what is meant by "fixed"? I'm finding that binding multiple 
paramaters with the same name works fine for PDO/mysql, but fails in weird ways 
for PDO/postgres...


Previous Comments:

[2007-03-06 00:53:01] il...@php.net

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.




[2007-03-03 15:13:15] exaton at free dot fr

*Damn* *it*.

Good on you for spotting that, mgagne. For some freaking reason I was so bent 
on examining the documentation for binding methods that I skipped prepare(). No 
idea why.

Ilia, my apologies again, therefore ; but really I had not understood your 
intermediate reply. At least now we have the knowledge that you were working 
with all along.

So now, of course, the question is : should the spec' be changed in favor of 
PHP's behaviour up until now ? I of course advocate changing the manual, 
allowing for the new "feature" of multiple parameter markers with the same 
name. I argue with the following points :

1) This issue already seems quite popular ; obviously, quite a few people 
relied on the feature without realizing that it went against the true 
specification.

Now that, of course, is a rather specious argument ; developers working with 
PHP should stick to the spec' and get bent if they make use of unintended 
functionality which is suddenly dropped -- I'm the first to agree. However :

2) I see no compelling reason for which PHP should not "support" this feature. 
It is a very natural feature that makes perfect sense when it is used. It is 
most practical is naive search engine implementations for small sites 
(auto-generated : WHERE (title LIKE :term0 OR text LIKE :term0 OR author_name 
LIKE :term0) AND (title LIKE :term1 OR text LIKE :term1 OR author_name LIME 
:term1) ...).

The underlying code is already designed in such a way as to support the feature 
of multiple parameter markers with the same name. The only change in PHP 5.2.1 
is a condition check that throws an error, based on the specification. And 
admittedly, writing that check in conformance with the "feature" would be 
expensive (see e.g. my suggestion above) and/or cumbersome or complicated, etc.

This would be a call for the PHP core developers.


[2007-03-02 21:59:15] mgagne at generationphp dot net

Unfortunately for some people, Iliaa is right:

"You cannot use a named parameter marker of the same name twice in a prepared 
statement."

However, even if it's was added to the documentation about a year ago (Sun Jan 
8 14:02:42 2006 UTC), the behavior changed between PHP 5.2.0 and PHP 5.2.1 and 
it should have been added to the changelog as well.

I didn't know when happened to my application until I saw this bug report.


[2007-03-02 07:25:23] mgagne at generationphp dot net

Hi,

I have the same bug using PHP 5.2.1. I had to downgrade to PHP 5.2.0 and it 
fixed the problem.

I'm using PDO::MYSQL. I have 2 bound variables in my request. All 2 have the 
same name. Since I'm only binding value once using PDO::bindValue, the error is 
triggered without valid reason.

My query is similar to this one:

SELECT *
FROM posts
WHERE post_title LIKE :q OR
  post_text LIKE :q

I'm binding value once like this:

$sth->bindValue(':q', "$q", PDO::PARAM_STR);

This means there is something wrong within the internal count.

Also for the records, issue does not seem to be related to any specific PDO 
driver. (issue is present with PostGreSQL and MySQL driver)

Thanks


[2007-03-01 15:30:09] exaton at free dot fr

@ xing : I had not seen that word from Wez, but indeed is does make sense to 
add the check in principle -- the API should make sure that enough tokens were 
bound (to enhance its service and avoid "silent" bugs) and can also guarantee 
that not too many were bound (might as well).

It's back to the proble

[PHP-BUG] Bug #64350 [NEW]: fmod returning wrong values for negative dividends

2013-03-04 Thread spam at michaelburri dot ch
From: spam at michaelburri dot ch
Operating system: OS X 10.8.2 (12C3012)
PHP version:  5.4Git-2013-03-04 (Git)
Package:  Math related
Bug Type: Bug
Bug description:fmod returning wrong values for negative dividends

Description:

The fmod(dividend, divisor) function returns wrong values for negative
dividends 
that are smaller than the divisor.

For example -0.8 mod 6 => -1 * 6 + 5.2, so the result of the modulo (=
remainder) 
is 5.2.

Test script:
---


Expected result:

5.2

Actual result:
--
-0.8

-- 
Edit bug report at https://bugs.php.net/bug.php?id=64350&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=64350&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=64350&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=64350&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=64350&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=64350&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64350&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=64350&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=64350&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64350&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=64350&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64350&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64350&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=64350&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64350&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=64350&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=64350&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64350&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64350&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64350&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=64350&r=mysqlcfg



Bug #61141 [Com]: curl_multi_select returns -1

2012-06-06 Thread ihate at spam dot com
Edit report at https://bugs.php.net/bug.php?id=61141&edit=1

 ID: 61141
 Comment by: ihate at spam dot com
 Reported by:amoo_miki at yahoo dot com
 Summary:curl_multi_select returns -1
 Status: Assigned
 Type:   Bug
 Package:cURL related
 Operating System:   Windows 7 x64
 PHP Version:5.3.10
 Assigned To:pierrick
 Block user comment: N
 Private report: N

 New Comment:

Always returns -1 on Windows 7 64bit. Tried on 5.4 and 5.4.3. It worked a 
couple 
of months ago, perhaps some Win7 update changed something.


Previous Comments:

[2012-05-30 02:48:04] larue...@php.net

Pierrick, could you please look at this? :)


[2012-05-29 11:52:09] amoo_miki at yahoo dot com

I can confirm that PHP 5.4.3 (cli) (built: May  8 2012 00:23:27) suffers from 
the same bug.


[2012-05-25 12:08:45] kulminaator at gmail dot com

Running PHP 5.4.0 on Windows 7 has the same issue,  curl_multi_select always  
returns -1 


PHP Version => 5.4.0
System => Windows NT MSA-3644048 6.1 build 7601 (Windows 7 Enterprise Edition 
Service Pack 1) i586

cURL support => enabled
cURL Information => 7.24.0
Age => 3
Features
AsynchDNS => Yes
Debug => No
GSS-Negotiate => Yes
IDN => No
IPv6 => Yes
Largefile => Yes
NTLM => Yes
SPNEGO => No
SSL => Yes
SSPI => Yes
krb4 => No
libz => Yes
CharConv => No
Protocols => dict, file, ftp, ftps, gopher, http, https, imap, imaps, ldap, 
pop3, pop3s, rtsp, scp, sftp, smtp, smtps, telnet, tftp
Host => i386-pc-win32
SSL Version => OpenSSL/0.9.8t
ZLib Version => 1.2.5
libSSH Version => libssh2/1.3.0


[2012-04-03 16:26:35] bompus at gmail dot com

Related to 60790 and 61240


[2012-02-29 08:17:12] amoo_miki at yahoo dot com

The curl details on 5.3.9 are:
cURL support => enabled
cURL Information => 7.21.7
Age => 3
Features
AsynchDNS => Yes
Debug => No
GSS-Negotiate => Yes
IDN => No
IPv6 => Yes
Largefile => Yes
NTLM => Yes
SPNEGO => No
SSL => Yes
SSPI => Yes
krb4 => No
libz => Yes
CharConv => No
Protocols => dict, file, ftp, ftps, gopher, http, https, imap, imaps, ldap, 
pop3, pop3s, rtsp, scp, sftp, smtp, smtps, telnet, tftp
Host => i386-pc-win32
SSL Version => OpenSSL/0.9.8r
ZLib Version => 1.2.5
libSSH Version => libssh2/1.2.7


meaning the changes are related to one of the following:
   5.3.9 -> 5.3.10
libcURL:  7.21.7 -> 7.24.0
GSS/Negotiate:   Yes -> NO
SSPI:Yes -> No
OpenSSL:  0.9.8r -> 0.9.8t
libSSH:1.2.7 -> 1.3.0

I don't see a reason for the last 2 effecting anything.




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

https://bugs.php.net/bug.php?id=61141


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61141&edit=1


#48443 [NEW]: is_readable returns false on a file which is readable for group

2009-05-31 Thread spam at noamik dot de
From: spam at noamik dot de
Operating system: Debian Lenny
PHP version:  5.2.9
PHP Bug Type: Filesystem function related
Bug description:  is_readable returns false on a file which is readable for 
group

Description:

When executing is_readable("/path/to/my/file.txt") the function returns
false, even so file permissions are as follows:
-rw-rw 1 someuser www-data 1529 2009-06-01 04:28 file.txt
where www-data is a group the web server executing the script is member
of.
To eliminate caching issues, clearstatcache(); has been executed before.
The same goes for is_writable. I'm not shure if it is intended or a bug,
but if it is intended, the documentation would be wrong (at least IMHO).
If it is intended, a similar function for group rights would be needed ...

Reproduce code:
---
---
>From manual page: function.is-readable
---


Expected result:

In the above example, is_readable should return true ...

Actual result:
--
is_readable returns true, but file can be opened with fopen anyways ...

-- 
Edit bug report at http://bugs.php.net/?id=48443&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48443&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48443&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48443&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48443&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48443&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48443&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48443&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48443&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48443&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48443&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48443&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48443&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48443&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48443&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48443&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48443&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48443&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48443&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48443&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48443&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48443&r=mysqlcfg



#48443 [Opn]: is_readable returns false on a file which is readable for group

2009-05-31 Thread spam at noamik dot de
 ID:   48443
 User updated by:  spam at noamik dot de
 Reported By:  spam at noamik dot de
 Status:   Open
 Bug Type: Filesystem function related
 Operating System: Debian Lenny
 PHP Version:  5.2.9
 New Comment:

In actual result: it should read "is_readable returns *false*, but file
can be opened with fopen anyways ..."


Previous Comments:


[2009-06-01 02:51:52] spam at noamik dot de

Description:

When executing is_readable("/path/to/my/file.txt") the function returns
false, even so file permissions are as follows:
-rw-rw 1 someuser www-data 1529 2009-06-01 04:28 file.txt
where www-data is a group the web server executing the script is member
of.
To eliminate caching issues, clearstatcache(); has been executed
before. The same goes for is_writable. I'm not shure if it is intended
or a bug, but if it is intended, the documentation would be wrong (at
least IMHO).
If it is intended, a similar function for group rights would be needed
...

Reproduce code:
---
---
>From manual page: function.is-readable
---


Expected result:

In the above example, is_readable should return true ...

Actual result:
--
is_readable returns true, but file can be opened with fopen anyways ...





-- 
Edit this bug report at http://bugs.php.net/?id=48443&edit=1



#18556 [Com]: Setting locale to 'tr_TR' lowercases class names

2009-06-18 Thread spam at pamignot dot org
 ID:   18556
 Comment by:   spam at pamignot dot org
 Reported By:  spud at nothingness dot org
 Status:   No Feedback
 Bug Type: Scripting Engine problem
 Operating System: Linux (RedHat 7.2)
 PHP Version:  5CVS, 4CVS (2005-10-04)
 Assigned To:  andrei
 New Comment:

This bug is still alive !!
Can someone have a look to this ?

While it is not fixed, you can set LC_CTYPE to another locale to get it
works again.


Previous Comments:


[2009-03-05 19:28:22] cankoy at ymail dot com

This also occurs in function names:


outputs:
---
tr_TR

Fatal error: Call to undefined function HI5() in...
---
whereas the following works OK:


outputs:
---
tr_TR
Five!
---

using php-cli 5.2.6 on Ubuntu 8.10.



[2008-05-20 07:44:31] c dot muench at netz98 dot de

This bug is still alive in version 5.2.5.
I tested the posted script and get the same results.



[2008-04-21 18:40:05] jreeve at pelagodesign dot com

We are still getting this bug with PHP 5.2.3
PHP 5.2.3 (cli) (built: Feb  7 2008 06:40:06)

As noted below, this function:


Produces this error:
tr_TR.utf8
DOMImplementationList No Longer Exists!
DOMImplementationSource No Longer Exists!
DOMImplementation No Longer Exists!
DOMProcessingInstruction No Longer Exists!
RecursiveIteratorIterator No Longer Exists!
IteratorIterator No Longer Exists!
FilterIterator No Longer Exists!
RecursiveFilterIterator No Longer Exists!
ParentIterator No Longer Exists!
LimitIterator No Longer Exists!
CachingIterator No Longer Exists!
RecursiveCachingIterator No Longer Exists!
NoRewindIterator No Longer Exists!
AppendIterator No Longer Exists!
InfiniteIterator No Longer Exists!
RegexIterator No Longer Exists!
RecursiveRegexIterator No Longer Exists!
EmptyIterator No Longer Exists!
ArrayIterator No Longer Exists!
RecursiveArrayIterator No Longer Exists!
SplFileInfo No Longer Exists!
DirectoryIterator No Longer Exists!
RecursiveDirectoryIterator No Longer Exists!
SimpleXMLIterator No Longer Exists!
InvalidArgumentException No Longer Exists!
__PHP_Incomplete_Class No Longer Exists!



[2007-08-16 17:24:36] tokul at users dot sourceforge dot net

class_exists() function uses zend_str_tolower(). zend_str_tolower()
uses
zend_tolower(). zend_tolower() uses _tolower_l() on Windows and
tolower() on other oses. _tolower_l() is not locale aware. tolower() is
LC_CTYPE aware.

Turkish language can trigger some i18n programming errors in case
insensitive comparison functions, because small latin i is not equal to
capital latin i in Turkish language. Azerbaijani (az) and Kurdish (ku)
locales use Turkish language rules on Linux.

P.S. According to msdn documentation _tolower_l() is not meant to be
called directly and is provided for internal use by _totlower_l



[2007-06-03 22:22:16] mike dot ditum at tripleplay-services dot com

I can confirm that this bug is still there... I'm testing with snapshot
php5.2-200706031230 and get the following...

Instantiating an infoBlob with a lowercase iFooInstantiating an
InfoBlob with an uppercase I
Fatal error: Class 'InfoBlob' not found in
/root/php5.2-200706031230/test.php on line 18

Another simple script I have discovered that shows the same problem
is...



For this program I get the following output...

[r...@blankfedora php5.2-200706031230]# sapi/cli/php  ~/test2.php
tr_TR.utf8
DOMImplementationList No Longer Exists!
DOMImplementationSource No Longer Exists!
DOMImplementation No Longer Exists!
DOMProcessingInstruction No Longer Exists!
RecursiveIteratorIterator No Longer Exists!
IteratorIterator No Longer Exists!
FilterIterator No Longer Exists!
RecursiveFilterIterator No Longer Exists!
ParentIterator No Longer Exists!
LimitIterator No Longer Exists!
CachingIterator No Longer Exists!
RecursiveCachingIterator No Longer Exists!
NoRewindIterator No Longer Exists!
AppendIterator No Longer Exists!
InfiniteIterator No Longer Exists!
RegexIterator No Longer Exists!
RecursiveRegexIterator No Longer Exists!
EmptyIterator No Longer Exists!
ArrayIterator No Longer Exists!
RecursiveArrayIterator No Longer Exists!
SplFileInfo No Longer Exists!
DirectoryIterator No Longer Exists!
RecursiveDirectoryIterator No Longer Exists!
SimpleXMLIterator No Longer Exists!
InvalidArgumentException No Longer Exists!
__PHP_Incomplete_Class No Longer Exists!

This does not just occur with tr_TR.utf8 it also occurs with the
following locales... tr_CY.utf8, ku_TR.utf8 and az_AZ.utf8.

Thanks



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bu

#48816 [NEW]: IteratorIterator seek() causes bus error

2009-07-06 Thread spam at burgestrand dot se
From: spam at burgestrand dot se
Operating system: Mac OS 10.5.7
PHP version:  5.3.0
PHP Bug Type: SPL related
Bug description:  IteratorIterator seek() causes bus error

Description:

After using seek() on an IteratorIterator containing an ArrayIterator the
next() call results in a bus error.

Also, the seek() method doesn’t seem to advance the key to the specified
position on the inner iterator (unless issuing getInnerIterator()->seek(x)
directly and calling getInnerIterator()->current()).

Reproduce code:
---
rewind();
$iiter->seek(2);

var_dump($iiter->current());
$iiter->next(); // bus error
var_dump($iiter->current());

/* End of file */

Expected result:

int(2)
int(3)

Actual result:
--
int(0)

-- 
Edit bug report at http://bugs.php.net/?id=48816&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48816&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48816&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48816&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48816&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48816&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48816&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48816&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48816&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48816&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48816&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48816&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48816&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48816&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48816&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48816&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48816&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48816&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48816&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48816&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48816&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48816&r=mysqlcfg



#44047 [Com]: IIS Worker Process stopped working

2008-02-28 Thread nonya at spam dot this
 ID:   44047
 Comment by:   nonya at spam dot this
 Reported By:  matthew dot horner at redprairie dot com
 Status:   Open
 Bug Type: IIS related
 Operating System: Windows Vista
 PHP Version:  5.2.5
 New Comment:

To elaborate on Matthew, (Every PHP5\Vista\IIS7 machine I have every
worked on does this; 20+ machines)

The same error can be achieved back-to-back simply by running any PHP,
which in turn will add 1 active application to the DefaultAppPool.  This
is visible in the IIS7 Manager.  You can select the DefaultAppPool and
click "Recycle...", wait 3-5 secs (because WerFault.exe kicks in,
Windows Error Reporting Service) and you have a "IIS Worker Process has
failed" message with the event in the windows event log the way Matt
described which says the fault came from c:\windows\system32\ntdll.dll

If the PHP dev guys are trying to recreate this issue, you need to be
using Latest PHP5/IIS7/ISAPI-Configuration/Vista

This has been going on since Vista RC1.  Everyone who is not getting
this error may not be complaining because the error doesn't seem to do
major damage.

The closest thing to a resolution I have seen since the release of
Vista is to just adjust the timing of the automated recycle cycle. 
Since the error is only occurring during recycling, they have been
scheduling 1 recycle per day, hence 1 crash per day.

There are many, many, many, MANY forums and support threads with people
having the same problem, they just aren't posting here.
Here are a few:
forums.techarena.in/showthread.php?t=686723
www.developersdex.com/asp/message.asp?p=592&r=6057007
www.issociate.de/board/post/468636/IIS_+_PHP_--_Worker_Process_alert_&_w3wp.exe_crash?.html
forums.techarena.in/showthread.php?t=821723
groups.google.com/group/comp.lang.php/browse_thread/thread/93aef1ff2f0ba3b0
www.thescripts.com/forum/thread742344.html


Previous Comments:


[2008-02-05 16:17:54] matthew dot horner at redprairie dot com

I removed all extensions and re-tested with the same results.



[2008-02-05 15:01:16] [EMAIL PROTECTED]

Do you have any extensions loaded via php.ini or this is purely whats
statically built into PHP?

If you do have extensions can you disable them all and see if you can
reproduce the problem.



[2008-02-05 14:17:23] matthew dot horner at redprairie dot com

I have tested with the latest and the crash is still occurring with the
exact same stack trace.  The build date of the current installation is
Feb 5 2008 08:04:21.



[2008-02-05 05:07:30] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.2-win32-installer-latest.msi





[2008-02-04 23:42:22] matthew dot horner at redprairie dot com

Description:

I am able to reproduce this issue as others have seen reported in other
bug reports with no solution.  If you simply
run the following script, the error should reproduce itself.

I have done several different tests using IIS7 and have concluded that
there are no issues with PHP4 but 5.1.6 and 5.2.5 both cause the crash.

I am using Vista Businesss and confirmed with several other developers
in our organization the same issues with IIS7 on Vista.  Those
reporting
this issue to our group reported that the problem was also seen but
not
limited to 5.2.3.

I have slightly altered my configuration of IIS to accelerate the
crash.
 Using the IIS Manager, I clicked Application Pools, selected
DefaultAppPool and clicked Advanced Settings.  In settings
configuration
screen, I changed the Idle Timeout (minutes) under Process Model to 1.

Do an iisreset, execute the example script above in the brower and
wait.
 Within one minute you should see a message stating the 'IIS Worker
Process has stopped working.'

I downloaded the DebugDiag tool from
http://www.microsoft.com/downloads/details.aspx?FamilyID=28bd5941-c458-4
6f1-b24d-f60151d875a3&DisplayLang=en

If you would like the complete log of the crash as reported by the
DebugDiag
tool, I would be more than happy to pass it along.  If any assistance
is
required, please feel free to contact me and I will do everything I
can.

Thanks,
Matt

Reproduce code:
---


Expected result:

The phpinfo page, shows as expected.  However, after the Idle Timeout
specified in IIS has been reached, a crash message is displayed.  Expect
this message not be display after the offending code is fixed.

Actual resul

#44047 [Com]: IIS Worker Process stopped working

2008-03-03 Thread nonya at spam dot this
 ID:   44047
 Comment by:   nonya at spam dot this
 Reported By:  matthew dot horner at redprairie dot com
 Status:   Open
 Bug Type: IIS related
 Operating System: Windows Vista
 PHP Version:  5.2.5
 New Comment:

Yea, that is a horrible idea.  You are literally telling IIS to never
clean it's caches or do garbage collection on the AppPools.  I am sure
that there are more critical consequences on high-volume web servers if
you decide to do this.

PHP just fix it


Previous Comments:


[2008-03-03 13:52:11] matthew dot horner at redprairie dot com

Setting the recycle time to 0 would not be considered a solution, but
rather a workaround.  The solution to the problem would require a code
change.  That change would resolve the issue, so that the workaround
would not have to be applied.  This change to standard code would also
avoid changing standard configuration of the IIS server for _every_
instance that has a PHP 5 installation.



[2008-03-02 12:27:34] satan at dclxvi dot nl

lol, your test is the solution... where you set it idle time out to 1
to test it earlier, just set it to '0'. it will error out once more and
the next time it starts it will stay on.. there is no problem with
leaving it on..



[2008-02-29 04:37:22] nonya at spam dot this

To elaborate on Matthew, (Every PHP5\Vista\IIS7 machine I have every
worked on does this; 20+ machines)

The same error can be achieved back-to-back simply by running any PHP,
which in turn will add 1 active application to the DefaultAppPool.  This
is visible in the IIS7 Manager.  You can select the DefaultAppPool and
click "Recycle...", wait 3-5 secs (because WerFault.exe kicks in,
Windows Error Reporting Service) and you have a "IIS Worker Process has
failed" message with the event in the windows event log the way Matt
described which says the fault came from c:\windows\system32\ntdll.dll

If the PHP dev guys are trying to recreate this issue, you need to be
using Latest PHP5/IIS7/ISAPI-Configuration/Vista

This has been going on since Vista RC1.  Everyone who is not getting
this error may not be complaining because the error doesn't seem to do
major damage.

The closest thing to a resolution I have seen since the release of
Vista is to just adjust the timing of the automated recycle cycle. 
Since the error is only occurring during recycling, they have been
scheduling 1 recycle per day, hence 1 crash per day.

There are many, many, many, MANY forums and support threads with people
having the same problem, they just aren't posting here.
Here are a few:
forums.techarena.in/showthread.php?t=686723
www.developersdex.com/asp/message.asp?p=592&r=6057007
www.issociate.de/board/post/468636/IIS_+_PHP_--_Worker_Process_alert_&_w3wp.exe_crash?.html
forums.techarena.in/showthread.php?t=821723
groups.google.com/group/comp.lang.php/browse_thread/thread/93aef1ff2f0ba3b0
www.thescripts.com/forum/thread742344.html



[2008-02-05 16:17:54] matthew dot horner at redprairie dot com

I removed all extensions and re-tested with the same results.



[2008-02-05 15:01:16] [EMAIL PROTECTED]

Do you have any extensions loaded via php.ini or this is purely whats
statically built into PHP?

If you do have extensions can you disable them all and see if you can
reproduce the problem.



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/44047

-- 
Edit this bug report at http://bugs.php.net/?id=44047&edit=1



#46338 [NEW]: Segfault on script ending

2008-10-18 Thread spam at pamignot dot org
From: spam at pamignot dot org
Operating system: Linux 2.6.22-15-generic (Ubuntu)
PHP version:  5.3.0alpha2
PHP Bug Type: Apache2 related
Bug description:  Segfault on script ending

Description:

I just passed from 5.1.6 to 5.3.

I cannot give a quick code to reproduce the bug, but the script actually
does those actions :
- getting GET POST COOKIE information, giving them to HTMLPurifier and set
an array of the result
- define custom error handler
- execute action given by user
- display HTML result page

The script goes to the end, echo'ing wanted html page but it results in a
segfault.

If I comment out the next line, or if I comment out the static method
'exception_error_handler' from my class MyException, the script just works
fine :

set_error_handler(array('MyException', 'exception_error_handler'));

But if I let declared the method 'exception_error_handler', even with no
code inside, returning true or false, or throwing an exception, the script
ends up with a segfault.


Reproduce code:
---
/* some code using some PEAR packages, 
custom error handler, echo'ing a HTML page */
exit();

Expected result:

Expected result is displaying HTML page to user.

Actual result:
--
The actual result is the output of my desired HTML page, ending with a
segfault :

# gdb php
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) r index.php
Starting program: /usr/local/bin/php index.php
[Thread debugging using libthread_db enabled]
[New Thread -1223292352 (LWP 21507)]

/* here comes my HTML page */

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1223292352 (LWP 21507)]
zend_hash_destroy (ht=0x8ce9ac4) at
/home/myhome/php-5.3.0alpha2/Zend/zend_hash.c:524
524 p = p->pListNext;
(gdb) bt
#0  zend_hash_destroy (ht=0x8ce9ac4) at
/home/myhome/php-5.3.0alpha2/Zend/zend_hash.c:524
#1  0x083d34e7 in _zval_dtor_func (zvalue=0x8ce9a78) at
/home/myhome/php-5.3.0alpha2/Zend/zend_variables.c:43
#2  0x083d2c55 in zend_ptr_stack_apply (stack=0x88ba628, func=0x83d3440
<_zval_dtor_func>) at
/home/myhome/php-5.3.0alpha2/Zend/zend_ptr_stack.c:90
#3  0x083d2c9f in zend_ptr_stack_clean (stack=0x88ba628, func=0x83d3440
<_zval_dtor_func>, free_elements=1 '\001')
at /home/myhome/php-5.3.0alpha2/Zend/zend_ptr_stack.c:97
#4  0x083c67f9 in shutdown_executor (tsrm_ls=0x88b82a0) at
/home/myhome/php-5.3.0alpha2/Zend/zend_execute_API.c:271
#5  0x083d3ab9 in zend_deactivate (tsrm_ls=0x88b82a0) at
/home/myhome/php-5.3.0alpha2/Zend/zend.c:899
#6  0x0837995a in php_request_shutdown (dummy=0x0) at
/home/myhome/php-5.3.0alpha2/main/main.c:1516
#7  0x0846a6da in main (argc=2, argv=0xbfc9d7a4) at
/home/myhome/php-5.3.0alpha2/sapi/cli/php_cli.c:1311
(gdb) 


When I try from my browser and gdb "run -X" option, the backtrace looks
like this :

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1216632640 (LWP 21116)]
zend_hash_destroy (ht=0x85e50e8) at
/home/myhome/php-5.3.0alpha2/Zend/zend_hash.c:524
524 p = p->pListNext;
(gdb) 
(gdb) 
(gdb) 
(gdb) 
(gdb) 
(gdb) 
(gdb) bt
#0  zend_hash_destroy (ht=0x85e50e8) at
/home/myhome/php-5.3.0alpha2/Zend/zend_hash.c:524
#1  0xb72b9a57 in _zval_dtor_func (zvalue=0x85e509c) at
/home/myhome/php-5.3.0alpha2/Zend/zend_variables.c:43
#2  0xb72b91c5 in zend_ptr_stack_apply (stack=0x81e5980, func=0xb72b99b0
<_zval_dtor_func>) at
/home/myhome/php-5.3.0alpha2/Zend/zend_ptr_stack.c:90
#3  0xb72b920f in zend_ptr_stack_clean (stack=0x81e5980, func=0xb72b99b0
<_zval_dtor_func>, free_elements=1 '\001')
at /home/myhome/php-5.3.0alpha2/Zend/zend_ptr_stack.c:97
#4  0xb72acd69 in shutdown_executor (tsrm_ls=0x8132108) at
/home/myhome/php-5.3.0alpha2/Zend/zend_execute_API.c:271
#5  0xb72ba029 in zend_deactivate (tsrm_ls=0x8132108) at
/home/myhome/php-5.3.0alpha2/Zend/zend.c:899
#6  0xb725feca in php_request_shutdown (dummy=0x0) at
/home/myhome/php-5.3.0alpha2/main/main.c:1516
#7  0xb734fc1e in php_handler (r=0x8452b80) at
/home/myhome/php-5.3.0alpha2/sapi/apache2handler/sapi_apache2.c:470
#8  0x08079259 in ap_run_handler ()
#9  0x0807c5b7 in ap_invoke_handler ()
#10 0x08089998 in ap_process_request ()
#11 0x08086c9b in ?? ()
#12 0x08452b80 in ?? ()
#13 0x0004 in ?? ()
#14 0x08452b80 in ?? ()
#15 0x in ?? ()
(gdb)

-- 
Edit bug report at http://bugs.php.net/?id=46338&edit=1
-- 
Try a CVS snapshot 

#46338 [Opn]: Segfault on script ending

2008-10-18 Thread spam at pamignot dot org
 ID:   46338
 User updated by:  spam at pamignot dot org
 Reported By:  spam at pamignot dot org
 Status:   Open
-Bug Type: Apache2 related
+Bug Type: Unknown/Other Function
 Operating System: Linux 2.6.22-15-generic (Ubuntu)
 PHP Version:  5.3.0alpha2
 New Comment:

Surely not related to Apache2, but maybe GC (?), deplaced in
Unknown/Other.


Previous Comments:


[2008-10-18 21:27:58] spam at pamignot dot org

Description:

I just passed from 5.1.6 to 5.3.

I cannot give a quick code to reproduce the bug, but the script
actually does those actions :
- getting GET POST COOKIE information, giving them to HTMLPurifier and
set an array of the result
- define custom error handler
- execute action given by user
- display HTML result page

The script goes to the end, echo'ing wanted html page but it results in
a segfault.

If I comment out the next line, or if I comment out the static method
'exception_error_handler' from my class MyException, the script just
works fine :

set_error_handler(array('MyException', 'exception_error_handler'));

But if I let declared the method 'exception_error_handler', even with
no code inside, returning true or false, or throwing an exception, the
script ends up with a segfault.


Reproduce code:
---
/* some code using some PEAR packages, 
custom error handler, echo'ing a HTML page */
exit();

Expected result:

Expected result is displaying HTML page to user.

Actual result:
--
The actual result is the output of my desired HTML page, ending with a
segfault :

# gdb php
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library
"/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) r index.php
Starting program: /usr/local/bin/php index.php
[Thread debugging using libthread_db enabled]
[New Thread -1223292352 (LWP 21507)]

/* here comes my HTML page */

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1223292352 (LWP 21507)]
zend_hash_destroy (ht=0x8ce9ac4) at
/home/myhome/php-5.3.0alpha2/Zend/zend_hash.c:524
524 p = p->pListNext;
(gdb) bt
#0  zend_hash_destroy (ht=0x8ce9ac4) at
/home/myhome/php-5.3.0alpha2/Zend/zend_hash.c:524
#1  0x083d34e7 in _zval_dtor_func (zvalue=0x8ce9a78) at
/home/myhome/php-5.3.0alpha2/Zend/zend_variables.c:43
#2  0x083d2c55 in zend_ptr_stack_apply (stack=0x88ba628, func=0x83d3440
<_zval_dtor_func>) at
/home/myhome/php-5.3.0alpha2/Zend/zend_ptr_stack.c:90
#3  0x083d2c9f in zend_ptr_stack_clean (stack=0x88ba628, func=0x83d3440
<_zval_dtor_func>, free_elements=1 '\001')
at /home/myhome/php-5.3.0alpha2/Zend/zend_ptr_stack.c:97
#4  0x083c67f9 in shutdown_executor (tsrm_ls=0x88b82a0) at
/home/myhome/php-5.3.0alpha2/Zend/zend_execute_API.c:271
#5  0x083d3ab9 in zend_deactivate (tsrm_ls=0x88b82a0) at
/home/myhome/php-5.3.0alpha2/Zend/zend.c:899
#6  0x0837995a in php_request_shutdown (dummy=0x0) at
/home/myhome/php-5.3.0alpha2/main/main.c:1516
#7  0x0846a6da in main (argc=2, argv=0xbfc9d7a4) at
/home/myhome/php-5.3.0alpha2/sapi/cli/php_cli.c:1311
(gdb) 


When I try from my browser and gdb "run -X" option, the backtrace looks
like this :

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1216632640 (LWP 21116)]
zend_hash_destroy (ht=0x85e50e8) at
/home/myhome/php-5.3.0alpha2/Zend/zend_hash.c:524
524 p = p->pListNext;
(gdb) 
(gdb) 
(gdb) 
(gdb) 
(gdb) 
(gdb) 
(gdb) bt
#0  zend_hash_destroy (ht=0x85e50e8) at
/home/myhome/php-5.3.0alpha2/Zend/zend_hash.c:524
#1  0xb72b9a57 in _zval_dtor_func (zvalue=0x85e509c) at
/home/myhome/php-5.3.0alpha2/Zend/zend_variables.c:43
#2  0xb72b91c5 in zend_ptr_stack_apply (stack=0x81e5980,
func=0xb72b99b0 <_zval_dtor_func>) at
/home/myhome/php-5.3.0alpha2/Zend/zend_ptr_stack.c:90
#3  0xb72b920f in zend_ptr_stack_clean (stack=0x81e5980,
func=0xb72b99b0 <_zval_dtor_func>, free_elements=1 '\001')
at /home/myhome/php-5.3.0alpha2/Zend/zend_ptr_stack.c:97
#4  0xb72acd69 in shutdown_executor (tsrm_ls=0x8132108) at
/home/myhome/php-5.3.0alpha2/Zend/zend_execute_API.c:271
#5  0xb72ba029 in zend_deactivate (tsrm_ls=0x8132108) at
/home/myhome/php-5.3.0alpha2/Zend/zend.c:899
#6  0xb725feca in php_request_shutdown (dummy=0x0) at
/home/myhome/php-5.3.0alpha2/main/main.c:1516
#7  0xb734fc1e in php_handler (r=0x8452b80) at
/home/myhome/php-5.3.0alpha2/sapi/apache2handler/sapi_apache2.c:470
#8 

#46338 [Fbk->Opn]: Segfault on script ending

2008-10-20 Thread spam at pamignot dot org
 ID:   46338
 User updated by:  spam at pamignot dot org
 Reported By:  spam at pamignot dot org
-Status:   Feedback
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Linux 2.6.22-15-generic (Ubuntu)
 PHP Version:  5.3.0alpha2
 New Comment:

Here's the code. 
I notified HTMLPurifier developpers, since I think the problem comes
from the library.

purify('something');
set_error_handler(array('myException', 'exception_error_handler'));

?>


Previous Comments:


[2008-10-20 15:51:12] [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 ,
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-10-18 21:52:49] spam at pamignot dot org

Surely not related to Apache2, but maybe GC (?), deplaced in
Unknown/Other.

----

[2008-10-18 21:27:58] spam at pamignot dot org

Description:

I just passed from 5.1.6 to 5.3.

I cannot give a quick code to reproduce the bug, but the script
actually does those actions :
- getting GET POST COOKIE information, giving them to HTMLPurifier and
set an array of the result
- define custom error handler
- execute action given by user
- display HTML result page

The script goes to the end, echo'ing wanted html page but it results in
a segfault.

If I comment out the next line, or if I comment out the static method
'exception_error_handler' from my class MyException, the script just
works fine :

set_error_handler(array('MyException', 'exception_error_handler'));

But if I let declared the method 'exception_error_handler', even with
no code inside, returning true or false, or throwing an exception, the
script ends up with a segfault.


Reproduce code:
---
/* some code using some PEAR packages, 
custom error handler, echo'ing a HTML page */
exit();

Expected result:

Expected result is displaying HTML page to user.

Actual result:
--
The actual result is the output of my desired HTML page, ending with a
segfault :

# gdb php
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library
"/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) r index.php
Starting program: /usr/local/bin/php index.php
[Thread debugging using libthread_db enabled]
[New Thread -1223292352 (LWP 21507)]

/* here comes my HTML page */

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1223292352 (LWP 21507)]
zend_hash_destroy (ht=0x8ce9ac4) at
/home/myhome/php-5.3.0alpha2/Zend/zend_hash.c:524
524 p = p->pListNext;
(gdb) bt
#0  zend_hash_destroy (ht=0x8ce9ac4) at
/home/myhome/php-5.3.0alpha2/Zend/zend_hash.c:524
#1  0x083d34e7 in _zval_dtor_func (zvalue=0x8ce9a78) at
/home/myhome/php-5.3.0alpha2/Zend/zend_variables.c:43
#2  0x083d2c55 in zend_ptr_stack_apply (stack=0x88ba628, func=0x83d3440
<_zval_dtor_func>) at
/home/myhome/php-5.3.0alpha2/Zend/zend_ptr_stack.c:90
#3  0x083d2c9f in zend_ptr_stack_clean (stack=0x88ba628, func=0x83d3440
<_zval_dtor_func>, free_elements=1 '\001')
at /home/myhome/php-5.3.0alpha2/Zend/zend_ptr_stack.c:97
#4  0x083c67f9 in shutdown_executor (tsrm_ls=0x88b82a0) at
/home/myhome/php-5.3.0alpha2/Zend/zend_execute_API.c:271
#5  0x083d3ab9 in zend_deactivate (tsrm_ls=0x88b82a0) at
/home/myhome/php-5.3.0alpha2/Zend/zend.c:899
#6  0x0837995a in php_request_shutdown (dummy=0x0) at
/home/myhome/php-5.3.0alpha2/main/main.c:1516
#7  0x0846a6da in main (argc=2, argv=0xbfc9d7a4) at
/home/myhome/php-5.3.0alpha2/sapi/cli/php_cli.c:1311
(gdb) 


When I try from my browser and gdb "run -X" option, the backtrace looks
like this :

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1216632640 (LWP 21116)]
zend_hash_destroy (ht=0x85e50e8) at
/home/myhome/php-5.3.0alpha2/Zend/zend_hash.c:524
524 p = p->pListNext;
(gdb) 
(gdb) 
(gdb) 
(gdb) 
(gdb) 
(gdb) 
(gdb) bt
#0  zend_hash_destroy (ht=0x85

#46338 [Ver->Csd]: Segfault on multiple error handler

2008-10-21 Thread spam at pamignot dot org
 ID:   46338
 User updated by:  spam at pamignot dot org
 Reported By:  spam at pamignot dot org
-Status:   Verified
+Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: Irrelevant
 PHP Version:  5.3.0alpha3-dev
 New Comment:

Ok, sorry for the noise.

Duplicate bug closed, just see :
http://bugs.php.net/46241


Previous Comments:


[2008-10-21 15:36:53] [EMAIL PROTECTED]

Yeah, these are most definitely duplicates. (Doesn't know how to close
a bug as a dupe).



[2008-10-21 06:35:17] clemens dot kalb at netlogix dot de

Setting the error handler twice does indeed seem to be the problem. I
can reproduce this with 5.3 alpha3-dev Build Date Oct 19 2008 04:42:11.
See #46241 for a possible duplicate of this entry.



[2008-10-20 19:00:28] [EMAIL PROTECTED]

Oh, also, I tested it on the latest alpha3-dev build.

php --version
PHP 5.3.0alpha3-dev (cli) (built: Oct 20 2008 20:49:57)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies



[2008-10-20 18:54:55] [EMAIL PROTECTED]

I believe this is a problem with the error handler stack. I get
"zend_mm_heap corrupted" when I set the error handler twice.

purify('something');
set_error_handler(array('myException', 'exception_error_handler'));

?>



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/46338

-- 
Edit this bug report at http://bugs.php.net/?id=46338&edit=1



#46282 [Com]: Corrupt DBF When Using DATE

2009-01-15 Thread no at spam dot net
 ID:   46282
 Comment by:   no at spam dot net
 Reported By:  mattias dot geniar at gmail dot com
 Status:   No Feedback
 Bug Type: dBase related
 Operating System: CentOS 5.2
 PHP Version:  5.2.6
 New Comment:

I have the same problem on FreeBSD 6.3-STABLE, PHP5.2.8


Previous Comments:


[2008-11-18 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".



[2008-11-10 11:32:59] j...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/





[2008-10-12 14:03:50] mattias dot geniar at gmail dot com

Description:

Creating a dBase file with a DATE-field type, will corrupt the
database. Work-around as for now is to use a CHAR-type and convert it
later manually.

This bug is similar to #42261, which dates back to August 2007.

Reproduce code:
---



Expected result:

A simple database with 5 lines, where DATE, Name & Email are entered
correctly.

Actual result:
--
The code above will create file called "test.dbf", which is corrupted
when opening it with any normal DBF-viewer (CDBF, DBF Manager, ...). If
the DATE-field is replaced with a CHAR-field, all works fine.
Date-format is taken from the PHP.NET website and confirmed by the
dBase-format.





-- 
Edit this bug report at http://bugs.php.net/?id=46282&edit=1



#47432 [NEW]: Error message for built-in override is very non-obvious

2009-02-17 Thread spam at paulisageek dot com
From: spam at paulisageek dot com
Operating system: OS Independent
PHP version:  5.2.9RC2
PHP Bug Type: *General Issues
Bug description:  Error message for built-in override is very non-obvious

Description:

If you have a c extension defining certain classes, then defining the same
class in user land gives the message :

Fatal error: Cannot redeclare class *classname* in *file* on line
*linenum*

This is quite confusing, since most people will know to look through all
their user land scripts for the redefinition, and few will actually look at
their installed extensions to find conflicts.

I recommend changing the error message to:

Fatal error: Cannot redeclare built-in class *classname* in *file* on line
*linenum*

Reproduce code:
---


Expected result:

Fatal error: Cannot redeclare built-in class *classname* in *file* on line
*linenum*

Actual result:
--
Fatal error: Cannot redeclare class *classname* in *file* on line
*linenum*

-- 
Edit bug report at http://bugs.php.net/?id=47432&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47432&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47432&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47432&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47432&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47432&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47432&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47432&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47432&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47432&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47432&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47432&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47432&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47432&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47432&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47432&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47432&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47432&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47432&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47432&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47432&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47432&r=mysqlcfg



#48684 [Com]: cant make STDIN non blocking

2009-12-08 Thread spam at helper3000 dot net
 ID:   48684
 Comment by:   spam at helper3000 dot net
 Reported By:  ryan at ryanmills dot net
 Status:   Open
 Bug Type: Streams related
 Operating System: win32 only - Vista X64
 PHP Version:  5.2.10
 New Comment:

Problem experianced using 5.3.1 in both thread and non-thread safe
binaries on windows XP SP2.

I too have read that it is an ongoing problem; it should have been
fixed many years ago.


Previous Comments:


[2009-10-20 23:32:06] ron at rongage dot org

Actually, it still doesn't work on Linux either (5.2.11).

Yes, the actual fread is non-blocking.  However, if you press any key,
it is NOT registered so you can't react to keystrokes.

The code:
http://bugs.php.net/bug.php?id=47893&edit=2

Tested on 5.2.9-2 and 5.2.10

Notes say it was fixed in CVS so I assume 5.2.10 would have had the
fix.


*NOTE php.ini changes

;;;
; Resource Limits ;
;;;

max_execution_time = 0   ; Maximum execution time of each script, in
seconds
max_input_time = 0  ; Maximum amount of time each script may spend
parsing request data
;max_input_nesting_level = 64 ; Maximum input variable nesting level
memory_limit = 512M  ; Maximum amount of memory a script may
consume (128MB)



Reproduce code:
---


Expected result:

A never-ending sequence of var_dumps of either an empty string or a
typed character

Actual result:
--
stuck waiting for the user to press enter.





-- 
Edit this bug report at http://bugs.php.net/?id=48684&edit=1



#48684 [Com]: cant make STDIN non blocking

2009-12-11 Thread spam at helper3000 dot net
 ID:   48684
 Comment by:   spam at helper3000 dot net
 Reported By:  ryan at ryanmills dot net
 Status:   Open
 Bug Type: Streams related
 Operating System: win32 only - Vista X64
 PHP Version:  5.2.10
 New Comment:

Would also just like to add that after a mere day, a busy friend I know
managed to fix PHP 5.2 and apply the patch to 5.3, it now works
perfectly using his modified build.
UNDER A DAY. And this issue has been continuing in PHP for at least 7
years...


Previous Comments:


[2009-12-08 20:59:57] spam at helper3000 dot net

Problem experianced using 5.3.1 in both thread and non-thread safe
binaries on windows XP SP2.

I too have read that it is an ongoing problem; it should have been
fixed many years ago.



[2009-10-20 23:32:06] ron at rongage dot org

Actually, it still doesn't work on Linux either (5.2.11).

Yes, the actual fread is non-blocking.  However, if you press any key,
it is NOT registered so you can't react to keystrokes.

The code:
http://bugs.php.net/bug.php?id=47893&edit=2

Tested on 5.2.9-2 and 5.2.10

Notes say it was fixed in CVS so I assume 5.2.10 would have had the
fix.


*NOTE php.ini changes

;;;
; Resource Limits ;
;;;

max_execution_time = 0   ; Maximum execution time of each script, in
seconds
max_input_time = 0  ; Maximum amount of time each script may spend
parsing request data
;max_input_nesting_level = 64 ; Maximum input variable nesting level
memory_limit = 512M  ; Maximum amount of memory a script may
consume (128MB)



Reproduce code:
---


Expected result:

A never-ending sequence of var_dumps of either an empty string or a
typed character

Actual result:
--
stuck waiting for the user to press enter.





-- 
Edit this bug report at http://bugs.php.net/?id=48684&edit=1



#48684 [Com]: cant make STDIN non blocking

2009-12-11 Thread spam at helper3000 dot net
 ID:   48684
 Comment by:   spam at helper3000 dot net
 Reported By:  ryan at ryanmills dot net
 Status:   Feedback
 Bug Type: Streams related
 Operating System: win32 only - Vista X64
 PHP Version:  5.2.10
 New Comment:

http://rapidshare.com/files/319636981/php-5.3.1L.zip.html

He's refining it more and as so includes no source.


Previous Comments:


[2009-12-11 22:46:48] paj...@php.net

And where is the patch then?



[2009-12-11 22:43:54] spam at helper3000 dot net

Would also just like to add that after a mere day, a busy friend I know
managed to fix PHP 5.2 and apply the patch to 5.3, it now works
perfectly using his modified build.
UNDER A DAY. And this issue has been continuing in PHP for at least 7
years...



[2009-12-08 20:59:57] spam at helper3000 dot net

Problem experianced using 5.3.1 in both thread and non-thread safe
binaries on windows XP SP2.

I too have read that it is an ongoing problem; it should have been
fixed many years ago.



[2009-10-20 23:32:06] ron at rongage dot org

Actually, it still doesn't work on Linux either (5.2.11).

Yes, the actual fread is non-blocking.  However, if you press any key,
it is NOT registered so you can't react to keystrokes.

The code:
http://bugs.php.net/48684

-- 
Edit this bug report at http://bugs.php.net/?id=48684&edit=1



#44047 [Com]: IIS Worker Process stopped working

2008-04-03 Thread nonya at spam dot this
 ID:   44047
 Comment by:   nonya at spam dot this
 Reported By:  matthew dot horner at redprairie dot com
 Status:   Open
 Bug Type: IIS related
 Operating System: Windows Vista
 PHP Version:  5.2.5
 New Comment:

I see this topic has been labeled an IIS issue and there was no
response from PHP staff.

If it is a IIS7 issue, why was it not occurring in PHP4?


Previous Comments:


[2008-03-19 04:22:41] jaedsm at hotmail dot com

Having the same issue here too. Installed IIS7 and PHP 5.2.5 the other
day on my home system running Vista Home Premium. Didn't consider it
would have been caused by some timeout but after reading here that makes
sense.

No crash message has appeared while I've been working for hours on end,
once I stop though it appears a little while later and doesn't appear
again unless I load another php page.



[2008-03-06 14:00:56] matthew dot horner at redprairie dot com

I would still consider this a workaround, as this is not standard
procedure for installing ISAPI modules in IIS7.  Furthermore, this issue
is not an issue with PHP 4.  Which to me, would indicate there is
something coded differently with PHP 5 to cause the crash when recycling
the process.  Also, reconfiguring the Application Pool, affects more
than just your pool hosting PHP driven applications.  What side effects 
there are, is unclear to me, but certainly not something I would like to
find out about once a site is in production.

I posted this bug because I would like to have the PHP developers debug
this issue and determine if there is indeed a code problem or a problem
with IIS7.  Not to have a workaround to avoid crashes on IIS7.

I am not disputing the fact that your solution works.  However, this
appears to be an issue and should be addressed at the PHP level first. 


Thank you for your suggestions.



[2008-03-06 10:36:54] satan at dclxvi dot nl

to be clear, these are my settings:

Recycle time is set to the default every 1740 minutes.
Idle timeout is set to '0'
Disable Overlapped Recycle is set to 'True'

never had the error again...
no horrible workarround whatsoever.. it's just that IIS7 is defaultly
configured to run MS stuff like ASP.NET etc..



[2008-03-06 10:13:01] satan at dclxvi dot nl

Also, I found out the solution that it won't error on recycle...

go to the advanced settings of the appPool you are using and set
"Disable Overlapped Recycle" to "True". 

PHP5 can't seam to run multiple instances so it errors out when it
starts a new instance before it recycles the old..

And again with the idle timeout set to "0", it will still recycle..



[2008-03-06 09:39:53] satan at dclxvi dot nl

it will still recycle if you set it to 0, it just won't time out.. on
higher traffic servers it will will never timeout and there's no problem
there, is there? the recycling is another setting..

besides, this has little or nothing to do with php, as it also occurs
after running asp..



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/44047

-- 
Edit this bug report at http://bugs.php.net/?id=44047&edit=1



#35046 [NEW]: bad css when using phpinfo()

2005-11-01 Thread spam at gemal dot dk
From: spam at gemal dot dk
Operating system: Linux
PHP version:  5.0.5
PHP Bug Type: PHP options/info functions
Bug description:  bad css when using phpinfo()

Description:

Error: Selector expected.  Ruleset ignored due to bad selector.
Source file: phpinfo.php
Line: 23

Error: Unexpected end of file while searching for closing } of invalid
rule set.
Source file: phpinfo.php
Line: 23


Reproduce code:
---
 

Expected result:

<!--
blabla
//-->

should be:

blabla


to be valid css



-- 
Edit bug report at http://bugs.php.net/?id=35046&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=35046&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=35046&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=35046&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=35046&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=35046&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=35046&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=35046&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=35046&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35046&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=35046&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=35046&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=35046&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=35046&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=35046&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=35046&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=35046&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35046&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=35046&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=35046&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=35046&r=mysqlcfg


#35614 [NEW]: extends crashes apache with Segmentation fault

2005-12-09 Thread spam at gemal dot dk
From: spam at gemal dot dk
Operating system: Linux
PHP version:  5.1.1
PHP Bug Type: Apache related
Bug description:  extends crashes apache with Segmentation fault

Description:

the following code produces Segmentation fault on php



PHP 5.0.5 (cli) (built: Oct 31 2005 10:51:24)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.5, Copyright (c) 1998-2004 Zend Technologies
with Zend Extension Manager v1.0.9, Copyright (c) 2003-2005, by Zend
Technologies
with Zend Optimizer v2.6.0, Copyright (c) 1998-2005, by Zend
Technologies
with Zend Debugger v5.0.0, Copyright (c) 1999-2005, by Zend
Technologies

Reproduce code:
---




-- 
Edit bug report at http://bugs.php.net/?id=35614&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=35614&r=trysnapshot44
Try a CVS snapshot (PHP 5.1): 
http://bugs.php.net/fix.php?id=35614&r=trysnapshot51
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=35614&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35614&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=35614&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=35614&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35614&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35614&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=35614&r=support
Expected behavior:http://bugs.php.net/fix.php?id=35614&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=35614&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=35614&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35614&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=35614&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35614&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35614&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=35614&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=35614&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=35614&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35614&r=mysqlcfg


  1   2   >