date:20100901

Bug #52752 [Com]: Program terminated with signal 7, Bus error.

2010-09-01 Thread paulgao at yeah dot net

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

 ID: 52752
 Comment by: paulgao at yeah dot net
 Reported by:paulgao at yeah dot net
 Summary:Program terminated with signal 7, Bus error.
 Status: Feedback
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   irrelevant
 PHP Version:5.3SVN-2010-08-31 (SVN)
 Block user comment: N

 New Comment:

please use âab -n 200 -n 20 http://xxx/xxx.phpâ test.


Previous Comments:

[2010-09-01 15:19:11] paulgao at yeah dot net

script run in Centos 5 32bit server, php-fpm mode.



configure command:

./configure --prefix=/usr/local/php --without-pear --with-mysqli=mysqlnd
--disable-phar --with-iconv --with-zlib --enable-exif --enable-sockets
--enable-mbstring=all --enable-inline-optimization --enable-debug
--enable-static --disable-ipv6 --disable-pdo --without-sqlite
--enable-fpm --with-libevent=shared


[2010-09-01 15:17:28] paulgao at yeah dot net

test script:





core dump backtreace message:





#0  0x082fd8d6 in lex_scan (zendlval=0xbff7295c) at
Zend/zend_language_scanner.c:930

930 yych = *YYCURSOR;

(gdb) bt

#0  0x082fd8d6 in lex_scan (zendlval=0xbff7295c) at
Zend/zend_language_scanner.c:930

#1  0x08324d5d in zendlex (zendlval=0xbff72958) at
/root/php-5.3.3/Zend/zend_compile.c:4947

#2  0x082f7447 in zendparse () at
/root/php-5.3.3/Zend/zend_language_parser.c:3280

#3  0x082fcc97 in compile_file (file_handle=0xbff72ad0, type=2) at
Zend/zend_language_scanner.l:354

#4  0x082fcdec in compile_filename (type=2, filename=0xa179af0) at
Zend/zend_language_scanner.l:397

#5  0x0837983e in ZEND_INCLUDE_OR_EVAL_SPEC_TMP_HANDLER
(execute_data=0xa179a04) at /root/php-5.3.3/Zend/zend_vm_execute.h:5199

#6  0x08369b48 in execute (op_array=0xa1467a4) at
/root/php-5.3.3/Zend/zend_vm_execute.h:107

#7  0x083398ca in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/php-5.3.3/Zend/zend.c:1266

#8  0x082cc48f in php_execute_script (primary_file=0xbff77034) at
/root/php-5.3.3/main/main.c:2275

#9  0x0840f171 in main (argc=3, argv=0xbff77174) at
/root/php-5.3.3/sapi/fpm/fpm/fpm_main.c:1865


[2010-09-01 07:00:48] ras...@php.net

That doesn't seem to be APC-related if the backtrace is to be believed. 
It seems 

to be happening on the initial compile.  But yes, please verify that it
happens 

without APC as well.


[2010-09-01 06:01:59] ahar...@php.net

Please test if this fails without APC. If so, we'll need a test script
to diagnose the problem.


[2010-08-31 20:45:32] paulgao at yeah dot net

I use 5.3.4-dev, and APC 3.1.5-dev.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=52752


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

Bug #52589 [Com]: com_exception when read array from object->property

2010-09-01 Thread bastard dot internets at gmail dot com

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

 ID: 52589
 Comment by: bastard dot internets at gmail dot com
 Reported by:stinger25 at yandex dot ru
 Summary:com_exception when read array from object->property
 Status: Open
 Type:   Bug
 Package:COM related
 Operating System:   WinXP
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

"ÐÐ°ÑÐ°Ð¼ÐµÑÑ ÑÐ²Ð»ÑÐµÑÑÑ Ð¾Ð±ÑÐ·Ð°ÑÐµÐ»ÑÐ½ÑÐ¼" = "The
parameter is mandatory" I'm assuming.  You appear to have Text() return
as a single string, meaning it won't behave like an array as you have
"$str = $obj->Text[$i];" implying.  Try "$str = $obj->Text($i);"
instead.


Previous Comments:

[2010-08-12 09:08:13] stinger25 at yandex dot ru

It's working if instead property write method.

VB6 Code

Public Function ReadText(index) As String

Dim ret As String

ReDim str_Text(3)

str_Text(0) = "Test zero string"

str_Text(1) = "Test first string"

str_Text(2) = "Test second string"



If ((index < 0) Or (index >= 3)) Then

ret = ""

Else

ret = str_Text(index)

End If

ReadText = ret

End Function



and in PHP page

Count;

print $j."";



for ($i=0; $i<$j; $i++)

{

//  $str = $obj->Text[$i];

$str = $obj->ReadText($i);

print $str.""   ;

}

?>

Actual result:

3

Test zero string

Test first string

Test second string


[2010-08-12 08:52:30] stinger25 at yandex dot ru

Description:

I have small test ActiveX DLL writen in VB6.

It is code of DLL:

Option Explicit

Private str_Text() As String

Public Property Get Text(index As Integer) As String

ReDim str_Text(3)

str_Text(0) = "Test zero string"

str_Text(1) = "Test first string"

str_Text(2) = "Test second string"

If ((index < 0) Or (index >= 3)) Then

Text = ""

Else

Text = str_Text(index)

End If

End Property

Public Property Get Count() As Long

Count = 3

End Property



When I trying read array from Text property PHP page generate error, but
in VB6 

it's working correct.

Test script:
---
Count;

print $j."";



for ($i=0; $i<$j; $i++)

{

$str = $obj->Text[$i];

print $str.""   ;

}

?>

Expected result:

3



Test zero string

Test first string

Test second string

Actual result:
--
3



Fatal error: Uncaught exception 'com_exception' with message 'Error
[0x8002000f] 

ÐÐ°ÑÐ°Ð¼ÐµÑÑ ÑÐ²Ð»ÑÐµÑÑÑ Ð¾Ð±ÑÐ·Ð°ÑÐµÐ»ÑÐ½ÑÐ¼. ' in 

C:\Inetpub\_web_script_\SKU_Buffer\docsgenerator\xls.php:8 Stack trace:
#0 

C:\Inetpub\_web_script_\SKU_Buffer\docsgenerator\xls.php(8): unknown()
#1 {main} 

thrown in C:\Inetpub\_web_script_\SKU_Buffer\docsgenerator\xls.php on
line 8






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

Req #44889 [Com]: T_OPEN_TAG doesn't match

2010-09-01 Thread daniel at danielnorton dot com

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

 ID: 44889
 Comment by: daniel at danielnorton dot com
 Reported by:mikec at resnet dot net dot nz
 Summary:T_OPEN_TAG doesn't match  Array

(

[0] => 368

[1] =>  1

)



)

Array

(

[0] => Array

(

[0] => 311

[1] =>  1

)



)

Actual result:
--
string(0) ""

Array

(

[0] => Array

(

[0] => 311

[1] =>  1

)



[1] => Array

(

[0] => 311

[1] => php

[2] => 1

)



)

Array

(

[0] => Array

(

[0] => 311

[1] =>  1

)



)






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

Bug #41462 [Com]: config-scan-dir and config-path will load the same php.ini twice.

2010-09-01 Thread dotpointer at gmail dot com

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

 ID: 41462
 Comment by: dotpointer at gmail dot com
 Reported by:jean dot bruenn at ip-minds dot de
 Summary:config-scan-dir and config-path will load the same
 php.ini twice.
 Status: Bogus
 Type:   Bug
 Package:*Configuration Issues
 Operating System:   Linux (2.6.x Kernel) SMP
 PHP Version:5.2.2
 Block user comment: N

 New Comment:

Stumbled upon this problem recently. Maybe this is not named "bug"
specifically, but a problem it is.



It took time to understand why PHP CLI complained about already loaded
modules.



Something - even a warning when running ./configure would be in place.



Best (I guess) would be that php.ini is avoided when trying to load
additional ini-files.



Say I am so stupid I compile PHP with these paramters (which was what I
did lately...):

--with-config-file-scan-dir=/etc/php

--with-config-file-path=/etc/php





Then I have to choose between not being able to load the shared modules
at all, or to get an error in the CLI, because the INI-file is being
read twice, which disables the functionality.


Previous Comments:

[2007-05-23 16:51:21] jean dot bruenn at ip-minds dot de

So, it's not a bug, if it's loading the php.ini twice? ;-)



I mean, i understand that it's not a real bug - but i think this should
be changed. Cause if you look in your favorite search engine for such
problems (and related) you'll see that many ppl having this problem.



Anyway. Simply wanted to report it, now you have it, do what u want with
it ;-)


[2007-05-22 17:30:24] johan...@php.net

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

.


[2007-05-22 15:32:45] jean dot bruenn at ip-minds dot de

Description:

btw. it does not matter WHICH php Version - i had this problems with
older version of php5 too.



i was wondering why i get errors cause of extensions. It meant it can't
load them 'again'. That was no problem at all, i just ignored this
messages, now i tried to install the zend optimizer (hey.. it's not a
zend-related problem!) it gives a fatal error cause it can't load the
extension twice. It seems that many ppl having such problems - it comes
when u use --with-config-scan-dir and --with-config-path (both options)
and both are pointing to the same directory.

Reproduce code:
---
Well.. just create a folder to store the php.ini - for example "testphp"
in /etc now recompile php with: '--with-layout=GNU'
'--with-config-file-path=/etc/testphp'
'--with-config-file-scan-dir=/etc/testphp' now put your php.ini into
this directory and put some extensions into it, for example xcache or
the zend optimizer or apc, or whatever you want. when you go to your
source directory and type "make test" you will see 1. (see at actual
result) - and it will give you errors cause of some extensions (zend
optimizer will give a fatal one and make test is stopping)



i recompiled it then with _one_ of these settings - see 1. in expected
results - now it's working, strange eh?



So.. is it a bug or a feature? ;)

Expected result:

1. (thats how it looks if you use one of these configure settings)



INI actual  : /etc/testphp/php.ini

More .INIs  : 







Actual result:
--
1. (thats how it look if you use both configure settings)



INI actual  : /etc/testphp/php.ini

More .INIs  : /etc/testphp/php.ini












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

Bug #51248 [Com]: Segmentation fault in mysql_fetch_array

2010-09-01 Thread php at group dot apple dot com

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

 ID: 51248
 Comment by: php at group dot apple dot com
 Reported by:mbecc...@php.net
 Summary:Segmentation fault in mysql_fetch_array
 Status: Assigned
 Type:   Bug
 Package:MySQL related
 Operating System:   FreeBSD 6.2
 PHP Version:5.3.2
 Assigned To:mysql
 Block user comment: N

 New Comment:

Does the request for valgrind mean you are unable to reproduce the
behavior with -

fstack-protector-all?


Previous Comments:

[2010-09-01 16:05:57] and...@php.net

valgrind output would be helpful :)

Thanks!


[2010-08-27 22:00:08] php at group dot apple dot com

This reproduces on Mac OS X, and appears to be a stack overflow issue. I
enabled 

stack overflow protection by adding "-g -fstack-protector-all" to the
CFLAGS passed 

to configure. (The problem does not reproduce when configured with
--enable-debug 

or -O0 instead of -Os.) In running this through gdb, the following line
in changes 

execute_data and may be the start of the corruption:

  zend_vm_execute.h:301 EX_T(opline->result.u.var).var.ptr_ptr 
= 

&EX_T(opline->result.u.var).var.ptr;



With the following sample script, the third pass through 

zend_do_fcall_common_helper_SPEC() demonstrates the crash:






[2010-08-26 13:27:05] u...@php.net

Please try to provide a short test script, like its good style with
every other bug report.


[2010-08-25 10:32:16] paj...@php.net

Latest drupal (6+) versions work with 5.3 smoothly.


[2010-08-25 10:22:29] mbecc...@php.net

@Chris: I understand that Drupal and PHP 5.3 might not live happily
together, but I'd expect errors, not segmentation faults.



@Andrey: Is there anything I can do to help understanding what happens
on when using libmysql?




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/bug.php?id=51248


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

Bug->Req #52630 [Asn->Opn]: additional syntax for closures

2010-09-01 Thread stas

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

 ID: 52630
 Updated by: s...@php.net
 Reported by:giorgio dot liscio at email dot it
 Summary:additional syntax for closures
-Status: Assigned
+Status: Open
-Type:   Bug
+Type:   Feature/Change Request
 Package:Variables related
 Operating System:   all
 PHP Version:5.3.3
 Assigned To:stas
 Block user comment: N

 New Comment:

See http://wiki.php.net/rfc/fcallfcall


Previous Comments:

[2010-08-18 01:02:18] ka...@php.net

I like the:

function($x) use($y) {return $x * $y;}(22);



approach, its consistent with that of other languages, like JavaScript


[2010-08-17 22:41:04] giorgio dot liscio at email dot it

any alternative syntax can be good if the result is the same, defining
end invoking on the same instruction without using any var



now:



$f = function($x) use($y){return $x * $y;};

$f(22);



request:



(function($x) use($y) {return $x * $y;})(22);



or



function($x) use($y) {return $x * $y;}(22);



or 



function($x) use($y) invoke(22) {return $x * $y;};



etc


[2010-08-17 22:21:17] ka...@php.net

I belive stas' had a patch for this? Or atleast function call chaining,
but I assume if implemented it would allow this syntax?


[2010-08-17 22:17:26] giorgio dot liscio at email dot it

Description:

hi, would be nice having this syntax for closures





$this->addResult

(

(

function ($param) use ($x) { return $x*$param; }

)($result)

);



a closure defined and executed in the same instruction, as JavaScript
allows









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

Bug #52283 [Asn->Bgs]: IntlDateFormatter invalid parsing with YYYY

2010-09-01 Thread stas

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

 ID: 52283
 Updated by: s...@php.net
 Reported by:danikas2k2 at gmail dot com
 Summary:IntlDateFormatter invalid parsing with 
-Status: Assigned
+Status: Bogus
 Type:   Bug
 Package:I18N and L10N related
 Operating System:   WinXP
 PHP Version:5.3.2
 Assigned To:stas
 Block user comment: N

 New Comment:

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

 is not a regular year (that's ). It's a year from "week date"
format, see here: http://en.wikipedia.org/wiki/ISO_8601#Week_dates

it's kind of funny format, since it speaks in whole weeks, so if part of
week was in 2006 and part of 2007, giving just year number actually can
send you to a last week of previous year. As an example goes in wiki,
2008-12-29 is written "2009-W01-1".  and MM thus won't mix that
well. Use .


Previous Comments:

[2010-07-08 13:05:43] johan...@php.net

Stas, please look into this. Thanks. I don't know whether that might be
expected or is an icu issue or ...


[2010-07-08 09:29:39] danikas2k2 at gmail dot com

Description:

Parsing a value with  in the pattern returns unexpected results.
Formatting 

the value using the  in the pattern works perfect.

Test script:
---
$fmt = new IntlDateFormatter('lt_LT', IntlDateFormatter::FULL,
IntlDateFormatter::FULL, 'Europe/Vilnius',
IntlDateFormatter::GREGORIAN);



$value = '2007-10-01'; // notice, that 2007-01-01 equals to 2007-W01-1

$variants = array();



$fmt->setPattern('');

$pts = $fmt->parse($value);

$variants[] = array($pts, $fmt->format($pts));



$fmt->setPattern('-MM');

$pts = $fmt->parse($value);

$variants[] = array($pts, $fmt->format($pts));



$fmt->setPattern('-MM-dd');

$pts = $fmt->parse($value);

$variants[] = array($pts, $fmt->format($pts));



$fmt->setPattern('');

$pts = $fmt->parse($value);

$variants[] = array($pts, $fmt->format($pts));



$fmt->setPattern('-MM');

$pts = $fmt->parse($value);

$variants[] = array($pts, $fmt->format($pts));



$fmt->setPattern('-MM-dd');

$pts = $fmt->parse($value);

$variants[] = array($pts, $fmt->format($pts));



print_r($variants);



Expected result:

array (

  0 =>

  array (

0 => 1167602400,

1 => '2007',

  ),

  1 =>

  array (

0 => 1191186000,

1 => '2007-10',

  ),

  2 =>

  array (

0 => 1191186000,

1 => '2007-10-01',

  ),

  3 =>

  array (

0 => 1167602400,

1 => '2007',

  ),

  4 =>

  array (

0 => 1191186000,

1 => '2007-10',

  ),

  5 =>

  array (

0 => 1191186000,

1 => '2007-10-01',

  ),

)

Actual result:
--
array (

  0 =>

  array (

0 => 1167602400,

1 => '2007',

  ),

  1 =>

  array (

0 => 1191186000,

1 => '2007-10',

  ),

  2 =>

  array (

0 => 1191186000,

1 => '2007-10-01',

  ),

  3 =>

  array (

0 => 1166997600,

1 => '2006',

  ),

  4 =>

  array (

0 => 1166997600,

1 => '2006-12',

  ),

  5 =>

  array (

0 => 23576400,

1 => '1970-10-01',

  ),

)






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

Bug #43511 [Com]: unlink() gives "No error in..." warning

2010-09-01 Thread wytsep at hotmail dot com

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

 ID: 43511
 Comment by: wytsep at hotmail dot com
 Reported by:marius dot radvan at yahoo dot com
 Summary:unlink() gives "No error in..." warning
 Status: No Feedback
 Type:   Bug
 Package:*General Issues
 Operating System:   windows
 PHP Version:5.2.5
 Block user comment: N

 New Comment:

I got this when I uploaded a file which exceeded the maximum file size
which was defined in HTML like this:







After removing the tag it worked.



(PHP version 5.3.0)


Previous Comments:

[2010-08-10 22:42:00] calicojack at gmail dot com

Getting this as of PHP Version 5.2.9-2 on Windows Server 2008. 



 

if(ftp_put($connection, $dest, $source,FTP_ASCII)){ 

echo 'FTP Upload SUCCESS!';

ftp_close($connection); 

unlink($source);

}


[2008-12-22 01:36:11] admin at beyondmaster dot com

I got the same error even trying to set chmod to 0777

chmod() [function.chmod]: No error in ... on line 34



Warning: unlink() [function.unlink]: No error in ...


[2007-12-15 01:00:00] php-bugs at lists dot php dot net

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


[2007-12-07 10:49:06] j...@php.net

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




[2007-12-06 07:42:07] marius dot radvan at yahoo dot com

Description:

Warning: unlink() [function.unlink]: No error in C:\Program
Files\VertrigoServ\www\peluza.info\poze.php 

i get this non error warning

Reproduce code:
---
 if (($pext != "jpg")  && ($pext != "jpeg")) {

  unlink($_FILES['img']['tmp_name']);

?>

Expected result:

delete temp file

Actual result:
--
it shows me that warning






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

Bug #50590 [Asn->Csd]: IntlDateFormatter::parse result is limited to the integer range

2010-09-01 Thread stas

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

 ID: 50590
 Updated by: s...@php.net
 Reported by:a dot farhadi at gmail dot com
 Summary:IntlDateFormatter::parse result is limited to the
 integer range
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:I18N and L10N related
 Operating System:   Ubuntu
 PHP Version:5.3.1
 Assigned To:stas
 Block user comment: N

 New Comment:

This bug has been fixed in SVN.

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.




Previous Comments:

[2010-09-01 22:35:01] s...@php.net

Automatic comment from SVN on behalf of stas
Revision: http://svn.php.net/viewvc/?view=revision&revision=302982
Log: Fix bug #50590 - IntlDateFormatter::parse result is limited to the
integer range


[2010-06-21 09:59:41] a dot farhadi at gmail dot com

Actually what I want to do is to convert dates between different
calendars and to do so I'm using the returned timestamp with
IntlDateFormatter::format method as follow:



$df_persian = new IntlDateFormatter('e...@calendar=persian',
IntlDateFormatter::FULL, IntlDateFormatter::FULL, 'Asia/Tehran',
IntlDateFormatter::GREGORIAN, '-MM-dd');

$df_gregorian = new IntlDateFormatter('en', IntlDateFormatter::FULL,
IntlDateFormatter::FULL, 'Asia/Tehran', IntlDateFormatter::GREGORIAN,
'-MM-dd');

echo $df_gregorian->format($df_persian->parse('1388-03-31'));



Hopefully, format method accepts float values as argument and the only
problem is parse method which doesn't return past-2038 timestamps.



And by the way float precision loss wouldn't be a problem at least for
timestamps up to 14 decimal digits.


[2010-06-21 01:42:27] s...@php.net

Out of curiosity - how do you expect to use past-2038 timestamps? Many
Unix systems won't support those. Do you expect 64-bit value or some
other way? float might be not very good for it due to the precision
loss.


[2009-12-28 12:46:06] a dot farhadi at gmail dot com

Description:

The result of IntlDateFormatter::parse is integer and is limited to the
integer range. (i.e. IntlDateFormatter::parse returns The least integer
value (e.g. -2147483648 in 32-bit Platforms) when the result is out of
the integer range.)



Reproduce code:
---
$fmt = new IntlDateFormatter("en_US", IntlDateFormatter::FULL,
IntlDateFormatter::FULL);

var_dump($fmt->parse("Wednesday, January 20, 2038 3:14:07 AM GMT"));

Expected result:

float(2147570047)

Actual result:
--
int(-2147483648)






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

Req #52761 [Bgs]: include backtrace in web server log on fatal error

2010-09-01 Thread freeman3 at centrum dot cz

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

 ID: 52761
 User updated by:freeman3 at centrum dot cz
 Reported by:freeman3 at centrum dot cz
 Summary:include backtrace in web server log  on fatal error
 Status: Bogus
 Type:   Feature/Change Request
 Package:Apache2 related
 Operating System:   opensuse
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

I know it's not a bug. That's why I marked it as feature request (where
else 

should I post feature request?!?). And I didn't find such option in php
manual. I 

wanted only extend the error message in the log, I don't want to install
xdebug 

on production server...

I still think it would be a good idea.


Previous Comments:

[2010-09-01 21:30:41] johan...@php.net

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

You can install xdebug on your development server to get this feature.
http://xdebug.org


[2010-09-01 19:01:23] freeman3 at centrum dot cz

Too long? I mean log only for fatal error and such. I happens only when
developing application usually, few times a day. It would be few extra
lines only. Access log has several GB usually so I think few lines
doesn't matter. I think many developers would be grateful because this
can save much time.

I have tried something with shutdown handler but it didn't work for me.
If you have a code that returns backtrace when fatal error occurs, I
would be grateful.


[2010-09-01 18:11:05] giorgio dot liscio at email dot it

i think this will marked as "wont fix"



full backtrace will be too long to log..

if you want you can implement your error logger in user space


[2010-09-01 15:21:28] freeman3 at centrum dot cz

Description:

is it possible to include debug backtrace in the error log when some
serious error occurs? Error like "PHP Fatal error:  Call to a member
function getColumns() on a non-object in ../core/entity_core.php on line
230" is quite useless because I don't know from where it was called.

Expected result:

Include debug backtrace in the error log

Actual result:
--
Now only the last line of backtrace is present






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

Req #52761 [Opn->Bgs]: include backtrace in web server log on fatal error

2010-09-01 Thread johannes

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

 ID: 52761
 Updated by: johan...@php.net
 Reported by:freeman3 at centrum dot cz
 Summary:include backtrace in web server log  on fatal error
-Status: Open
+Status: Bogus
 Type:   Feature/Change Request
 Package:Apache2 related
 Operating System:   opensuse
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

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

You can install xdebug on your development server to get this feature.
http://xdebug.org


Previous Comments:

[2010-09-01 19:01:23] freeman3 at centrum dot cz

Too long? I mean log only for fatal error and such. I happens only when
developing application usually, few times a day. It would be few extra
lines only. Access log has several GB usually so I think few lines
doesn't matter. I think many developers would be grateful because this
can save much time.

I have tried something with shutdown handler but it didn't work for me.
If you have a code that returns backtrace when fatal error occurs, I
would be grateful.


[2010-09-01 18:11:05] giorgio dot liscio at email dot it

i think this will marked as "wont fix"



full backtrace will be too long to log..

if you want you can implement your error logger in user space


[2010-09-01 15:21:28] freeman3 at centrum dot cz

Description:

is it possible to include debug backtrace in the error log when some
serious error occurs? Error like "PHP Fatal error:  Call to a member
function getColumns() on a non-object in ../core/entity_core.php on line
230" is quite useless because I don't know from where it was called.

Expected result:

Include debug backtrace in the error log

Actual result:
--
Now only the last line of backtrace is present






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

Bug #52763 [Com]: There is a problem in concatenation with strings and functions

2010-09-01 Thread amaury dot carrade at free dot fr

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

 ID: 52763
 Comment by: amaury dot carrade at free dot fr
 Reported by:amaury dot carrade at free dot fr
 Summary:There is a problem in concatenation with strings and
 functions
 Status: Bogus
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   Linux Kubuntu 10.04
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

Sorry for this pseudo-bug. 

I have not read very well the documentation...


Previous Comments:

[2010-09-01 20:22:39] ras...@php.net

It's not a bug.  Anything that outputs directly instead of returning the
result is 

going to display out of order when inlined into an expression like that.


[2010-09-01 20:19:36] amaury dot carrade at free dot fr

NOTE : I found this bug only, for the time being, whith var_dump
function and a personnal function dump() (same processing as var dump
plus '' and '')


[2010-09-01 20:17:34] ras...@php.net

var_dump() can't be used inline like that.  Use print_r() or
var_export() with the 

return parameter set.


[2010-09-01 20:14:24] amaury dot carrade at free dot fr

Description:

There is a problem in concatenation.

When I write : 

' . var_dump($var) . '';

?>



PHP show the same result as :

';

?>



There is a solution (show below), but it is not practical

';

echo var_dump($var) . '';

?>



Test script:
---
' . var_dump($var) . '';

?>



Expected result:

The result of the function var_dump()

Actual result:
--
The result of the function var_dump()






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

Bug #52763 [Opn->Bgs]: There is a problem in concatenation with strings and functions

2010-09-01 Thread rasmus

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

 ID: 52763
 Updated by: ras...@php.net
 Reported by:amaury dot carrade at free dot fr
 Summary:There is a problem in concatenation with strings and
 functions
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   Linux Kubuntu 10.04
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

It's not a bug.  Anything that outputs directly instead of returning the
result is 

going to display out of order when inlined into an expression like that.


Previous Comments:

[2010-09-01 20:19:36] amaury dot carrade at free dot fr

NOTE : I found this bug only, for the time being, whith var_dump
function and a personnal function dump() (same processing as var dump
plus '' and '')


[2010-09-01 20:17:34] ras...@php.net

var_dump() can't be used inline like that.  Use print_r() or
var_export() with the 

return parameter set.


[2010-09-01 20:14:24] amaury dot carrade at free dot fr

Description:

There is a problem in concatenation.

When I write : 

' . var_dump($var) . '';

?>



PHP show the same result as :

';

?>



There is a solution (show below), but it is not practical

';

echo var_dump($var) . '';

?>



Test script:
---
' . var_dump($var) . '';

?>



Expected result:

The result of the function var_dump()

Actual result:
--
The result of the function var_dump()






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

Bug #52763 [Bgs->Opn]: There is a problem in concatenation with strings and functions

2010-09-01 Thread amaury dot carrade at free dot fr

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

 ID: 52763
 User updated by:amaury dot carrade at free dot fr
 Reported by:amaury dot carrade at free dot fr
-Summary:There is a problem in concatenation
+Summary:There is a problem in concatenation with strings and
 functions
-Status: Bogus
+Status: Open
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   Linux Kubuntu 10.04
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

NOTE : I found this bug only, for the time being, whith var_dump
function and a personnal function dump() (same processing as var dump
plus '' and '')


Previous Comments:

[2010-09-01 20:17:34] ras...@php.net

var_dump() can't be used inline like that.  Use print_r() or
var_export() with the 

return parameter set.


[2010-09-01 20:17:26] ras...@php.net

var_dump() can't be used line like that.  Use print_r() or var_export()
with the 

return parameter set.


[2010-09-01 20:14:24] amaury dot carrade at free dot fr

Description:

There is a problem in concatenation.

When I write : 

' . var_dump($var) . '';

?>



PHP show the same result as :

';

?>



There is a solution (show below), but it is not practical

';

echo var_dump($var) . '';

?>



Test script:
---
' . var_dump($var) . '';

?>



Expected result:

The result of the function var_dump()

Actual result:
--
The result of the function var_dump()






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

Bug #47279 [Bgs]: Symbol xmlTextReaderSetup definition was not found

2010-09-01 Thread johntmills at yahoo dot com

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

 ID: 47279
 User updated by:johntmills at yahoo dot com
 Reported by:johntmills at yahoo dot com
 Summary:Symbol xmlTextReaderSetup definition was not found
 Status: Bogus
 Type:   Bug
 Package:Apache2 related
 Operating System:   AIX537
 PHP Version:5.2.8
 Block user comment: N

 New Comment:

./configure --with-apxs2=/apps/apache/httpd-2.2.4/bin/apxs
--with-libxml-dir=/opt/libxml2/2.6.30 --with-mysql=/opt/mysql/5.0.67
--with-config-file-path=/apps/apache/conf  --enable-maintainer-zts
--prefix=/opt/php/5.2.8 --enable-sigchild
--with-oci8=/oracle/app/oracle/product/10.2.0

make -i install



cp .libs/libphp5.a /apps/IBMIHS/modules/libphp5.a

cp .libs/libphp5.lai /apps/IBMIHS/modules/libphp5.la

cp -p .libs/libphp5.so /apps/IBMIHS/modules/libphp5.so

chmod 755 /apps/IBMIHS/modules/libphp5.so

libtool --finish /mnt/php/5.2.8/php-5.2.8_webcomm_aix53_src/libs



cd / ; tar -cvf /mnt/php/5.2.8/php-5.2.8_webcomm_aix53.tar ./opt/php
./apps/IBMIHS/modules/libphp* ./apps/IBMIHS/conf/php.ini ; cd -





cp -p ./.libs/libphp5.so /apps/apache/httpd-2.2.4/modules/libphp5.so

chmod 755 /apps/apache/httpd-2.2.4/modules/libphp5.so

libtool --finish /export/packages/php-5.2.8_aix53_src/libs





rc.httpd details:





start_httpd() 

   {

echo "Starting HTTPD..."

PID=`cat /apps/apache/logs/httpd.pid 2>/dev/null`

if ps -ef | grep httpd | grep -v grep | awk {'print "_" $2 "_"'}
|  grep "_${PID}_" 1>/dev/null 2>/dev/null

   then

   echo "HTTPD is already running..."

else

   PRELIB=$LIBPATH

   LIBPATH=/apps/apache/httpd-2.2.4/lib:/opt/libxml2/2.6.30/lib

   export LIBPATH

   /apps/apache/httpd-2.2.4/bin/apachectl start

   LIBPATH=$PRELIB

   export LIBPATH

fi

}



stop_httpd() 

   {

# stop daemon

echo "Stopping HTTPD..."

PID=`cat /apps/apache/logs/httpd.pid 2>/dev/null`

if ps -ef | grep httpd | grep -v grep | awk {'print "_" $2 "_"'}
|  grep "_${PID}_" 1>/dev/null 2>/dev/null

   then

   PRELIB=$LIBPATH

   LIBPATH=/apps/apache/httpd-2.2.4/lib:/opt/libxml2/2.6.30/lib

   export LIBPATH

   /apps/apache/httpd-2.2.4/bin/apachectl stop

   LIBPATH=$PRELIB

   export LIBPATH

else

   echo "HTTPD is not running..."

fi


Previous Comments:

[2010-08-27 05:49:11] johntmills at yahoo dot com

Ah well that never really worked.  What I did was make install with an
ignore errors flag, than manually moved the files where they needed to
be to prepare for use.  I'll grab my procedure for IBM VAC in the
morning and post it.


[2010-08-25 15:55:46] rodri dot martins at gmail dot com

I'm getting the same error you in the installation of PHP on AIX 5.3.
Can you help?


[2010-08-25 15:54:01] rodri dot martins at gmail dot com

# gmake -k install

Installing PHP SAPI module:   apache2handler

/usr/local/buildforge/apache/build/instdso.sh
SH_LIBTOOL='/usr/local/buildforge/apache/build/libtool' libphp5.la
/usr/local/buildforge/apache/modules

rm -f /usr/local/buildforge/apache/modules/libphp5.so

/usr/local/buildforge/apache/build/libtool --mode=install cp libphp5.la
/usr/local/buildforge/apache/modules/

cp .libs/libphp5.a /usr/local/buildforge/apache/modules/libphp5.a

cp .libs/libphp5.lai /usr/local/buildforge/apache/modules/libphp5.la

libtool: install: warning: remember to run `libtool --finish
/install/update/php-5.2.6/libs'

chmod 755 /usr/local/buildforge/apache/modules/libphp5.so

chmod: /usr/local/buildforge/apache/modules/libphp5.so: A file or
directory in the path name does not exist.

apxs:Error: Command failed with rc=65536

.

gmake: *** [install-sapi] Error 1

Installing PHP CLI binary:/usr/local/buildforge/php/bin/

Installing PHP CLI man page:  /usr/local/buildforge/php/man/man1/

Installing shared extensions:
/usr/local/buildforge/php/lib/php/extensions/no-debug-non-zts-20060613/

Installing build environment:
/usr/local/buildforge/php/lib/php/build/

Installing header files: 
/usr/local/buildforge/php/include/php/

Installing helper programs:   /usr/local/buildforge/php/bin/

  program: phpize

  program: php-config

Installing man pages: /usr/local/buildforge/php/man/man1/

  page: phpize.1

  page: php-config.1

Installing PEAR environment:  /usr/local/buildforge/php/lib/php/

[PEAR] PEAR   - already installed: 1.7.1

Wrote PEAR system config file at:
/usr/local/buildforge/php/etc/pear.conf

You may want to add: /usr/local/buildforge/php/lib/php to your php.ini
include_path

Install

Bug #52763 [Bgs]: There is a problem in concatenation

2010-09-01 Thread rasmus

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

 ID: 52763
 Updated by: ras...@php.net
 Reported by:amaury dot carrade at free dot fr
 Summary:There is a problem in concatenation
 Status: Bogus
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   Linux Kubuntu 10.04
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

var_dump() can't be used inline like that.  Use print_r() or
var_export() with the 

return parameter set.


Previous Comments:

[2010-09-01 20:17:26] ras...@php.net

var_dump() can't be used line like that.  Use print_r() or var_export()
with the 

return parameter set.


[2010-09-01 20:14:24] amaury dot carrade at free dot fr

Description:

There is a problem in concatenation.

When I write : 

' . var_dump($var) . '';

?>



PHP show the same result as :

';

?>



There is a solution (show below), but it is not practical

';

echo var_dump($var) . '';

?>



Test script:
---
' . var_dump($var) . '';

?>



Expected result:

The result of the function var_dump()

Actual result:
--
The result of the function var_dump()






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

Bug #52763 [Opn->Bgs]: There is a problem in concatenation

2010-09-01 Thread rasmus

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

 ID: 52763
 Updated by: ras...@php.net
 Reported by:amaury dot carrade at free dot fr
 Summary:There is a problem in concatenation
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   Linux Kubuntu 10.04
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

var_dump() can't be used line like that.  Use print_r() or var_export()
with the 

return parameter set.


Previous Comments:

[2010-09-01 20:14:24] amaury dot carrade at free dot fr

Description:

There is a problem in concatenation.

When I write : 

' . var_dump($var) . '';

?>



PHP show the same result as :

';

?>



There is a solution (show below), but it is not practical

';

echo var_dump($var) . '';

?>



Test script:
---
' . var_dump($var) . '';

?>



Expected result:

The result of the function var_dump()

Actual result:
--
The result of the function var_dump()






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

[PHP-BUG] Bug #52763 [NEW]: There is a problem in concatenation

2010-09-01 Thread amaury dot carrade at free dot fr

From: 
Operating system: Linux Kubuntu 10.04
PHP version:  5.3.3
Package:  Unknown/Other Function
Bug Type: Bug
Bug description:There is a problem in concatenation

Description:

There is a problem in concatenation.

When I write : 

' . var_dump($var) . '';

?>



PHP show the same result as :

';

?>



There is a solution (show below), but it is not practical

';

echo var_dump($var) . '';

?>



Test script:
---
' . var_dump($var) . '';

?>



Expected result:

The result of the function var_dump()

Actual result:
--
The result of the function var_dump()

-- 
Edit bug report at http://bugs.php.net/bug.php?id=52763&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52763&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52763&r=trysnapshot53
Try a snapshot (trunk):  
http://bugs.php.net/fix.php?id=52763&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52763&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=52763&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52763&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=52763&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=52763&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=52763&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=52763&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=52763&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=52763&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=52763&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52763&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=52763&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52763&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=52763&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=52763&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=52763&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=52763&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=52763&r=mysqlcfg

Bug #47930 [Asn->Csd]: ext/filter crashes when module startup bails out

2010-09-01 Thread stas

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

 ID: 47930
 Updated by: s...@php.net
 Reported by:stas at zend dot com
 Summary:ext/filter crashes when module startup bails out
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Reproducible crash
 Operating System:   *
 PHP Version:5.2CVS-2009-04-29
 Assigned To:stas
 Block user comment: N

 New Comment:

This bug has been fixed in SVN.

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.

I think this one is fine in both 5.3 and trunk.


Previous Comments:

[2009-09-06 10:16:43] paj...@php.net

I got that, but why trunk (HEAD) is different from 5.3?



Or do you mean:



- 5.2, no fix at all

- 5.3, fix but without ABI break

- 6, all changes kept



?


[2009-09-05 23:40:20] s...@php.net

Fix for 5.3 changes binary API, so it can't be applied to 5.2


[2009-09-05 17:17:31] paj...@php.net

Any reason why this change has been commited to HEAD but never to 5.3,
or has it been reverted?



Please clarify the situation and sync both branches as soon as possible.


[2009-04-29 00:41:24] s...@php.net

fixed for 5.3/HEAD, 5.2 fix still required, since 5.3+ fix changes
binary API


[2009-04-08 23:01:04] stas at zend dot com

Description:

1. If one of the modules startup bails out, that leads to aborting the
startup sequence and PG(modules_activated) be 0.

This, in turn, precludes running RSHUTDOWN functions on modules.



2. ext/filter allocates IF_G(get_array), etc. in the course of the
request startup, and if RSHUTDOWN is not called, they are not cleaned
up.



3. Since ext/filter does not initialize IF_G arrays, on the next request
uncleaned value will be used. Since these arrays are no longer pointing
to a valid memory (which was cleaned on the end of the previous
request), this will result in a crash. 

Reproduce code:
---
1. Create extension that uses zend_bailout in RINIT.

2. Run two requests while ext/filter is present and turned on

3. Crash! 







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

Req #45829 [Asn]: [intl] Allow MessageFormatter / IntlDateFormatter to accept DateTime objects?

2010-09-01 Thread stas

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

 ID: 45829
 Updated by: s...@php.net
 Reported by:mathieuk at gmail dot com
 Summary:[intl] Allow MessageFormatter / IntlDateFormatter to
 accept DateTime objects?
 Status: Assigned
 Type:   Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
 Operating System:   Mac OSX 10.5
 PHP Version:5.3.0alpha1
 Assigned To:stas
 Block user comment: N

 New Comment:

Yes, this is on the TODO list (contributions welcome! :)


Previous Comments:

[2008-08-16 16:09:15] mathieuk at gmail dot com

Additionally, MessageFormatter::parse() might return a DateTime object 

instead of a UNIX timestamp.


[2008-08-15 06:13:57] mathieuk at gmail dot com

Description:

Feature request for the new intl extension.



Both the MessageFormatter and the IntlDateFormatter accept values for 

dates. The IntlDateFormatter accepts both Unix timestamps and the value


for localtime(). I'm assuming it's the same for the MessageFormatter.



Since PHP 5.2 we have the DateTime object through the standard date 

extension. While it's easy to get the unix timestamp from a DateTime 

object through DateTime::getTimestamp() introduce in 5.3, this is an 

extra statement which just adds clutter.



Could these two formatters be made to also accept DateTime objects ?









Reproduce code:
---
format(array($date));



?>





Expected result:

Output: Today one year ago is 15 aug 2007

Actual result:
--
Output: Today one year ago is 1 jan 1970






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

Bug #51043 [Fbk->NoF]: apache crashes on php return statement

2010-09-01 Thread stas

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

 ID: 51043
 Updated by: s...@php.net
 Reported by:php at lokedupont dot info
 Summary:apache crashes on php return statement
-Status: Feedback
+Status: No Feedback
 Type:   Bug
 Package:Reproducible crash
 Operating System:   OS X Snow leopard
 PHP Version:5.3.1
 Assigned To:stas
 Block user comment: N

 New Comment:

If you still have repro example (with zf is ok) and it works with latest
5.3 build please send it to me.


Previous Comments:

[2010-04-25 20:03:12] fel...@php.net

Please try using this snapshot:

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

  http://windows.php.net/snapshots/




[2010-02-24 01:00:04] 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".


[2010-02-16 10:45:39] paj...@php.net

Try to figure out where it crashes in ZF and then try to write a script
to reproduce the same context.



You can also try to report a bug in the ZF tracker, they could help.


[2010-02-16 10:43:14] php at lokedupont dot info

I haven't been able to get it to crash without using that ZF bit.



Should i open a bug with the ZF guys or does stas have some contact
he/she will ping?


[2010-02-14 20:15:27] paj...@php.net

Try to catch where it crashed in ZF and write a script to reproduce the
same situation. Or try to convince the ZF developers to figure out why
it crashes. But using the ZF to fix a crash is not smtg we can do.



Assigned to Stas so he can ping the ZF guys if necessary.




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/bug.php?id=51043


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

Bug #49764 [Com]: number_format() fails (randomly?)

2010-09-01 Thread adenman at tmea dot org

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

 ID: 49764
 Comment by: adenman at tmea dot org
 Reported by:tec at baufi24 dot de
 Summary:number_format() fails (randomly?)
 Status: Assigned
 Type:   Bug
 Package:Math related
 Operating System:   Windows
 PHP Version:*
 Assigned To:pajoye
 Block user comment: N

 New Comment:

I am able to reproduce this.

PHP: 5.2.13

OS: Windows 2008 Standard Server, 64-bit

(Windows NT WEB2 6.1 build 7600 from phpinfo)

CPU: AMD Opteron 6172



Using the test posted by 'adrianv at taly dot net' on bug
http://bugs.php.net/bug.php?id=47418 and changing to list whole numbers,
I have found the following numbers exhibit this odd behavior:

17, 19, 29, 39

and multiples of ten of these numbers (170, 1700, 17000, etc)



They get output as:

16.:0, 18.:0, 28.:0, 38.:0, etc

when using the number_format or sprintf functions to format them with
decimal places.



In addition to number_format and sprintf, I have found that once you do
basic math with these numbers and float numbers, even just echoing the
result will trigger this bug. The bcmath functions do not exhibit this
behavior.



Example:

$tot = 17;

$math = $tot * 1.5;

$math = $math / 1.5;

$math2 = bcmul($tot, 1.5, 1);

$math2 = bcdiv($math2, 1.5, 1);

echo $math //outputs 16.:, expect 17

echo $math2 //outputs 17.0, expect 17.0


Previous Comments:

[2010-08-04 13:15:33] codeslinger at compsalot dot com

it's not random, it's just very hard to reproduce.  only certain
specific values will trigger this bug.  and the weird thing is that the
specific value changes from build to build and with different oses.



this bug is a dup of the many other existing reports about this bug.

bugs 43487, 47304, 47716, 47732, 51396  etc..



this bug has been encountered in:

php 5.2.11, 5.2.12, 5.2.13, 5.2.25, 5.2.26, 5.2.9...  



it has been found on  Windows 2000, Windows XP, Windows 2003, ubuntu,
mandriva. This bug has been reproduced both with and without xdebug
and/or zend debugger.





You want to reproduce this bug???!!!  it's very easy, I will give you a
one-liner



install ubuntu 8.0.4

install the standard php that comes with ubuntu 8.0.4



now run this:

echo (string) (double) -0.0;



actual result:  -0.0:



Note that changing the float percision greatly affects the bug.



The thing is that the value is very specific to the actual build and the
actual os.  For instance it was reported that on Windows nt 5.2 (2003?)
the following will fail:



echo round(1451,2);



actual result: 1450.:0





It has also been reported that using BCMath helps but does not totally
solve this problem "3 out of 4 were fixed".





But despite all of the above, this bug keeps getting blown off as not
repro!!!  :-(





Consider the following true story:



once upon a time, there was a German insurance company sued by a client
whoâd lost a lot of money through the insurance companyâs flawed
bookkeeping. The insurance company went into a panic and started hunting
the bug and were able to prove it was caused by customized software
theyâd bought from a German software house. They sued the software
house.



The software house went into a panic and started hunting the bug
further. They were able to prove the bug was actually caused by a flaw
in Lotus Symphony. So they sued Lotus.



Now Lotus went into a panic and started hunting the bug further. They
were able to prove the bug was actually in their C compiler. The
compiler was generating a short jump when instead it should have been
generating a long jump.



===



I first encountered this bug in a billing program that I wrote...  and
so far nobody seems to give a flying fig about fixing this bug.  I do
not wish to get sued by an irate customer...  especially since I am
still in start-up mode and have yet to make a single nickel, otherwise
I'd be willing to throw some money at php devs if that's what it took to
get this fixed.  How about somebody else stepping up to the plate, there
are some deep pockets out there, come on ibm, microsoft, ???   where is
your community spirit?  



If there is even one single math error in php that is too much.  PHP is
widely used for eCommerce $ and math accuracy is critical.  If I did not
have such a huge investment in php code and skills I would have already
jumped ship to a different language, as it is, I'm giving it very
serious consideration.  This situation is very ungood.



Just randomly using a different version of php (the latest snapshot)
does not solve anything.  It has already been established that every
single version of php fails with different values.  So changing the
version will cause that specific value to no longer fail.  But until the
*cause* of the bug is *actually understood*...  we still have lurking
failures

Req #52761 [Opn]: include backtrace in web server log on fatal error

2010-09-01 Thread freeman3 at centrum dot cz

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

 ID: 52761
 User updated by:freeman3 at centrum dot cz
 Reported by:freeman3 at centrum dot cz
 Summary:include backtrace in web server log  on fatal error
 Status: Open
 Type:   Feature/Change Request
 Package:Apache2 related
 Operating System:   opensuse
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

Too long? I mean log only for fatal error and such. I happens only when
developing application usually, few times a day. It would be few extra
lines only. Access log has several GB usually so I think few lines
doesn't matter. I think many developers would be grateful because this
can save much time.

I have tried something with shutdown handler but it didn't work for me.
If you have a code that returns backtrace when fatal error occurs, I
would be grateful.


Previous Comments:

[2010-09-01 18:11:05] giorgio dot liscio at email dot it

i think this will marked as "wont fix"



full backtrace will be too long to log..

if you want you can implement your error logger in user space


[2010-09-01 15:21:28] freeman3 at centrum dot cz

Description:

is it possible to include debug backtrace in the error log when some
serious error occurs? Error like "PHP Fatal error:  Call to a member
function getColumns() on a non-object in ../core/entity_core.php on line
230" is quite useless because I don't know from where it was called.

Expected result:

Include debug backtrace in the error log

Actual result:
--
Now only the last line of backtrace is present






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

[PHP-BUG] Bug #52762 [NEW]: autoload not called inside create_function

2010-09-01 Thread morpika at vipmail dot hu

From: 
Operating system: FreeBSD 8.0
PHP version:  5.3.3
Package:  *Programming Data Structures
Bug Type: Bug
Bug description:autoload not called inside create_function

Description:

If i define my own error handler with the use of the set_error_handler and
the create_function functions, then the 'errors' class inside the
create_function triggers the autoload function by errors that user defined
error handlers can handle. It's OK!



But when i make an E_STRICT error for example by defining the 'connect'
function in class 'a' (which already exists in the built in mysqli class),
then it won't call the autoload function, it gives me a fatal error for not
finding the 'errors' class.



What i expected:



a) If this type of E_STRICT error cann't be handled by my own error
handler, then PHP's default error handler should have been used.

b) If this type of E_STRICT error can be handled by my own error handler,
then the __autoload function should have been called as a last chance for
opening the 'errors' class.

Test script:
---
index.php:







mysql.php:





Expected result:

autoload called

Actual result:
--
Fatal error: Class 'errors' not found in mysql.php on line 7

-- 
Edit bug report at http://bugs.php.net/bug.php?id=52762&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52762&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52762&r=trysnapshot53
Try a snapshot (trunk):  
http://bugs.php.net/fix.php?id=52762&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52762&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=52762&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52762&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=52762&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=52762&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=52762&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=52762&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=52762&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=52762&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=52762&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52762&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=52762&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52762&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=52762&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=52762&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=52762&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=52762&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=52762&r=mysqlcfg

Bug #35228 [Com]: Php is slow under Mac OS X 10.4

2010-09-01 Thread djpumpkin at gmail dot com

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

 ID: 35228
 Comment by: djpumpkin at gmail dot com
 Reported by:nicolas dot ross at cybercat dot ca
 Summary:Php is slow under Mac OS X 10.4
 Status: Bogus
 Type:   Bug
 Package:Performance problem
 Operating System:   Mac OS X 10.4
 PHP Version:4.4.1
 Block user comment: N

 New Comment:

I know this is an old thread - but I can also confirm that Php is slow
under Mac 

OS X 10.4



I've been trying to build a web development environment on 10.4 and have


experienced the 15 second page load times as described here.



I have seen the proposed solution here: http://marc.info/?l=php-

general&m=113198556215028&w=2  but can find no way to implement this.



How can I fix this?


Previous Comments:

[2005-11-15 18:15:57] nicolas dot ross at cybercat dot ca

Maybe, but still it makes php works ok under mac os x 10.4. Without it,
php is slow, hell slow.


[2005-11-15 18:07:56] sni...@php.net

Don't use --enable-experimental-zts (it will definately break things!)




[2005-11-15 17:11:26] nicolas dot ross at cybercat dot ca

Description:

Php is slow under Mac OS X 10.4 (tiger). All php code that is not
"simple" is slow. Page generation time is ranging from 8 to 15 seconds
for page normally taking less than 1 second. I've tracked down the
problem to a system-call filesystem related problem



Please see those threads :



http://marc.theaimsgroup.com/?l=php-dev&m=113200357113670

http://marc.theaimsgroup.com/?t=11267031754

for more details, and the solution I've found.

Reproduce code:
---
- Take a php app (forum like phpbb, gallery2, mambo cms, or others)

- Use it under Mac OS X 10.4

- Any version of php was tried and confirmed to experience major
slowdown: Stock php from Mac OS X, all official php 4.3.x, 4.4.x

- Any recent version of apache, default configure and compile: apache
1.3.33, 2.0.55.



Apache configure line used :

/configure --enable-so --enable-modules=most --enable-mods-shared=max
--enable-proxy --enable-ssl



Php configure line used :

./configure --with-apxs2=/usr/local/apache2/bin/apxs
--enable-experimental-zts --with-mysql=/usr/local/mysql --with-fbsql
--with-xml --enable-ftp --with-curl=/sw --with-zlib --with-png-dir=/sw
--with-jpeg-dir=/sw --with-gd --with-ttf=/sw --with-freetype-dir=/sw
--enable-track-vars --enable-trans-id --disable-debug



All options were striped down except mysql and --enable-track-vars
--enable-trans-id --disable-debug with no more restult.

Expected result:

less than 1 second page generation time for the a test site using mambo
CMS

Actual result:
--
8 to 15 second of page generation time. During this time, the actual
apache thread that serves the request eats 100% of the cpu time.






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

Req #52761 [Com]: include backtrace in web server log on fatal error

2010-09-01 Thread giorgio dot liscio at email dot it

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

 ID: 52761
 Comment by: giorgio dot liscio at email dot it
 Reported by:freeman3 at centrum dot cz
 Summary:include backtrace in web server log  on fatal error
 Status: Open
 Type:   Feature/Change Request
 Package:Apache2 related
 Operating System:   opensuse
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

i think this will marked as "wont fix"



full backtrace will be too long to log..

if you want you can implement your error logger in user space


Previous Comments:

[2010-09-01 15:21:28] freeman3 at centrum dot cz

Description:

is it possible to include debug backtrace in the error log when some
serious error occurs? Error like "PHP Fatal error:  Call to a member
function getColumns() on a non-object in ../core/entity_core.php on line
230" is quite useless because I don't know from where it was called.

Expected result:

Include debug backtrace in the error log

Actual result:
--
Now only the last line of backtrace is present






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

Bug #52419 [Com]: Unable to compile PHP with both Apache2 and FPM support

2010-09-01 Thread f...@php.net

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

 ID: 52419
 Comment by: f...@php.net
 Reported by:php-bugs at majkl578 dot cz
 Summary:Unable to compile PHP with both Apache2 and FPM
 support
 Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   Linux Debian
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

the problem is the same if compiling SAPI apache2handler with litespeed.
The same 

with fpm and litespeed.



Is it possible to compile PHP with multiple SAPI ?


Previous Comments:

[2010-09-01 14:29:49] f...@php.net

The problem is:



in the general Makefile there is:



BUILD_FPM = $(LIBTOOL) --mode=link $(CC) -export-dynamic $(CFLAGS_CLEAN)


$(EXTRA_CFLAGS) $(EXTRA_LDFLAGS_PROGRAM) $(LDFLAGS) $(PHP_RPATHS) 

$(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS) $(EXTRA_LIBS) $(SAPI_EXTRA_LIBS) 

$(ZEND_EXTRA_LIBS) -o $(SAPI_FPM_PATH)



and 



PHP_SAPI_OBJS = sapi/apache2handler/mod_php5.lo 

sapi/apache2handler/sapi_apache2.lo sapi/apache2handler/apache_config.lo


sapi/apache2handler/php_functions.lo sapi/fpm/fpm/fastcgi.lo
sapi/fpm/fpm/fpm.lo 

sapi/fpm/fpm/fpm_children.lo sapi/fpm/fpm/fpm_cleanup.lo 

sapi/fpm/fpm/fpm_clock.lo sapi/fpm/fpm/fpm_conf.lo
sapi/fpm/fpm/fpm_env.lo 

sapi/fpm/fpm/fpm_events.lo sapi/fpm/fpm/fpm_main.lo
sapi/fpm/fpm/fpm_php.lo 

sapi/fpm/fpm/fpm_php_trace.lo sapi/fpm/fpm/fpm_process_ctl.lo 

sapi/fpm/fpm/fpm_request.lo sapi/fpm/fpm/fpm_shm.lo 

sapi/fpm/fpm/fpm_shm_slots.lo sapi/fpm/fpm/fpm_signals.lo 

sapi/fpm/fpm/fpm_sockets.lo sapi/fpm/fpm/fpm_status.lo
sapi/fpm/fpm/fpm_stdio.lo 

sapi/fpm/fpm/fpm_unix.lo sapi/fpm/fpm/fpm_worker_pool.lo
sapi/fpm/fpm/zlog.lo 

sapi/fpm/fpm/fpm_trace.lo sapi/fpm/fpm/fpm_trace_ptrace.lo 

main/internal_functions.lo



FPM is linked with apache but the apr lib is not known at compile time.



There is the same problem when compiling libphp5.so which is linked
agains FPM 

object files and libevent is not known at compile time:



# make libs/libphp5.bundle



sapi/fpm/fpm/fpm_children.o: In function `fpm_children_make':

/LIBRE/dev/php-src/branches/PHP_5_3/sapi/fpm/fpm/fpm_children.c:381:
undefined 

reference to `event_reinit'


[2010-09-01 12:05:43] f...@php.net

I have a similar issue with the current PHP_5_3.



When the php-fpm is built, it's linked against :



sapi/apache2handler/mod_php5.lo

sapi/apache2handler/sapi_apache2.lo

sapi/apache2handler/apache_config.lo

sapi/apache2handler/php_functions.lo



I think it's somehow related to http://bugs.php.net/52498.


[2010-08-04 10:35:24] ali at aliziad dot clom

fyi:



I am also getting the same error with php 5.3.3 (/w apxs and fpm) on
CentOS



-ali


[2010-07-23 20:44:23] ras...@php.net

You could try it in a clean Debian image using the free vmware player
and the 

images from http://www.thoughtpolice.co.uk/vmware/

Just so you have a clean environment to compare yours against.


[2010-07-23 20:39:38] php-bugs at majkl578 dot cz

No, I don't, I've only this one. Maybe it's really (somehow) related to
my environment, because I'm also unable to compile PHP with pecl binary
even if '--with-pear' and '--enable-cli' are set...




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/bug.php?id=52419


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

Bug #51248 [Asn]: Segmentation fault in mysql_fetch_array

2010-09-01 Thread andrey

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

 ID: 51248
 Updated by: and...@php.net
 Reported by:mbecc...@php.net
 Summary:Segmentation fault in mysql_fetch_array
 Status: Assigned
 Type:   Bug
 Package:MySQL related
 Operating System:   FreeBSD 6.2
 PHP Version:5.3.2
 Assigned To:mysql
 Block user comment: N

 New Comment:

valgrind output would be helpful :)

Thanks!


Previous Comments:

[2010-08-27 22:00:08] php at group dot apple dot com

This reproduces on Mac OS X, and appears to be a stack overflow issue. I
enabled 

stack overflow protection by adding "-g -fstack-protector-all" to the
CFLAGS passed 

to configure. (The problem does not reproduce when configured with
--enable-debug 

or -O0 instead of -Os.) In running this through gdb, the following line
in changes 

execute_data and may be the start of the corruption:

  zend_vm_execute.h:301 EX_T(opline->result.u.var).var.ptr_ptr 
= 

&EX_T(opline->result.u.var).var.ptr;



With the following sample script, the third pass through 

zend_do_fcall_common_helper_SPEC() demonstrates the crash:






[2010-08-26 13:27:05] u...@php.net

Please try to provide a short test script, like its good style with
every other bug report.


[2010-08-25 10:32:16] paj...@php.net

Latest drupal (6+) versions work with 5.3 smoothly.


[2010-08-25 10:22:29] mbecc...@php.net

@Chris: I understand that Drupal and PHP 5.3 might not live happily
together, but I'd expect errors, not segmentation faults.



@Andrey: Is there anything I can do to help understanding what happens
on when using libmysql?


[2010-08-24 20:14:29] chris at chrischarlton dot us

Drupal 6.14 was the first 6.x to start supporting PHP 5.3, but mileage
will vary. 

It is highly recommended to run Drupal on a PHP 5.2.x server. Of course
Drupal will 

natively support PHP 5.3, there are just a few kinks being worked out.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=51248


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

Bug #52756 [Fbk]: bounding box coordinates are wrong

2010-09-01 Thread pajoye

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

 ID: 52756
 Updated by: paj...@php.net
 Reported by:rasmus at mindplay dot dk
 Summary:bounding box coordinates are wrong
 Status: Feedback
 Type:   Bug
 Package:GD related
 Operating System:   Linux delphinus 2.6.32.8
 PHP Version:5.2.14
 Block user comment: N

 New Comment:

Please provide the font file you use.


Previous Comments:

[2010-09-01 14:18:14] rasmus at mindplay dot dk

No luck with PHP 5.3.3 from the XAMPP distribution on Windows.


[2010-09-01 11:12:08] paj...@php.net

Please try with 5.3.3


[2010-09-01 04:12:49] rasmus at mindplay dot dk

Description:

The metrics returned by this function are inaccurate - I put together a
comprehensive test script that demonstrates the problem:



http://fontjazz.com/metrics/test.php



This is also reproducible on my workstation with PHP 5.3.1 on Windows
Vista SP1 (build 6001).



This bug has been present in Windows builds of PHP 5 for at least a
year, and was introduced in Linux builds more recently - my font
embedding system (fontjazz.com) is currently generating broken fonts due
to this bug.



I've reported this bug before, and if I recall, others reported it
before I did - relating this problem to notes/revisions from previous
attempts to address this problem might be useful, but I can't seem to
find the old bug in the database anymore.



I don't recall if this bug was blamed on PHP, GD or FreeType - I think
there were different theories at the time, but it looks like there was
no resolution.

Test script:
---
The source code for the test script is displayed on this page:



http://fontjazz.com/metrics/test.php



You will need a font for testing - I recommend "georgiai.ttf", the
OpenType version, which can be found on Windows Vista installations
under WINDOWS\Fonts.



If you don't have this font, try another OpenType font in italics - this
problem seems to affect italic fonts the worst, probably because italic
typefaces generally have more glyph overlap.



With some non-italic fonts, unless rendered at really large sizes, the
problem may not be obvious enough to spot with the eye, but there is
always some degree of inaccuracy, with any font, when rendered at a
sufficiently large size.



Expected result:

The red outline should accurately surround the rendered text.

Actual result:
--
The red outline is somewhat offset.






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

[PHP-BUG] Req #52761 [NEW]: include backtrace in web server log on fatal error

2010-09-01 Thread freeman3 at centrum dot cz

From: 
Operating system: opensuse
PHP version:  5.3.3
Package:  Apache2 related
Bug Type: Feature/Change Request
Bug description:include backtrace in web server log  on fatal error

Description:

is it possible to include debug backtrace in the error log when some
serious error occurs? Error like "PHP Fatal error:  Call to a member
function getColumns() on a non-object in ../core/entity_core.php on line
230" is quite useless because I don't know from where it was called.

Expected result:

Include debug backtrace in the error log

Actual result:
--
Now only the last line of backtrace is present

-- 
Edit bug report at http://bugs.php.net/bug.php?id=52761&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52761&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52761&r=trysnapshot53
Try a snapshot (trunk):  
http://bugs.php.net/fix.php?id=52761&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52761&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=52761&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52761&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=52761&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=52761&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=52761&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=52761&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=52761&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=52761&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=52761&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52761&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=52761&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52761&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=52761&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=52761&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=52761&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=52761&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=52761&r=mysqlcfg

Bug #52752 [Com]: Program terminated with signal 7, Bus error.

2010-09-01 Thread paulgao at yeah dot net

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

 ID: 52752
 Comment by: paulgao at yeah dot net
 Reported by:paulgao at yeah dot net
 Summary:Program terminated with signal 7, Bus error.
 Status: Feedback
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   irrelevant
 PHP Version:5.3SVN-2010-08-31 (SVN)
 Block user comment: N

 New Comment:

script run in Centos 5 32bit server, php-fpm mode.



configure command:

./configure --prefix=/usr/local/php --without-pear --with-mysqli=mysqlnd
--disable-phar --with-iconv --with-zlib --enable-exif --enable-sockets
--enable-mbstring=all --enable-inline-optimization --enable-debug
--enable-static --disable-ipv6 --disable-pdo --without-sqlite
--enable-fpm --with-libevent=shared


Previous Comments:

[2010-09-01 15:17:28] paulgao at yeah dot net

test script:





core dump backtreace message:





#0  0x082fd8d6 in lex_scan (zendlval=0xbff7295c) at
Zend/zend_language_scanner.c:930

930 yych = *YYCURSOR;

(gdb) bt

#0  0x082fd8d6 in lex_scan (zendlval=0xbff7295c) at
Zend/zend_language_scanner.c:930

#1  0x08324d5d in zendlex (zendlval=0xbff72958) at
/root/php-5.3.3/Zend/zend_compile.c:4947

#2  0x082f7447 in zendparse () at
/root/php-5.3.3/Zend/zend_language_parser.c:3280

#3  0x082fcc97 in compile_file (file_handle=0xbff72ad0, type=2) at
Zend/zend_language_scanner.l:354

#4  0x082fcdec in compile_filename (type=2, filename=0xa179af0) at
Zend/zend_language_scanner.l:397

#5  0x0837983e in ZEND_INCLUDE_OR_EVAL_SPEC_TMP_HANDLER
(execute_data=0xa179a04) at /root/php-5.3.3/Zend/zend_vm_execute.h:5199

#6  0x08369b48 in execute (op_array=0xa1467a4) at
/root/php-5.3.3/Zend/zend_vm_execute.h:107

#7  0x083398ca in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/php-5.3.3/Zend/zend.c:1266

#8  0x082cc48f in php_execute_script (primary_file=0xbff77034) at
/root/php-5.3.3/main/main.c:2275

#9  0x0840f171 in main (argc=3, argv=0xbff77174) at
/root/php-5.3.3/sapi/fpm/fpm/fpm_main.c:1865


[2010-09-01 07:00:48] ras...@php.net

That doesn't seem to be APC-related if the backtrace is to be believed. 
It seems 

to be happening on the initial compile.  But yes, please verify that it
happens 

without APC as well.


[2010-09-01 06:01:59] ahar...@php.net

Please test if this fails without APC. If so, we'll need a test script
to diagnose the problem.


[2010-08-31 20:45:32] paulgao at yeah dot net

I use 5.3.4-dev, and APC 3.1.5-dev.


[2010-08-31 20:43:53] paulgao at yeah dot net

Description:

sometimes, PHP was core dump, error message is 'Program terminated with
signal 7, Bus error.'.

Test script:
---
I don't know code.

Actual result:
--
gdb backtrace message:





#0  0x007e9179 in lex_scan (zendlval=0x7fffe9900bd8) at
Zend/zend_language_scanner.l:1635

#1  0x00814517 in zendlex (zendlval=0x7fffe9900bd0) at
/root/php-5.3.3/Zend/zend_compile.c:4946

#2  0x007e2700 in zendparse () at
/root/php-5.3.3/Zend/zend_language_parser.c:3280

#3  0x007e817c in compile_file (file_handle=0x7fffe9901fc0,
type=2) at Zend/zend_language_scanner.l:354

#4  0x004c5bd8 in my_compile_file (h=0x7fffe9901fc0, type=2) at
/root/php-5.3.3/ext/apc/apc_main.c:541

#5  0x007e82f3 in compile_filename (type=2, filename=0x4ce0440)
at Zend/zend_language_scanner.l:397

#6  0x0087ee91 in ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER
(execute_data=0x2ac39df370f0) at
/root/php-5.3.3/Zend/zend_vm_execute.h:8569

#7  0x0085a9f3 in execute (op_array=0x3e1cd80) at
/root/php-5.3.3/Zend/zend_vm_execute.h:107

#8  0x0082a2d7 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/php-5.3.3/Zend/zend.c:1194

#9  0x007b44cb in php_execute_script
(primary_file=0x7fffe9906920) at /root/php-5.3.3/main/main.c:2260

#10 0x0091deae in main (argc=3, argv=0x7fffe9906b28) at
/root/php-5.3.3/sapi/fpm/fpm/fpm_main.c:1865






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

Bug #52752 [Com]: Program terminated with signal 7, Bus error.

2010-09-01 Thread paulgao at yeah dot net

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

 ID: 52752
 Comment by: paulgao at yeah dot net
 Reported by:paulgao at yeah dot net
 Summary:Program terminated with signal 7, Bus error.
 Status: Feedback
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   irrelevant
 PHP Version:5.3SVN-2010-08-31 (SVN)
 Block user comment: N

 New Comment:

test script:





core dump backtreace message:





#0  0x082fd8d6 in lex_scan (zendlval=0xbff7295c) at
Zend/zend_language_scanner.c:930

930 yych = *YYCURSOR;

(gdb) bt

#0  0x082fd8d6 in lex_scan (zendlval=0xbff7295c) at
Zend/zend_language_scanner.c:930

#1  0x08324d5d in zendlex (zendlval=0xbff72958) at
/root/php-5.3.3/Zend/zend_compile.c:4947

#2  0x082f7447 in zendparse () at
/root/php-5.3.3/Zend/zend_language_parser.c:3280

#3  0x082fcc97 in compile_file (file_handle=0xbff72ad0, type=2) at
Zend/zend_language_scanner.l:354

#4  0x082fcdec in compile_filename (type=2, filename=0xa179af0) at
Zend/zend_language_scanner.l:397

#5  0x0837983e in ZEND_INCLUDE_OR_EVAL_SPEC_TMP_HANDLER
(execute_data=0xa179a04) at /root/php-5.3.3/Zend/zend_vm_execute.h:5199

#6  0x08369b48 in execute (op_array=0xa1467a4) at
/root/php-5.3.3/Zend/zend_vm_execute.h:107

#7  0x083398ca in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/php-5.3.3/Zend/zend.c:1266

#8  0x082cc48f in php_execute_script (primary_file=0xbff77034) at
/root/php-5.3.3/main/main.c:2275

#9  0x0840f171 in main (argc=3, argv=0xbff77174) at
/root/php-5.3.3/sapi/fpm/fpm/fpm_main.c:1865


Previous Comments:

[2010-09-01 07:00:48] ras...@php.net

That doesn't seem to be APC-related if the backtrace is to be believed. 
It seems 

to be happening on the initial compile.  But yes, please verify that it
happens 

without APC as well.


[2010-09-01 06:01:59] ahar...@php.net

Please test if this fails without APC. If so, we'll need a test script
to diagnose the problem.


[2010-08-31 20:45:32] paulgao at yeah dot net

I use 5.3.4-dev, and APC 3.1.5-dev.


[2010-08-31 20:43:53] paulgao at yeah dot net

Description:

sometimes, PHP was core dump, error message is 'Program terminated with
signal 7, Bus error.'.

Test script:
---
I don't know code.

Actual result:
--
gdb backtrace message:





#0  0x007e9179 in lex_scan (zendlval=0x7fffe9900bd8) at
Zend/zend_language_scanner.l:1635

#1  0x00814517 in zendlex (zendlval=0x7fffe9900bd0) at
/root/php-5.3.3/Zend/zend_compile.c:4946

#2  0x007e2700 in zendparse () at
/root/php-5.3.3/Zend/zend_language_parser.c:3280

#3  0x007e817c in compile_file (file_handle=0x7fffe9901fc0,
type=2) at Zend/zend_language_scanner.l:354

#4  0x004c5bd8 in my_compile_file (h=0x7fffe9901fc0, type=2) at
/root/php-5.3.3/ext/apc/apc_main.c:541

#5  0x007e82f3 in compile_filename (type=2, filename=0x4ce0440)
at Zend/zend_language_scanner.l:397

#6  0x0087ee91 in ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER
(execute_data=0x2ac39df370f0) at
/root/php-5.3.3/Zend/zend_vm_execute.h:8569

#7  0x0085a9f3 in execute (op_array=0x3e1cd80) at
/root/php-5.3.3/Zend/zend_vm_execute.h:107

#8  0x0082a2d7 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/php-5.3.3/Zend/zend.c:1194

#9  0x007b44cb in php_execute_script
(primary_file=0x7fffe9906920) at /root/php-5.3.3/main/main.c:2260

#10 0x0091deae in main (argc=3, argv=0x7fffe9906b28) at
/root/php-5.3.3/sapi/fpm/fpm/fpm_main.c:1865






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

Bug #52419 [Com]: Unable to compile PHP with both Apache2 and FPM support

2010-09-01 Thread f...@php.net

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

 ID: 52419
 Comment by: f...@php.net
 Reported by:php-bugs at majkl578 dot cz
 Summary:Unable to compile PHP with both Apache2 and FPM
 support
 Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   Linux Debian
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

The problem is:



in the general Makefile there is:



BUILD_FPM = $(LIBTOOL) --mode=link $(CC) -export-dynamic $(CFLAGS_CLEAN)


$(EXTRA_CFLAGS) $(EXTRA_LDFLAGS_PROGRAM) $(LDFLAGS) $(PHP_RPATHS) 

$(PHP_GLOBAL_OBJS) $(PHP_SAPI_OBJS) $(EXTRA_LIBS) $(SAPI_EXTRA_LIBS) 

$(ZEND_EXTRA_LIBS) -o $(SAPI_FPM_PATH)



and 



PHP_SAPI_OBJS = sapi/apache2handler/mod_php5.lo 

sapi/apache2handler/sapi_apache2.lo sapi/apache2handler/apache_config.lo


sapi/apache2handler/php_functions.lo sapi/fpm/fpm/fastcgi.lo
sapi/fpm/fpm/fpm.lo 

sapi/fpm/fpm/fpm_children.lo sapi/fpm/fpm/fpm_cleanup.lo 

sapi/fpm/fpm/fpm_clock.lo sapi/fpm/fpm/fpm_conf.lo
sapi/fpm/fpm/fpm_env.lo 

sapi/fpm/fpm/fpm_events.lo sapi/fpm/fpm/fpm_main.lo
sapi/fpm/fpm/fpm_php.lo 

sapi/fpm/fpm/fpm_php_trace.lo sapi/fpm/fpm/fpm_process_ctl.lo 

sapi/fpm/fpm/fpm_request.lo sapi/fpm/fpm/fpm_shm.lo 

sapi/fpm/fpm/fpm_shm_slots.lo sapi/fpm/fpm/fpm_signals.lo 

sapi/fpm/fpm/fpm_sockets.lo sapi/fpm/fpm/fpm_status.lo
sapi/fpm/fpm/fpm_stdio.lo 

sapi/fpm/fpm/fpm_unix.lo sapi/fpm/fpm/fpm_worker_pool.lo
sapi/fpm/fpm/zlog.lo 

sapi/fpm/fpm/fpm_trace.lo sapi/fpm/fpm/fpm_trace_ptrace.lo 

main/internal_functions.lo



FPM is linked with apache but the apr lib is not known at compile time.



There is the same problem when compiling libphp5.so which is linked
agains FPM 

object files and libevent is not known at compile time:



# make libs/libphp5.bundle



sapi/fpm/fpm/fpm_children.o: In function `fpm_children_make':

/LIBRE/dev/php-src/branches/PHP_5_3/sapi/fpm/fpm/fpm_children.c:381:
undefined 

reference to `event_reinit'


Previous Comments:

[2010-09-01 12:05:43] f...@php.net

I have a similar issue with the current PHP_5_3.



When the php-fpm is built, it's linked against :



sapi/apache2handler/mod_php5.lo

sapi/apache2handler/sapi_apache2.lo

sapi/apache2handler/apache_config.lo

sapi/apache2handler/php_functions.lo



I think it's somehow related to http://bugs.php.net/52498.


[2010-08-04 10:35:24] ali at aliziad dot clom

fyi:



I am also getting the same error with php 5.3.3 (/w apxs and fpm) on
CentOS



-ali


[2010-07-23 20:44:23] ras...@php.net

You could try it in a clean Debian image using the free vmware player
and the 

images from http://www.thoughtpolice.co.uk/vmware/

Just so you have a clean environment to compare yours against.


[2010-07-23 20:39:38] php-bugs at majkl578 dot cz

No, I don't, I've only this one. Maybe it's really (somehow) related to
my environment, because I'm also unable to compile PHP with pecl binary
even if '--with-pear' and '--enable-cli' are set...


[2010-07-23 19:38:21] ras...@php.net

Do you have access to another Debian box somewhere?  Or perhaps a clean
VM?  A lot 

of the PHP developers are on Debian, myself included, so it would really
surprise 

me if there was a general compile issue there.  And since I can't
reproduce it 

with your exact configure line, there is something about your
environment that is 

different.




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/bug.php?id=52419


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

Bug #52756 [Com]: bounding box coordinates are wrong

2010-09-01 Thread rasmus at mindplay dot dk

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

 ID: 52756
 Comment by: rasmus at mindplay dot dk
 Reported by:rasmus at mindplay dot dk
 Summary:bounding box coordinates are wrong
 Status: Feedback
 Type:   Bug
 Package:GD related
 Operating System:   Linux delphinus 2.6.32.8
 PHP Version:5.2.14
 Block user comment: N

 New Comment:

No luck with PHP 5.3.3 from the XAMPP distribution on Windows.


Previous Comments:

[2010-09-01 11:12:08] paj...@php.net

Please try with 5.3.3


[2010-09-01 04:12:49] rasmus at mindplay dot dk

Description:

The metrics returned by this function are inaccurate - I put together a
comprehensive test script that demonstrates the problem:



http://fontjazz.com/metrics/test.php



This is also reproducible on my workstation with PHP 5.3.1 on Windows
Vista SP1 (build 6001).



This bug has been present in Windows builds of PHP 5 for at least a
year, and was introduced in Linux builds more recently - my font
embedding system (fontjazz.com) is currently generating broken fonts due
to this bug.



I've reported this bug before, and if I recall, others reported it
before I did - relating this problem to notes/revisions from previous
attempts to address this problem might be useful, but I can't seem to
find the old bug in the database anymore.



I don't recall if this bug was blamed on PHP, GD or FreeType - I think
there were different theories at the time, but it looks like there was
no resolution.

Test script:
---
The source code for the test script is displayed on this page:



http://fontjazz.com/metrics/test.php



You will need a font for testing - I recommend "georgiai.ttf", the
OpenType version, which can be found on Windows Vista installations
under WINDOWS\Fonts.



If you don't have this font, try another OpenType font in italics - this
problem seems to affect italic fonts the worst, probably because italic
typefaces generally have more glyph overlap.



With some non-italic fonts, unless rendered at really large sizes, the
problem may not be obvious enough to spot with the eye, but there is
always some degree of inaccuracy, with any font, when rendered at a
sufficiently large size.



Expected result:

The red outline should accurately surround the rendered text.

Actual result:
--
The red outline is somewhat offset.






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

Req #49510 [Com]: boolean validation fails with FILTER_NULL_ON_FAILURE

2010-09-01 Thread schkovich at gmail dot com

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

 ID: 49510
 Comment by: schkovich at gmail dot com
 Reported by:m dot kurzyna at crystalpoint dot pl
 Summary:boolean validation fails with FILTER_NULL_ON_FAILURE
 Status: Assigned
 Type:   Feature/Change Request
 Package:Feature/Change Request
 Operating System:   Linux
 PHP Version:5.3.0
 Assigned To:pajoye
 Block user comment: N

 New Comment:

filter_var(false,FILTER_VALIDATE_BOOLEAN,FILTER_NULL_ON_FAILURE)

 // got NULL, expected false



That does not make sense at all! Further on, I have to agree with
m.kurzyna that since false === (bool)""
filter_var("",FILTER_VALIDATE_BOOLEAN,FILTER_NULL_ON_FAILURE) should 

return FALSE and not NULL.



Basically, as implemented, getting FALSE from
filter_var(false,FILTER_VALIDATE_BOOLEAN) means that validation failed.
It appears to be a design problem since filter_var() as 

specified will return FALSE if the filter fails making it impossible to
distinguish if filter failed  or valid FALSE value is returned.
Therefore, instead returning FALSE if 

filter fails perhaps warning could be issued or even better exception
thrown.



On addition when voting I've wrongly selected that I am not using the
same version and the same operating system. Correct ones are:

PHP Version => 5.3.2-1ubuntu4.2

System => Linux schkovich 2.6.32-24-generic #42-Ubuntu SMP Fri Aug 20
14:21:58 UTC 2010 x86_64


Previous Comments:

[2009-09-10 11:24:37] m dot kurzyna at crystalpoint dot pl

As much as i'd like to have empty string be invalid false cast i have to
disagree with you for consistency reasons.



If (boolean)'' == false then filter_var('','boolean') should also return
false. Both in general and in case of FILTER_NULL_ON_FAILURE (just like
the documentation states).



Also, because i can't stress it enough, this is a VALIDATOR not a
SANITIZER so using it as a strict caster is secondary to it's validation
purpose and as such it currently fails both on implied and explicit
behavior.



The ideal solution would be to have FILTER_VALIDATE_BOOLEAN roughly
equal to current behavior with FILTER_NULL_ON_FAILURE and a *seperate*
FILTER_SANITIZE_BOOLEAN similar to current behavior w/o the null failure
flag. This however probably is impossible due to BC.


[2009-09-10 11:09:43] sjo...@php.net

I agree that filter_var() should return null for the empty string. I
think that this usage of filter_var() is meant to convert string
representations of booleans to boolean values. That is, "true", "on",
"1", "false", "off" and "0" should be converted, other strings should
return null.


[2009-09-10 09:05:53] m dot kurzyna at crystalpoint dot pl

Personally i think it's just fine (empty string ain't false - if
anything it's null) but in PHP world it is (both on PHP and C levels):



(string)false = ''

(boolean)'' == false



Z_STRLEN_P(value) = 0





Oh, and there is this little documentation thingy you like to cite from
time to time:



If FILTER_NULL_ON_FAILURE is set, FALSE is returned only for "0",
"false", "off", "no", and "", and NULL is returned for all non-boolean
values.



where empty string is explicitly stated as being false.


[2009-09-10 08:57:29] sjo...@php.net

Why do you think it is wrong that it returns null for an empty string?


[2009-09-10 08:53:11] m dot kurzyna at crystalpoint dot pl

Actually it is broken even more then i initially reported because it
also returns NULL for empty string:



filter_var('',FILTER_VALIDATE_BOOLEAN,array('flags'=>FILTER_NULL_ON_FAILURE))
  // got NULL, expected false





The problem is in ext/filter/logical_filters.c(233) - the check is done
by using string representation of zval being checked. For false value
it's an empty string and the switch from line 244 doesn't cover this
case (hence same result for false and empty string).



Something along the lines of following patch should fix the problem: 



--- logical_filters.c   2009-06-10 21:01:17.0 +0200

+++ logical_filters.fixed.c 2009-09-10 10:48:59.953675880 +0200

@@ -242,6 +242,10 @@

 * returns false for "0", "false", "off", "no", and ""

 * null otherwise. */

switch (len) {

+   case 0:

+   ret = 0;

+   break;

+

case 1:

if (*str == '1') {

ret = 1;











On the side note: i was always wondering why (string)false == '' and not
'0'?

--

Bug #52754 [Bgs]: Array keys in $_SESSION with "!" unsets the whole array in PHP 5.3.3

2010-09-01 Thread dotpointer at gmail dot com

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

 ID: 52754
 User updated by:dotpointer at gmail dot com
 Reported by:dotpointer at gmail dot com
 Summary:Array keys in $_SESSION with "!" unsets the whole
 array in PHP 5.3.3
 Status: Bogus
 Type:   Bug
 Package:Session related
 Operating System:   Slackware Linux 12
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

That's fine for me. I did not know that, so I used the site name as key,
which worked fine until I updated PHP, then suddenly this happened.


Previous Comments:

[2010-09-01 06:25:51] ahar...@php.net

I'm not too sure how or why this would have worked in 5.2, but session
variables not being able to use certain characters in their names is
documented behaviour, per http://php.net/session.examples.basic ââ:



"The keys in the $_SESSION associative array are subject to the same
limitations as regular variable names in PHP, i.e. they cannot start
with a number and must start with a letter or underscore. For more
details see the section on variables in this manual."


[2010-08-31 21:47:10] dotpointer at gmail dot com

Description:

Array keys in $_SESSION containing exclamation marks (!) does not seem
to work anymore as of 5.3.3.



Have tried key with different characters like #, " and Â£ - these
worked. Using "!" in the key seems not only to be unregistered but also
to make the whole $_SESSION to be unset in the next run.



This worked before, as in 5.2.x.

Test script:
---


Expected result:

That array keys containing exclamation marks ("!") either give a
understandable error or does work as any other key.

Actual result:
--
The whole array is being totally empty if a key containing exclamation
mark is entered.






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

Req #16620 [Opn->Csd]: Ingres_II: Don't get two connects in one script

2010-09-01 Thread grantc

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

 ID: 16620
 Updated by: gra...@php.net
 Reported by:joerg dot schoppet at web dot de
 Summary:Ingres_II: Don't get two connects in one script
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
 Operating System:   Win NT4/Win 2k
 PHP Version:4.2.1
 Assigned To:grantc
 Block user comment: N

 New Comment:

Mutiple connects are availible in the PECL ingres driver, see 

http://pecl.php.net/ingres for links on how to download and the current


documentation.


Previous Comments:

[2002-06-05 05:01:40] joerg dot schoppet at web dot de

Hi,



ok, good explanation, but why did this work in php 4.0.8dev?



Joerg


[2002-06-05 04:12:39] mfisc...@php.net

ext/ingriss_ii suffers from the same problem a few other db extension
suffer: hey're internally hashing the credients for db accessing and
re-use this hashes for every connection and therefore not allowing two
connection to the same db.



Reclassifying as feature request, it should be an easy fix (as it was
for ext/mysql)



Sidenote: it would be nice if we can get all db extensions to behave
this way (afaik pgsql has the same problem, though I didn't checked this
lately if it's still true).



Actually I can't tell why the dll is not in 4.2.1, Edink, do you know?


[2002-06-05 03:43:47] joerg dot schoppet at web dot de

Hi,



I want to try the ingres features in 4.2.1 like derick said. But now I
see that the php_ingres.dll was removed from this version and I have
nothing found in the changelog.



What's going on? Have php not anymore ingres-functions?



Joerg Schoppet


[2002-05-25 09:00:47] der...@php.net

Thank you for taking the time to report a problem with PHP.
Unfortunately your version of PHP is too old -- the problem
might already be fixed. Please download a new PHP
version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.




[2002-04-15 09:57:09] joerg dot schoppet at web dot de

Hi,



I've tried to connect to two ingres dbs (ingres II 2.0) in one script
(to make some compares).



One connect is no problem and everything works fine, but when the script
wants to connect to the second db, I get a Error-Message from DrWatson
(nothing else).



This all works fine with php 4.0.8dev, but in php 4.1.0 and now also in
php 4.1.2 I get these error messages.



Hope this could help



Joerg schoppet





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

Bug #51766 [Asn->Csd]: SplFileInfo::isLink() Fails for Symlinks on windows

2010-09-01 Thread pajoye

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

 ID: 51766
 Updated by: paj...@php.net
 Reported by:v-sumada at microsoft dot com
 Summary:SplFileInfo::isLink()  Fails for Symlinks on windows
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:SPL related
 Operating System:   All Windows OS
 PHP Version:5.3.2
 Assigned To:pajoye
 Block user comment: N

 New Comment:

Patch applied to PHP_5_3 and trunk, fixing is_link and SPL's related
methods.


Previous Comments:

[2010-08-31 10:53:01] paj...@php.net

The following patch has been added/updated:

Patch Name: add_lstat_support
Revision:   1283244780
URL:   
http://bugs.php.net/patch-display.php?bug=51766&patch=add_lstat_support&revision=1283244780


[2010-08-30 19:48:33] paj...@php.net

The following patch has been added/updated:

Patch Name: lstat-support-1
Revision:   1283190512
URL:   
http://bugs.php.net/patch-display.php?bug=51766&patch=lstat-support-1&revision=1283190512


[2010-08-30 19:46:44] paj...@php.net

This patch http://pastie.org/1127049 fixes this issue (along other).


[2010-08-07 01:56:33] johan...@php.net

Pierre, I think you played with symlinks on Windows before, can you add
the magic needed, here?


[2010-05-07 19:08:08] v-sumada at microsoft dot com

Description:

SplFileInfo::isLink()  Which returns False for Symbolic links on all 
windows OS. we have a  File Symbolic link created  for a file and tried
to test whether the referenced file  by SplFileInfo is symbolic link or
not.





In the above script we have a symlink(filesymlink)created for a file
'testfile'  and tried to check with the file_exists function for
symlink(filesymlink) which returns true and it returns false for the
SplFileInfo::isLink().





Test script:
---
isLink());

?>

Expected result:

bool(true)

bool(true)

Actual result:
--
bool(true)

bool(false)






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

Bug #49215 [Fbk->Opn]: make fails on glob_wrapper

2010-09-01 Thread aharvey

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

 ID: 49215
 Updated by: ahar...@php.net
 Reported by:jim dot stcyr at gmail dot com
 Summary:make fails on glob_wrapper
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   RedHat 2.6.9-89.0.3.ELsmp
 PHP Version:5.3SVN-2009-08-11 (snap)
 Block user comment: N



Previous Comments:

[2010-09-01 11:50:48] damien dot gerard at sgcib dot com

Still got the same problem with last snapshot:



php5.3-201009010830/main/streams/glob_wrapper.c:40: error: expected
specifier-qualifier-list before 'glob_t'



Red Hat Enterprise Linux Server release 5.4 (Tikanga)

gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)


[2010-05-09 23:20:42] fel...@php.net

Please try using this snapshot:

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

  http://windows.php.net/snapshots/




[2009-11-19 01:58:22] lcmattoso at hotmail dot com

Try just 

rm -f config.cache

and your old ./configure params

works for me


[2009-08-20 01:00:00] 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".


[2009-08-12 09:03:33] j...@php.net

Can you try the PHP_5_2 snapshot also:



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



And are you absolutely sure nothing has changed in your system..?

I suggest trying to recompile the last PHP version you were able to
build before..








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/bug.php?id=49215


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

Bug #52419 [Com]: Unable to compile PHP with both Apache2 and FPM support

2010-09-01 Thread f...@php.net

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

 ID: 52419
 Comment by: f...@php.net
 Reported by:php-bugs at majkl578 dot cz
 Summary:Unable to compile PHP with both Apache2 and FPM
 support
 Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   Linux Debian
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

I have a similar issue with the current PHP_5_3.



When the php-fpm is built, it's linked against :



sapi/apache2handler/mod_php5.lo

sapi/apache2handler/sapi_apache2.lo

sapi/apache2handler/apache_config.lo

sapi/apache2handler/php_functions.lo



I think it's somehow related to http://bugs.php.net/52498.


Previous Comments:

[2010-08-04 10:35:24] ali at aliziad dot clom

fyi:



I am also getting the same error with php 5.3.3 (/w apxs and fpm) on
CentOS



-ali


[2010-07-23 20:44:23] ras...@php.net

You could try it in a clean Debian image using the free vmware player
and the 

images from http://www.thoughtpolice.co.uk/vmware/

Just so you have a clean environment to compare yours against.


[2010-07-23 20:39:38] php-bugs at majkl578 dot cz

No, I don't, I've only this one. Maybe it's really (somehow) related to
my environment, because I'm also unable to compile PHP with pecl binary
even if '--with-pear' and '--enable-cli' are set...


[2010-07-23 19:38:21] ras...@php.net

Do you have access to another Debian box somewhere?  Or perhaps a clean
VM?  A lot 

of the PHP developers are on Debian, myself included, so it would really
surprise 

me if there was a general compile issue there.  And since I can't
reproduce it 

with your exact configure line, there is something about your
environment that is 

different.


[2010-07-23 19:35:26] php-bugs at majkl578 dot cz

I've reinstalled libapr and libapr-dev, make clean'ed, then reconfigured
and re-run compilation. Exactly same error.

Compiling them separately works fine.



Versions:

apache2: 2.2.15-6

libapr and libapr-dev: 1.4.2-3




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/bug.php?id=52419


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

Bug #49215 [Com]: make fails on glob_wrapper

2010-09-01 Thread damien dot gerard at sgcib dot com

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

 ID: 49215
 Comment by: damien dot gerard at sgcib dot com
 Reported by:jim dot stcyr at gmail dot com
 Summary:make fails on glob_wrapper
 Status: Feedback
 Type:   Bug
 Package:Compile Failure
 Operating System:   RedHat 2.6.9-89.0.3.ELsmp
 PHP Version:5.3SVN-2009-08-11 (snap)
 Block user comment: N

 New Comment:

Still got the same problem with last snapshot:



php5.3-201009010830/main/streams/glob_wrapper.c:40: error: expected
specifier-qualifier-list before 'glob_t'



Red Hat Enterprise Linux Server release 5.4 (Tikanga)

gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)


Previous Comments:

[2010-05-09 23:20:42] fel...@php.net

Please try using this snapshot:

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

  http://windows.php.net/snapshots/




[2009-11-19 01:58:22] lcmattoso at hotmail dot com

Try just 

rm -f config.cache

and your old ./configure params

works for me


[2009-08-20 01:00:00] 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".


[2009-08-12 09:03:33] j...@php.net

Can you try the PHP_5_2 snapshot also:



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



And are you absolutely sure nothing has changed in your system..?

I suggest trying to recompile the last PHP version you were able to
build before..






[2009-08-11 20:29:59] jim dot stcyr at gmail dot com

What's really irritating about this issue is that PHP has been
successfully built on this machine in the past; as recently as last
month.  



[auto...@les1 ~]$ gcc -v

Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs

Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk
--host=i386-redhat-linux

Thread model: posix

gcc version 3.4.6 20060404 (Red Hat 3.4.6-11)




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/bug.php?id=49215


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

Req #52759 [Com]: mysqlnd do not support named pipe on windows

2010-09-01 Thread songchongzhan at gmail dot com

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

 ID: 52759
 Comment by: songchongzhan at gmail dot com
 Reported by:songchongzhan at gmail dot com
 Summary:mysqlnd do not support named pipe on windows
 Status: Duplicate
 Type:   Feature/Change Request
 Package:MySQLi related
 Operating System:   Windows
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

Thanks,aharvey!

I tried to compile it on windows using option --without-mysqlnd, it
works by 

using mysql lib 50051, but not stable, in some case it can't get assoc
result 

correctly.

When I using mysql 5.5.3 lib, it has error: 

Creating library Release_TS\php5ts.lib and object Release_TS\php5ts.exp

mysqli.obj : error LNK2001: unresolved external symbol _client_errors

Release_TS\php5ts.dll : fatal error LNK1120: 1 unresolved externals

NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
9.0\VC\BIN

\cl.exe"' : return code '0x2'

Stop.



I don't know it is mysql lib or php problem.


Previous Comments:

[2010-09-01 10:06:21] ahar...@php.net

This is request #48082, which is being worked on.


[2010-09-01 10:00:40] songchongzhan at gmail dot com

Description:

MySQLi using persistent connect, when there are a lot of connection come
at the 

same time, the persistent connection will arise, like 1000 persistent
connections, 

but after some time, the number of connection will not reduce
automatically when 

there is not more request. 

And then I want to connect to mysql using named pipe on 

windows, the php5.3.3 does not support. 

I think php should enable named pipe 

connection to mysql on windows.







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

Bug #52756 [Opn->Fbk]: bounding box coordinates are wrong

2010-09-01 Thread pajoye

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

 ID: 52756
 Updated by: paj...@php.net
 Reported by:rasmus at mindplay dot dk
 Summary:bounding box coordinates are wrong
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:GD related
 Operating System:   Linux delphinus 2.6.32.8
 PHP Version:5.2.14
 Block user comment: N

 New Comment:

Please try with 5.3.3


Previous Comments:

[2010-09-01 04:12:49] rasmus at mindplay dot dk

Description:

The metrics returned by this function are inaccurate - I put together a
comprehensive test script that demonstrates the problem:



http://fontjazz.com/metrics/test.php



This is also reproducible on my workstation with PHP 5.3.1 on Windows
Vista SP1 (build 6001).



This bug has been present in Windows builds of PHP 5 for at least a
year, and was introduced in Linux builds more recently - my font
embedding system (fontjazz.com) is currently generating broken fonts due
to this bug.



I've reported this bug before, and if I recall, others reported it
before I did - relating this problem to notes/revisions from previous
attempts to address this problem might be useful, but I can't seem to
find the old bug in the database anymore.



I don't recall if this bug was blamed on PHP, GD or FreeType - I think
there were different theories at the time, but it looks like there was
no resolution.

Test script:
---
The source code for the test script is displayed on this page:



http://fontjazz.com/metrics/test.php



You will need a font for testing - I recommend "georgiai.ttf", the
OpenType version, which can be found on Windows Vista installations
under WINDOWS\Fonts.



If you don't have this font, try another OpenType font in italics - this
problem seems to affect italic fonts the worst, probably because italic
typefaces generally have more glyph overlap.



With some non-italic fonts, unless rendered at really large sizes, the
problem may not be obvious enough to spot with the eye, but there is
always some degree of inaccuracy, with any font, when rendered at a
sufficiently large size.



Expected result:

The red outline should accurately surround the rendered text.

Actual result:
--
The red outline is somewhat offset.






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

Bug #52725 [Ana->Csd]: gcc builtin atomic functions are sometimes used when they are not available

2010-09-01 Thread fat

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

 ID: 52725
 Updated by: f...@php.net
 Reported by:fedora at famillecollet dot com
 Summary:gcc builtin atomic functions are sometimes used when
 they are not available
-Status: Analyzed
+Status: Closed
 Type:   Bug
 Package:FPM related
 Operating System:   GNU/Linux (RHEL 5.5)
 PHP Version:5.3SVN-2010-08-28 (snap)
 Assigned To:fat
 Block user comment: N

 New Comment:

This bug has been fixed in SVN.

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.




Previous Comments:

[2010-09-01 10:17:20] f...@php.net

Automatic comment from SVN on behalf of fat
Revision: http://svn.php.net/viewvc/?view=revision&revision=302965
Log: - Fixed bug #52725 (gcc builtin atomic functions were sometimes
used when they were not available).


[2010-08-30 18:19:34] fedora at famillecollet dot com

Try build of latest snapshot (201008301430) with your patch



Fedora 13 x86_64 - gcc 4.4.4 : BUILD OK



$ grep HAVE_BUILTIN_ATOMIC build-fpm/main/php_config.h 

#define HAVE_BUILTIN_ATOMIC 1



Enterprise Linux 5 i386 - gcc 4.1.2 : BUILD OK



$ grep HAVE_BUILTIN_ATOMIC build-fpm/main/php_config.h

/* #undef HAVE_BUILTIN_ATOMIC */





So, the patch seems fine to me.

Thanks for taking care of this.


[2010-08-30 15:47:11] f...@php.net

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.


Can you please try the following patch ?



Don't forget to run ./buildconf before executing ./configure
--enable-fpm && make.



Thanks


[2010-08-30 15:45:55] f...@php.net

The following patch has been added/updated:

Patch Name: fpm_builtin_atomic.patch
Revision:   1283175955
URL:   
http://bugs.php.net/patch-display.php?bug=52725&patch=fpm_builtin_atomic.patch&revision=1283175955


[2010-08-28 22:37:23] fedora at famillecollet dot com

Description:

Build fails on RHEL/Centos 5 (gcc-4.1.2)



sapi/fpm/fpm/fpm_shm_slots.o: In function `fpm_spinlock':

/builddir/build/BUILD/php5.3-201008281230/sapi/fpm/fpm/fpm_atomic.h:148:
undefined reference to `__sync_bool_compare_and_swap_4'

/builddir/build/BUILD/php5.3-201008281230/sapi/fpm/fpm/fpm_atomic.h:143:
undefined reference to `__sync_bool_compare_and_swap_4'



This seems linked to commit 302600

http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/sapi/fpm/fpm/fpm_atomic.h?r1=299794&r2=302600



Changing the test fixes the issue  

#if (__GNUC__) && (__GNUC__ >= 4 &&  __GNUC_MINOR__ >= 2)



I don't know which is the correct value.



Build ok on fedora 12 (gcc-4.4.4) and fedora 13 (gcc-4.4.4)









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

Bug #52725 [Asn->Ana]: gcc builtin atomic functions are sometimes used when they are not available

2010-09-01 Thread fat

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

 ID: 52725
 Updated by: f...@php.net
 Reported by:fedora at famillecollet dot com
-Summary:undefined reference to
 `__sync_bool_compare_and_swap_4'
+Summary:gcc builtin atomic functions are sometimes used when
 they are not available
-Status: Assigned
+Status: Analyzed
 Type:   Bug
 Package:FPM related
 Operating System:   GNU/Linux (RHEL 5.5)
 PHP Version:5.3SVN-2010-08-28 (snap)
 Assigned To:fat
 Block user comment: N



Previous Comments:

[2010-08-30 18:19:34] fedora at famillecollet dot com

Try build of latest snapshot (201008301430) with your patch



Fedora 13 x86_64 - gcc 4.4.4 : BUILD OK



$ grep HAVE_BUILTIN_ATOMIC build-fpm/main/php_config.h 

#define HAVE_BUILTIN_ATOMIC 1



Enterprise Linux 5 i386 - gcc 4.1.2 : BUILD OK



$ grep HAVE_BUILTIN_ATOMIC build-fpm/main/php_config.h

/* #undef HAVE_BUILTIN_ATOMIC */





So, the patch seems fine to me.

Thanks for taking care of this.


[2010-08-30 15:47:11] f...@php.net

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.


Can you please try the following patch ?



Don't forget to run ./buildconf before executing ./configure
--enable-fpm && make.



Thanks


[2010-08-30 15:45:55] f...@php.net

The following patch has been added/updated:

Patch Name: fpm_builtin_atomic.patch
Revision:   1283175955
URL:   
http://bugs.php.net/patch-display.php?bug=52725&patch=fpm_builtin_atomic.patch&revision=1283175955


[2010-08-28 22:37:23] fedora at famillecollet dot com

Description:

Build fails on RHEL/Centos 5 (gcc-4.1.2)



sapi/fpm/fpm/fpm_shm_slots.o: In function `fpm_spinlock':

/builddir/build/BUILD/php5.3-201008281230/sapi/fpm/fpm/fpm_atomic.h:148:
undefined reference to `__sync_bool_compare_and_swap_4'

/builddir/build/BUILD/php5.3-201008281230/sapi/fpm/fpm/fpm_atomic.h:143:
undefined reference to `__sync_bool_compare_and_swap_4'



This seems linked to commit 302600

http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/sapi/fpm/fpm/fpm_atomic.h?r1=299794&r2=302600



Changing the test fixes the issue  

#if (__GNUC__) && (__GNUC__ >= 4 &&  __GNUC_MINOR__ >= 2)



I don't know which is the correct value.



Build ok on fedora 12 (gcc-4.4.4) and fedora 13 (gcc-4.4.4)









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

Req #52759 [Opn->Dup]: mysqlnd do not support named pipe on windows

2010-09-01 Thread aharvey

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

 ID: 52759
 Updated by: ahar...@php.net
 Reported by:songchongzhan at gmail dot com
 Summary:mysqlnd do not support named pipe on windows
-Status: Open
+Status: Duplicate
 Type:   Feature/Change Request
 Package:MySQLi related
 Operating System:   Windows
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

This is request #48082, which is being worked on.


Previous Comments:

[2010-09-01 10:00:40] songchongzhan at gmail dot com

Description:

MySQLi using persistent connect, when there are a lot of connection come
at the 

same time, the persistent connection will arise, like 1000 persistent
connections, 

but after some time, the number of connection will not reduce
automatically when 

there is not more request. 

And then I want to connect to mysql using named pipe on 

windows, the php5.3.3 does not support. 

I think php should enable named pipe 

connection to mysql on windows.







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

[PHP-BUG] Req #52759 [NEW]: mysqlnd do not support named pipe on windows

2010-09-01 Thread songchongzhan at gmail dot com

From: 
Operating system: Windows
PHP version:  5.3.3
Package:  MySQLi related
Bug Type: Feature/Change Request
Bug description:mysqlnd do not support named pipe on windows

Description:

MySQLi using persistent connect, when there are a lot of connection come at
the 

same time, the persistent connection will arise, like 1000 persistent
connections, 

but after some time, the number of connection will not reduce automatically
when 

there is not more request. 

And then I want to connect to mysql using named pipe on 

windows, the php5.3.3 does not support. 

I think php should enable named pipe 

connection to mysql on windows.


-- 
Edit bug report at http://bugs.php.net/bug.php?id=52759&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52759&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52759&r=trysnapshot53
Try a snapshot (trunk):  
http://bugs.php.net/fix.php?id=52759&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52759&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=52759&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52759&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=52759&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=52759&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=52759&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=52759&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=52759&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=52759&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=52759&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52759&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=52759&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52759&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=52759&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=52759&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=52759&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=52759&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=52759&r=mysqlcfg

47 matches

Mail list logo