#32504 [Bgs->Opn]: ldd problem on make test
ID: 32504 User updated by: ralph at cs dot cf dot ac dot uk Reported By: ralph at cs dot cf dot ac dot uk -Status: Bogus +Status: Open Bug Type: Compile Failure Operating System: MacOS X 10.3.x PHP Version: 5CVS-2005-03-30 (dev) New Comment: OK, downloaded latest snapshot, did NOT do ./buildconf, just did ./ configure with appropriate arguments, and still got the error I originally notified: Please allow this report to be send to the PHP QA team. This will give us a better understanding in how PHP's test cases are doing. (choose "s" to just save the results to a file)? [Yns]: Y Please enter your email address. (Your address will be mangled so that it will not go out on any mailinglist in plain text): [EMAIL PROTECTED] sh: line 1: /usr/local/src/php5-200503310630./build/ shtool: No such file or directory sh: line 1: --version: command not found sh: line 1: ldd: command not found Posting to qa.php.net /buildtest-process.php Thank you for helping to make PHP better. Previous Comments: [2005-03-30 19:05:01] [EMAIL PROTECTED] This problem was fixed a couple of days ago and now there is ./configure script. I just downloaded the snap and checked - it's on its place. [2005-03-30 18:52:22] ralph at cs dot cf dot ac dot uk If I dont run ./builconf, then there is no configure file! [2005-03-30 17:16:06] [EMAIL PROTECTED] Don't run buildconf yourself. [2005-03-30 15:59:31] ralph at cs dot cf dot ac dot uk Description: This bug seems to be the reult of a not-quite-correct solution to bug 29136. On doing "make test" a failure occurs when trying to mail the results to the developers. Reproduce code: --- ./buildconf ./configure make make test Expected result: list of build issues to be mailed to the developers Actual result: -- Please allow this report to be send to the PHP QA team. This will give us a better understanding in how PHP's test cases are doing. (choose "s" to just save the results to a file)? [Yns]: Please enter your email address. (Your address will be mangled so that it will not go out on any mailinglist in plain text): [EMAIL PROTECTED]: line 1: /usr/local/src/php5-200503301230./build/shtool: No such file or directory sh: line 1: --version: command not found sh: line 1: ldd: command not found Posting to qa.php.net /buildtest-process.php Thank you for helping to make PHP better. -- Edit this bug report at http://bugs.php.net/?id=32504&edit=1
#32513 [NEW]: session_write_close has to be called explicitly
From: tomas_matousek at hotmail dot com Operating system: WinXP PHP version: 5.0.3 PHP Bug Type: Session related Bug description: session_write_close has to be called explicitly Description: If user handlers are set, the Write callback is not triggered and so session vars set to $_SESSION are not persisted on the end of the script unless session_write_close is called. This is related to bugs #16282 and #12915. -- Edit bug report at http://bugs.php.net/?id=32513&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32513&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32513&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32513&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32513&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32513&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32513&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32513&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32513&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32513&r=support Expected behavior: http://bugs.php.net/fix.php?id=32513&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32513&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32513&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32513&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32513&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32513&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32513&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32513&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32513&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32513&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32513&r=mysqlcfg
#32513 [Opn->Fbk]: session_write_close has to be called explicitly
ID: 32513 Updated by: [EMAIL PROTECTED] Reported By: tomas_matousek at hotmail dot com -Status: Open +Status: Feedback Bug Type: Session related Operating System: WinXP PHP Version: 5.0.3 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Previous Comments: [2005-03-31 10:49:23] tomas_matousek at hotmail dot com Description: If user handlers are set, the Write callback is not triggered and so session vars set to $_SESSION are not persisted on the end of the script unless session_write_close is called. This is related to bugs #16282 and #12915. -- Edit this bug report at http://bugs.php.net/?id=32513&edit=1
#30962 [Com]: Space being returned for NULL columns
ID: 30962 Comment by: beschr at free dot fr Reported By: richard dot quadling at bandvulc dot co dot uk Status: No Feedback Bug Type: MSSQL related Operating System: Windows XP Pro SP2 PHP Version: 5.0.3 New Comment: Please ignore my precedent comment, the bug is still present in CVS. I test the mssql.dll today (latest snap: Built On: Mar 29, 2005 16:30 GMT) and the bug is still present. Previous Comments: [2005-03-25 14:54:28] rantal at eoss dot ru Same problem still exist in php4 snapshot php4-win32-STABLE-200503230530.zip [2005-03-17 17:59:57] beschr at free dot fr I've got this problem too with php 5.0.3 on IIS/Windows XP Pro SP2. With the mssql.dll of this snaps: Built On: Mar 17, 2005 01:30 GMT it work great. So I think the correction in CVs is ok and you can close this bug. [2005-03-08 01:00:11] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-02-28 21:19:22] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-02-15 19:13:23] erudd at netfor dot com -- The reason I say this, is that if I make the column NULL, -- then I get NULL. If I make the column an empty string -- (i.e. select all and then delete - doing this in -- Enterprise Manager), I get a space in the result set! I recently came across this issue when upgrading to the lastest FreeTDS and the lastet PHP 4.3.x connecting to MS SQL Server 2000. The issue was actualy not php, as it was easily fixed by editing the freetds.conf and set the global "tds version" from 4.2 to 7.0 and the space issue went away. 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/30962 -- Edit this bug report at http://bugs.php.net/?id=30962&edit=1
#32512 [NEW]: flush() does not work after sending Location header
From: kulakov74 at yandex dot ru
Operating system: Linux, Win 2000
PHP version: 4.3.9
PHP Bug Type: Output Control
Bug description: flush() does not work after sending Location header
Description:
We want a script to make a redirect and then make some Sql-queries, so
that the user would not wait for the queries to execute (sometimes they
may take too long). I added
echo("-"); flush();
after sending the Location header which made PHP send the header
immediately away, but the problem is IE does not make the redirect as soon
as it gets the header - probably it expects other headers or a page, so it
only redirects after the script completes. If I add more output after that
and a flush() call then PHP won't output anything else until the script
completes. This is emulated with a sleep(3) call. More precisely, PHP only
sends headers immediately, it doesn't send anything else (the dash in this
case).
Reproduce code:
---
//This is the redirect
header("Location: http://hotelsys.biz/hotels/Bali";);
//This is how I force PHP to send it right away
echo("-"); flush();
//This is how I cannot make PHP send anything else
echo(str_repeat("-", 1024*16)); flush();
//Pause emulation
sleep(3);
//the end - this is when the browser gets the output
exit;
Expected result:
The first "-" character and the next 16K of it sent right away.
Actual result:
--
I only get dashes in 3 seconds; the browser (IE) makes the redirect in
this time too.
--
Edit bug report at http://bugs.php.net/?id=32512&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32512&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32512&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32512&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32512&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32512&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32512&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32512&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32512&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32512&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32512&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32512&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32512&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32512&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32512&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32512&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32512&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32512&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32512&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32512&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32512&r=mysqlcfg
#32514 [NEW]: session_start() crashes when session exists
From: red at raven dot ch
Operating system: Fedora Core 3
PHP version: 5.0.3
PHP Bug Type: Session related
Bug description: session_start() crashes when session exists
Description:
When I create a session and write some objects to it the server crashes
with a segmentation fault on the next request.
When searching in the bug database I found
http://bugs.php.net/bug.php?id=31734 which seems to have similar behaviour
on my machine.
Reproduce code:
---
This is the content of the session file: The code is a bit too complex to
post here.
VidaAuth|O:8:"VidaAuth":4:{s:14:"VidaAuthuser";N;s:18:"VidaAuthloggedIn";N;s:25:
"VidaAuthuserEntityClass";s:4:"User";s:25:"VidaAuthuserObjectCache";O:4:"User":5
:{s:13:"*entityCore";N;s:14:"*tableScheme";O:13:"DBTableScheme":9:{s:20:"DBTable
Schemetable";s:5:"users";s:21:"DBTableSchemefields";a:3:{i:0;s:8:"username";i:1;
s:8:"password";i:2;s:5:"email";}s:20:"DBTableSchemetypes";a:3:{s:8:"username";s:
6:"string";s:8:"password";s:6:"string";s:5:"email";s:6:"string";}s:18:"DBTableSc
hemekey";s:8:"username";s:19:"DBTableSchemenull";a:3:{s:8:"username";b:0;s:8:"pa
ssword";b:0;s:5:"email";b:0;}s:29:"DBTableSchemeeffectiveTypes";a:3:{s:8:"userna
me";s:7:"varchar";s:8:"password";s:7:"varchar";s:5:"email";s:7:"varchar";}s:21:"
DBTableSchemelength";a:3:{s:8:"username";s:3:"255";s:8:"password";s:3:"255";s:5:
"email";s:3:"255";}s:26:"DBTableSchemeforeignKeys";a:0:{}s:22:"DBTableSchemesetI
nfo";a:0:{}}s:12:"*newValues";a:0:{}s:13:"*nullValues";a:0:{}s:8:"*state";i:0;}}
FormManager|O:11:"FormManager":2:{s:7:"counter";i:2;s:5:"stock";a:2:{s:13:"VidaL
oginForm";a:1:{i:1;O:15:"FormDataStorage":7:{s:6:"values";a:0:{}s:25:"FormDataSt
orageinvalids";a:0:{}s:8:"messages";a:0:{}s:29:"FormDataStoragesystemValues";a:2
:{s:15:"controllerClass";s:11:"LoginAction";s:3:"url";O:7:"ThisURL":5:{s:11:"URL
scheme";s:0:"";s:9:"URLhost";s:0:"";s:9:"URLpath";s:6:"/vita/";s:9:"URLfile";s:1
0:"index.php5";s:16:"URLqueryValues";a:0:{}}}s:23:"FormDataStorageparent";N;s:27
:"FormDataStorageidentifier";i:1;s:24:"FormDataStoragereferer";O:7:"Referer":5:{
s:11:"URLscheme";s:0:"";s:9:"URLhost";s:0:"";s:9:"URLpath";s:6:"/vita/";s:9:"URL
file";s:10:"index.php5";s:16:"URLqueryValues";a:0:{s:13:"XmlModuleForm";a:1:
{i:2;O:15:"FormDataStorage":7:{s:6:"values";a:0:{}s:25:"FormDataStorageinvalids"
;a:0:{}s:8:"messages";a:0:{}s:29:"FormDataStoragesystemValues";a:2:{s:15:"contro
llerClass";s:15:"XmlModuleAction";s:3:"url";r:45;}s:23:"FormDataStorageparent";N
;s:27:"FormDataStorageidentifier";i:2;s:24:"FormDataStoragereferer";O:7:"Referer
":5:{s:11:"URLscheme";s:0:"";s:9:"URLhost";s:0:"";s:9:"URLpath";s:6:"/vita/";s:9
Expected result:
To load the session and create the Objects.
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208899904 (LWP 28088)]
0x012d7aaf in zend_do_fcall_common_helper (execute_data=0xbfe83c20,
opline=0x99f46dc, op_array=0x99ef37c)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2656
2656if (EX(function_state).function->common.fn_flags &
ZEND_ACC_ABSTRACT) {
--
Edit bug report at http://bugs.php.net/?id=32514&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32514&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32514&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32514&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32514&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32514&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32514&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32514&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32514&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32514&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32514&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32514&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32514&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32514&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32514&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32514&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32514&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32514&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32514&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32514&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32514&r=mysqlcfg
#32514 [Opn->Fbk]: session_start() crashes when session exists
ID: 32514
Updated by: [EMAIL PROTECTED]
Reported By: red at raven dot ch
-Status: Open
+Status: Feedback
Bug Type: Session related
Operating System: Fedora Core 3
PHP Version: 5.0.3
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
Please try to reduce your reproduce script to reasonable size (~20
lines) or upload it somewhere and gives us the link.
Also, please post _full_ backtrace instead of the last line.
Previous Comments:
[2005-03-31 11:06:39] red at raven dot ch
Description:
When I create a session and write some objects to it the server crashes
with a segmentation fault on the next request.
When searching in the bug database I found
http://bugs.php.net/bug.php?id=31734 which seems to have similar
behaviour on my machine.
Reproduce code:
---
This is the content of the session file: The code is a bit too complex
to post here.
VidaAuth|O:8:"VidaAuth":4:{s:14:"VidaAuthuser";N;s:18:"VidaAuthloggedIn";N;s:25:
"VidaAuthuserEntityClass";s:4:"User";s:25:"VidaAuthuserObjectCache";O:4:"User":5
:{s:13:"*entityCore";N;s:14:"*tableScheme";O:13:"DBTableScheme":9:{s:20:"DBTable
Schemetable";s:5:"users";s:21:"DBTableSchemefields";a:3:{i:0;s:8:"username";i:1;
s:8:"password";i:2;s:5:"email";}s:20:"DBTableSchemetypes";a:3:{s:8:"username";s:
6:"string";s:8:"password";s:6:"string";s:5:"email";s:6:"string";}s:18:"DBTableSc
hemekey";s:8:"username";s:19:"DBTableSchemenull";a:3:{s:8:"username";b:0;s:8:"pa
ssword";b:0;s:5:"email";b:0;}s:29:"DBTableSchemeeffectiveTypes";a:3:{s:8:"userna
me";s:7:"varchar";s:8:"password";s:7:"varchar";s:5:"email";s:7:"varchar";}s:21:"
DBTableSchemelength";a:3:{s:8:"username";s:3:"255";s:8:"password";s:3:"255";s:5:
"email";s:3:"255";}s:26:"DBTableSchemeforeignKeys";a:0:{}s:22:"DBTableSchemesetI
nfo";a:0:{}}s:12:"*newValues";a:0:{}s:13:"*nullValues";a:0:{}s:8:"*state";i:0;}}
FormManager|O:11:"FormManager":2:{s:7:"counter";i:2;s:5:"stock";a:2:{s:13:"VidaL
oginForm";a:1:{i:1;O:15:"FormDataStorage":7:{s:6:"values";a:0:{}s:25:"FormDataSt
orageinvalids";a:0:{}s:8:"messages";a:0:{}s:29:"FormDataStoragesystemValues";a:2
:{s:15:"controllerClass";s:11:"LoginAction";s:3:"url";O:7:"ThisURL":5:{s:11:"URL
scheme";s:0:"";s:9:"URLhost";s:0:"";s:9:"URLpath";s:6:"/vita/";s:9:"URLfile";s:1
0:"index.php5";s:16:"URLqueryValues";a:0:{}}}s:23:"FormDataStorageparent";N;s:27
:"FormDataStorageidentifier";i:1;s:24:"FormDataStoragereferer";O:7:"Referer":5:{
s:11:"URLscheme";s:0:"";s:9:"URLhost";s:0:"";s:9:"URLpath";s:6:"/vita/";s:9:"URL
file";s:10:"index.php5";s:16:"URLqueryValues";a:0:{s:13:"XmlModuleForm";a:1:
{i:2;O:15:"FormDataStorage":7:{s:6:"values";a:0:{}s:25:"FormDataStorageinvalids"
;a:0:{}s:8:"messages";a:0:{}s:29:"FormDataStoragesystemValues";a:2:{s:15:"contro
llerClass";s:15:"XmlModuleAction";s:3:"url";r:45;}s:23:"FormDataStorageparent";N
;s:27:"FormDataStorageidentifier";i:2;s:24:"FormDataStoragereferer";O:7:"Referer
":5:{s:11:"URLscheme";s:0:"";s:9:"URLhost";s:0:"";s:9:"URLpath";s:6:"/vita/";s:9
Expected result:
To load the session and create the Objects.
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208899904 (LWP 28088)]
0x012d7aaf in zend_do_fcall_common_helper (execute_data=0xbfe83c20,
opline=0x99f46dc, op_array=0x99ef37c)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2656
2656if (EX(function_state).function->common.fn_flags &
ZEND_ACC_ABSTRACT) {
--
Edit this bug report at http://bugs.php.net/?id=32514&edit=1
#32491 [Opn]: File upload error - unable to create a temporary file
ID: 32491
Updated by: [EMAIL PROTECTED]
Reported By: Oscar dot Castillo at jpl dot nasa dot gov
Status: Open
Bug Type: iPlanet related
Operating System: Solaris 9
PHP Version: 5CVS-2005-03-31
New Comment:
Again the old STDIO problem: There are some places in PHP where the C
library stdio functions are used instead of posix io (popen in all
excute functions/sendmail functions, uploading of temporary files, some
3rd party extensions). Under Solaris with the AT&T libc stdio is limited
to 255 file descriptors, if the current posix file descriptor gets
larger than 255 all further fopens or fdopens fail because the field in
the FILE* struct is a unsigned char. Using Posix IO has no limit here
(descriptor is int).
There are 2 solutions:
a) limiting the accepting threads in sunone/iplanet and disabling java
in webserver completely (java is very descriptor intensive ->
descriptors for PHP get > 255)
b) using PHP as CGI/FastCGI (look for Sun PHP enabler at zend.com) or
my CGI enabler: http://www.thetaphi.de/php-ressources/
Changing this in PHP is a heavy task, the zend engine itsself is safe
since 4.3.3, other parts should be changed in the future to POSIX IO.
This is a Solaris problem which gets important in a multithreaded and
heavy file descriptor using webserver like sunone/iplanet
Previous Comments:
[2005-03-31 01:16:53] Oscar dot Castillo at jpl dot nasa dot gov
So changing the Category of problem to "iPlanet related" means what? Do
I have to open a bug report with Sun for this problem? Please help.
[2005-03-29 21:55:27] Oscar dot Castillo at jpl dot nasa dot gov
Description:
I am using iPlanet 6.0 SP5, Zend 2.5.7 and PHP 5.0.3 on a 64 bit
Solaris 9 SunFire V880 (4x4GHz CPU, 8Gb RAM). I have a problem with an
HTTP POST command that attempts to upload a file onto the web server
and a consistent "File upload error - unable to create a temporary file
in Unknown on line 0" error message appears in the error logs. The
upload_tmp_dir directory is set to /tmp. The error message disappears
with a web server daemon reset (stop/start the web server daemon), but
the error begins to occur within 2 to 24 hours again. When the errors
occur, the /tmp directory begins to accumulate with php[web_server_pid]
files that are zero bytes in size. My upload_max_filesize parameter is
configured to 2Mb, however the uploaded files are never above 50kb.
I've tried many suggested fixes from the php.net bug reports area, but
to no avail. Thanks in advance for your help!
Reproduce code:
---
9) { phpinfo(); }
//
// Configurable variables
//
$BaseDir = './';
$LogFileName = $BaseDir . "RTIU_translator.log";
$SCLK_SCET_Dir = "/afs/jpl/group/casops/dom/data/main/sclkscet/"; //
placed in executed shell script
$UploadDir = $BaseDir . "Temp/" ; // Where the posted files
are
placed
$TransferDir = $BaseDir . "Xfer/";// Where the tar file for the
translator is created
//
// Verify resources are available
//
$LogFile = fopen( $LogFileName,'a');
if (! $LogFile)
{ print("Logging is disabled, please save all displayed messages if
help is needed from IO support");
}
// Verify UPLOAD directory
if (!file_exists($UploadDir))
{ if ($LogFile)
{ $TmpStr = sprintf("%s VERIFY Upload directory does not exist\n",
gmdate("Y-m-d H:i:s") );
// strftime("%Y-%m-%d %T"));
fwrite($LogFile, $TmpStr);
}
if(!mkdir($UploadDir,0774))
{ DisplayError("Could not create Upload directory",0);
return;
}
}
// Verify TRANSFER directory
if (!file_exists($TransferDir))
{ if ($LogFile)
{ $TmpStr = sprintf("%s VERIFY Transfer directory does not exist\n",
gmdate("Y-m-d H:i:s") );
// strftime("%Y-%m-%d %T"));
fwrite($LogFile, $TmpStr);
}
print( "Missing Transfer Directory: $TransferDir ");
if (!mkdir($TransferDir,0774))
{ DisplayError("Could not create Transfer directory",0);
return;
}
}
//
// Capture form values
//
$BaseName = escapeshellcmd($_POST['BaseName']);
$SequenceID = $_POST['SequenceID'];
$SCLK_SCET_File = $_POST['SCLK_SCET_File'];
$StartTimeUTC = $_POST['StartTimeUTC'];
$StopTimeUTC = $_POST['StopTimeUTC'];
$InputType = $_POST['input_type']; // SASF or PRT
$OutputType = $_POST['output_type'];// SEQ or IEB
$UserFileName = $_FILES['UploadFile']['name'];
$StartALF = $_POST['StartALF']; // 0 <= ?
$ALF_Partition = $_POST['ALF_Partition']; // DEFAULT or NON_DEFAULT
$ALF_Step = $_POST['ALF_Step']; // 4 or 8
$CAS_User = $_SERVER['REMOTE_USER'];
$HostSource = $_SERVER['REMOTE_HOST'];
//
// Debug stuff (POST data)
//
if ($debug_level > 3)
{ print( "Upload Directory: $
#32514 [Fbk->Opn]: session_start() crashes when session exists
ID: 32514
User updated by: red at raven dot ch
Reported By: red at raven dot ch
-Status: Feedback
+Status: Open
Bug Type: Session related
Operating System: Fedora Core 3
PHP Version: 5.0.3
New Comment:
Unfortunatly I am not able to write a short script which reproduces
this segfault.
(gdb) bt
#0 0x012b4aaf in zend_do_fcall_common_helper (execute_data=0xbfeed720,
opline=0x891d6dc, op_array=0x891837c)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2656
#1 0x012b5583 in zend_do_fcall_by_name_handler
(execute_data=0xbfeed720,
opline=0x891d6dc, op_array=0x891837c)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2825
#2 0x012af3ed in execute (op_array=0x891837c)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:1400
#3 0x012b4ece in zend_do_fcall_common_helper (execute_data=0xbfeed8c0,
opline=0x890cd7c, op_array=0x8949dc4)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2740
#4 0x012b5583 in zend_do_fcall_by_name_handler
(execute_data=0xbfeed8c0,
opline=0x890cd7c, op_array=0x8949dc4)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2825
#5 0x012af3ed in execute (op_array=0x8949dc4)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:1400
#6 0x012b4ece in zend_do_fcall_common_helper (execute_data=0xbfeeda00,
opline=0x85ce3f4, op_array=0x89498fc)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2740
#7 0x012b5583 in zend_do_fcall_by_name_handler
(execute_data=0xbfeeda00,
opline=0x85ce3f4, op_array=0x89498fc)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2825
#8 0x012af3ed in execute (op_array=0x89498fc)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:1400
#9 0x012b7c40 in zend_include_or_eval_handler
(execute_data=0xbfeedba0,
opline=0x8630e30, op_array=0x85d3dac)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:3565
#10 0x012af3ed in execute (op_array=0x85d3dac)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:1400
#11 0x012b4ece in zend_do_fcall_common_helper (execute_data=0xbfeedda0,
opline=0x871aec8, op_array=0x871b1d0)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2740
#12 0x012b5583 in zend_do_fcall_by_name_handler
(execute_data=0xbfeedda0,
opline=0x871aec8, op_array=0x871b1d0)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2825
#13 0x012af3ed in execute (op_array=0x871b1d0)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:1400
#14 0x0127b952 in zend_call_function (fci=0xbfeedf00, fci_cache=0x0)
at /usr/local/src/php-5.0.3/Zend/zend_execute_API.c:836
#15 0x0127a9a4 in call_user_function_ex (function_table=0x850de20,
object_pp=0x0, function_name=0xbfeedfc0, retval_ptr_ptr=0xbfeedfa8,
param_count=1, params=0xbfeedfdc, no_separation=0,
symbol_table=0x0)
at /usr/local/src/php-5.0.3/Zend/zend_execute_API.c:551
#16 0x0127be99 in zend_lookup_class (name=0x85e0224 "User",
name_length=4,
ce=0xbfeee028) at
/usr/local/src/php-5.0.3/Zend/zend_execute_API.c:928
#17 0x01225613 in php_var_unserialize (rval=0xbfeee08c, p=0xbfeee1bc,
max=0x863d0e0 "\204�217*I", var_hash=0xbfeee1a4)
at /usr/local/src/php-5.0.3/ext/standard/var_unserializer.c:488
#18 0x0122669f in process_nested_data (rval=0xbfeee1b0, p=0xbfeee1bc,
max=0x863d0e0 "\204�217*I", var_hash=0xbfeee1a4,
ht=0x863d6c4,
elements=0) at
/usr/local/src/php-5.0.3/ext/standard/var_unserializer.c:196
#19 0x01226964 in object_common2 (rval=0xbfeee1b0, p=0xbfeee1bc,
max=0x863d0e0 "\204�217*I", var_hash=0xbfeee1a4,
elements=4)
at /usr/local/src/php-5.0.3/ext/standard/var_unserializer.c:259
#20 0x01225910 in php_var_unserialize (rval=0xbfeee1b0, p=0xbfeee1bc,
max=0x863d0e0 "\204�217*I", var_hash=0xbfeee1a4)
at /usr/local/src/php-5.0.3/ext/standard/var_unserializer.c:540
#21 0x01116ad1 in ps_srlzr_decode_php (
val=0x863c82c "VidaAuth|O:8:\"VidaAuth\":4:{s:14:\"", vallen=2228)
at /usr/local/src/php-5.0.3/ext/session/session.c:509
#22 0x01116f76 in php_session_decode (
val=0x863c82c "VidaAuth|O:8:\"VidaAuth\":4:{s:14:\"", vallen=2228)
at /usr/local/src/php-5.0.3/ext/session/session.c:567
#23 0x011175b2 in php_session_initialize ()
at /usr/local/src/php-5.0.3/ext/session/session.c:748
#24 0x011195b4 in php_session_start ()
at /usr/local/src/php-5.0.3/ext/session/session.c:1195
#25 0x0111b14f in zif_session_start (ht=0, return_value=0x87122dc,
this_ptr=0x0, return_value_used=0)
#26 0x012b4d35 in zend_do_fcall_common_helper (execute_data=0xbfeee680,
opline=0x8714b88, op_array=0x85dccfc)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2711
#27 0x012b5691 in zend_do_fcall_handler (execute_data=0xbfeee680,
opline=0x8714b88, op_array=0x85dccfc)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2843
#28 0x012af3ed in execute (op_array=0x85dccfc)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:1400
#29 0x012b7c40 in zend_include_or_eval_handler
(execute_data=0xbfeeea00,
opline=0x871a6dc, op_ar
#32516 [NEW]: mkdir's recursive parameter
From: cbelin at free dot fr Operating system: Windows XP PHP version: 5.0.3 PHP Bug Type: Directory function related Bug description: mkdir's recursive parameter Description: What is the purpose of the 'recursive' parameter of the 'mkdir' function ? I expected that it allow to create a directory structure recursively but it doesn't seem to work ! -- Edit bug report at http://bugs.php.net/?id=32516&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32516&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32516&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32516&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32516&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32516&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32516&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32516&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32516&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32516&r=support Expected behavior: http://bugs.php.net/fix.php?id=32516&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32516&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32516&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32516&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32516&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32516&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32516&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32516&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32516&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32516&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32516&r=mysqlcfg
#32510 [Fbk->Bgs]: ¬ replaced with ¬
ID: 32510
Updated by: [EMAIL PROTECTED]
Reported By: jimmy dot palm at netatonce dot net
-Status: Feedback
+Status: Bogus
Bug Type: *General Issues
Operating System: Linux
PHP Version: 5.0.3
New Comment:
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 a browser issue, has nothing to do with PHP itself.
Previous Comments:
[2005-03-31 08:18:02] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
I can not reproduce this..
[2005-03-31 02:10:30] jimmy dot palm at netatonce dot net
Description:
when I write ¬, php 5.0.3 will replace it with ¬
¬ => replaces with ¬
¤ => replaces with ¤
Weird???
ex.
$currency = "EUR" ;
printf("¤cy = %s", $currency) ;
will write:
¤cy=EUR
? what is the problem ?
Expected result:
That:
$currency = "EUR" ;
printf("¤cy = %s", $currency) ;
gives output
¤cy = EUR
--
Edit this bug report at http://bugs.php.net/?id=32510&edit=1
#32517 [NEW]: Bug in HTTP_POST_VARS with checkboxes
From: crandym2003 at yahoo dot com
Operating system: Windows/Unix
PHP version: 4.3.10
PHP Bug Type: CGI related
Bug description: Bug in HTTP_POST_VARS with checkboxes
Description:
When using HTML checkboxes in an application, the checkbox is not
recognized in HTTP_POST_VARS unless it is checked. If the checkbox is
checked, the value of "customer_active" is "on", however it the checkbox
is not checked, no value exists and HTTP_POST_VARS does not recognize the
entity "customer_active".
I believe HTTP_POST_VARS should always recognize a defined HTML entity
regardless of its state (i.e., checked or unchecked)
Reproduce code:
---
if ($m['customer_active'] == 'yes') {$customer_active = 'CHECKED';
} else {
$customer_active = '';
};
print '';
print '';
print 'Activate Customer:';
print '';
print '';
print '';
print ' Cancel';
print '';
print '';
Expected result:
If the checkbox is unchecked, the value of "customer_active" should be
"off" instead of HTTP_POST_VARS reporting that it is undefined.
Actual result:
--
If the checkbox "customer_active" is checked, then
HTTP_POST_VARS['customer_active'] has a value of 'on'. If it is
unchecked, there is no defined HTTP_POST_VARS['customer_active'].
--
Edit bug report at http://bugs.php.net/?id=32517&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32517&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32517&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32517&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32517&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32517&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32517&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32517&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32517&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32517&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32517&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32517&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32517&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32517&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32517&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32517&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32517&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32517&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32517&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32517&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32517&r=mysqlcfg
#32517 [Opn->Bgs]: Bug in HTTP_POST_VARS with checkboxes
ID: 32517
Updated by: [EMAIL PROTECTED]
Reported By: crandym2003 at yahoo dot com
-Status: Open
+Status: Bogus
Bug Type: CGI related
Operating System: Windows/Unix
PHP Version: 4.3.10
New Comment:
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 a browser "feature".
Previous Comments:
[2005-03-31 16:17:53] crandym2003 at yahoo dot com
Description:
When using HTML checkboxes in an application, the checkbox is not
recognized in HTTP_POST_VARS unless it is checked. If the checkbox is
checked, the value of "customer_active" is "on", however it the
checkbox is not checked, no value exists and HTTP_POST_VARS does not
recognize the entity "customer_active".
I believe HTTP_POST_VARS should always recognize a defined HTML entity
regardless of its state (i.e., checked or unchecked)
Reproduce code:
---
if ($m['customer_active'] == 'yes') {$customer_active = 'CHECKED';
} else {
$customer_active = '';
};
print '';
print '';
print 'Activate Customer:';
print '';
print '';
print '';
print ' Cancel';
print '';
print '';
Expected result:
If the checkbox is unchecked, the value of "customer_active" should be
"off" instead of HTTP_POST_VARS reporting that it is undefined.
Actual result:
--
If the checkbox "customer_active" is checked, then
HTTP_POST_VARS['customer_active'] has a value of 'on'. If it is
unchecked, there is no defined HTTP_POST_VARS['customer_active'].
--
Edit this bug report at http://bugs.php.net/?id=32517&edit=1
#32330 [Com]: session_destroy, "Failed to initialize storage module", custom session handler
ID: 32330 Comment by: evenh+phpbug at pvv dot ntnu dot no Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Session related Operating System: * PHP Version: 4CVS, 5CVS (2005-03-17) Assigned To: sniper New Comment: I experienced this one too, but only when using tavi.sourceforge.net. This intrigued me, and I've developed a little script to give information related to this issue. The script at http://tavi.sourceforge.net/bug32330.php shows a counter which jumps around at it own free will, seemingly. This due to the changing host underneath, see changing $_SERVER['SERV_ADDR']. The script always uses /tmp, and it's always writeable, but it's not on the same computer! This could be fixed by using a common path, as is done in http://tavi.sourceforge.net/bug32330fix.php . And now the counter works, and I don't get the "Failed to initialize..."-message either. The reason for not getting the message, I've experienced, could be related to accidentially calling session_start() twice... Either in the same script, or script running in concurrent time space. Or maybe the lack of session_write_close()? Note that both the supplied script would include phpinfo() if adding "?a" (or anything at all) after the script name. The scripts will be available for some weeks. Feel free to copy them if needed... ;-) But the messages seems to have gone away, so I'm happy. For now. Regards, Even Holen Previous Comments: [2005-03-31 06:33:58] [EMAIL PROTECTED] I don't see how this relates to my problem besides the error message. I ask you guys kindly to open a new report about your specific problem. Your problem has no relation to session handler loosing when calling session_destroy. [2005-03-30 17:42:49] todd dot trann at palidar dot com RedHat 9 PHP 4.3.9 from RPM (php-4.3.9-11.rh90.art) Zend Engine 1.3.0, Optimizer 2.5.5 I am experiencing the same problem: the error indicates storage module "user", yet php.ini has it set to "files", and nowhere in my code do I change it to "user". The problem comes and goes as the page is reloaded. A PHP page with no session code does not exhibit the problem. Todd [2005-03-24 22:27:36] scliburn at trtinfo dot com mfischer, I'm positive about the session.save_handler and the session_module_name not being set anywhere. I'm emailing direct my link to my php info page. no sessions nothing on the page expect for phpinfo(); the save_handler is set to files. No joke. another test i've done was to have a copy of a website running on 2 servers (same code, same db) Server 1: Redhat php 4.3.9 Zend engine 1.3.0 - no problems Server 2: php 4.3.10 Zend Zend engine 1.3.0 Optimizer 2+ - problems [2005-03-24 21:43:44] [EMAIL PROTECTED] Do you use session_destroy in your code? Are you sure you aren't calling session_module_name somewhere? Does a clean page, with no session_start but only phpinfo in it, also tell you that the session module in use is 'user' rather then files? [2005-03-24 18:43:34] scott at trtinfo dot com scott => scliburn are one in the same :). We have not been using any custom session handlers. We have been utilizing the PHP built in session handlers. My session.save_handler all have been set to "files". I have noticed the error message still states: Fatal error: session_start(): Failed to initialize storage module: user (path: /tmp) Take notice to the module "user", however this is my php.ini (i've located and updated all instances of the php.ini); session.save_handler = files I was also unable to produce this error on another machine (win2003-webedition) which has thread saftey on. Not sure if that is helpful. This error has only produced itself after upgrading Zend 2+ on php 4.3.9, 4.3.10, & 5.03 (I cannot produce this error on 5.02 with Zend 2+) yet. I'm taking a wild non-technical quess in that the save_handler setting is obviously getting reset during a php request, but have no clue as to where. I know it's not the code calling to this. I wrote it. Zend? Heres another twist. I do have another site that is running osCommerce with custom session handlers and that site doesnot produce this error (once again, yet). odly enough 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/32330 -- Edit this bug report at http://bugs.php.net/?id=32330&edit=1
#32518 [NEW]: number_format returns -0,00
From: php at mijav dot dk Operating system: FreeBSD PHP version: 4.3.9 PHP Bug Type: Math related Bug description: number_format returns -0,00 Description: Tthe number -0,00 is non-existent and inconsistent, pointed out in a duplicate bug report, and therefore the output is jibberish. If you do a number_format(round($foo,2), 2, ",", "."); then the output will be correct/as expected. This is also why number_format should be considered buggy. If number_format rounds before formatting, it should be consistent: -0,00 isn't consistent since -0,505 gets rounded to -0,51. Please re-evaluate the situation. The output -0,00 is not useful. Please note that our production server uses 4.3.8, but the Changelog reports nothing about a fix, and the previous bug report was marked Bogus. Reproduce code: --- Expected result: 0,00 Actual result: -- -0,00 -- Edit bug report at http://bugs.php.net/?id=32518&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32518&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32518&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32518&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32518&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32518&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32518&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32518&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32518&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32518&r=support Expected behavior: http://bugs.php.net/fix.php?id=32518&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32518&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32518&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32518&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32518&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32518&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32518&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32518&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32518&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32518&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32518&r=mysqlcfg
#32483 [Fbk->Opn]: ./configure check crashes
ID: 32483 User updated by: pieter dot donche at ua dot ac dot be Reported By: pieter dot donche at ua dot ac dot be -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: solaris 2.9 PHP Version: 5CVS-2005-03-30 New Comment: I have installed OpenSSL for the first time on Jan 28, 2004 (version 0.0.6l), and then on May 25, 2004 the version 0.9.7d both with --openssldir=/usr/local Yesterday(see above) I reinstalled 0.9.7d with no options in its .configure, so that it installs in its default place /usr/local/ssl. The problems exist already much longer than yesterday.. I also see I have a /usr/local/md5 directory, which was in 2002, installed to check fingerprints of Solaris binaries because we had had an intrusion. The tool was supplied by SUN. Previous Comments: [2005-03-31 00:05:16] [EMAIL PROTECTED] Do you have many OpenSSL versions installed? Make sure you have exactly ONE version only. And that the libraries/headers match each other. [2005-03-30 17:40:14] pieter dot donche at ua dot ac dot be checking for standard DES.. yes ... no **ATTENTION** message make starts and completes without crashing BTW In previous case where the standard DES was not found, it still always was possible to do a make of php that did complete without crasjing, but when doing a make install it always crashed at Installing PEAR environment. I had the same problem with apache-1.3 and php-4.3.10 [2005-03-30 17:20:25] [EMAIL PROTECTED] Try this: # rm -f config.cache # ./configure --disable-all --disable-cgi && make [2005-03-30 17:16:41] pieter dot donche at ua dot ac dot be The problem describes below seems to occur when using the --with-ldap=/usr/local option. During the ./configure I see ... checking for standard DES crypt... no checking for extended DES crypt... no chekcing for MD5 crypt... no Segmentation fault - core dumped ... And an **ATTENTION** message at the end, stating thet "Something is likely to be mesed up gere, ..." When leaving out --with-ldap The line about standard DES is yes: checking for standard DES... yes I had openSSL installed in /usr/local, which is different from the default /usr/local/ssl. I tried with adding --with-openssl=/usr/local --> SAME PROBLEM Then installed openSSL again, now using the default install /usr/local/ssl, did PHP configure again without a --with-openssl line --> SAME PROBLEM with a --with-openssl=/usr/local/ssl --> SAME PROBLEM Waht is going on ? Why does PHP configure nog succeed in finding standard DES ? [2005-03-30 08:58:12] pieter dot donche at ua dot ac dot be dowloaded php5-latest.tar.gz ( php5-200503300630 ) exactly the same results. Pieter 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/32483 -- Edit this bug report at http://bugs.php.net/?id=32483&edit=1
#32521 [NEW]: apache2handler accidental crashes caused by SPL
From: su1d at phpclub dot net Operating system: Win32 PHP version: 5CVS-2005-03-31 (dev) PHP Bug Type: Reproducible crash Bug description: apache2handler accidental crashes caused by SPL Description: OS: Windows XP Pro (SP1, Eng) PHP: 5.1-dev Apache: 2.0.53 When PHP is installed as Apache's module, the web server sometimes segfaults accidentally. The call stack backtrace is the following: php5ts.dll!_estrdup(const char * s=0x00d4b8d8) Line 400 + 0xf bytesC php5ts.dll!zm_activate_spl(int type=11, int module_number=18392672, void * * * tsrm_ls=0x00d4b8a8) Line 510 + 0x19 bytes C php5ts.dll!module_registry_request_startup(_zend_module_entry * module=0x0118a660, void * * * tsrm_ls=0x0533fe10) Line 1543 + 0x10 bytes C php5ts.dll!zend_hash_apply(_hashtable * ht=0x007061c0, int (void *, void * * *)* apply_func=0x0118a660, void * * * tsrm_ls=0x007d9f0a) Line 664 + 0x7 bytes C php5ts.dll!zend_activate_modules(void * * * tsrm_ls=0x0118a660) Line 793 + 0x14 bytesC php5ts.dll!php_request_startup(void * * * tsrm_ls=0x0118a660) Line 1058C php5apache2.dll!php_handler(request_rec * r=0x0065ef40) Line 534 + 0x8 bytes C [...] Obviously, the crash occurs directly in Zend/zend_alloc.c:400 inside of the function _estrdup() which is in turn called from ext/spl/php_spl.c:510. That seems to be a Windows specific behaviour, so a tiny patch is being proposed to fix the problem. The patch could be downloaded from http://tmp.e-taller.net/php_spl.c-win32.patch Reproduce code: --- Any PHP application, i.e. entering to phpMyAdmin always leads to a crash. Expected result: no segfaults Actual result: -- *oops* -- Edit bug report at http://bugs.php.net/?id=32521&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32521&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32521&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32521&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32521&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32521&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32521&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32521&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32521&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32521&r=support Expected behavior: http://bugs.php.net/fix.php?id=32521&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32521&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32521&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32521&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32521&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32521&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32521&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32521&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32521&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32521&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32521&r=mysqlcfg
#32521 [Opn->Asn]: apache2handler accidental crashes caused by SPL
ID: 32521 Updated by: [EMAIL PROTECTED] Reported By: su1d at phpclub dot net -Status: Open +Status: Assigned Bug Type: Reproducible crash Operating System: Win32 PHP Version: 5CVS-2005-03-31 (dev) -Assigned To: +Assigned To: helly Previous Comments: [2005-03-31 19:05:26] su1d at phpclub dot net Description: OS: Windows XP Pro (SP1, Eng) PHP: 5.1-dev Apache: 2.0.53 When PHP is installed as Apache's module, the web server sometimes segfaults accidentally. The call stack backtrace is the following: php5ts.dll!_estrdup(const char * s=0x00d4b8d8) Line 400 + 0xf bytesC php5ts.dll!zm_activate_spl(int type=11, int module_number=18392672, void * * * tsrm_ls=0x00d4b8a8) Line 510 + 0x19 bytes C php5ts.dll!module_registry_request_startup(_zend_module_entry * module=0x0118a660, void * * * tsrm_ls=0x0533fe10) Line 1543 + 0x10 bytes C php5ts.dll!zend_hash_apply(_hashtable * ht=0x007061c0, int (void *, void * * *)* apply_func=0x0118a660, void * * * tsrm_ls=0x007d9f0a) Line 664 + 0x7 bytesC php5ts.dll!zend_activate_modules(void * * * tsrm_ls=0x0118a660) Line 793 + 0x14 bytesC php5ts.dll!php_request_startup(void * * * tsrm_ls=0x0118a660) Line 1058C php5apache2.dll!php_handler(request_rec * r=0x0065ef40) Line 534 + 0x8 bytes C [...] Obviously, the crash occurs directly in Zend/zend_alloc.c:400 inside of the function _estrdup() which is in turn called from ext/spl/php_spl.c:510. That seems to be a Windows specific behaviour, so a tiny patch is being proposed to fix the problem. The patch could be downloaded from http://tmp.e-taller.net/php_spl.c-win32.patch Reproduce code: --- Any PHP application, i.e. entering to phpMyAdmin always leads to a crash. Expected result: no segfaults Actual result: -- *oops* -- Edit this bug report at http://bugs.php.net/?id=32521&edit=1
#32521 [Asn->Csd]: apache2handler accidental crashes caused by SPL
ID: 32521 Updated by: [EMAIL PROTECTED] Reported By: su1d at phpclub dot net -Status: Assigned +Status: Closed Bug Type: Reproducible crash -Operating System: Win32 +Operating System: * PHP Version: 5CVS-2005-03-31 (dev) Assigned To: helly New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-03-31 19:05:26] su1d at phpclub dot net Description: OS: Windows XP Pro (SP1, Eng) PHP: 5.1-dev Apache: 2.0.53 When PHP is installed as Apache's module, the web server sometimes segfaults accidentally. The call stack backtrace is the following: php5ts.dll!_estrdup(const char * s=0x00d4b8d8) Line 400 + 0xf bytesC php5ts.dll!zm_activate_spl(int type=11, int module_number=18392672, void * * * tsrm_ls=0x00d4b8a8) Line 510 + 0x19 bytes C php5ts.dll!module_registry_request_startup(_zend_module_entry * module=0x0118a660, void * * * tsrm_ls=0x0533fe10) Line 1543 + 0x10 bytes C php5ts.dll!zend_hash_apply(_hashtable * ht=0x007061c0, int (void *, void * * *)* apply_func=0x0118a660, void * * * tsrm_ls=0x007d9f0a) Line 664 + 0x7 bytesC php5ts.dll!zend_activate_modules(void * * * tsrm_ls=0x0118a660) Line 793 + 0x14 bytesC php5ts.dll!php_request_startup(void * * * tsrm_ls=0x0118a660) Line 1058C php5apache2.dll!php_handler(request_rec * r=0x0065ef40) Line 534 + 0x8 bytes C [...] Obviously, the crash occurs directly in Zend/zend_alloc.c:400 inside of the function _estrdup() which is in turn called from ext/spl/php_spl.c:510. That seems to be a Windows specific behaviour, so a tiny patch is being proposed to fix the problem. The patch could be downloaded from http://tmp.e-taller.net/php_spl.c-win32.patch Reproduce code: --- Any PHP application, i.e. entering to phpMyAdmin always leads to a crash. Expected result: no segfaults Actual result: -- *oops* -- Edit this bug report at http://bugs.php.net/?id=32521&edit=1
#32508 [Fbk->Opn]: ob_gzhandler w/ chunking can crash Apache 2
ID: 32508 User updated by: myronwu at gmail dot com Reported By: myronwu at gmail dot com -Status: Feedback +Status: Open Bug Type: Output Control -Operating System: Linux 2.4 +Operating System: Linux 2.4 + Mac OS X PHP Version: 5.0.3 New Comment: Pretty convinced this occurs whenever chunking occurs, irrespective of what the chunk size is. Setting it to something silly like 1 also has the same problem, for example. I also confirmed again the same behaviour on a Mac OS X (10.3.8) machine, with its default php 4.3.10 setup over Apache 1.3.33, zlib 1.1.4. Configure command is just what's default on os x, but if you don't have an os x machine handy, it's: '/SourceCache/apache_mod_php/apache_mod_php-17.5/php/ configure' '--prefix=/usr' '--mandir=/usr/share/man' '-- infodir=/usr/share/info' '--with-apxs' '--with-ldap=/ usr' '--with-kerberos=/usr' '--enable-cli' '--with-zlib- dir=/usr' '--enable-trans-sid' '--with-xml' '--enable- exif' '--enable-ftp' '--enable-mbstring' '--enable- mbregex' '--enable-dbx' '--enable-sockets' '--with- iodbc=/usr' '--with-curl=/usr' '--with-config-file- path=/etc' '--sysconfdir=/private/etc' The php.ini is untouched from defaults. Previous Comments: [2005-03-31 09:34:17] [EMAIL PROTECTED] You can always make the chunk size smaller than 2048? Or doesn't this problem occur then? [2005-03-31 08:33:29] myronwu at gmail dot com Sorry, it's my sysadmin that set up those configure variables Anyway, we used phpinfo() for example code because it outputs something larger than the example chunk size I was using of 2048 bytes. I could manually write out more than 2048, but that probably wouldn't be as concise for bug reporting. The problem we have specifically arises when the ob_gzhandler attempts to send out chunks. [2005-03-31 08:20:56] [EMAIL PROTECTED] Does it only happen when you have phpinfo() in there? (I'd put something else between there..) Also, try doing ./configure --help sometimes. You have several options used that don't even exist. Like --enable-track-vars, --with-apache2.. [2005-03-31 02:15:34] myronwu at gmail dot com Reconfirmed the bug using the reproduce code on CVS snapshot php5-STABLE-200503302230, configure command: './configure' '--with-mysqli=/usr/local/mysql/bin/mysql_config' '--with-mysql=/usr/local/mysql' '--with-apache2=/usr/src/apache/httpd-2.0.53' '--enable-yp' '--enable-track-vars' '--with-zlib' '--with-jpeg' '--with-png' '--with-tiff' '--with-pdflib' '--with-gd' '--with-apxs2=/var/www/bin/apxs' '--with-gettext' '--with-pspell' Otherwise same setup as reported above. [2005-03-30 22:44:12] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/32508 -- Edit this bug report at http://bugs.php.net/?id=32508&edit=1
#32508 [Opn]: ob_gzhandler w/ chunking can crash Apache 2
ID: 32508
User updated by: myronwu at gmail dot com
Reported By: myronwu at gmail dot com
Status: Open
Bug Type: Output Control
Operating System: Linux 2.4 + Mac OS X
PHP Version: 5.0.3
New Comment:
Let me clarify some more, here's some more ob_start
calls that you can substitute into the reproduce code
given:
These work OK:
ob_start();
ob_start(null, 2048);
ob_start(null, 1024);
ob_start('ob_gzhandler');
These don't work:
ob_start('ob_gzhandler', 1024);
ob_start('ob_gzhandler', 2048);
ob_start('ob_gzhandler', 1);
Previous Comments:
[2005-03-31 19:22:10] myronwu at gmail dot com
Pretty convinced this occurs whenever chunking occurs,
irrespective of what the chunk size is. Setting it to
something silly like 1 also has the same problem, for
example.
I also confirmed again the same behaviour on a Mac OS X
(10.3.8) machine, with its default php 4.3.10 setup over
Apache 1.3.33, zlib 1.1.4. Configure command is just
what's default on os x, but if you don't have an os x
machine handy, it's:
'/SourceCache/apache_mod_php/apache_mod_php-17.5/php/
configure' '--prefix=/usr' '--mandir=/usr/share/man' '--
infodir=/usr/share/info' '--with-apxs' '--with-ldap=/
usr' '--with-kerberos=/usr' '--enable-cli' '--with-zlib-
dir=/usr' '--enable-trans-sid' '--with-xml' '--enable-
exif' '--enable-ftp' '--enable-mbstring' '--enable-
mbregex' '--enable-dbx' '--enable-sockets' '--with-
iodbc=/usr' '--with-curl=/usr' '--with-config-file-
path=/etc' '--sysconfdir=/private/etc'
The php.ini is untouched from defaults.
[2005-03-31 09:34:17] [EMAIL PROTECTED]
You can always make the chunk size smaller than 2048?
Or doesn't this problem occur then?
[2005-03-31 08:33:29] myronwu at gmail dot com
Sorry, it's my sysadmin that set up those
configure variables
Anyway, we used phpinfo() for example code because it
outputs something larger than the example chunk size I
was using of 2048 bytes. I could manually write out
more than 2048, but that probably wouldn't be as concise
for bug reporting.
The problem we have specifically arises when the
ob_gzhandler attempts to send out chunks.
[2005-03-31 08:20:56] [EMAIL PROTECTED]
Does it only happen when you have phpinfo() in there?
(I'd put something else between there..)
Also, try doing ./configure --help sometimes. You have several options
used that don't even exist. Like --enable-track-vars, --with-apache2..
[2005-03-31 02:15:34] myronwu at gmail dot com
Reconfirmed the bug using the reproduce code on CVS snapshot
php5-STABLE-200503302230, configure command:
'./configure' '--with-mysqli=/usr/local/mysql/bin/mysql_config'
'--with-mysql=/usr/local/mysql'
'--with-apache2=/usr/src/apache/httpd-2.0.53' '--enable-yp'
'--enable-track-vars' '--with-zlib' '--with-jpeg' '--with-png'
'--with-tiff' '--with-pdflib' '--with-gd'
'--with-apxs2=/var/www/bin/apxs' '--with-gettext' '--with-pspell'
Otherwise same setup as reported above.
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/32508
--
Edit this bug report at http://bugs.php.net/?id=32508&edit=1
#32491 [Opn]: File upload error - unable to create a temporary file
ID: 32491
User updated by: Oscar dot Castillo at jpl dot nasa dot gov
Reported By: Oscar dot Castillo at jpl dot nasa dot gov
Status: Open
Bug Type: iPlanet related
Operating System: Solaris 9
PHP Version: 5CVS-2005-03-31
New Comment:
I have 3 web server environments setup with the same version of PHP, a
development environment, a test environment and a production
environment. Your description of the common Solaris /iPlanet problem
explains why the same PHP script works well in the development and test
environment, but not the production environment. I do have Java enabled
on all 3 web server environments, but the only difference is that our
production is obviously much more heavily utilized than the test and
development environment. I thank you very much for the explanation.
Since Java is required on our web servers, I obviously cannot disable
Java. I will try loading the fastcgi API. I'll keep you posted.
Previous Comments:
[2005-03-31 11:17:11] [EMAIL PROTECTED]
Again the old STDIO problem: There are some places in PHP where the C
library stdio functions are used instead of posix io (popen in all
excute functions/sendmail functions, uploading of temporary files, some
3rd party extensions). Under Solaris with the AT&T libc stdio is limited
to 255 file descriptors, if the current posix file descriptor gets
larger than 255 all further fopens or fdopens fail because the field in
the FILE* struct is a unsigned char. Using Posix IO has no limit here
(descriptor is int).
There are 2 solutions:
a) limiting the accepting threads in sunone/iplanet and disabling java
in webserver completely (java is very descriptor intensive ->
descriptors for PHP get > 255)
b) using PHP as CGI/FastCGI (look for Sun PHP enabler at zend.com) or
my CGI enabler: http://www.thetaphi.de/php-ressources/
Changing this in PHP is a heavy task, the zend engine itsself is safe
since 4.3.3, other parts should be changed in the future to POSIX IO.
This is a Solaris problem which gets important in a multithreaded and
heavy file descriptor using webserver like sunone/iplanet
[2005-03-31 01:16:53] Oscar dot Castillo at jpl dot nasa dot gov
So changing the Category of problem to "iPlanet related" means what? Do
I have to open a bug report with Sun for this problem? Please help.
[2005-03-29 21:55:27] Oscar dot Castillo at jpl dot nasa dot gov
Description:
I am using iPlanet 6.0 SP5, Zend 2.5.7 and PHP 5.0.3 on a 64 bit
Solaris 9 SunFire V880 (4x4GHz CPU, 8Gb RAM). I have a problem with an
HTTP POST command that attempts to upload a file onto the web server
and a consistent "File upload error - unable to create a temporary file
in Unknown on line 0" error message appears in the error logs. The
upload_tmp_dir directory is set to /tmp. The error message disappears
with a web server daemon reset (stop/start the web server daemon), but
the error begins to occur within 2 to 24 hours again. When the errors
occur, the /tmp directory begins to accumulate with php[web_server_pid]
files that are zero bytes in size. My upload_max_filesize parameter is
configured to 2Mb, however the uploaded files are never above 50kb.
I've tried many suggested fixes from the php.net bug reports area, but
to no avail. Thanks in advance for your help!
Reproduce code:
---
9) { phpinfo(); }
//
// Configurable variables
//
$BaseDir = './';
$LogFileName = $BaseDir . "RTIU_translator.log";
$SCLK_SCET_Dir = "/afs/jpl/group/casops/dom/data/main/sclkscet/"; //
placed in executed shell script
$UploadDir = $BaseDir . "Temp/" ; // Where the posted files
are
placed
$TransferDir = $BaseDir . "Xfer/";// Where the tar file for the
translator is created
//
// Verify resources are available
//
$LogFile = fopen( $LogFileName,'a');
if (! $LogFile)
{ print("Logging is disabled, please save all displayed messages if
help is needed from IO support");
}
// Verify UPLOAD directory
if (!file_exists($UploadDir))
{ if ($LogFile)
{ $TmpStr = sprintf("%s VERIFY Upload directory does not exist\n",
gmdate("Y-m-d H:i:s") );
// strftime("%Y-%m-%d %T"));
fwrite($LogFile, $TmpStr);
}
if(!mkdir($UploadDir,0774))
{ DisplayError("Could not create Upload directory",0);
return;
}
}
// Verify TRANSFER directory
if (!file_exists($TransferDir))
{ if ($LogFile)
{ $TmpStr = sprintf("%s VERIFY Transfer directory does not exist\n",
gmdate("Y-m-d H:i:s") );
// strftime("%Y-%m-%d %T"));
fwrite($LogFile, $TmpStr);
}
print( "Missing Transfer Directory: $TransferDir ");
if (!mkdir($TransferDir,0774))
{ DisplayError("Could not create
#32516 [Opn->Fbk]: mkdir's recursive parameter
ID: 32516 Updated by: [EMAIL PROTECTED] Reported By: cbelin at free dot fr -Status: Open +Status: Feedback Bug Type: Directory function related Operating System: Windows XP PHP Version: 5.0.3 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Previous Comments: [2005-03-31 15:41:15] cbelin at free dot fr Description: What is the purpose of the 'recursive' parameter of the 'mkdir' function ? I expected that it allow to create a directory structure recursively but it doesn't seem to work ! -- Edit this bug report at http://bugs.php.net/?id=32516&edit=1
#32514 [Opn->Fbk]: session_start() crashes when session exists
ID: 32514
Updated by: [EMAIL PROTECTED]
Reported By: red at raven dot ch
-Status: Open
+Status: Feedback
Bug Type: Session related
Operating System: Fedora Core 3
PHP Version: 5.0.3
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Previous Comments:
[2005-03-31 11:43:43] red at raven dot ch
Unfortunatly I am not able to write a short script which reproduces
this segfault.
(gdb) bt
#0 0x012b4aaf in zend_do_fcall_common_helper (execute_data=0xbfeed720,
opline=0x891d6dc, op_array=0x891837c)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2656
#1 0x012b5583 in zend_do_fcall_by_name_handler
(execute_data=0xbfeed720,
opline=0x891d6dc, op_array=0x891837c)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2825
#2 0x012af3ed in execute (op_array=0x891837c)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:1400
#3 0x012b4ece in zend_do_fcall_common_helper (execute_data=0xbfeed8c0,
opline=0x890cd7c, op_array=0x8949dc4)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2740
#4 0x012b5583 in zend_do_fcall_by_name_handler
(execute_data=0xbfeed8c0,
opline=0x890cd7c, op_array=0x8949dc4)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2825
#5 0x012af3ed in execute (op_array=0x8949dc4)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:1400
#6 0x012b4ece in zend_do_fcall_common_helper (execute_data=0xbfeeda00,
opline=0x85ce3f4, op_array=0x89498fc)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2740
#7 0x012b5583 in zend_do_fcall_by_name_handler
(execute_data=0xbfeeda00,
opline=0x85ce3f4, op_array=0x89498fc)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2825
#8 0x012af3ed in execute (op_array=0x89498fc)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:1400
#9 0x012b7c40 in zend_include_or_eval_handler
(execute_data=0xbfeedba0,
opline=0x8630e30, op_array=0x85d3dac)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:3565
#10 0x012af3ed in execute (op_array=0x85d3dac)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:1400
#11 0x012b4ece in zend_do_fcall_common_helper (execute_data=0xbfeedda0,
opline=0x871aec8, op_array=0x871b1d0)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2740
#12 0x012b5583 in zend_do_fcall_by_name_handler
(execute_data=0xbfeedda0,
opline=0x871aec8, op_array=0x871b1d0)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2825
#13 0x012af3ed in execute (op_array=0x871b1d0)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:1400
#14 0x0127b952 in zend_call_function (fci=0xbfeedf00, fci_cache=0x0)
at /usr/local/src/php-5.0.3/Zend/zend_execute_API.c:836
#15 0x0127a9a4 in call_user_function_ex (function_table=0x850de20,
object_pp=0x0, function_name=0xbfeedfc0, retval_ptr_ptr=0xbfeedfa8,
param_count=1, params=0xbfeedfdc, no_separation=0,
symbol_table=0x0)
at /usr/local/src/php-5.0.3/Zend/zend_execute_API.c:551
#16 0x0127be99 in zend_lookup_class (name=0x85e0224 "User",
name_length=4,
ce=0xbfeee028) at
/usr/local/src/php-5.0.3/Zend/zend_execute_API.c:928
#17 0x01225613 in php_var_unserialize (rval=0xbfeee08c, p=0xbfeee1bc,
max=0x863d0e0 "\204�217*I", var_hash=0xbfeee1a4)
at /usr/local/src/php-5.0.3/ext/standard/var_unserializer.c:488
#18 0x0122669f in process_nested_data (rval=0xbfeee1b0, p=0xbfeee1bc,
max=0x863d0e0 "\204�217*I", var_hash=0xbfeee1a4,
ht=0x863d6c4,
elements=0) at
/usr/local/src/php-5.0.3/ext/standard/var_unserializer.c:196
#19 0x01226964 in object_common2 (rval=0xbfeee1b0, p=0xbfeee1bc,
max=0x863d0e0 "\204�217*I", var_hash=0xbfeee1a4,
elements=4)
at /usr/local/src/php-5.0.3/ext/standard/var_unserializer.c:259
#20 0x01225910 in php_var_unserialize (rval=0xbfeee1b0, p=0xbfeee1bc,
max=0x863d0e0 "\204�217*I", var_hash=0xbfeee1a4)
at /usr/local/src/php-5.0.3/ext/standard/var_unserializer.c:540
#21 0x01116ad1 in ps_srlzr_decode_php (
val=0x863c82c "VidaAuth|O:8:\"VidaAuth\":4:{s:14:\"", vallen=2228)
at /usr/local/src/php-5.0.3/ext/session/session.c:509
#22 0x01116f76 in php_session_decode (
val=0x863c82c "VidaAuth|O:8:\"VidaAuth\":4:{s:14:\"", vallen=2228)
at /usr/local/src/php-5.0.3/ext/session/session.c:567
#23 0x011175b2 in php_session_initialize ()
at /usr/local/src/php-5.0.3/ext/session/session.c:748
#24 0x011195b4 in php_session_start ()
at /usr/local/src/php-5.0.3/ext/session/session.c:1195
#25 0x0111b14f in zif_session_start (ht=0, return_value=0x87122dc,
this_ptr=0x0, return_value_used=0)
#26 0x012b4d35 in zend_do_fcall_common_helper (execute_data=0xbfeee680,
opline=0x8714b88, op_array=0x85dccfc)
at /usr/local/src/php-5.0.3/Zend/zend_execute.c:2711
#27 0x012b5691 in zend_do_fcall_handler (execute_data=0xbfeee680,
opline=0x8714b8
#32519 [Opn->Bgs]: cli segv with https wrapper
ID: 32519
Updated by: [EMAIL PROTECTED]
Reported By: mark at everytruckjob dot com
-Status: Open
+Status: Bogus
-Bug Type: Reproducible crash
+Bug Type: Verisign Payflow Pro related
Operating System: slackware 10.1 glibc 2.3.4
PHP Version: 5CVS-2005-03-31 (dev)
New Comment:
RTFM: http://www.php.net/pfpro
Not PHP bug.
Previous Comments:
[2005-03-31 17:53:52] mark at everytruckjob dot com
Description:
The reproducable code worked using cli with php 5.0.3 but causes a
segmentation fault with 5.0.4 and php5-200503311430.
The http wrapper still works fine.
The same code works under apache2 with all versions.
I recompiled php 5.0.4 without the pfpro extension (the backtrace made
me want to try this) and no segfault occured, so maybe some changes
with the https wrapper is conflicting with the pfpro extension (which
hasn't had any changes committed in 10 months)?
Reproduce code:
---
$contents = file_get_contents("https://www.glo-bus.com/";);
// OR
$contents = file("https://www.glo-bus.com/";);
Expected result:
$contents would contain the contents of the url requested.
Actual result:
--
php 5.0.4 backtrace:
http://www.tuscaloosadesigncompany.com/php-5.0.4-bt.txt
php5-200503311430 backtrace:
http://www.tuscaloosadesigncompany.com/php5-200503311430.bt.txt
--
Edit this bug report at http://bugs.php.net/?id=32519&edit=1
#32508 [Opn->Ver]: ob_gzhandler w/ chunking can crash Apache 2
ID: 32508
Updated by: [EMAIL PROTECTED]
Reported By: myronwu at gmail dot com
-Status: Open
+Status: Verified
Bug Type: Output Control
-Operating System: Linux 2.4 + Mac OS X
+Operating System: *
-PHP Version: 5.0.3
+PHP Version: 4CVS, 5CVS (2005-03-31)
New Comment:
Nobody should try this at home. :)
Definately eats all memory and eventually crashes.
Here's what I got in error_log:
PHP Fatal error: Allowed memory size of 1603177144 bytes exhausted at
/usr/src/php/php5/ext/zlib/zlib.c:623
Previous Comments:
[2005-03-31 19:27:56] myronwu at gmail dot com
Let me clarify some more, here's some more ob_start
calls that you can substitute into the reproduce code
given:
These work OK:
ob_start();
ob_start(null, 2048);
ob_start(null, 1024);
ob_start('ob_gzhandler');
These don't work:
ob_start('ob_gzhandler', 1024);
ob_start('ob_gzhandler', 2048);
ob_start('ob_gzhandler', 1);
[2005-03-31 19:22:10] myronwu at gmail dot com
Pretty convinced this occurs whenever chunking occurs,
irrespective of what the chunk size is. Setting it to
something silly like 1 also has the same problem, for
example.
I also confirmed again the same behaviour on a Mac OS X
(10.3.8) machine, with its default php 4.3.10 setup over
Apache 1.3.33, zlib 1.1.4. Configure command is just
what's default on os x, but if you don't have an os x
machine handy, it's:
'/SourceCache/apache_mod_php/apache_mod_php-17.5/php/
configure' '--prefix=/usr' '--mandir=/usr/share/man' '--
infodir=/usr/share/info' '--with-apxs' '--with-ldap=/
usr' '--with-kerberos=/usr' '--enable-cli' '--with-zlib-
dir=/usr' '--enable-trans-sid' '--with-xml' '--enable-
exif' '--enable-ftp' '--enable-mbstring' '--enable-
mbregex' '--enable-dbx' '--enable-sockets' '--with-
iodbc=/usr' '--with-curl=/usr' '--with-config-file-
path=/etc' '--sysconfdir=/private/etc'
The php.ini is untouched from defaults.
[2005-03-31 09:34:17] [EMAIL PROTECTED]
You can always make the chunk size smaller than 2048?
Or doesn't this problem occur then?
[2005-03-31 08:33:29] myronwu at gmail dot com
Sorry, it's my sysadmin that set up those
configure variables
Anyway, we used phpinfo() for example code because it
outputs something larger than the example chunk size I
was using of 2048 bytes. I could manually write out
more than 2048, but that probably wouldn't be as concise
for bug reporting.
The problem we have specifically arises when the
ob_gzhandler attempts to send out chunks.
[2005-03-31 08:20:56] [EMAIL PROTECTED]
Does it only happen when you have phpinfo() in there?
(I'd put something else between there..)
Also, try doing ./configure --help sometimes. You have several options
used that don't even exist. Like --enable-track-vars, --with-apache2..
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/32508
--
Edit this bug report at http://bugs.php.net/?id=32508&edit=1
#32508 [Ver]: ob_gzhandler w/ chunking can crash Apache 2
ID: 32508
Updated by: [EMAIL PROTECTED]
Reported By: myronwu at gmail dot com
Status: Verified
Bug Type: Output Control
Operating System: *
PHP Version: 4CVS, 5CVS (2005-03-31)
New Comment:
Also this was there:
PHP Fatal error: Allowed memory size of 725463920 bytes exhausted at
/usr/src/php/php5/main/output.c:229
Previous Comments:
[2005-03-31 21:12:50] [EMAIL PROTECTED]
Nobody should try this at home. :)
Definately eats all memory and eventually crashes.
Here's what I got in error_log:
PHP Fatal error: Allowed memory size of 1603177144 bytes exhausted at
/usr/src/php/php5/ext/zlib/zlib.c:623
[2005-03-31 19:27:56] myronwu at gmail dot com
Let me clarify some more, here's some more ob_start
calls that you can substitute into the reproduce code
given:
These work OK:
ob_start();
ob_start(null, 2048);
ob_start(null, 1024);
ob_start('ob_gzhandler');
These don't work:
ob_start('ob_gzhandler', 1024);
ob_start('ob_gzhandler', 2048);
ob_start('ob_gzhandler', 1);
[2005-03-31 19:22:10] myronwu at gmail dot com
Pretty convinced this occurs whenever chunking occurs,
irrespective of what the chunk size is. Setting it to
something silly like 1 also has the same problem, for
example.
I also confirmed again the same behaviour on a Mac OS X
(10.3.8) machine, with its default php 4.3.10 setup over
Apache 1.3.33, zlib 1.1.4. Configure command is just
what's default on os x, but if you don't have an os x
machine handy, it's:
'/SourceCache/apache_mod_php/apache_mod_php-17.5/php/
configure' '--prefix=/usr' '--mandir=/usr/share/man' '--
infodir=/usr/share/info' '--with-apxs' '--with-ldap=/
usr' '--with-kerberos=/usr' '--enable-cli' '--with-zlib-
dir=/usr' '--enable-trans-sid' '--with-xml' '--enable-
exif' '--enable-ftp' '--enable-mbstring' '--enable-
mbregex' '--enable-dbx' '--enable-sockets' '--with-
iodbc=/usr' '--with-curl=/usr' '--with-config-file-
path=/etc' '--sysconfdir=/private/etc'
The php.ini is untouched from defaults.
[2005-03-31 09:34:17] [EMAIL PROTECTED]
You can always make the chunk size smaller than 2048?
Or doesn't this problem occur then?
[2005-03-31 08:33:29] myronwu at gmail dot com
Sorry, it's my sysadmin that set up those
configure variables
Anyway, we used phpinfo() for example code because it
outputs something larger than the example chunk size I
was using of 2048 bytes. I could manually write out
more than 2048, but that probably wouldn't be as concise
for bug reporting.
The problem we have specifically arises when the
ob_gzhandler attempts to send out chunks.
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/32508
--
Edit this bug report at http://bugs.php.net/?id=32508&edit=1
#32512 [Opn->Fbk]: flush() does not work after sending Location header
ID: 32512
Updated by: [EMAIL PROTECTED]
Reported By: kulakov74 at yandex dot ru
-Status: Open
+Status: Feedback
Bug Type: Output Control
Operating System: Linux, Win 2000
PHP Version: 4.3.9
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
I can NOT reproduce this with latest CVS (tested PHP_4_3 / HEAD
branches)
Previous Comments:
[2005-03-31 10:32:10] kulakov74 at yandex dot ru
Description:
We want a script to make a redirect and then make some Sql-queries, so
that the user would not wait for the queries to execute (sometimes they
may take too long). I added
echo("-"); flush();
after sending the Location header which made PHP send the header
immediately away, but the problem is IE does not make the redirect as
soon as it gets the header - probably it expects other headers or a
page, so it only redirects after the script completes. If I add more
output after that and a flush() call then PHP won't output anything
else until the script completes. This is emulated with a sleep(3) call.
More precisely, PHP only sends headers immediately, it doesn't send
anything else (the dash in this case).
Reproduce code:
---
//This is the redirect
header("Location: http://hotelsys.biz/hotels/Bali";);
//This is how I force PHP to send it right away
echo("-"); flush();
//This is how I cannot make PHP send anything else
echo(str_repeat("-", 1024*16)); flush();
//Pause emulation
sleep(3);
//the end - this is when the browser gets the output
exit;
Expected result:
The first "-" character and the next 16K of it sent right away.
Actual result:
--
I only get dashes in 3 seconds; the browser (IE) makes the redirect in
this time too.
--
Edit this bug report at http://bugs.php.net/?id=32512&edit=1
#32522 [Bgs]: String offsets REALLY weird
ID: 32522
User updated by: php at alterego dot dp dot ua
Reported By: php at alterego dot dp dot ua
Status: Bogus
Bug Type: Strings related
Operating System: FreeBSD 4.10
PHP Version: 5.0.3
New Comment:
I do not expect PHP5 to be PHP4. I just expect it to be consistent in
some way.
Would you please be so kind as to give me a gentle hint of what is
wrong with $a{0}{0} (CURLY BRACES).
Thanks!
Previous Comments:
[2005-03-31 21:56:04] [EMAIL PROTECTED]
If it worked in PHP4, it doesn't mean it will work in PHP 5 where it's
behaving like it should have behaved in PHP 4 too..
And $a[0][0] is not same as when you assign it first..
[2005-03-31 21:49:15] php at alterego dot dp dot ua
Description:
Strings offsets in PHP5 are broken strangely. Seems like repeated
offsets are not allowed at all, even at the times where they make good
sense.
I see nothing fatal in $a[0][0] or even $a{0}{0} or even $a[0]{0}[0] if
$a is a non-empty string. And PHP5 just crashes at any one of them.
Why $a{0} can't be a string without extra intermediate assignment?
Please, look at the code before marking bogus.
Reproduce code:
---
Expected result:
00
Actual result:
--
0
Fatal error: Cannot use string offset as an array in /www/test.php on
line 8
--
Edit this bug report at http://bugs.php.net/?id=32522&edit=1
#31989 [Fbk->Csd]: Xmlrpc 'infinite loop' issue in php5 for windows only
ID: 31989 User updated by: grangeway at blueyonder dot co dot uk Reported By: grangeway at blueyonder dot co dot uk -Status: Feedback +Status: Closed Bug Type: XMLRPC-EPI related Operating System: Windows PHP Version: 5.0.3 Assigned To: edink New Comment: This issues seems to now be resolved. Previous Comments: [2005-03-28 02:08:06] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-03-25 01:23:13] [EMAIL PROTECTED] Edin, can you look into this or not? [2005-02-16 01:49:19] [EMAIL PROTECTED] It's because this extension is linked with libxml2 which this extension DOES NOT support. It should be linked with expat like it is in PHP 4.. [2005-02-16 01:27:42] grangeway at blueyonder dot co dot uk Description: The following code works fine in php 4.x for windows, appears to work fine in 4.x/5.x under linux, but in the distributed windows binarys, and also my own compilation, results in an infinite loop, in what appears to be xmlParseChunk. This issue only seems to occur if the xml header i.e. is not included in the response, and it's the windows build. Reproduce code: --- $foo = " Welcome "; var_dump($foo); var_dump(xmlrpc_decode($foo)); Expected result: Result under freebsd: > php/bin/php test.php Content-type: text/html X-Powered-By: PHP/5.0.4-dev string(110) " Welcome " string(7) "Welcome" Actual result: -- inifinite loop: char * data=0x00a40528 is "" php5ts_debug.dll!_xmlParseDocument() + 0x5c5 C php5ts_debug.dll!_xmlParseChunk() + 0xe5 C > php5ts_debug.dll!php_XML_Parse(_XML_Parser * parser=0x00a3f060, const unsigned char * data=0x00a40528, int data_len=7, int is_final=1) Line 481 + 0x18 C php5ts_debug.dll!xml_elem_parse_buf(const char * in_buf=0x00a40528, int len=7, _xml_input_options * options=0x0012f298, _xml_elem_error * error=0x0012f18c) Line 699 + 0x16 C php5ts_debug.dll!XMLRPC_REQUEST_FromXML(const char * in_buf=0x00a40528, int len=7, _xmlrpc_request_input_options * in_options=0x0012f298) Line 762 + 0x1c C php5ts_debug.dll!decode_request_worker(_zval_struct * xml_in=0x00a40440, _zval_struct * encoding_in=0x, _zval_struct * method_name_out=0x) Line 713 + 0x16 C php5ts_debug.dll!zif_xmlrpc_decode(int ht=1, _zval_struct * return_value=0x00a3f018, _zval_struct * this_ptr=0x, int return_value_used=1, void * * * tsrm_ls=0x00912910) Line 778 + 0x31C -- Edit this bug report at http://bugs.php.net/?id=31989&edit=1
#30160 [Fbk->NoF]: Installing PHP SAPI module fails
ID: 30160 Updated by: php-bugs@lists.php.net Reported By: tessarek at evermeet dot cx -Status: Feedback +Status: No Feedback Bug Type: Apache2 related Operating System: AIX 5.x PHP Version: 5CVS-2005-03-24 New Comment: 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". Previous Comments: [2005-03-24 18:48:09] [EMAIL PROTECTED] What do these commands output: # grep --version # egrep --version # sed --version [2005-03-24 18:48:02] [EMAIL PROTECTED] I removed most comments, none of them gave any additional information that you haven't already given in your initial comment. Please don't add only NEW information from now on. And try to post only answers to what we ask, NOTHING else. [2004-09-20 08:36:36] tessarek at evermeet dot cx Description: This problem came with PHP 5.0.0 and is still there in 5.0.1. The make of PHP 5.0.x works fine, but when running the 'make install', I get following error: Installing PHP SAPI module: apache2filter /opt/apache/build/instdso.sh SH_LIBTOOL='/opt/apache/build/libtool' libphp5.la /opt/apache/modules rm -f /opt/apache/modules/libphp5.so /opt/apache/build/libtool --mode=install cp libphp5.la /opt/apache/modules/ cp .libs/libphp5.a /opt/apache/modules/libphp5.a cp .libs/libphp5.lai /opt/apache/modules/libphp5.la libtool: install: warning: remember to run `libtool --finish /ext/php-5.0.1/libs' chmod 755 /opt/apache/modules/libphp5.so chmod: /opt/apache/modules/libphp5.so: A file or directory in the path name does not exist. apxs:Error: Command failed with rc=65536 . make: 1254-004 The error code from the last command is 1. There seems something wrong with the makefile. With PHP 4.x.x I never had this problem. My Apache version is 2.0.51, but the problem is also reproducable with older versions. It is kind of funny, because there is a libphp5.so file in the /ext/php-5.0.1/.libs directory, where /ext/php-5.0.1/ is my compilation directory. I can copy the file manually to my Apache modules directory and everything works fine. The only problem is that when I do it manually, there is nothing in my PHP target (/opt/php) directory. My configure line is as follows: ./configure --prefix=/opt/php --with-config-file-path=/etc --with-apxs2filter=/opt/apache/bin/apxs --without-mysql --with-ibm-db2=/usr/opt/db2_08_01 --with-xml --enable-cli --disable-ipv6 --enable-force-cgi-redirect --disable-debug --enable-pic --enable-inline-optimization --with-ncurses --with-iconv --with-regex=system --enable-bcmath --enable-exif --enable-ftp --enable-magic-quotes --enable-sockets --enable-sysvsem --enable-sysvshm --enable-track-vars --enable-trans-sid --enable-wddx --without-oci8 --enable-ucd-snmp-hack --enable-memory-limit --enable-shmop --enable-versioning --enable-calendar --enable-dbx --enable-dio --enable-mcal --with-gettext --with-dom --with-zlib --with-zlib-dir=/usr/lib --with-imap --with-openssl=/opt/freeware --with-gd --with-jpeg-dir=/usr/lib --with-png-dir=/usr/lib --with-pdflib --without-sqlite --with-bz2 The problem occurs under AIX 5.1 / AIX 5.2 / Redhat 8.0 / Redhat 9.0 and Redhat Enterprise Server 3.0. (These are the systems I've tested it on.) I hope that this bug has not already been submitted, because I haven't found anything in the bug database. -- Edit this bug report at http://bugs.php.net/?id=30160&edit=1
#32199 [Fbk->NoF]: php-cgi hanging
ID: 32199 Updated by: php-bugs@lists.php.net Reported By: valenok at gmail dot com -Status: Feedback +Status: No Feedback Bug Type: CGI related Operating System: windows xp professional PHP Version: 5.0.3 New Comment: 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". Previous Comments: [2005-03-24 18:42:05] [EMAIL PROTECTED] Let's keep the status at 'Feedback' until you can give some results. We're not interested in WHEN you might do it. [2005-03-24 11:17:19] valenok at gmail dot com thank you. I will try it today evening. [2005-03-23 23:57:20] [EMAIL PROTECTED] You can build the debug version yourself, see README.WIN32-BUILD-SYSTEM in the source snapshot package: http://snaps.php.net/php5-latest.tar.gz [2005-03-22 23:02:57] valenok at gmail dot com with that latest release, 5.1.0-dev, the script hangs every single time! [2005-03-22 18:42:13] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip There was some thread issue fixed. 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/32199 -- Edit this bug report at http://bugs.php.net/?id=32199&edit=1
#32399 [Fbk->NoF]: isapi marshalling problem
ID: 32399 Updated by: php-bugs@lists.php.net Reported By: shunt at ctg dot queensu dot ca -Status: Feedback +Status: No Feedback Bug Type: IIS related Operating System: windows 2003 PHP Version: 5.0.3 New Comment: 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". Previous Comments: [2005-03-22 18:39:02] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Some threading issues are fixed recently, make sure you remove ALL old PHP related dlls before installing the snapshot! (and make sure you _really_ get them deleted before installing!) [2005-03-22 14:03:44] shunt at ctg dot queensu dot ca Hi, ok, I installed php 5.0.3 a few weeks ago and I also have some ASP pages that are in use as well. After installing php I noticed that if I go to one of my php pages and then over to an asp page the browser gives me this error: 'The application called an interface that was marshalled for a different thread.' After refreshing the browser a few times the asp page appears(anywhere from 1 - 5 refreshes does the trick), but then next time I visit the asp page it does it again until i restart the web services(running iis6) . All seems well with the asp pages UNTIL i run another php page and then the error appears again on the asp page. I use the php5isapi DLL as an isapi filter on my site(I also have php enabled as a web service extension using the same DLL). Hope this is enough info. Steve. [2005-03-21 23:07:46] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2005-03-21 20:52:40] shunt at ctg dot queensu dot ca Description: Hi, This bug was already reported for a previous version of php. (Bug #10480 ISAPI module conflicts with asp.dll) but I am having the same problem running a newer version of php and running IIS6. Thanks for your time on this. Steve. -- Edit this bug report at http://bugs.php.net/?id=32399&edit=1
#32383 [Fbk->NoF]: count() hits 4796 maximum count
ID: 32383 Updated by: php-bugs@lists.php.net Reported By: mark dot booker at gmail dot com -Status: Feedback +Status: No Feedback Bug Type: Arrays related Operating System: Windows Server 2003 Ent. Edt. PHP Version: 5.0.3 New Comment: 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". Previous Comments: [2005-03-20 17:56:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip I can not reproduce this. [2005-03-20 12:53:44] mark dot booker at gmail dot com Description: Using count() on an array that has more than 4796 elements, count returns 4796, other functions such as print_r() show all elements and the foreach() command also goes beyond the 4796 limit. Reproduce code: --- $i=single dimension array with 4830 elements print count($i); Expected result: 4830 printed on screen Actual result: -- 4796 printed on screen -- Edit this bug report at http://bugs.php.net/?id=32383&edit=1
#32409 [Fbk->NoF]: Corrupt JPEG data: premature end of data segment
ID: 32409 Updated by: php-bugs@lists.php.net Reported By: sanry at now dot net dot cn -Status: Feedback +Status: No Feedback Bug Type: GD related Operating System: redhat9 PHP Version: 4.3.10 New Comment: 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". Previous Comments: [2005-03-22 15:51:02] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2005-03-22 15:49:07] sanry at now dot net dot cn Description: [Sun Mar 13 18:24:29 2005] [notice] Apache/2.0.53 (Unix) mod_ssl/2.0.53 OpenSSL/0.9.7d mod_jk2/2.0.4 PHP/4.3.10 configured -- resuming normal operations java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158) at java.net.Socket.connect(Socket.java:452) at java.net.Socket.connect(Socket.java:402) at java.net.Socket.(Socket.java:309) at java.net.Socket.(Socket.java:124) at com.todaynic.scp.SCPDaemonService.sendMessage(SCPDaemonService.java:166) at com.todaynic.scp.SCPDaemonService.stopService(SCPDaemonService.java:197) at com.todaynic.scp.Server.ShutDown(Server.java:116) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.todaynic.bootstart.BootStart.main(BootStart.java:76) Corrupt JPEG data: premature end of data segment [Sun Mar 20 07:32:58 2005] [notice] caught SIGTERM, shutting down [Sun Mar 20 07:34:42 2005] [notice] Apache/2.0.53 (Unix) mod_ssl/2.0.53 OpenSSL/0.9.7d mod_jk2/2.0.4 PHP/4.3.10 configured -- resuming normal operati -- Edit this bug report at http://bugs.php.net/?id=32409&edit=1
#32447 [Fbk->NoF]: --with-oci8-instant-client[=DIR] problem
ID: 32447 Updated by: php-bugs@lists.php.net Reported By: vladymyr_ca at yahoo dot ca -Status: Feedback +Status: No Feedback Bug Type: Compile Failure Operating System: RH 7.3 PHP Version: 4.3.10 New Comment: 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". Previous Comments: [2005-03-25 00:27:26] [EMAIL PROTECTED] Please explain more specifically what are you talking about and why Oracle Instant Client libs are in your ORACLE_HOME, as there is no ORACLE_HOME at all when you're using Instant Client. [2005-03-24 21:41:38] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2005-03-24 20:49:29] vladymyr_ca at yahoo dot ca Description: Actually it's a 4.3.11 problem I was using Download: .gz (4.7M) Built On: Mar 24, 2005 17:30 GMT May be just documentation should be changed Currently it is stating that "if you're using Oracle Instant Client, you need to build PHP with the option --with-oci8-instant-client[=DIR]. Note that Oracle Instant Client support first appeared in versions 4.3.11" "where DIR defaults to your environment variable ORACLE_HOME." but in configure script /lib is expected to be included in this pass, and /lib is not a part of ORACLE_HOME When running configure for --with-oci8-instant-client=ORACLE_HOME/lib everything is OK -- Edit this bug report at http://bugs.php.net/?id=32447&edit=1
#32524 [NEW]: Advanced imploding
From: bart at mediawave dot nl
Operating system: Any
PHP version: 5CVS-2005-04-01 (dev)
PHP Bug Type: Feature/Change Request
Bug description: Advanced imploding
Description:
I often find myself being in the situation where I need more advanced ways
to implode() something. For example, a way to implode an array into:
"table1 AS alias1, table2 AS alias2, table3 AS alias3"
or:
"var1=value1&var2=value2&var3=value3"
I would like to make 3 suggestions to implement such a functionality in
PHP.
1) Extend implode so that it can handle a second (or more?) "glue"
argument.
$vars = array(
'var1' => 'value1',
'var2' => 'value2',
'var3' => 'value3'
);
or maybe it would need a multidimensional array:
$vars = array(
array('var1', 'value1'),
array('var2', 'value2'),
array('var3', 'value3')
);
echo implode($vars, '=', '&');
// Would print: var1=value1&var2=value2&var3=value3
The problem here is that implode would need to get its arguments in a
different order. Perhaps, this could be solved by creating a new function.
2) Modify array_map() so that, when the third argument is a string, it is
always passed along as an extra argument to all the function calls:
$vars = array(
array('var1', 'value1'),
array('var2', 'value2'),
array('var3', 'value3')
);
echo implode('&', array_map('implode', $vars, '='));
// Would print: var1=value1&var2=value2&var3=value3
3) This is probably the most powerfull and elegant solution. (My personal
favourite) Modify the __toString() magic method so that, when an object is
passed to a function that needs a string as input, __toString() is called.
In this example __toString() could be something like:
function __toString() {
return $this->name.'='.$this->value;
}
And the implode() code could look like:
$vars = array(
new urlVar('var1', 'value1'),
new urlVar('var1', 'value1'),
new urlVar('var1', 'value1')
);
echo implode($vars, '&');
// Would print: var1=value1&var2=value2&var3=value3
This could also produce more complex strings like:
"WHERE var1='value1' AND var2='value2' OR var3='value3'"
--
Edit bug report at http://bugs.php.net/?id=32524&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32524&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32524&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32524&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32524&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32524&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32524&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32524&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32524&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32524&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32524&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32524&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32524&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32524&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32524&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32524&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32524&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32524&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32524&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32524&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32524&r=mysqlcfg
#32525 [NEW]: RunTests.php in package-PEAR.xml but file does not exist in distribution
From: phyre at rogers dot com Operating system: Linux 2.4 PHP version: 5.0.3 PHP Bug Type: Unknown/Other Function Bug description: RunTests.php in package-PEAR.xml but file does not exist in distribution Description: package-PEAR.xml references installing 'RunTests.php' however the distribution fails to include it in 5.0.4. The 'RunTests.php' was not references in 5.0.3 as a file needed to install, but is in 5.0.4. Reproduce code: --- make install in source tree To fix, remove line referencing 'RunTests.php' from package-PEAR.xml Expected result: [PEAR] PEAR - installed: 1.3.5 Wrote PEAR system config file at: /usr/local/etc/pear.conf You may want to add: /tmp to your php.ini include_path Actual result: -- [PEAR] PEAR: file does not exist -- Edit bug report at http://bugs.php.net/?id=32525&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32525&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32525&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32525&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32525&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32525&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32525&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32525&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32525&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32525&r=support Expected behavior: http://bugs.php.net/fix.php?id=32525&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32525&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32525&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32525&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32525&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32525&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32525&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32525&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32525&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32525&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32525&r=mysqlcfg
#32525 [Opn]: RunTests.php in package-PEAR.xml but file does not exist in distribution
ID: 32525 User updated by: phyre at rogers dot com Reported By: phyre at rogers dot com Status: Open Bug Type: Unknown/Other Function Operating System: Linux 2.4 PHP Version: 5.0.3 New Comment: Apologies- 'RunTest.php' should be without the 's' as I used it in my report. Previous Comments: [2005-04-01 01:29:59] phyre at rogers dot com Description: package-PEAR.xml references installing 'RunTests.php' however the distribution fails to include it in 5.0.4. The 'RunTests.php' was not references in 5.0.3 as a file needed to install, but is in 5.0.4. Reproduce code: --- make install in source tree To fix, remove line referencing 'RunTests.php' from package-PEAR.xml Expected result: [PEAR] PEAR - installed: 1.3.5 Wrote PEAR system config file at: /usr/local/etc/pear.conf You may want to add: /tmp to your php.ini include_path Actual result: -- [PEAR] PEAR: file does not exist -- Edit this bug report at http://bugs.php.net/?id=32525&edit=1
#32496 [Bgs]: Session string values are references
ID: 32496 User updated by: ceo at l-i-e dot com Reported By: ceo at l-i-e dot com Status: Bogus Bug Type: Session related Operating System: FreeBSD 5.3-RELEASE PHP Version: 5.0.3 New Comment: Fixed in CVS, I guess. Others have confirmed the bug in 5.0.3 on non FreeBSD platforms. Previous Comments: [2005-03-30 07:25:38] [EMAIL PROTECTED] Using latest CVS + register_globals = Off -> Works just fine. [2005-03-30 05:23:22] ceo at l-i-e dot com Description: \n"; ?> Now, hit this page, re-load it, and what do *YOU* expect $_SESSION['name'] to output? A) 'Richard Lynch', because you never re-assigned $_SESSION['name'] B) 'Fooey' because $name is a reference, and you changed it, so that changed your session data. *I* expected A) Alas, the reality is B) -- Edit this bug report at http://bugs.php.net/?id=32496&edit=1
#32526 [NEW]: PEAR fails installation
From: ktk at enterprise dot bidmc dot harvard dot edu
Operating system: Linux Slackware 10.1
PHP version: 5.0.3
PHP Bug Type: *Compile Issues
Bug description: PEAR fails installation
Description:
This is relevant to PHP 5.0.4, although that could not be
selected from the bug-reporting version dropdown.
Executing "make install" fails to install PEAR.
Here's a snippit of the output:
Installing PEAR environment: /tmp/foo/lib/php/
[PEAR] Archive_Tar- already installed: 1.1
[PEAR] Console_Getopt - already installed: 1.2
[PEAR] PEAR: file does not exist
[PEAR] HTML_Template_IT- already installed: 1.1
[PEAR] Net_UserAgent_Detect- already installed: 2.0.1
[PEAR] XML_RPC- already installed: 1.2.2
The directory /tmp/foo/lib/php/PEAR is missing all of the
normal PEAR files.
Reproduce code:
---
./configure --prefix=/tmp/foo
make && make install
Expected result:
Normally ${INSTALL_ROOT}/lib/php/PEAR/ contains a variety
of .php files, and ${INSTALL_ROOT}/lib/php/PEAR.php
exists. But in this case, none of the PEAR files are
installed.
--
Edit bug report at http://bugs.php.net/?id=32526&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32526&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32526&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32526&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32526&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32526&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32526&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32526&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32526&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32526&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32526&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32526&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32526&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32526&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32526&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32526&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32526&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32526&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32526&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32526&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32526&r=mysqlcfg
#32527 [NEW]: iconv library
From: yama152 at yahoo dot com Operating system: Solaris 9 (Intel) PHP version: 5.0.3 PHP Bug Type: Compile Failure Bug description: iconv library Description: This is actually 5.0.4 on Solaris 9 (intel). setenv LD_LIBRARY_PATH /usr/local/BerkeleyDB.4.3/lib:/usr/local/lib ./configure --with-apxs2=/usr/local/apache2/bin/apxs \ --enable-trans-sid \ --enable-zend-multibyte --enable-mbstring --enable-mbstr-enc-trans \ --enable-track-vars --enable-force-cgi-redirect gives /bin/sh /export/hoge/sys/php/php-5.0.4/libtool --silent --preserve-dup-deps --mode=link gcc -export-dynamic -g -O2 -L/usr/ucblib -L/usr/local/lib/gcc/i386-pc-solaris2.9/3.4.3 -L/usr/local/lib -R /usr/ucblib -R /usr/local/lib/gcc/i386-pc-solaris2.9/3.4.3 -R /usr/local/lib ext/libxml/libxml.lo ext/ctype/ctype.lo ext/dom/php_dom.lo ext/dom/attr.lo ext/dom/document.lo ext/dom/domerrorhandler.lo ext/dom/domstringlist.lo ext/dom/domexception.lo ext/dom/namelist.lo ext/dom/processinginstruction.lo ext/dom/cdatasection.lo ext/dom/documentfragment.lo ext/dom/domimplementation.lo ext/dom/element.lo ext/dom/node.lo ext/dom/string_extend.lo ext/dom/characterdata.lo ext/dom/documenttype.lo ext/dom/domimplementationlist.lo ext/dom/entity.lo ext/dom/nodelist.lo ext/dom/text.lo ext/dom/comment.lo ext/dom/domconfiguration.lo ext/dom/domimplementationsource.lo ext/dom/entityreference.lo ext/dom/notation.lo ext/dom/xpath.lo ext/dom/dom_iterators.lo ext/dom/typeinfo.lo ext/dom/domerror.lo ext/dom/domlocator.lo ext/dom/namednodemap.lo ext/dom/userdatahandler.lo ext/iconv/iconv.lo ext/mbstring/mbstring.lo ext/mbstring/php_unicode.lo ext/mbstring/mb_gpc.lo ext/mbstring/php_mbregex.lo ext/mbstring/oniguruma/regcomp.lo ext/mbstring/oniguruma/regerror.lo ext/mbstring/oniguruma/regexec.lo ext/mbstring/oniguruma/reggnu.lo ext/mbstring/oniguruma/regparse.lo ext/mbstring/oniguruma/regenc.lo ext/mbstring/oniguruma/regext.lo ext/mbstring/oniguruma/regsyntax.lo ext/mbstring/oniguruma/regtrav.lo ext/mbstring/oniguruma/regversion.lo ext/mbstring/oniguruma/st.lo ext/mbstring/oniguruma/enc/unicode.lo ext/mbstring/oniguruma/enc/ascii.lo ext/mbstring/oniguruma/enc/utf8.lo ext/mbstring/oniguruma/enc/euc_jp.lo ext/mbstring/oniguruma/enc/euc_tw.lo ext/mbstring/oniguruma/enc/euc_kr.lo ext/mbstring/oniguruma/enc/sjis.lo ext/mbstring/oniguruma/enc/iso8859_1.lo ext/mbstring/oniguruma/enc/iso8859_2.lo ext/mbstring/oniguruma/enc/iso8859_3.lo ext/mbstring/oniguruma/enc/iso8859_4.lo ext/mbstring/oniguruma/enc/iso8859_5.lo ext/mbstring/oniguruma/enc/iso8859_6.lo ext/mbstring/oniguruma/enc/iso8859_7.lo ext/mbstring/oniguruma/enc/iso8859_8.lo ext/mbstring/oniguruma/enc/iso8859_9.lo ext/mbstring/oniguruma/enc/iso8859_10.lo ext/mbstring/oniguruma/enc/iso8859_11.lo ext/mbstring/oniguruma/enc/iso8859_13.lo ext/mbstring/oniguruma/enc/iso8859_14.lo ext/mbstring/oniguruma/enc/iso8859_15.lo ext/mbstring/oniguruma/enc/iso8859_16.lo ext/mbstring/oniguruma/enc/koi8.lo ext/mbstring/oniguruma/enc/koi8_r.lo ext/mbstring/oniguruma/enc/big5.lo ext/mbstring/oniguruma/enc/utf16_be.lo ext/mbstring/oniguruma/enc/utf16_le.lo ext/mbstring/oniguruma/enc/utf32_be.lo ext/mbstring/oniguruma/enc/utf32_le.lo ext/mbstring/libmbfl/filters/html_entities.lo ext/mbstring/libmbfl/filters/mbfilter_7bit.lo ext/mbstring/libmbfl/filters/mbfilter_ascii.lo ext/mbstring/libmbfl/filters/mbfilter_base64.lo ext/mbstring/libmbfl/filters/mbfilter_big5.lo ext/mbstring/libmbfl/filters/mbfilter_byte2.lo ext/mbstring/libmbfl/filters/mbfilter_byte4.lo ext/mbstring/libmbfl/filters/mbfilter_cp1251.lo ext/mbstring/libmbfl/filters/mbfilter_cp1252.lo ext/mbstring/libmbfl/filters/mbfilter_cp866.lo ext/mbstring/libmbfl/filters/mbfilter_cp932.lo ext/mbstring/libmbfl/filters/mbfilter_cp936.lo ext/mbstring/libmbfl/filters/mbfilter_euc_cn.lo ext/mbstring/libmbfl/filters/mbfilter_euc_jp.lo ext/mbstring/libmbfl/filters/mbfilter_euc_jp_win.lo ext/mbstring/libmbfl/filters/mbfilter_euc_kr.lo ext/mbstring/libmbfl/filters/mbfilter_euc_tw.lo ext/mbstring/libmbfl/filters/mbfilter_htmlent.lo ext/mbstring/libmbfl/filters/mbfilter_hz.lo ext/mbstring/libmbfl/filters/mbfilter_iso2022_kr.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_1.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_10.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_13.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_14.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_15.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_16.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_2.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_3.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_4.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_5.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_6.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_7.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_8.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_9.lo ext/mbstring/libmbfl/filters/mbfilter_jis.lo ext/mbstring/libmbfl/filters/mbfilter_koi8r.lo ext/mbstring/libmbfl/filters/mbfilter_qprint.
#32529 [NEW]: bsprintf?
From: andala at gmail dot com
Operating system: MacOS X
PHP version: 5CVS-2005-04-01 (dev)
PHP Bug Type: Feature/Change Request
Bug description: bsprintf?
Description:
Not sure how open you are to feature requests like this.
I use my own function bsprintf() (i.e. boolean sprintf)
quite a bit for display code. What it does is return
$var outputted according to $format *only* if $var is
not empty, otherwise return nothing. If (optional)
$default is passed in, $default is returned instead of
nothing if $var is empty.
function bsprintf($var,$format='%s',$default="") {
if (!empty($var)) {return sprintf($format,$var);}
else if (!empty($default)) return $default;
};
Thought I'd suggest implementing something like this as
a built-in function. Here is a brief example of the type
of use that I've found useful, mostly to keep code
simple, condensed, and readable (especially with long
scripts):
USING bsprintf -
$apples=100;
echo "% Apples: ".bsprintf($apples,'%s%%',"None.")."
/ % Oranges: ".bsprintf($oranges,'%s%%',"None.");
(Total lines: 2)
Returns: % Apples: 100% / % Oranges: None.
NOT USING bsprintf -
$apples=100;
echo "% Apples: ";
echo (!empty($apples)) ? $apples."%" : "None.";
echo " / % Oranges: ";
echo (!empty($oranges)) ? $oranges."%" : "None.";
(OR)
$apples=100;
echo "% Apples: ".((!empty($apples)) ? $apples."%" :
"None.")." / % Oranges: ".((!empty($oranges)) ?
$oranges."%" : "None.");
(Total lines: 5, or 2-- including a really ugly, hard to
read one)
Returns: same as above!
--
Edit bug report at http://bugs.php.net/?id=32529&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32529&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32529&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32529&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32529&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32529&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32529&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32529&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32529&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32529&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32529&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32529&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32529&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32529&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32529&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32529&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32529&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32529&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32529&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32529&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32529&r=mysqlcfg
#31217 [Com]: extract($GLOBALS, EXTR_REFS) corrupts memory
ID: 31217
Comment by: john at carney dot id dot au
Reported By: cdragon at draconic dot com
Status: No Feedback
Bug Type: Zend Engine 2 problem
Operating System: win2k
PHP Version: 5CVS-2004-12-18 (dev)
New Comment:
I too had an issue with extract($GLOBALS,EXTR_REFS) in PHP4, but it was
resolved and I haven't seen any problems again until today when I
reorganised some code and suddenly I'm getting extract() problems
again. I haven't got a simple script that reproduces the problem (yet),
but the symptom I'm getting is when I pass a variable that is set to a
definitely as a parameter to a function, null is being sent instead of
the variable value. Commenting out the extract() fixes the problem (but
breaks other code).
Previous Comments:
[2005-03-15 01:00:36] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2005-03-07 21:41:53] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-01-19 22:10:02] [EMAIL PROTECTED]
See also bug #30074
[2004-12-21 04:26:04] cdragon at draconic dot com
Description:
Since php 5.0.1, extract($GLOBALS, EXTR_REFS) seems to corrupt code
memory and cause various random problems. In my test case, it caused
COM("someobject") to always return null, and in another case it just
caused some strange output of a "1" instead of the expected strings. I
never had a problem in php 5.0.0 up to CVS snapshot
php5.0-win32-200407301630. Commenting out extract($GLOBALS, EXTR_REFS)
fixes all strange behavior.
I had a similar problem in php 4 which I reported as bug id 25708.
That bug was fixed and I never had a problem again until 5.0.1.
Reproduce code:
---
extract($GLOBALS, EXTR_REFS);
$query = new COM("IXSSO.Query");
if(is_object($query) == false) {
var_dump($query);
print "Can't create IXSSO Query object.";
exit();
}
Expected result:
Nothing
Actual result:
--
PHP has encountered an Access Violation at 01D5F185
--
Edit this bug report at http://bugs.php.net/?id=31217&edit=1
#31217 [Com]: extract($GLOBALS, EXTR_REFS) corrupts memory
ID: 31217
Comment by: john at carney dot id dot au
Reported By: cdragon at draconic dot com
Status: No Feedback
Bug Type: Zend Engine 2 problem
Operating System: win2k
PHP Version: 5CVS-2004-12-18 (dev)
New Comment:
ps. this behaviour is observed in both 5.0.3 and 5.0.4
Previous Comments:
[2005-04-01 08:33:13] john at carney dot id dot au
I too had an issue with extract($GLOBALS,EXTR_REFS) in PHP4, but it was
resolved and I haven't seen any problems again until today when I
reorganised some code and suddenly I'm getting extract() problems
again. I haven't got a simple script that reproduces the problem (yet),
but the symptom I'm getting is when I pass a variable that is set to a
definitely as a parameter to a function, null is being sent instead of
the variable value. Commenting out the extract() fixes the problem (but
breaks other code).
[2005-03-15 01:00:36] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2005-03-07 21:41:53] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-01-19 22:10:02] [EMAIL PROTECTED]
See also bug #30074
[2004-12-21 04:26:04] cdragon at draconic dot com
Description:
Since php 5.0.1, extract($GLOBALS, EXTR_REFS) seems to corrupt code
memory and cause various random problems. In my test case, it caused
COM("someobject") to always return null, and in another case it just
caused some strange output of a "1" instead of the expected strings. I
never had a problem in php 5.0.0 up to CVS snapshot
php5.0-win32-200407301630. Commenting out extract($GLOBALS, EXTR_REFS)
fixes all strange behavior.
I had a similar problem in php 4 which I reported as bug id 25708.
That bug was fixed and I never had a problem again until 5.0.1.
Reproduce code:
---
extract($GLOBALS, EXTR_REFS);
$query = new COM("IXSSO.Query");
if(is_object($query) == false) {
var_dump($query);
print "Can't create IXSSO Query object.";
exit();
}
Expected result:
Nothing
Actual result:
--
PHP has encountered an Access Violation at 01D5F185
--
Edit this bug report at http://bugs.php.net/?id=31217&edit=1
#32512 [Fbk->Opn]: flush() does not work after sending Location header
ID: 32512
User updated by: kulakov74 at yandex dot ru
Reported By: kulakov74 at yandex dot ru
-Status: Feedback
+Status: Open
Bug Type: Output Control
Operating System: Linux, Win 2000
PHP Version: 4.3.9
New Comment:
I'm sorry, this is my fault - the HTTP-interface I use for testing
could not display single characters which made me think PHP didn't send
anything. After I added newlines to the output - echo("-\n"); flush(); -
it worked as expected.
Also, I tried using register_shutdown_function to separate the slow
part from sending headers, but it didn't work. The docs says:
The registered shutdown functions are called after the request has been
completed (including sending any output buffers), so it is not possible
to send output to the browser using echo() or print()...
But I tried to output with echo() within the regisreted function and,
to my surprise, the output got to the browser! Seems like when the
function is called the connection may well be open unless it was closed
by the user/net; I wish there would be a way to tell Apache to close it
at any moment so that script would run in background.
Previous Comments:
[2005-03-31 22:00:43] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
I can NOT reproduce this with latest CVS (tested PHP_4_3 / HEAD
branches)
[2005-03-31 10:32:10] kulakov74 at yandex dot ru
Description:
We want a script to make a redirect and then make some Sql-queries, so
that the user would not wait for the queries to execute (sometimes they
may take too long). I added
echo("-"); flush();
after sending the Location header which made PHP send the header
immediately away, but the problem is IE does not make the redirect as
soon as it gets the header - probably it expects other headers or a
page, so it only redirects after the script completes. If I add more
output after that and a flush() call then PHP won't output anything
else until the script completes. This is emulated with a sleep(3) call.
More precisely, PHP only sends headers immediately, it doesn't send
anything else (the dash in this case).
Reproduce code:
---
//This is the redirect
header("Location: http://hotelsys.biz/hotels/Bali";);
//This is how I force PHP to send it right away
echo("-"); flush();
//This is how I cannot make PHP send anything else
echo(str_repeat("-", 1024*16)); flush();
//Pause emulation
sleep(3);
//the end - this is when the browser gets the output
exit;
Expected result:
The first "-" character and the next 16K of it sent right away.
Actual result:
--
I only get dashes in 3 seconds; the browser (IE) makes the redirect in
this time too.
--
Edit this bug report at http://bugs.php.net/?id=32512&edit=1
