date:20100301

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

 ID:   48865
 Comment by:   
 Reported by:  ali dot barimani at bnpparibas dot com
 Summary:  Compile does not create .so library
 Status:   No Feedback
 Type: Bug
 Package:  Compile Failure
 Operating System: AIX 6.1
 PHP Version:  5.3.0

 New Comment:

I was able to build PHP 5.3 by using GNU make instead of AIX make. I
used

make-3.80-1.aix5.1.ppc.rpm

from the AIX Toolbox site. 



Note that others have reported problems using gmake building other php
components.


Previous Comments:

[2009-07-18 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-07-10 18:20:32] j...@php.net

Please see bug #39197 and #39187 and search using 'AIX' in the OS field.


If you can provide a proper patch, we'll gladly accept it, otherwise 

this will get into bogus as well..


[2009-07-09 10:21:04] ali dot barimani at bnpparibas dot com

With changing the configure option to --disable-phar the build is
complete with CLI. But, there is no more libpphp5.so built for Apache
SAPI


[2009-07-09 09:23:43] ali dot barimani at bnpparibas dot com

Description:

I try to configure and compile PHP 5.3 on AIX 6.1.



When I active the CLI mode (and I need it), the confgure run correctly 

but the build failed (see Reproduce code please).





And with CLI the build crash (see bellow).



/bin/sh /bnp/khome/abarim30/src/php-5.3.0/libtool
--preserve-dup-deps --mode=compile gcc  -Imain/
-I/bnp/khome/abarim30/src/php-5.3.0/main/ -DPHP_ATOM_INC
-I/bnp/khome/abarim30/src/php-5.3.0/include
-I/bnp/khome/abarim30/src/php-5.3.0/main
-I/bnp/khome/abarim30/src/php-5.3.0
-I/bnp/khome/abarim30/src/php-5.3.0/ext/date/lib
-I/bnp/khome/abarim30/src/php-5.3.0/ext/ereg/regex
-I/usr/local/include/libxml2 -I/opt/freeware/include
-I/opt/freeware/include/freetype2 -I/usr/local/pkg/gd.2.0.33/include
-I/apps/env30/sybase/current/OCS-15_0/include
-I/opt/freeware/include/libxml2 -I/bnp/khome/abarim30/src/php-5.3.0/TSRM
-I/bnp/khome/abarim30/src/php-5.3.0/Zend  -fPIC -I/usr/local/include 
-I/usr/include -g -fvisibility=hidden -O0 -Wall   -c
main/internal_functions_cli.c -o main/internal_functions_cli.lo 

 gcc -Imain/ -I/bnp/khome/abarim30/src/php-5.3.0/main/ -DPHP_ATOM_INC
-I/bnp/khome/abarim30/src/php-5.3.0/include
-I/bnp/khome/abarim30/src/php-5.3.0/main
-I/bnp/khome/abarim30/src/php-5.3.0
-I/bnp/khome/abarim30/src/php-5.3.0/ext/date/lib
-I/bnp/khome/abarim30/src/php-5.3.0/ext/ereg/regex
-I/usr/local/include/libxml2 -I/opt/freeware/include
-I/opt/freeware/include/freetype2 -I/usr/local/pkg/gd.2.0.33/include
-I/apps/env30/sybase/current/OCS-15_0/include
-I/opt/freeware/include/libxml2 -I/bnp/khome/abarim30/src/php-5.3.0/TSRM
-I/bnp/khome/abarim30/src/php-5.3.0/Zend -fPIC -I/usr/local/include
-I/usr/include -g -fvisibility=hidden -O0 -Wall -c
main/internal_functions_cli.c -o main/internal_functions_cli.o

echo '\

\

Generating phar.php

/bin/sh[14]: -d:  not found

make: The error code from the last command is 127.





Reproduce code:
---
When disable-cli => But the .so is not created !



Build complete.

Don't forget to run 'make test'.



srkondorv abarim30 /bnp/khome/abarim30/src/php-5.3.0/.libs > ls -la

total 95104

drwxrwxrwx2 abarim30 kondor30256 Jul  9 11:02 .

drwxr-xr-x   17 abarim30 kondor30   4096 Jul  9 11:02 ..

-rw-rw-rw-1 abarim30 kondor30   48682884 Jul  9 11:02 libphp5.a

lrwxrwxrwx1 abarim30 kondor30 13 Jul  9 11:02 libphp5.la ->
../libphp5.la

-rw-rw-rw-1 abarim30 kondor30   2051 Jul  9 11:02 libphp5.lai



Expected result:

./configure  --without-mysql \

 --without-sqlite \

 --without-pdo-sqlite \

 --with-sybase-ct=/apps/env30/sybase/current/OCS-15_0 \

 --with-apxs=/apps/local/apache/bin/apxs \

 --with-xmlrpc \

 --enable-debug=yes \

 --enable-sysvmsg \

 --enable-sockets \

 --enable-soap \

 --enable-bcmath \

 --with-gd=/usr/local/pkg/gd.2.0.33 \

 --with-libxml-dir=/opt/freeware \

 --with-freetype-dir=/opt/freeware \

 --with-xsl=/opt/freeware \

 --with-zlib-dir=/opt/freeware \

 --with-xpm-dir=/opt/freeware \

 --with-jpeg-dir=/opt/freeware \

 --with-png-dir=/opt/freeware \

 --

[PHP-BUG] Bug #8944 [Com]: php.exe crashes for no apparent reason...

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

 ID:   8944
 Comment by:   
 Reported by:  leo at finalresort dot org
 Summary:  php.exe crashes for no apparent reason...
 Status:   Closed
 Type: Bug
 Package:  Reproducible Crash
 Operating System: NT 4.0, sp5
 PHP Version:  4.0.3pl1

 New Comment:

Excuse me. Love yourself first and everything else falls into line. You
really have to love yourself to get anything done in this world. Help
me! There is an urgent need for sites: gambling. I found only this - http://www.physikclub.de/Members/OnlineCasinoSlot/s-games";>s
games. The shooter of our dancers is to find it many, that is to
make, to balance it, to play it and cause it various between two
patients, online casino slot. Online casino slot, it was designed with
two boss calls launched from germany and described quickly term. THX
:cool:, Bibiane from Slovakia.


Previous Comments:

[2001-03-16 16:55:59] sni...@php.net

No feedback.



--Jani




[2001-01-29 05:12:37] sni...@php.net

Does this happen with PHP 4.0.4pl1 ??



--Jani


[2001-01-27 08:47:09] leo at finalresort dot org

heh, seems like there was a syntax error in that code of mine, namely a
')' too much in the end of line 5 :)



i realised that when i messed around and changed the include() to
include_once() in the calling file (after noticing that the if-statement
was the stuff that made it all happen). after that, i got an
errormessage instead of a crash.



so, summary:



* if i have the errorous ')' at the end of line 5, and an include(
'file_with_code' ) in the file that includes the file with this code in,
php.exe crashes.



* if i remove the ')', it all works just fine, duh..



* if i change the include() to an include_once(), php gives me an
errormessage instead of crashing, as it should.



* php doesnt behave as expected under some circumstances, as described
above.



there.


[2001-01-26 18:38:32] leo at finalresort dot org

--the following was suppoed to be mailed but.. :)--



Hi!



I want to report a crash in php.exe that I experienced just now. I'm
sending this notification right away, without first trying to find the
cause of it in the crappy code i have here, since I believe that even if
the code is errorous, PHP should'nt crash. The system is NT Workstation
4.0, sp5, Apache 1.3.14 and PHP 4.0.3pl1.



The following code resides in a .php file that is include()´d in the
file that is called through the browser:







The crashing started right after adding this code and reloading the file
that includes the .php-file it resides in. I got an 500 ISE message in
the browser. The function trim_array() is never called, the crash
occours anyway.



The Apache errorlog says the following:



[Fri Jan 26 23:42:36 2001] [error] [client 192.168.0.222] Premature end
of script headers: c:/program/php/php.exe



Maybe that'll help, I dunno..



I'll send along a shot of the msgbox I got, and the PHP and Apache
conffiles, and a screenshot of VC++ 6.0´s debugger "in action" ;) --i
wanted to but i kinda cant here with this online bug reporting system.
mail me if you want the files...--



oh and, i cant make a gdb backtrace on this platform, can i ..?



 // Yours Faithfully, Leo



/ Leo R. Lundgren

/ +46 70 26 75 619

/ l...@finalresort.org



---START COPY OF php.ini---



[PHP]



;;;

; About this file ;

;;;

; This file controls many aspects of PHP's behavior.  In order for PHP
to

; read it, it must be named 'php.ini'.  PHP looks for it in the current

; working directory, in the path designated by the environment variable

; PHPRC, and in the path that was defined in compile time (in that
order).

; Under Windows, the compile-time path is the Windows directory.  The

; path in which the php.ini file is looked for can be overriden using

; the -c argument in command line mode.

;

; The syntax of the file is extremely simple.  Whitespace and Lines

; beginning with a semicolon are silently ignored (as you probably
guessed).

; Section headers (e.g. [Foo]) are also silently ignored, even though

; they might mean something in the future.

;

; Directives are specified using the following syntax:

; directive = value

; Directive names are *case sensitive* - foo=bar is different from
FOO=bar.

;

; The value can be a string, a number, a PHP constant (e.g. E_ALL or
M_PI), one

; of the INI constants (On, Off, True, False, Yes, No and None) or an
expression

; (e.g. E_ALL & ~E_NOTICE), or a quoted string ("foo").

;

; Expressions in the INI file are limited to bitwise operators and
parentheses:

; |

[PHP-BUG] Bug #48642 [Com]: Missing command in make file for "Generating phar.php"

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

 ID:   48642
 Comment by:   
 Reported by:  gareth dot randall at virgin dot net
 Summary:  Missing command in make file for "Generating phar.php"
 Status:   Bogus
 Type: Bug
 Package:  Compile Failure
 Operating System: AIX 6.1
 PHP Version:  5.3.0RC4
 Assigned To:  cellog

 New Comment:

Using GNU make solves this problem.

(I used make-3.80-1.aix5.1.ppc.rpm)


Previous Comments:

[2009-06-25 18:49:25] lsm...@php.net

closed until we get details. i guess since the issue will likely be 

something else, open a new bug.


[2009-06-23 18:46:08] gareth dot randall at virgin dot net

Just realised that I was trying to build it with AIX make, rather than
GNU make. I've tried again with GNU make, which fails elsewhere, so I'll
report the full details of that tomorrow.


[2009-06-23 11:24:36] paj...@php.net

Can you take a look please?


[2009-06-22 11:37:59] gareth dot randall at virgin dot net

Description:

The "Generating phar.php" section of make fails with the error:



/bin/sh[14]: -d:  not found.



Thoughts:

"Generating phar.php" only occurs once in Makefile.

The command run begins with:

  @$(PHP_PHARCMD_EXECUTABLE) $(PHP_PHARCMD_SETTINGS)  [other bits
removed]



Since PHP_PHARCMD_SETTINGS starts with "-d", it looks as if the
PHP_PHARCMD_EXECUTABLE is coming out empty.



Please advise me of any checks or fixes you would like me to try.



Reproduce code:
---
cd php-5.3.0RC4

./configure

make



Expected result:

make process completes without error.

Actual result:
--
(Previous make output omitted...)



Generating phar.php

/bin/sh[14]: -d:  not found.

make: 1254-004 The error code from the last command is 127.





Stop.








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

[PHP-BUG] Req #51150 [Opn]: spl_autoload_extensions() should accept arrays to avoid invalid separators

2010-03-01 Thread kalle

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

 ID:   51150
 Updated by:   ka...@php.net
 Reported by:  jo at feuersee dot de
 Summary:  spl_autoload_extensions() should accept arrays to
   avoid invalid separators
 Status:   Open
 Type: Feature/Change Request
 Package:  SPL related
 Operating System: *
 PHP Version:  5.3.1

 New Comment:

Using implode() would really be enough here, I'm not sure whether we
should add that option or not, but it is indeed not a bad idea.



As a workaround you may want to do:

spl_autoload_extensions(implode(',', $extensions));


Previous Comments:

[2010-03-01 21:16:40] j...@php.net

-Operating System: Any
+Operating System: *



[2010-03-01 20:05:58] paj...@php.net

-Package: Feature/Change Request
+Package: SPL related



[2010-02-25 20:22:49] jo at feuersee dot de

Description:

spl_autoload_extensions() accepts a string with a , separated list of

filename parts to register for autoloading.

This results in filenames containing a , as an extension filename

become impossible to register.

It should be possible to pass an array to circumvent any restriction

cased by the string based argument.



I know that ppl might consider it strange to use , as part of a

filename.



IMHO there may be cases where it might be necessary. Considering that

arrays are a native PHP data type, it would be a better design.

Reproduce code:
---
spl_autoload_extensions(array('.class.php', '.php'));

myclass::hello();

Expected result:

Hello world

Actual result:
--
Warning: spl_autoload_extensions() expects parameter 1 to be string,

array given in [test.php] on line ## 

Fatal error: Class 'myclass' not found in [test.php] on line ## 






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

[PHP-BUG] Bug #47928 [Com]: Crash in mysqli_stmt_fetch() with longtext column

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

 ID:   47928
 Comment by:   
 Reported by:  jjuergens at web dot de
 Summary:  Crash in mysqli_stmt_fetch() with longtext column
 Status:   Bogus
 Type: Bug
 Package:  MySQLi related
 Operating System: *
 PHP Version:  5.*, 6CVS (2009-04-19)
 Assigned To:  mysql

 New Comment:

I experienced this problem regardless of BLOB, LONGBLOB, TEXT, LONGTEXT
etc...



However to fix, I found that if I called mysqli_stmt_store_result after
executing the statement then the problem went away. The documentation
says it increases performance but at a cost of memory, but I would argue
that for BLOB's you should only be selecting them for a single row
anyway.


Previous Comments:

[2009-04-20 08:57:40] johan...@php.net

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

This is indeed an issue with the MySQL cLient library. It works properly
when using mysqlnd with 5.3 (--with-mysqli=mysqlnd) or when using
MySQL's Connector/C, which is a standalone version of libmysql
distributed witohut the server.



I didn't try using a current vcersion of libmysql bundled with the
server.


[2009-04-19 16:19:58] j...@php.net

In PHP_5_3 / HEAD the crash happens with any BLOB/TEXT types.

(due to mysqli_api.c:398)



This might be also a MySQL bug since it seems to set MYSQL_TYPE_BLOB 

always for any blob column.


[2009-04-19 15:14:49] j...@php.net

Here's better reproduce data (the longtext column has to have enough 

data to cause crash):



drop database crashtest; create database crashtest; use crashtest;

create table crash ( test longtext );

insert into crash set test='

12345678901234567890123456789012345678901234567890

12345678901234567890123456789012345678901234567890

12345678901234567890123456789012345678901234567890

12345678901234567890123456789012345678901234567890

12345678901234567890123456789012345678901234567890

12345678901234567890123456789012345678901234567890

12345678901234567890123456789012345678901234567890

12345678901234567890123456789012345678901234567890

12345678901234567890123456789012345678901234567890

12345678901234567890123456789012345678901234567890

';

grant select on crashtest.* to 'test'@'localhost';




[2009-04-19 14:44:29] jjuergens at web dot de

Yeah, you're right: Soon as I change the column-type from longtext to
text, PHP doesn't crash anymore. The example you provided also crashes
on my debug-enabled PHP-Version, while the Opensuse-Version (with
Suoshin-Patch) throws efree()-errors until there are more than 396
characters in the textfield.

I actually tried to debug the PHP-code some (with very limited
knowledge) and I think that the problem is somewhere within the binding
of the resultset since thats where the script stops.


[2009-04-19 14:11:14] j...@php.net

See also bug #46808






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=47928


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

[PHP-BUG] Req #51179 [NEW]: call_user_func() should take parameters by reference

2010-03-01 Thread info at fedushin dot ru

From: 
Operating system: 
PHP version:  5.2.13
Package:  Unknown/Other Function}
Bug Type: Feature/Change Request
Bug description:call_user_func() should take parameters by reference

Description:

Currently it's impossible to pass variable by reference to user callback
through call_user_func().

There's plenty of complaints about it on the Web.

Such missing possibility would be very useful.



As said in Bug #17309, the situation is not a bug because call_user_func()
takes its parameters by value.

Suggestion is to change call_user_func() signature & make it take 2nd &
following parameters by reference.

Test script:
---


Expected result:

1

Actual result:
--
0

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

[PHP-BUG] Bug #16153 [Com]: Kernel Panic on compile

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

ID: 16153
Comment by:
Reported by: sean at caedmon dot net
Summary: Kernel Panic on compile
Status: Bogus
Type: Bug
Package: Compile Failure
Operating System: Debian Unstable (sid)
PHP Version: 4.0CVS-2002-03-18

New Comment:

Good evening. We are what we repeatedly do. Help me! It has to find
sites on the: Download geico commercial. I found only this - http://vancruisers.ca/Members/Geico";>geico gecko costume.
Geico, plants from the geico ad company needed online of the line but it
was then small. Geico, it is national whether these choices number from
state ". Thank :confused: Fallon from Tajikistan.

Previous Comments:

[2002-03-18 16:50:40] sean at caedmon dot net

(yes, I know. I wasn't asking for support. Just reporting a kernel panic
in case it really was PHP related. And yes, I know, that's a canned
response. (-:) I just compiled again without the panic. Thanks for the
quick response, but it looks like this is not PHP related after all.

[2002-03-18 16:48:35] der...@php.net

A very likely cause is bad memory, or other broken hardware.

Derick

[2002-03-18 16:42:04] mfisc...@php.net

The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php

[2002-03-18 16:38:16] sean at caedmon dot net

I just got a kernel panic when running ./configure --enable-sockets. I
did a (mostly) successful compile a few minutes ago, then a make clean,
now, bye bye uptime.

Attached it part of my terminal log. I'll try to reproduce it.. )-:

---

checking for sys/time.h... (cached) yes

checking for sys/types.h... (cached) yes

Message from sysl...@adnagaporp at Mon Mar 18 16:43:20 2002 ...

adnagaporp kernel: CPU 0: Machine Check Exception: 0004

Message from sysl...@adnagaporp at Mon Mar 18 16:43:20 2002 ...

adnagaporp kernel: Bank 4: b2040151<0>Kernel panic: CPU context
corrupt

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

[PHP-BUG] Bug #43314 [NoF->Csd]: iconv_mime_encode(), broken Q scheme

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

 ID:   43314
 Updated by:   ras...@php.net
 Reported by:  wiela at centras dot lt
 Summary:  iconv_mime_encode(), broken Q scheme
-Status:   No Feedback
+Status:   Closed
 Type: Bug
 Package:  ICONV related
 Operating System: Windows XP HE
 PHP Version:  5.2.5
 Assigned To:  rasmus

 New Comment:

Fixed in SVN


Previous Comments:

[2010-03-02 01:34:15] ras...@php.net

-Status: No Feedback
+Status: Closed



[2010-03-02 00:34:59] letssurf at gmail dot com

Why has the status been set to No Feedback? Is this going to be fixed?


[2009-11-28 22:18:35] dennispopel at gmail dot com

Same on Vista/PHP5.3.0


[2009-01-09 14:38:50] om at viazenetti dot de

Hm, is this bugged fixed in newer versions? Currently we are using
version 5.2.6 and the error still occures.


[2008-11-04 01:00:01] 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".




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=43314


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

[PHP-BUG] Bug #51176 [Opn->Csd]: Static calling in non-static method behaves like $this->

2010-03-01 Thread felipe

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

 ID:   51176
 Updated by:   fel...@php.net
 Reported by:  majkl578 at gmail dot com
 Summary:  Static calling in non-static method behaves like
   $this->
-Status:   Open
+Status:   Closed
 Type: Bug
 Package:  Scripting Engine problem
 Operating System: Irrelevant
 PHP Version:  5.3.2RC3
 Assigned To:  felipe

 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-03-02 01:17:06] fel...@php.net

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.




[2010-03-01 16:53:03] majkl578 at gmail dot com

Description:

When calling non-existing static method from non-static method, __call()
is called instead of __callStatic().

self/static/className behaves incorrectly - like $this-> in that
context.



Verified on 5.3.2RC3, 5.3.1 and 5.3.0.

Reproduce code:
---
class Foo

{

public function start()

{

self::bar();

static::bar();

Foo::bar();

}



public function __call($n, $a)

{

echo 'instance';

}



public static function __callStatic($n, $a)

{

echo 'static';

}

}



$foo = new Foo();

$foo->start();

Expected result:

static

static

static

Actual result:
--
instance

instance

instance






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

[PHP-BUG] Bug #51178 [Opn->Bgs]: Compile fails randomly with default RPM CFLAGS

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

 ID:   51178
 Updated by:   ras...@php.net
 Reported by:  blake at bluehost dot com
 Summary:  Compile fails randomly with default RPM CFLAGS
-Status:   Open
+Status:   Bogus
 Type: Bug
 Package:  Compile Failure
 Operating System: CentOS 5.4
 PHP Version:  5.2.13

 New Comment:

I see nothing wrong with that code.  Line 136 of main/streams/cast.c in
PHP 

5.2.13 is:



#if HAVE_FOPENCOOKIE



And that define come from the configure check in acinclude.m4 which does
a test 

compile with _GNU_SOURCE defined.



I don't see why that would sometimes work and sometimes not on the same
system.  

Feel free to send us some suggested patches if you can figure out what
is 

sometimes tripping up your system, but since I see no bug here I am
marking this 

one bogus.


Previous Comments:

[2010-03-02 00:40:32] ras...@php.net

I see nothing wrong with that code.  Line 136 of main/streams/cast.c in
PHP 

5.2.13 is:



#if HAVE_FOPENCOOKIE



And that define come from the configure check in acinclude.m4 which does
a test 

compile with _GNU_SOURCE defined.



I don't see why that would sometimes work and sometimes not on the same
system.  

Feel free to send us some suggested patches if you can figure out what
is 

sometimes tripping up your system, but since I see no bug here I am
marking this 

one bogus.


[2010-03-01 22:48:17] blake at bluehost dot com

Description:

The CFLAGS used for this build are:

-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=0 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
-DSECURITY_HOLE_PASS_AUTHORIZATION



The differences from a default RPM build are
SECURITY_HOLE_PASS_AUTHORIZATION and _FORTIFY_SOURCE=2.  I don't have
this failure when building normally via ./configure && make, so this
makes me think it's the optimisation that's making the build flakey.  Is
it possible to make this function a little more resilient to
optimisation?



About 50% of the time PHP fails to build, it always fails in exactly the
same place:



/usr/src/rpm/BUILD/php-5.2.13/main/streams/cast.c:136: error: expected
'=', ',', ';', 'asm' or '__attribute__' before
'stream_cookie_functions'

/usr/src/rpm/BUILD/php-5.2.13/main/streams/cast.c: In function
'_php_stream_cast':

/usr/src/rpm/BUILD/php-5.2.13/main/streams/cast.c:189: warning: implicit
declaration of function 'fopencookie'

/usr/src/rpm/BUILD/php-5.2.13/main/streams/cast.c:189: error:
'stream_cookie_functions' undeclared (first use in this function)

/usr/src/rpm/BUILD/php-5.2.13/main/streams/cast.c:189: error: (Each
undeclared identifier is reported only once

/usr/src/rpm/BUILD/php-5.2.13/main/streams/cast.c:189: error: for each
function it appears in.)

/usr/src/rpm/BUILD/php-5.2.13/main/streams/cast.c:189: warning:
assignment makes pointer from integer without a cast

/usr/src/rpm/BUILD/php-5.2.13/main/streams/cast.c:230: warning: cast to
pointer from integer of different size

/usr/src/rpm/BUILD/php-5.2.13/main/streams/cast.c:233: warning: cast to
pointer from integer of different size

/usr/src/rpm/BUILD/php-5.2.13/main/streams/cast.c: In function
'_php_stream_open_wrapper_as_file':

/usr/src/rpm/BUILD/php-5.2.13/main/streams/cast.c:306: warning:
dereferencing type-punned pointer will break strict-aliasing rules

make: *** [main/streams/cast.lo] Error 1



Expected result:

A successful build 100% of the time.

Actual result:
--
If I build the RPM 20 times (without changing ANYTHING), it fails to
build at least - usually more - than half the time.  This increases the
time required to roll-out updates to PHP a great deal, by breaking our
automated build system.






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

[PHP-BUG] Bug #43314 [Com]: iconv_mime_encode(), broken Q scheme

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

 ID:   43314
 Comment by:   
 Reported by:  wiela at centras dot lt
 Summary:  iconv_mime_encode(), broken Q scheme
 Status:   No Feedback
 Type: Bug
 Package:  ICONV related
 Operating System: Windows XP HE
 PHP Version:  5.2.5

 New Comment:

Why has the status been set to No Feedback? Is this going to be fixed?


Previous Comments:

[2009-11-28 22:18:35] dennispopel at gmail dot com

Same on Vista/PHP5.3.0


[2009-01-09 14:38:50] om at viazenetti dot de

Hm, is this bugged fixed in newer versions? Currently we are using
version 5.2.6 and the error still occures.


[2008-11-04 01:00:01] php-bugs at lists dot php dot net

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


[2008-10-27 12:56:37] j...@php.net

Please try using this CVS snapshot:

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

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




[2008-02-01 14:10:33] d_kelsey at uk dot ibm dot com

I encountered a similar problem with another utf-8 string, and although
this may not be the best way to fix it, this change provides a
workaround.



in iconv.c (line 1281 in php5.2.5) the line

out_size -= ((nbytes_required - (char_cnt - 2)) + 1) / (3 - 1);



should be changed to

out_size -= ((nbytes_required - (char_cnt - 2)) + 1) / 3;



It looks like the code attempts to determine how many characters would
fit into output buffer when converted (given that it has gone over the
limit), but it assumes that on average each character uses 2 bytes (ie
an even mixture of encoded and printable characters). A lot of strings
will be greater than this and out_size will be set to a very large
positive number (as it subtracts a larger number from out_size and being
unsigned will result in a large positive number).

The workaround is to take the worst case scenario and assume all
characters generated 3 bytes (ie all encoded).




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=43314


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

[PHP-BUG] Bug #36424 [Fbk->Opn]: Serializable interface breaks object references

2010-03-01 Thread mastabog at hotmail dot com

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

 ID:   36424
 User updated by:  mastabog at hotmail dot com
 Reported by:  mastabog at hotmail dot com
 Summary:  Serializable interface breaks object references
-Status:   Feedback
+Status:   Open
 Type: Bug
 Package:  Scripting Engine problem
 Operating System: *
-PHP Version:  5.2.12
+PHP Version:  5.2.14-dev
 Assigned To:  helly

 New Comment:

Hi,



I tested with the latest Linux source snapshot (php5.2-201003011530) and
the bug is still there. I also tested the recently released 5.2.13
release and got the same result. Both Linux and Windows.



Did you run the reproduce code from the first post above and got the
expected result? The bug is definitely there in the snapshot I tested.



I've been avoiding the Serializable interface ever since it got
introduced due to this nasty bug. Could it please be fixed? It's growing
old and strong :)



Cheers


Previous Comments:

[2010-02-28 15:36:46] j...@php.net

Please try using this snapshot:

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

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




[2010-02-27 02:30:14] mastabog at hotmail dot com

I know it's been over 1 year since you asked me to try the latest CVS
snapshot but ...



... the bug is still there in 5.2.12 (Windows)! Yuu can try the
reproduce code from the first post.



Can this be fixed please?


[2008-11-10 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".


[2008-11-02 12:31:03] j...@php.net

Please try using this CVS snapshot:

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

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




[2006-07-22 22:11:56] mastabog at hotmail dot com

I'm not sure if we drifted away from the original bug report I made in
the first post. Has there been any progress on the original bug or plans
to fix it anytime soon?



I see the bug is still open so i take it the maintainer regards it as a
bug that needs fixing.



The latest snapshot I tried of php 5.2 from July 21 2006 still
experiences the same problem.




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

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


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

[PHP-BUG] Bug #35368 [Com]: PDO query does not work properly with serialize

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

ID: 35368
Comment by:
Reported by: lists at cyberlot dot net
Summary: PDO query does not work properly with serialize
Status: Suspended
Type: Bug
Package: PDO related
Operating System: *
PHP Version: 6CVS, 5CVS
Assigned To: wez

New Comment:

Excuse me. There is nothing more dreadful than imagination without
taste. Help me! I find sites on the topic: Cost of tamiflu without
insurance. I found only this - http://www.prolocotorrealfina.it/Members/Tamiflu/continuous-coughing-after-tamiflu-swine-flu";>continuous
coughing after tamiflu swine flu. Tamiflu, tamiflu infects the
number oil trying your genes and symptoms the type of recommended
changes of the century. Tamiflu, unless there is non-event close to
express a ability on, there spikes no oseltamivir in eating on the fish.
With love ;-), Asa from Togo.

Previous Comments:

[2010-01-07 06:51:19] uggabc at yahoo dot cn

It was my pleasure to visit your Website. I am also very Website you

enjoy the article.And I also have http://www.emu-boots.net/ emu boots
he feeling that it was really a pity that we didn

¡¯

t meet each other earlier. Because the kindness and warmth in your

Website can make me completely relaxed and happy. I hope that you

will visit my blog too

to see if you can have the same feeling.

[2010-01-07 06:50:39] uggabc at yahoo dot cn

It was my pleasure to visit your Website. I am also very Website you

enjoy the article.And I also have [url=http://www.emu-boots.net/]emu
boots[/url] he feeling that it was really a

pity that we didn¡¯

t meet each other earlier. Because the kindness and warmth in your

Website can make me completely relaxed and happy. I hope that you

will visit my blog too

[2010-01-07 06:48:39] uggabc at yahoo dot cn

It was my pleasure to visit your Website. I am also very Website you

enjoy the article.And I also have http://www.emu-boots.net/";>emu boots he feeling that it was

really a pity that we didn¡¯

t meet each other earlier. Because the kindness and warmth in your

Website can make me completely relaxed and happy. I hope that you

will visit my blog too

[2005-11-27 22:11:06] w...@php.net

We managed to reproduce the problem; it's a problem with the query
rewriter when it maps :name to ?. If the string is embedded in the SQL
using single quotes, but has double quotes backslashed, the string it
too tricky for the parser to follow, and it ends up transforming parts
of the serialized string that it shouldn't.

There are three possible workarounds for this issue, in order of
preference:

- Don't embed serialized data into the query string; use bound
parameters (that's what they're there for). In future versions of PDO,
prepared statements may be cacheable in persistent connections, leading
to a performance gain.

- Use PDO::quote() to correctly quote the string

- Use PDO::exec() to fire off this UPDATE/INSERT statement; it uses an
alternate API that doesn't need to handle parameters.

[2005-11-25 16:40:35] tony2...@php.net

This is fixed in CVS, get a fresh snapshot and try again.

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=35368

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

[PHP-BUG] Bug #51178 [NEW]: Compile fails randomly with default RPM CFLAGS

2010-03-01 Thread blake at bluehost dot com

From: 
Operating system: CentOS 5.4
PHP version:  5.2.13
Package:  Compile Failure}
Bug Type: Bug
Bug description:Compile fails randomly with default RPM CFLAGS

Description:

The CFLAGS used for this build are:

-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=0 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic
-DSECURITY_HOLE_PASS_AUTHORIZATION



The differences from a default RPM build are
SECURITY_HOLE_PASS_AUTHORIZATION and _FORTIFY_SOURCE=2.  I don't have this
failure when building normally via ./configure && make, so this makes me
think it's the optimisation that's making the build flakey.  Is it possible
to make this function a little more resilient to optimisation?



About 50% of the time PHP fails to build, it always fails in exactly the
same place:



/usr/src/rpm/BUILD/php-5.2.13/main/streams/cast.c:136: error: expected '=',
',', ';', 'asm' or '__attribute__' before 'stream_cookie_functions'

/usr/src/rpm/BUILD/php-5.2.13/main/streams/cast.c: In function
'_php_stream_cast':

/usr/src/rpm/BUILD/php-5.2.13/main/streams/cast.c:189: warning: implicit
declaration of function 'fopencookie'

/usr/src/rpm/BUILD/php-5.2.13/main/streams/cast.c:189: error:
'stream_cookie_functions' undeclared (first use in this function)

/usr/src/rpm/BUILD/php-5.2.13/main/streams/cast.c:189: error: (Each
undeclared identifier is reported only once

/usr/src/rpm/BUILD/php-5.2.13/main/streams/cast.c:189: error: for each
function it appears in.)

/usr/src/rpm/BUILD/php-5.2.13/main/streams/cast.c:189: warning: assignment
makes pointer from integer without a cast

/usr/src/rpm/BUILD/php-5.2.13/main/streams/cast.c:230: warning: cast to
pointer from integer of different size

/usr/src/rpm/BUILD/php-5.2.13/main/streams/cast.c:233: warning: cast to
pointer from integer of different size

/usr/src/rpm/BUILD/php-5.2.13/main/streams/cast.c: In function
'_php_stream_open_wrapper_as_file':

/usr/src/rpm/BUILD/php-5.2.13/main/streams/cast.c:306: warning:
dereferencing type-punned pointer will break strict-aliasing rules

make: *** [main/streams/cast.lo] Error 1



Expected result:

A successful build 100% of the time.

Actual result:
--
If I build the RPM 20 times (without changing ANYTHING), it fails to build
at least - usually more - than half the time.  This increases the time
required to roll-out updates to PHP a great deal, by breaking our automated
build system.

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

[PHP-BUG] Bug #51128 [Opn->Fbk]: imagefill() doesn't work with large images

2010-03-01 Thread pajoye

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

 ID:   51128
 Updated by:   paj...@php.net
 Reported by:  admin-team at suresupport dot com
 Summary:  imagefill() doesn't work with large images
-Status:   Open
+Status:   Feedback
 Type: Bug
 Package:  GD related
 Operating System: Linux Debian 64bit
 PHP Version:  5.2.12

 New Comment:

Can you paste the GD section of phpinfo of both servers please?


Previous Comments:

[2010-03-01 21:42:06] paj...@php.net

Can you paste the GD section of phpinfo of both servers please?


[2010-02-24 15:51:20] admin-team at suresupport dot com

Hello Pajoye,



Thank you for your anwser!



The code in test1.php & test2.php is taken from official documentation
of the function:



http://php.net/manual/en/function.imagefill.php



The problem described in my first post doesn't exist on another type of
server - RedHat Linux 32bit - I get 2 red rectangles.



Thank you


[2010-02-23 21:15:55] paj...@php.net

Please allocate a background and then a color to use for the fill.


[2010-02-23 21:09:38] admin-team at suresupport dot com

Description:

Hello, 



Please check this URL: 

http://imagefill.server260.com/



http://imagefill.server260.com/test1.php is working properly when the
size of the image is 255x255 pixels and is producing a red rectangle 



http://imagefill.server260.com/test2.php is the same code with image
size of 256x256 producing a black rectangle 



You should check http://imagefill.server260.com/info.php for the PHP
options.

Reproduce code:
---
http://imagefill.server260.com/test1.source.txt

http://imagefill.server260.com/test2.source.txt

http://imagefill.server260.com/test.diff.txt

Expected result:

When I run http://imagefill.server260.com/test2.php I should get a red
rectangle.

Actual result:
--
But I get a black rectangle.






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

[PHP-BUG] Bug #50627 [Com]: mhash extension tests fail

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

 ID:   50627
 Comment by:   
 Reported by:  rush at logic dot cz
 Summary:  mhash extension tests fail
 Status:   Open
 Type: Bug
 Package:  mhash related
 Operating System: *
 PHP Version:  5.2.12

 New Comment:

The just released php version 5.2.13 (eb4d0766dc4fb9667f05a68b6041e7d1 
php-5.2.13.tar.bz) still contains this trivial to fix error.



=

FAILED TEST SUMMARY

-

mhash() test [ext/mhash/tests/001.phpt]

mhash_keygen_s2k() test [ext/mhash/tests/003.phpt]

=


Previous Comments:

[2010-02-13 00:12:19] jvp at 4ssl dot us

'mhash() test [ext/mhash/tests/001.phpt]'

'mhash_keygen_s2k() test [ext/mhash/tests/003.phpt]'



5.2.12 with 64bit centos 5.4 mhash 0.9.9-1





it has been going on two months now and the test files have not been
corrected. why has that not been done so that compilers need not waste
time chasing down a bogus error?



--

thank you,



johann


[2010-01-01 19:10:20] rush at logic dot cz

Description:

PHP version 5.2.12 contains minor bug in files 

ext/mhash/tests/00{1,3}.phpt. Some occurrences of character 0x0d were 

replaced by 0x0a. This was possibly caused by revision control 

software.



File ext/mhash/tests/001.phpt Offset 0x23f 0x0a should be replaced by 

0x0d (MHASH_TIGER)



File ext/mhash/tests/003.phpt Offset 0x2b9 0x0a should be replaced by 

0x0d (MHASH_HAVAL224)



File ext/mhash/tests/003.phpt Offset 0x671 0x0a should be replaced by 

0x0d (MHASH_CRC32)



This bug is present in 5.2.12 and current 5.2 snapshot. Version 5.2.10 

is ok and tests are working as intended.



Expected result:

Replace the mentioned characters by their escaped counterparts. This 

could make them less vulnerable.

Actual result:
--
Performing mhash extension tests always fails with following error:



Running selected tests. 



TEST 1/3 [tests/001.phpt]   



FAIL mhash() test [tests/001.phpt]  



TEST 2/3 [tests/002.phpt]   



PASS mhash_get_block_size() & mhash_get_hash_name() test 

[tests/002.phpt]
   


TEST 3/3 [tests/003.phpt]   



FAIL mhash_keygen_s2k() test [tests/003.phpt]   



=   



Number of tests :3 3



Tests skipped   :0 (  0.0%) 



Tests warned:0 (  0.0%) (  0.0%)



Tests failed:2 ( 66.7%) ( 66.7%)



Expected fail   :0 (  0.0%) (  0.0%)



Tests passed:1 ( 33.3%) ( 33.3%)

[PHP-BUG] Bug #1 [Csd]: Apache 1.3b3 + mod_php3 is slow

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

 ID:   1
 Updated by:   j...@php.net
 Reported by:  rasmus at lerdorf dot on dot ca
 Summary:  Apache 1.3b3 + mod_php3 is slow
 Status:   Closed
 Type: Bug
 Package:  Performance problem
 Operating System: Solaris 2.5.1
 PHP Version:  3.0b3
 Assigned To:  jani

 New Comment:

test


Previous Comments:

[2010-03-01 20:29:38] der...@php.net

testing II


[2010-03-01 20:20:57] der...@php.net

testing.


[2009-05-22 09:27:28] j...@php.net

test


[1998-01-25 11:06:03] rasmus at lerdorf dot on dot ca

When PHP3 is linked into Apache 1.3b3 on Solaris 2.5.1 the

web server becomes extremely sluggish or won't answer requests

at all.  





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

[PHP-BUG] Bug #1 [Com]: Apache 1.3b3 + mod_php3 is slow

2010-03-01 Thread der...@php.net

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

 ID:   1
 Comment by:   der...@php.net
 Reported by:  rasmus at lerdorf dot on dot ca
 Summary:  Apache 1.3b3 + mod_php3 is slow
 Status:   Closed
 Type: Bug
 Package:  Performance problem
 Operating System: Solaris 2.5.1
 PHP Version:  3.0b3

 New Comment:

testing II


Previous Comments:

[2010-03-01 20:20:57] der...@php.net

testing.


[2009-05-22 09:27:28] j...@php.net

test


[1998-01-25 11:06:03] rasmus at lerdorf dot on dot ca

When PHP3 is linked into Apache 1.3b3 on Solaris 2.5.1 the

web server becomes extremely sluggish or won't answer requests

at all.  





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

#51177 [Fbk->Bgs]: Header Problem

 ID:   51177
 Updated by:   ras...@php.net
 Reported By:  baptistmanish at gmail dot com
-Status:   Feedback
+Status:   Bogus
 Bug Type: *General Issues
 Operating System: XP
 PHP Version:  5.3.1
 New Comment:

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.


.


Previous Comments:


[2010-03-01 19:11:05] ras...@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.


Try a support channel instead.  This isn\'t a PHP bug.



[2010-03-01 19:05:48] baptistmanish at gmail dot com

Description:

I am creating a dynamic xls file and then creating a link to download.

The code has worked on my local machine, but when i uploaded on the web
server it does not give download option


Reproduce code:
---
header("Content-Disposition: attachment; filename=$excel_file_name");

Expected result:

Download File Option

Actual result:
--
Not giving option to download file





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

#51177 [Opn->Fbk]: Header Problem

 ID:   51177
 Updated by:   ras...@php.net
 Reported By:  baptistmanish at gmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: *General Issues
 Operating System: XP
 PHP Version:  5.3.1
 New Comment:

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.


Try a support channel instead.  This isn't a PHP bug.


Previous Comments:


[2010-03-01 19:05:48] baptistmanish at gmail dot com

Description:

I am creating a dynamic xls file and then creating a link to download.

The code has worked on my local machine, but when i uploaded on the web
server it does not give download option


Reproduce code:
---
header("Content-Disposition: attachment; filename=$excel_file_name");

Expected result:

Download File Option

Actual result:
--
Not giving option to download file





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

#51177 [NEW]: Header Problem

2010-03-01 Thread baptistmanish at gmail dot com

From: baptistmanish at gmail dot com
Operating system: XP
PHP version:  5.3.1
PHP Bug Type: *General Issues
Bug description:  Header Problem

Description:

I am creating a dynamic xls file and then creating a link to download.

The code has worked on my local machine, but when i uploaded on the web
server it does not give download option


Reproduce code:
---
header("Content-Disposition: attachment; filename=$excel_file_name");

Expected result:

Download File Option

Actual result:
--
Not giving option to download file

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

#50839 [Opn->Bgs]: log_errors + display_errors = bogus timezone warning in response entity

 ID:   50839
 Updated by:   j...@php.net
 Reported By:  miqrogroove at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: PHP options/info functions
 Operating System: Windows 2003
 PHP Version:  5.3.1
 New Comment:

No bug.


Previous Comments:


[2010-02-26 06:24:37] miqrogroove at gmail dot com

Please keep this bug open.



[2010-02-26 06:23:57] miqrogroove at gmail dot com

Please keep this bug open.



[2010-02-03 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".



[2010-01-27 06:26:49] miqrogroove at gmail dot com

> you should actually read the error message and do what it suggests?

As a developer, I don't have the luxury of assuming servers are 
configured a certain way.  Since PHP offers no way to check if the 
default timezone has been set already, the only alternative I have is
to 
disable error reporting, so that functions like mail() wont interrupt 
header output or image generation.

If you do find that Windows snapshot for me, could you check if it
comes 
with the installer, or if there are any instructions for upgrading 
without the installer?



[2010-01-27 02:03:36] miqrogroove at gmail dot com

hi jani,

I followed your link and all it says is:

PHP 5.3
5.3 has no release.
PHP 5.2
5.2 has no release.
PHP 6.0
6.0 has no release.



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

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

#50896 [Opn->Bgs]: Bus error on execution on a MIPS system

 ID:   50896
 Updated by:   j...@php.net
 Reported By:  angel at wututu dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: GNU/Linux
 PHP Version:  5.2snapshot-201002171530
 New Comment:

No problem. No testing, no way to reproduce -> bogus.


Previous Comments:


[2010-02-26 13:13:52] angel at wututu dot com

Hi!

Sorry to say that, but I no longer have access to that machine for
testing this bug :/

At this moment I saw the Bus Error inside QEMU but copying the file
over the device when running it got stuck, with no error message, I had
to ctrl+c it to exit.

With QEMU I was using Ubuntu 9.10, and inside the device there was an
special version of openwrt.

About the -M option I don't remember much of it, I suppose it was mips
or mipsel. 

And that's all I can say about that, sorry :(



[2010-02-24 07:33:38] ahar...@php.net

I can't reproduce this on a Debian testing install within a mipsel 
QEMU VM: the current PHP 5.2 and 5.3 SVN branches compile and appear 
to work normally, at least for trivial scripts.

So, a few questions:

Are you only seeing the Bus Errors on the actual MIPS devices, or 
within QEMU as well?

Are you using a particular Linux distribution?

Which machine type are you emulating with QEMU (ie what -M option, if 
any, are you passing to qemu-system-mipsel)?

Have you tried a minimal build without any extensions enabled (ie just

./configure --enable-debug)? Does PHP still Bus Error out in that 
case? (If PHP works OK without any extensions, then it would be 
incredibly helpful if you were able to narrow down the problem to a 
particular extension that causes PHP to crash when it's compiled in.)



[2010-02-22 16:09:02] angel at wututu dot com

Well... not cross compiling. I'm compiling it natively inside a virtual
machine because I can't use the final machine because it lacks memory.



[2010-02-19 08:34:06] j...@php.net

-Status: Open
+Status: Bogus

Oh, you're cross-compiling this. We do not support that out-of-box,
you're totally on your own with it.



[2010-02-18 08:38:03] angel at wututu dot com

-Status: Feedback
+Status: Open
-PHP Version: 5.3SVN-2010-02-10
+PHP Version: 5.2snapshot-201002171530

The backtrace in this case is more or less the same as before:

(gdb) run
Starting program: /build/php5.2-201002171530/sapi/cli/php 
warning: no loadable sections found in added symbol-file
/usr/lib/libiconv.so.2

Program received signal SIGBUS, Bus error.
0x0071e704 in _zend_mm_alloc_int (heap=0x91f300, size=13)
at /build/php5.2-201002171530/Zend/zend_alloc.c:1897
1897ZEND_MM_CHECK_BLOCK_LINKAGE(best_fit);
(gdb) backtrace 
#0  0x0071e704 in _zend_mm_alloc_int (heap=0x91f300, size=13)
at /build/php5.2-201002171530/Zend/zend_alloc.c:1897
#1  0x0074a5b4 in zend_register_functions (scope=0x0,
functions=0x911ad0, 
function_table=, type=)
at /build/php5.2-201002171530/Zend/zend_operators.h:287
#2  0x0074358c in zend_startup (utility_functions=, 
extensions=, start_builtin_functions=1)
at /build/php5.2-201002171530/Zend/zend.c:676
#3  0x006ead00 in php_module_startup (sf=, 
additional_modules=0x0, num_additional_modules=0)
at /build/php5.2-201002171530/main/main.c:1710
#4  0x007ef254 in php_cli_startup (sapi_module=0x0)
at /build/php5.2-201002171530/sapi/cli/php_cli.c:389
#5  0x007efdd8 in main (argc=1, argv=0x7f948dc4)
at /build/php5.2-201002171530/sapi/cli/php_cli.c:748



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

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

#51155 [Opn->Fbk]: serialize() crashes with unreasonable/unexplicable "out of memory" for objects