Bug #15557 Updated: Date Command date("Y-m-t"); Not Correct with system time
ID: 15557
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Date/time related
Operating System: Slackware 8.0
PHP Version: 4.1.1
New Comment:
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-02-14 12:52:01] [EMAIL PROTECTED]
Well, for starters your listed date and the date format you have listed
in the bug title aren't the same.
Y-m-t = Year{4} - Month - Day of Month
So let's try reworking your report.
Send the:
Expected Date Format
Actual Date Format
Code Snippet that actually makes the date inserted into your DB.
I somehow doubt this is a bug.
-Chris
[2002-02-14 12:40:23] [EMAIL PROTECTED]
Well i noticed in my database that all the times where set to 2002-28-02
and cheaked the code. All seams okay even the system is correct. I
assume that the date command has a bug in it. The text format like the
day of the week is correct but when you use the numbers its all wrong.
--
Edit this bug report at http://bugs.php.net/?id=15557&edit=1
Bug #15108 Updated: Server variables to exist globally w/ register_globals = off
ID: 15108
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Feature/Change Request
Operating System: n/a
PHP Version: 4.2.0
New Comment:
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-01-18 23:47:42] [EMAIL PROTECTED]
After some searching, came across an important thread that my brain
never saw. The proposal on the issue of register_globals and "the big
change":
http://marc.theaimsgroup.com/?l=php-dev&m=99638397319055
Which includes some great information. Including import_globals(),
which in short, my concern is solved by: import_globals('S'). This next
thread (very long) is very related too, which existed before the above
proposal:
http://marc.theaimsgroup.com/?l=php-dev&m=99600275103594
It's all sounds good.
But :) Throughout the history of the manual, it's been *implied* that
predefined server variables are registered globally. This will
obviously change (see #14472) but point is, this is a potential problem.
Is this worth doing anything else about? Like, defaulting PHP with 'S'
(or ES) for a release or two? Or, would that just add unneeded
confusion.
[2002-01-18 16:52:14] [EMAIL PROTECTED]
> But most importantly, this will be useful.
no it won't, same security consideration as with
the other global registrations
[2002-01-18 16:14:25] [EMAIL PROTECTED]
In short, when register_globals = off, server variables would/should
continue to register globally. Variables such as:
$PHP_SELF, $DOCUMENT_ROOT, $REMOTE_ADDR, etc.
As currently they do not. And on a sidenote, the current docs imply
that server variables always exist, regardless of setting. Some
possible options:
a) Create a new config setting, such as register_server_globals or
register_predefined_globals
b) Make register_globals allow for individual EGPCS settings (default to
S)
c) Make server variables always exist, like track_vars do now.
d) ...
This will help ease the register_globals = off transition as well as
cause a lot less "4.2.0 BROKE PHP!!!" emails. But most importantly,
this will be useful.
--
Edit this bug report at http://bugs.php.net/?id=15108&edit=1
Bug #15008 Updated: Apache Crash
ID: 15008 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: Linux 2.4.5 PHP Version: 4.1.1 New Comment: See also http://bugs.php.net/bug.php?id=14529 Previous Comments: [2002-02-02 06:45:26] [EMAIL PROTECTED] Reopening. [2002-01-23 00:03:15] [EMAIL PROTECTED] See also http://bugs.php.net/bug.php?id=15096 [2002-01-22 23:45:59] [EMAIL PROTECTED] 2 x Apache 1.3.20 + MySQL 3.23.39 + Linux 2.4.17 (one with grsec patch). Pattern: logs full of messages mentioned in first report. Crash seems to happen on first load of the page in a freshly started browser (there's a session init on the page (two actually, on both same thing)), on reload things work ok. Session stuff done via mysql. PHP 4.1.1, loaded with extensions. [2002-01-12 21:15:06] [EMAIL PROTECTED] OK, This may actually not be a bug (In my case at least). Just reinstalled PHP 4.1.0 and it still happened. Not sure about the first submission, but it may still be a PHP bug but not for my case, at least. Sorry for all the bother. [2002-01-12 20:57:39] [EMAIL PROTECTED] Hrm, but there is no sign of anything PHP in that backtrace. You are saying PHP sent something that caused mod_layout to crash? That would indicate a problem in mod_layout as far as I am concerned. 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/15008 -- Edit this bug report at http://bugs.php.net/?id=15008&edit=1
Bug #16089: The memory could not be "read".
From: [EMAIL PROTECTED] Operating system: Windows 2000 Server/Pro PHP version: 4.1.2 PHP Bug Type: Reproducible crash Bug description: The memory could not be "read". Upon standard installation of the 4.1.2 PHP Windows installer on both a Windows 2000 SP2 SR1 Server machine and a Windows 2000 SP2 SR1 Professional machine, both running IIS 5.0, I setup the basic test file I have working on another Windows 2000 Pro machine installed with PHP 4.1.1 Upon attempts at execution the error returned on the console of the IIS server is as follows: php.exe - Application Error The instruction at "0x1000602e" referenced memory at "0x00080cdc". The memory could not be "read". Click on OK to terminate the program The browser reports the following after about 5 minutes: CGI Timeout The specified CGI application exceeded the allowed time for processing. The server has deleted the process. Hopefully this is enough information to help resolve this issue. Thank you, - Brad -- Edit bug report at http://bugs.php.net/?id=16089&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16089&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16089&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16089&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16089&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16089&r=support Expected behavior: http://bugs.php.net/fix.php?id=16089&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16089&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16089&r=submittedtwice
Bug #16043 Updated: $_SESSION can't use in PHP 4.1.2
ID: 16043
Updated by: [EMAIL PROTECTED]
-Summary: $_SESSION can't use in PHP 4.1.2
Reported By: [EMAIL PROTECTED]
-Status: Duplicate
+Status: Closed
Bug Type: Session related
Operating System: Windows XP
PHP Version: 4.1.2
New Comment:
Oops, this is fixed in CVS and will be fixed in 4.2.0 also.
Previous Comments:
[2002-03-14 18:58:34] [EMAIL PROTECTED]
I can confirm this with w2ksp2 + apache 1.3.23
[2002-03-14 15:58:47] [EMAIL PROTECTED]
Sample scripts to show symptoms.
The following script shows that NO session data is stored when you use
the new $_SESSION variables only as described in the PHP manual:
__
Simple PHP Session Test
Testing PHP Sessions...
";
foreach($_SESSION as $key => $value) {
echo "\$_SESSION['$key'] => '$value'";
}
//Set/Increment Counter
if ( !array_key_exists('counter', $_SESSION) ) {
$_SESSION['counter'] = 0;
} else {
$_SESSION['counter']++;
}
echo "Values at end of script:";
foreach($_SESSION as $key => $value) {
echo "\$_SESSION['$key'] => '$value'";
}
?>
__
And the modified version of this script uses the older
$HTTP_SESSION_VARS variable along with session_register(), to show that
session_register() creates the initial instance of a session variable,
but no updates occur after that. This is the best I've been able to do
with sessions in 4.1.2, so it's pretty useless at this point.
__
Simple PHP Session Test
Testing PHP Sessions...
";
foreach($HTTP_SESSION_VARS as $key => $value) {
echo "\$HTTP_SESSION_VARS['$key'] => '$value'";
}
//Set/Increment Counter
if ( !array_key_exists('counter', $HTTP_SESSION_VARS) ) {
$counter = 0;
session_register('counter');
} else {
$HTTP_SESSION_VARS['counter']++;
}
echo "Values at end of script:";
foreach($HTTP_SESSION_VARS as $key => $value) {
echo "\$HTTP_SESSION_VARS['$key'] => '$value'";
}
?>
__
P.S. For what it's worth, session files ARE created in the
session.save_path directory, but other than the latter script, the
files are always 0 bytes and completely empty. Hope this helps track
down the bug.
[2002-03-14 14:37:56] [EMAIL PROTECTED]
Also applies to NT 4.0 (sp6a) both Module and CGI $_SESSION
and also $HTTP_SESSION_VARS are dead. From what I can tell
the sess files get created in tmp ok, however nothing ever
gets written to it.
[2002-03-14 10:27:13] [EMAIL PROTECTED]
thank you for reply...
I test the $_SESSION use those 3 PHP file...
1.php
===
TEST';
echo 'SESSION';
foreach($_SESSION as $k => $v)
echo "$k => $v";
$_SESSION['a']='a';
?>
===
2.php
===
TEST';
echo 'SESSION';
foreach($_SESSION as $k => $v)
echo "$k => $v";
$_SESSION['b']='b';
?>
===
3.php
===
TEST';
echo 'SESSION';
foreach($_SESSION as $k => $v)
echo "$k => $v";
$_SESSION['c']='c';
?>
===
very simple...
I like use PHP 4.1.x new features($_GET, $_POST, $_SESSION... etc), so
I care about the $_SESSION can right work!
[2002-03-13 20:33:36] [EMAIL PROTECTED]
Have the same issue running the following config:
* Windows 2000 SP2
* Apache 1.3.23 for Windows
* PHP 4.1.2 Apache SAPI module
Everything works fine with PHP 4.1.1 in place. Swapping in PHP 4.1.2,
sessions break. It appears possible to store session variables
INITIALLY using session_register(), but no updates to session variables
are ever stored in the session file.
Attempting to follow the PHP documentation and just use
$_SESSION--avoiding using session_register() altogether--does not work
at all. Attempting to create a session variable by doing something
like
as written in the documentation fails miserably. (Note the
documentation neglects the session_start() call, which I added since I
did not have autostart enabled.)
BACKGROUND:
Here is how I swapped 4.1.2 into place to test this (what I do whenever
a new release comes out now):
* All Internet-related info is stored under \InetPub
(holdover from my IIS days)
* Apache is configured to look in \InetPub\PHP\SAPI for
the PHP4APACHE.DLL file. All appropriate settings in
HTTPD.CONF fi
Bug #16080 Updated: Segmentation fault
ID: 16080 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.3.0-dev New Comment: The same problem is reported, but I'll keep this one for now :) Currently, deleting or assining buffer variable ($page in this case) causes segfault. Workaround is Previous Comments: [2002-03-14 14:42:36] [EMAIL PROTECTED] [2002-03-14 14:41:59] [EMAIL PROTECTED] Reproduced with latest CVS. [2002-03-14 14:38:04] [EMAIL PROTECTED] following php code give me a segmention fault: -- Edit this bug report at http://bugs.php.net/?id=16080&edit=1
Bug #16082 Updated: libmm 1.1.3 session save handler = crash
ID: 16082 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Duplicate -Bug Type: Reproducible crash +Bug Type: Session related Operating System: Linux Redhat 7.1 PHP Version: 4.1.2 Previous Comments: [2002-03-14 15:09:22] [EMAIL PROTECTED] I am trying to get php 4.1.2 working with mm support (libmm 1.1.3) to act as my session save handler. I have a 100% reproducable segfault w/ apache 1.3.23. I have been able to reproduce this on Redhat 7.1 and Mandrake 8.1, with 2 different machines. This happens with and w/o the Zend Optimizer. The gdb stack dump here shows that I was running the Optimizer at the time. My php configure line is as follows: ./configure \ --with-mm=/usr/local \ --with-apxs=/usr/local/apache/bin/apxs \ --disable-debug (normally, I have a bunch of other items in the configure line, but I wanted to narrow the crash down to the least amount of variables) The php script is very simple: Here is the gdb output: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 28561)] 0x402ae4f9 in ps_srlzr_decode_php (val=0x81066ec "", vallen=135269900) at session.c:394 394 if (++q >= endptr) goto break_outer_loop; (gdb) bt #0 0x402ae4f9 in ps_srlzr_decode_php (val=0x81066ec "", vallen=135269900) at session.c:394 #1 0x402ae8b1 in php_session_decode (val=0x81066ec "", vallen=135269900) at session.c:457 #2 0x402aeb03 in php_session_initialize () at session.c:524 #3 0x402afbb2 in php_session_start () at session.c:890 #4 0x402b0e55 in zif_session_start (ht=0, return_value=0x8100dec, this_ptr=0x0, return_value_used=0) at session.c:1264 #5 0x443ef70b in zend_assign_to_variable_reference () from /usr/local/Zend/lib/ZendOptimizer.so #6 0x443f9325 in zend_oe () from /usr/local/Zend/lib/ZendOptimizer.so #7 0x402752e4 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:814 #8 0x40282b85 in php_execute_script (primary_file=0xb440) at main.c:1307 #9 0x4027ecf2 in apache_php_module_main (r=0x80f9a74, display_source_mode=0) at sapi_apache.c:90 #10 0x4027f7ce in send_php (r=0x80f9a74, display_source_mode=0, filename=0x0) at mod_php4.c:575 #11 0x4027f822 in send_parsed_php (r=0x80f9a74) at mod_php4.c:590 #12 0x080727b7 in ap_invoke_handler () #13 0x080869ff in process_request_internal () #14 0x08086a60 in ap_process_request () #15 0x0807de6d in child_main () #16 0x0807e0db in make_child () #17 0x0807e18c in startup_children () #18 0x0807e808 in standalone_main () #19 0x0807f067 in main () #20 0x40111627 in __libc_start_main (main=0x807ecc8 , argc=1, ubp_av=0xb884, init=0x804e760 <_init>, fini=0x809c0c0 <_fini>, rtld_fini=0x4000dcc4 <_dl_fini>, stack_end=0xb87c) at ../sysdeps/generic/libc-start.c:129 -- Edit this bug report at http://bugs.php.net/?id=16082&edit=1
Bug #16085 Updated: Invalid access to memory location when accessing ANY php page
ID: 16085 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: IIS related Operating System: Windows 2000 Server PHP Version: 4.1.2 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Previous Comments: [2002-03-14 18:10:44] [EMAIL PROTECTED] With PHP 4.0.6 everything works fine. With PHP 4.1.0, 4.1.1 and 4.1.2 the following error occurs when browsing ANY php page: 'Invalid access to memory location.' That is the only feedback I get. PHP is installed as ISAPI on IIS 5.0 running on W2K Server. -- Edit this bug report at http://bugs.php.net/?id=16085&edit=1
Bug #16066 Updated:
ID: 16066 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux (Debian) PHP Version: 4.1.1 New Comment: However without the space it outputs a warning: "Warning: Use of undefined constant PHP - assumed 'PHP'" But this (correctly) doesn't output anything... If you put code after the comment it is worse. This actually dies with a "parser error", but again this works if you use the shorter tag. Outputs "Hello" as expected. The fact that it works when you use "http://bugs.php.net/?id=16066&edit=1
Bug #16043 Updated: $_SESSION can't use in PHP 4.1.2
ID: 16043
Updated by: [EMAIL PROTECTED]
-Summary: $_SESSION can't use in PHP 4.1.2
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Duplicate
Bug Type: Session related
Operating System: Windows XP
PHP Version: 4.1.2
Previous Comments:
[2002-03-14 18:58:34] [EMAIL PROTECTED]
I can confirm this with w2ksp2 + apache 1.3.23
[2002-03-14 15:58:47] [EMAIL PROTECTED]
Sample scripts to show symptoms.
The following script shows that NO session data is stored when you use
the new $_SESSION variables only as described in the PHP manual:
__
Simple PHP Session Test
Testing PHP Sessions...
";
foreach($_SESSION as $key => $value) {
echo "\$_SESSION['$key'] => '$value'";
}
//Set/Increment Counter
if ( !array_key_exists('counter', $_SESSION) ) {
$_SESSION['counter'] = 0;
} else {
$_SESSION['counter']++;
}
echo "Values at end of script:";
foreach($_SESSION as $key => $value) {
echo "\$_SESSION['$key'] => '$value'";
}
?>
__
And the modified version of this script uses the older
$HTTP_SESSION_VARS variable along with session_register(), to show that
session_register() creates the initial instance of a session variable,
but no updates occur after that. This is the best I've been able to do
with sessions in 4.1.2, so it's pretty useless at this point.
__
Simple PHP Session Test
Testing PHP Sessions...
";
foreach($HTTP_SESSION_VARS as $key => $value) {
echo "\$HTTP_SESSION_VARS['$key'] => '$value'";
}
//Set/Increment Counter
if ( !array_key_exists('counter', $HTTP_SESSION_VARS) ) {
$counter = 0;
session_register('counter');
} else {
$HTTP_SESSION_VARS['counter']++;
}
echo "Values at end of script:";
foreach($HTTP_SESSION_VARS as $key => $value) {
echo "\$HTTP_SESSION_VARS['$key'] => '$value'";
}
?>
__
P.S. For what it's worth, session files ARE created in the
session.save_path directory, but other than the latter script, the
files are always 0 bytes and completely empty. Hope this helps track
down the bug.
[2002-03-14 14:37:56] [EMAIL PROTECTED]
Also applies to NT 4.0 (sp6a) both Module and CGI $_SESSION
and also $HTTP_SESSION_VARS are dead. From what I can tell
the sess files get created in tmp ok, however nothing ever
gets written to it.
[2002-03-14 10:27:13] [EMAIL PROTECTED]
thank you for reply...
I test the $_SESSION use those 3 PHP file...
1.php
===
TEST';
echo 'SESSION';
foreach($_SESSION as $k => $v)
echo "$k => $v";
$_SESSION['a']='a';
?>
===
2.php
===
TEST';
echo 'SESSION';
foreach($_SESSION as $k => $v)
echo "$k => $v";
$_SESSION['b']='b';
?>
===
3.php
===
TEST';
echo 'SESSION';
foreach($_SESSION as $k => $v)
echo "$k => $v";
$_SESSION['c']='c';
?>
===
very simple...
I like use PHP 4.1.x new features($_GET, $_POST, $_SESSION... etc), so
I care about the $_SESSION can right work!
[2002-03-13 20:33:36] [EMAIL PROTECTED]
Have the same issue running the following config:
* Windows 2000 SP2
* Apache 1.3.23 for Windows
* PHP 4.1.2 Apache SAPI module
Everything works fine with PHP 4.1.1 in place. Swapping in PHP 4.1.2,
sessions break. It appears possible to store session variables
INITIALLY using session_register(), but no updates to session variables
are ever stored in the session file.
Attempting to follow the PHP documentation and just use
$_SESSION--avoiding using session_register() altogether--does not work
at all. Attempting to create a session variable by doing something
like
as written in the documentation fails miserably. (Note the
documentation neglects the session_start() call, which I added since I
did not have autostart enabled.)
BACKGROUND:
Here is how I swapped 4.1.2 into place to test this (what I do whenever
a new release comes out now):
* All Internet-related info is stored under \InetPub
(holdover from my IIS days)
* Apache is configured to look in \InetPub\PHP\SAPI for
the PHP4APACHE.DLL file. All appropriate settings in
HTTPD.CONF file set for running PHP as module (vs. CGI).
* When a new PHP version is relea
Bug #16088 Updated: ini_set("session.save_handler", "user") causes segmentation fault
ID: 16088
Updated by: [EMAIL PROTECTED]
-Summary: ini_set("session.save_handler", "user") causes
segmentation fault
Reported By: [EMAIL PROTECTED]
Status: Duplicate
-Bug Type: PHP options/info functions
+Bug Type: Session related
Operating System: Redhat 7.2
PHP Version: 4.1.2
Previous Comments:
[2002-03-14 20:48:19] [EMAIL PROTECTED]
Further experimentations seems to show that the conflict is actually
having session auto start enabled, and having save_handler set to user
[2002-03-14 19:22:35] [EMAIL PROTECTED]
In my php.ini file I have "session.save_handler = files" for
compatibility reasons (so the other sites on my box will run).
I am developing a site that needs to store sessions in a mysql DB. I
have the session handler running fine when the php.ini file says
session.save_handler = user, but when I try to set it at runtime using
ini_set("session.save_handler", "user"), the child process dies:
'child pid 2167 exit signal Segmentation fault (11)'.
--
Edit this bug report at http://bugs.php.net/?id=16088&edit=1
Bug #16088 Updated: ini_set("session.save_handler", "user") causes segmentation fault
ID: 16088
Updated by: [EMAIL PROTECTED]
-Summary: ini_set("session.save_handler", "user") causes
segmentation fault
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Duplicate
Bug Type: PHP options/info functions
Operating System: Redhat 7.2
PHP Version: 4.1.2
Previous Comments:
[2002-03-14 20:48:19] [EMAIL PROTECTED]
Further experimentations seems to show that the conflict is actually
having session auto start enabled, and having save_handler set to user
[2002-03-14 19:22:35] [EMAIL PROTECTED]
In my php.ini file I have "session.save_handler = files" for
compatibility reasons (so the other sites on my box will run).
I am developing a site that needs to store sessions in a mysql DB. I
have the session handler running fine when the php.ini file says
session.save_handler = user, but when I try to set it at runtime using
ini_set("session.save_handler", "user"), the child process dies:
'child pid 2167 exit signal Segmentation fault (11)'.
--
Edit this bug report at http://bugs.php.net/?id=16088&edit=1
Bug #16069 Updated: ICONV transliteration failure
ID: 16069
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Analyzed
Bug Type: ICONV related
Operating System: win32, Linux
PHP Version: 4.1.2
New Comment:
I've fixed it whole ago for systems supports iconv in libc.
(Recent Linux/glibc is one of them)
For systems uses libiconv, there is problem still.
(I didn't fix problem with libiconv, since I don't use libiconv ;)
Previous Comments:
[2002-03-14 09:40:57] [EMAIL PROTECTED]
conversion between CP932(a variant of Shift_JIS charset) and any
Japanese charset other than CP932 unexpectantly failed when
transliteration mode is specified like "EUC-JP//TRANSLIT" on the output
encoding and the transliteration requires some larger buffer than
strlen(input_buf) * sizeof(ucs4_t).
testing script:
";
}
for( $i = 0; $i < 20; ++$i ) {
print $i.":".iconv( "EUC-JP", "Shift_JIS", iconv( "CP932",
"EUC-JP//TRANSLIT", "abcd".str_repeat( "", $i ) ) )."";
}
?>
where "" is ONE character described as "SQUARE MIRIBAARU" (0x876D)
and "" is ONE character described as "SQUARE AARU" (0x8765) on
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT
--
Edit this bug report at http://bugs.php.net/?id=16069&edit=1
Bug #16065 Updated: print_r() and var_dump() infinite loop.
ID: 16065 Updated by: [EMAIL PROTECTED] -Summary: var_dump() infinite loop. Problem occured after today's patch(np w/ 4.1.2) Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed Bug Type: Arrays related Operating System: RH 7.1 -PHP Version: 4.0CVS-2002-03-14 +PHP Version: 4.0CVS-2002-03-1 New Comment: Appearently, print_r() has the same problem :) Previous Comments: [2002-03-14 11:16:37] [EMAIL PROTECTED] Sorry - I misread the PR. [2002-03-14 10:34:34] [EMAIL PROTECTED] This bug has been fixed in CVS. [2002-03-14 09:26:22] [EMAIL PROTECTED] This piece of code causes infinite loop. If the commments are removed than this little scripts starts to eat memory too fast. 100MB for 15secs. When the physical RAM was not available started to eat from the swap. If var_export() is used no problems(with the CVS). With 4.1.2 only causes Fatal Error - too deep recursion. Proably this has something with Yasuo's patch that tried force var_dump() to work like print_r() - showing recursion not just crashing. -- Edit this bug report at http://bugs.php.net/?id=16065&edit=1
Bug #16088 Updated: ini_set("session.save_handler", "user") causes segmentation fault
ID: 16088
Updated by: [EMAIL PROTECTED]
-Summary: ini_set("session.save_handler", "user") causes
segmentation fault
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: PHP options/info functions
Operating System: Redhat 7.2
PHP Version: 4.1.2
New Comment:
Further experimentations seems to show that the conflict is actually
having session auto start enabled, and having save_handler set to user
Previous Comments:
[2002-03-14 19:22:35] [EMAIL PROTECTED]
In my php.ini file I have "session.save_handler = files" for
compatibility reasons (so the other sites on my box will run).
I am developing a site that needs to store sessions in a mysql DB. I
have the session handler running fine when the php.ini file says
session.save_handler = user, but when I try to set it at runtime using
ini_set("session.save_handler", "user"), the child process dies:
'child pid 2167 exit signal Segmentation fault (11)'.
--
Edit this bug report at http://bugs.php.net/?id=16088&edit=1
Bug #16088: ini_set("session.save_handler", "user") causes segmentation fault
From: [EMAIL PROTECTED]
Operating system: Redhat 7.2
PHP version: 4.1.2
PHP Bug Type: PHP options/info functions
Bug description: ini_set("session.save_handler", "user") causes segmentation fault
In my php.ini file I have "session.save_handler = files" for compatibility
reasons (so the other sites on my box will run).
I am developing a site that needs to store sessions in a mysql DB. I have
the session handler running fine when the php.ini file says
session.save_handler = user, but when I try to set it at runtime using
ini_set("session.save_handler", "user"), the child process dies:
'child pid 2167 exit signal Segmentation fault (11)'.
--
Edit bug report at http://bugs.php.net/?id=16088&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16088&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16088&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16088&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16088&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16088&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16088&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16088&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16088&r=submittedtwice
Bug #16087 Updated: Could not find/open font
ID: 16087
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: GD related
Operating System: Linux RedHat 6.2
PHP Version: 4.1.2
New Comment:
Use a full path. Font handling was changed in GD along the way, so if
you insist that it is a bug, report it to the GD people, not us.
Previous Comments:
[2002-03-14 19:06:31] [EMAIL PROTECTED]
Code:
Header ("Content-type: image/png");
$im = imagecreate (400, 30);
$black = ImageColorAllocate ($im, 0, 0, 0);
$white = ImageColorAllocate ($im, 255, 255, 255);
ImageTTFText ($im, 20, 0, 10, 20, $white, "./arial.ttf",
"Testing... Omega: Ω");
ImagePNG ($im);
ImageDestroy ($im);
As Result:
Warning: Could not find/open font in
/home/denis/public_html/rambler/test2.php on line 8
Warning: Could not find/open font in
/home/denis/public_html/rambler/test2.php on line 12
As i known, this is a old bug with all prev. versions, please fix it.
(and in 4.1.3-devCVS too)...
--
Edit this bug report at http://bugs.php.net/?id=16087&edit=1
Bug #16087: Could not find/open font
From: [EMAIL PROTECTED]
Operating system: Linux RedHat 6.2
PHP version: 4.1.2
PHP Bug Type: GD related
Bug description: Could not find/open font
Code:
Header ("Content-type: image/png");
$im = imagecreate (400, 30);
$black = ImageColorAllocate ($im, 0, 0, 0);
$white = ImageColorAllocate ($im, 255, 255, 255);
ImageTTFText ($im, 20, 0, 10, 20, $white, "./arial.ttf",
"Testing... Omega: Ω");
ImagePNG ($im);
ImageDestroy ($im);
As Result:
Warning: Could not find/open font in
/home/denis/public_html/rambler/test2.php on line 8
Warning: Could not find/open font in
/home/denis/public_html/rambler/test2.php on line 12
As i known, this is a old bug with all prev. versions, please fix it. (and
in 4.1.3-devCVS too)...
--
Edit bug report at http://bugs.php.net/?id=16087&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16087&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16087&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16087&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16087&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16087&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16087&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16087&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16087&r=submittedtwice
Bug #16043 Updated: $_SESSION can't use in PHP 4.1.2
ID: 16043
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: Windows XP
PHP Version: 4.1.2
New Comment:
I can confirm this with w2ksp2 + apache 1.3.23
Previous Comments:
[2002-03-14 15:58:47] [EMAIL PROTECTED]
Sample scripts to show symptoms.
The following script shows that NO session data is stored when you use
the new $_SESSION variables only as described in the PHP manual:
__
Simple PHP Session Test
Testing PHP Sessions...
";
foreach($_SESSION as $key => $value) {
echo "\$_SESSION['$key'] => '$value'";
}
//Set/Increment Counter
if ( !array_key_exists('counter', $_SESSION) ) {
$_SESSION['counter'] = 0;
} else {
$_SESSION['counter']++;
}
echo "Values at end of script:";
foreach($_SESSION as $key => $value) {
echo "\$_SESSION['$key'] => '$value'";
}
?>
__
And the modified version of this script uses the older
$HTTP_SESSION_VARS variable along with session_register(), to show that
session_register() creates the initial instance of a session variable,
but no updates occur after that. This is the best I've been able to do
with sessions in 4.1.2, so it's pretty useless at this point.
__
Simple PHP Session Test
Testing PHP Sessions...
";
foreach($HTTP_SESSION_VARS as $key => $value) {
echo "\$HTTP_SESSION_VARS['$key'] => '$value'";
}
//Set/Increment Counter
if ( !array_key_exists('counter', $HTTP_SESSION_VARS) ) {
$counter = 0;
session_register('counter');
} else {
$HTTP_SESSION_VARS['counter']++;
}
echo "Values at end of script:";
foreach($HTTP_SESSION_VARS as $key => $value) {
echo "\$HTTP_SESSION_VARS['$key'] => '$value'";
}
?>
__
P.S. For what it's worth, session files ARE created in the
session.save_path directory, but other than the latter script, the
files are always 0 bytes and completely empty. Hope this helps track
down the bug.
[2002-03-14 14:37:56] [EMAIL PROTECTED]
Also applies to NT 4.0 (sp6a) both Module and CGI $_SESSION
and also $HTTP_SESSION_VARS are dead. From what I can tell
the sess files get created in tmp ok, however nothing ever
gets written to it.
[2002-03-14 10:27:13] [EMAIL PROTECTED]
thank you for reply...
I test the $_SESSION use those 3 PHP file...
1.php
===
TEST';
echo 'SESSION';
foreach($_SESSION as $k => $v)
echo "$k => $v";
$_SESSION['a']='a';
?>
===
2.php
===
TEST';
echo 'SESSION';
foreach($_SESSION as $k => $v)
echo "$k => $v";
$_SESSION['b']='b';
?>
===
3.php
===
TEST';
echo 'SESSION';
foreach($_SESSION as $k => $v)
echo "$k => $v";
$_SESSION['c']='c';
?>
===
very simple...
I like use PHP 4.1.x new features($_GET, $_POST, $_SESSION... etc), so
I care about the $_SESSION can right work!
[2002-03-13 20:33:36] [EMAIL PROTECTED]
Have the same issue running the following config:
* Windows 2000 SP2
* Apache 1.3.23 for Windows
* PHP 4.1.2 Apache SAPI module
Everything works fine with PHP 4.1.1 in place. Swapping in PHP 4.1.2,
sessions break. It appears possible to store session variables
INITIALLY using session_register(), but no updates to session variables
are ever stored in the session file.
Attempting to follow the PHP documentation and just use
$_SESSION--avoiding using session_register() altogether--does not work
at all. Attempting to create a session variable by doing something
like
as written in the documentation fails miserably. (Note the
documentation neglects the session_start() call, which I added since I
did not have autostart enabled.)
BACKGROUND:
Here is how I swapped 4.1.2 into place to test this (what I do whenever
a new release comes out now):
* All Internet-related info is stored under \InetPub
(holdover from my IIS days)
* Apache is configured to look in \InetPub\PHP\SAPI for
the PHP4APACHE.DLL file. All appropriate settings in
HTTPD.CONF file set for running PHP as module (vs. CGI).
* When a new PHP version is released, I
1. Download the .ZIP file
2. Decompress into \InetPub (in this case creating
\InetPub\php-4.1.2-Win32\)
3. Copy PHP4TS.DLL into .\SAPI directory so it is in the
Bug #16086 Updated: dghnbdgnh
ID: 16086 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *Web Server problem Operating System: dgbhd PHP Version: 4.1.2 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Previous Comments: [2002-03-14 18:34:23] [EMAIL PROTECTED] dgndgndgndgndng -- Edit this bug report at http://bugs.php.net/?id=16086&edit=1
Bug #16086: dghnbdgnh
From: [EMAIL PROTECTED] Operating system: dgbhd PHP version: 4.1.2 PHP Bug Type: *Web Server problem Bug description: dghnbdgnh dgndgndgndgndng -- Edit bug report at http://bugs.php.net/?id=16086&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16086&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16086&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16086&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16086&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16086&r=support Expected behavior: http://bugs.php.net/fix.php?id=16086&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16086&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16086&r=submittedtwice
Bug #16085: Invalid access to memory location when accessing ANY php page
From: [EMAIL PROTECTED] Operating system: Windows 2000 Server PHP version: 4.1.2 PHP Bug Type: IIS related Bug description: Invalid access to memory location when accessing ANY php page With PHP 4.0.6 everything works fine. With PHP 4.1.0, 4.1.1 and 4.1.2 the following error occurs when browsing ANY php page: 'Invalid access to memory location.' That is the only feedback I get. PHP is installed as ISAPI on IIS 5.0 running on W2K Server. -- Edit bug report at http://bugs.php.net/?id=16085&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16085&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16085&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16085&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16085&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16085&r=support Expected behavior: http://bugs.php.net/fix.php?id=16085&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16085&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16085&r=submittedtwice
Bug #16060 Updated: Memory Access Violation
ID: 16060 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: Windows 2000 PHP Version: 4.1.2 New Comment: Just tried it with php 4.0.6 (allthough phpinfo() says 4.0.5) and everything works fine. btw it's Windows 2000 Server that I use. Previous Comments: [2002-03-14 17:14:38] [EMAIL PROTECTED] I have the exact same configuration. I just installed PHP 4.1.2 to work with the ISAPI module. When I visit ANY php page it gives the following error msg: "Invalid access to memory location." The CGI module still works ok. I was looking for version 4.1.1 to test if this one works, but it is not available on php.net any more. Could someone provide me a link to 4.1.1, so that I can see if it works with that one. [2002-03-14 04:57:28] [EMAIL PROTECTED] status -> feedback [2002-03-14 04:09:58] [EMAIL PROTECTED] Hi, Could you provide some information for us to work from? eg, what script in particular (if any) is causing this, and also some information on your environment. it doesn't crash for me. [2002-03-14 04:05:42] [EMAIL PROTECTED] We are using PHP 4.1.2 on IIS 5.0 on Windows 2000. PHP is running in ISAPI mode. We use to have Memory Access Violation in PHP 4.1.0, but the problem disappeared in version 4.1.1. We replace the version 4.1.1 by 4.1.2 this morning, and without changing anything else, we are getting Memory Access Violation every other pages. We are forced to go back to version 4.1.1 -- Edit this bug report at http://bugs.php.net/?id=16060&edit=1
Bug #16084: DLLs in the standard distribution using zlib need to be updated
From: [EMAIL PROTECTED] Operating system: Windows (any) PHP version: 4.0.5 PHP Bug Type: Zlib Related Bug description: DLLs in the standard distribution using zlib need to be updated The following DLLs in the standard, supported Win32 binary distribution appear to use ZLib, and need to be recompiled and repackaged, because a serious bug has been found in the deflate algorythm: php_cpdf.dll php_gd.dll php_pdf.dll php_zlib.dll Full information on the bug can be found in the related CERT advisory: http://www.kb.cert.org/vuls/id/368819 The updated zlib can be downloaded from its home page: http://www.gzip.org/zlib/ PS: sorry if this has been reported twice. However, I didn't find this bug in the database -- Edit bug report at http://bugs.php.net/?id=16084&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16084&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16084&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16084&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16084&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16084&r=support Expected behavior: http://bugs.php.net/fix.php?id=16084&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16084&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16084&r=submittedtwice
Bug #16060 Updated: Memory Access Violation
ID: 16060 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: Windows 2000 PHP Version: 4.1.2 New Comment: I have the exact same configuration. I just installed PHP 4.1.2 to work with the ISAPI module. When I visit ANY php page it gives the following error msg: "Invalid access to memory location." The CGI module still works ok. I was looking for version 4.1.1 to test if this one works, but it is not available on php.net any more. Could someone provide me a link to 4.1.1, so that I can see if it works with that one. Previous Comments: [2002-03-14 04:57:28] [EMAIL PROTECTED] status -> feedback [2002-03-14 04:09:58] [EMAIL PROTECTED] Hi, Could you provide some information for us to work from? eg, what script in particular (if any) is causing this, and also some information on your environment. it doesn't crash for me. [2002-03-14 04:05:42] [EMAIL PROTECTED] We are using PHP 4.1.2 on IIS 5.0 on Windows 2000. PHP is running in ISAPI mode. We use to have Memory Access Violation in PHP 4.1.0, but the problem disappeared in version 4.1.1. We replace the version 4.1.1 by 4.1.2 this morning, and without changing anything else, we are getting Memory Access Violation every other pages. We are forced to go back to version 4.1.1 -- Edit this bug report at http://bugs.php.net/?id=16060&edit=1
Bug #10686 Updated: Bug in "mktime()" on values out of bounds
ID: 10686
Updated by: [EMAIL PROTECTED]
-Summary: Bug in "mktime()" on values out of bounds
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Date/time related
-Operating System: MacOS X 10.0.2 (Darwin)
+Operating System: MacOS X 10.0.2 - 10.1.3 (Darwin)
PHP Version: 4.0.5 - 4.1.2
New Comment:
Happen on MacOS X 10.0.0 up to 10.1.3:
Darwin localhost 5.3 Darwin Kernel Version 5.3: Thu Jan 24
22:06:02 PST 2002; root:xnu/xnu-201.19.obj~1/RELEASE_PPC
Power Macintosh powerpc
Previous Comments:
[2002-03-14 17:01:07] [EMAIL PROTECTED]
I cannot see it fixed in 4.1.2. Try my fix ... that works!
01.02.2000 --> 949402800 --> 01.02.2000 12:00:00
00.02.2000 --> 949316400 --> 31.01.2000 12:00:00
-1.02.2000 --> 94923 --> 30.01.2000 12:00:00
01.03.2000 --> 951908400 --> 01.03.2000 12:00:00
00.03.2000 --> 951735600 --> 28.02.2000 12:00:00
-1.03.2000 --> 951649200 --> 27.02.2000 12:00:00
01.04.2000 --> 954583200 --> 01.04.2000 12:00:00
00.04.2000 --> 954410400 --> 30.03.2000 12:00:00
-1.04.2000 --> 954324000 --> 29.03.2000 12:00:00
01.05.2000 --> 957175200 --> 01.05.2000 12:00:00
00.05.2000 --> 957002400 --> 29.04.2000 12:00:00
-1.05.2000 --> 956916000 --> 28.04.2000 12:00:00
01.06.2000 --> 959853600 --> 01.06.2000 12:00:00
00.06.2000 --> 959680800 --> 30.05.2000 12:00:00
-1.06.2000 --> 959594400 --> 29.05.2000 12:00:00
=-1; $i--) {
$tm_mday=$i;
$tm_mon=$j;
printf ("%02d.%02d.%04d", $tm_mday,
$tm_mon,1900+$tm_year);
$tm = mktime(12,0,0,$tm_mon,$tm_mday,1900+
$tm_year);
echo " --> $tm";
echo " --> ".date("d.m.Y H:i:s", $tm);
echo "";
}
}
?>
[2002-01-08 16:06:23] [EMAIL PROTECTED]
This is reported fixed.
[2001-11-18 02:37:56] [EMAIL PROTECTED]
From: "Abner Diaz" <[EMAIL PROTECTED]>
I can verify the behavior of PHP Bug ID 10686 (http://
bugs.php.net/bug.php?id=10686), regarding mktime
malfunctions in OS X 10.1/Darwin 1.4. The fixes to
datetime.c posted by [EMAIL PROTECTED] worked well.
Thanks!
Sincerely,
Abner Diaz
[2001-10-23 09:03:49] [EMAIL PROTECTED]
Does it looks well? (Same in MacOS X 10.1 and Darwin 1.4.1)
[2001-08-18 21:30:34] [EMAIL PROTECTED]
i have a MacOSX box now so I'll test this out and submit it
if it looks good...
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/10686
--
Edit this bug report at http://bugs.php.net/?id=10686&edit=1
Bug #10686 Updated: Bug in "mktime()" on values out of bounds
ID: 10686
Updated by: [EMAIL PROTECTED]
-Summary: Bug in "mktime()" on values out of bounds
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type: Date/time related
Operating System: MacOS X 10.0.2 (Darwin)
-PHP Version: 4.0.5
+PHP Version: 4.0.5 - 4.1.2
New Comment:
I cannot see it fixed in 4.1.2. Try my fix ... that works!
01.02.2000 --> 949402800 --> 01.02.2000 12:00:00
00.02.2000 --> 949316400 --> 31.01.2000 12:00:00
-1.02.2000 --> 94923 --> 30.01.2000 12:00:00
01.03.2000 --> 951908400 --> 01.03.2000 12:00:00
00.03.2000 --> 951735600 --> 28.02.2000 12:00:00
-1.03.2000 --> 951649200 --> 27.02.2000 12:00:00
01.04.2000 --> 954583200 --> 01.04.2000 12:00:00
00.04.2000 --> 954410400 --> 30.03.2000 12:00:00
-1.04.2000 --> 954324000 --> 29.03.2000 12:00:00
01.05.2000 --> 957175200 --> 01.05.2000 12:00:00
00.05.2000 --> 957002400 --> 29.04.2000 12:00:00
-1.05.2000 --> 956916000 --> 28.04.2000 12:00:00
01.06.2000 --> 959853600 --> 01.06.2000 12:00:00
00.06.2000 --> 959680800 --> 30.05.2000 12:00:00
-1.06.2000 --> 959594400 --> 29.05.2000 12:00:00
=-1; $i--) {
$tm_mday=$i;
$tm_mon=$j;
printf ("%02d.%02d.%04d", $tm_mday,
$tm_mon,1900+$tm_year);
$tm = mktime(12,0,0,$tm_mon,$tm_mday,1900+
$tm_year);
echo " --> $tm";
echo " --> ".date("d.m.Y H:i:s", $tm);
echo "";
}
}
?>
Previous Comments:
[2002-01-08 16:06:23] [EMAIL PROTECTED]
This is reported fixed.
[2001-11-18 02:37:56] [EMAIL PROTECTED]
From: "Abner Diaz" <[EMAIL PROTECTED]>
I can verify the behavior of PHP Bug ID 10686 (http://
bugs.php.net/bug.php?id=10686), regarding mktime
malfunctions in OS X 10.1/Darwin 1.4. The fixes to
datetime.c posted by [EMAIL PROTECTED] worked well.
Thanks!
Sincerely,
Abner Diaz
[2001-10-23 09:03:49] [EMAIL PROTECTED]
Does it looks well? (Same in MacOS X 10.1 and Darwin 1.4.1)
[2001-08-18 21:30:34] [EMAIL PROTECTED]
i have a MacOSX box now so I'll test this out and submit it
if it looks good...
[2001-06-11 14:28:32] [EMAIL PROTECTED]
> you can use Darwin/Intel (see: http://www.darwinfo.de), if
Sorry. Informations about Darwin you can find on:
- http://www.darwinfo.org/
- http://www.apple.com/darwin/
Dieter
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/10686
--
Edit this bug report at http://bugs.php.net/?id=10686&edit=1
Bug #16043 Updated: $_SESSION can't use in PHP 4.1.2
ID: 16043
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: Windows XP
PHP Version: 4.1.2
New Comment:
Sample scripts to show symptoms.
The following script shows that NO session data is stored when you use
the new $_SESSION variables only as described in the PHP manual:
__
Simple PHP Session Test
Testing PHP Sessions...
";
foreach($_SESSION as $key => $value) {
echo "\$_SESSION['$key'] => '$value'";
}
//Set/Increment Counter
if ( !array_key_exists('counter', $_SESSION) ) {
$_SESSION['counter'] = 0;
} else {
$_SESSION['counter']++;
}
echo "Values at end of script:";
foreach($_SESSION as $key => $value) {
echo "\$_SESSION['$key'] => '$value'";
}
?>
__
And the modified version of this script uses the older
$HTTP_SESSION_VARS variable along with session_register(), to show that
session_register() creates the initial instance of a session variable,
but no updates occur after that. This is the best I've been able to do
with sessions in 4.1.2, so it's pretty useless at this point.
__
Simple PHP Session Test
Testing PHP Sessions...
";
foreach($HTTP_SESSION_VARS as $key => $value) {
echo "\$HTTP_SESSION_VARS['$key'] => '$value'";
}
//Set/Increment Counter
if ( !array_key_exists('counter', $HTTP_SESSION_VARS) ) {
$counter = 0;
session_register('counter');
} else {
$HTTP_SESSION_VARS['counter']++;
}
echo "Values at end of script:";
foreach($HTTP_SESSION_VARS as $key => $value) {
echo "\$HTTP_SESSION_VARS['$key'] => '$value'";
}
?>
__
P.S. For what it's worth, session files ARE created in the
session.save_path directory, but other than the latter script, the
files are always 0 bytes and completely empty. Hope this helps track
down the bug.
Previous Comments:
[2002-03-14 14:37:56] [EMAIL PROTECTED]
Also applies to NT 4.0 (sp6a) both Module and CGI $_SESSION
and also $HTTP_SESSION_VARS are dead. From what I can tell
the sess files get created in tmp ok, however nothing ever
gets written to it.
[2002-03-14 10:27:13] [EMAIL PROTECTED]
thank you for reply...
I test the $_SESSION use those 3 PHP file...
1.php
===
TEST';
echo 'SESSION';
foreach($_SESSION as $k => $v)
echo "$k => $v";
$_SESSION['a']='a';
?>
===
2.php
===
TEST';
echo 'SESSION';
foreach($_SESSION as $k => $v)
echo "$k => $v";
$_SESSION['b']='b';
?>
===
3.php
===
TEST';
echo 'SESSION';
foreach($_SESSION as $k => $v)
echo "$k => $v";
$_SESSION['c']='c';
?>
===
very simple...
I like use PHP 4.1.x new features($_GET, $_POST, $_SESSION... etc), so
I care about the $_SESSION can right work!
[2002-03-13 20:33:36] [EMAIL PROTECTED]
Have the same issue running the following config:
* Windows 2000 SP2
* Apache 1.3.23 for Windows
* PHP 4.1.2 Apache SAPI module
Everything works fine with PHP 4.1.1 in place. Swapping in PHP 4.1.2,
sessions break. It appears possible to store session variables
INITIALLY using session_register(), but no updates to session variables
are ever stored in the session file.
Attempting to follow the PHP documentation and just use
$_SESSION--avoiding using session_register() altogether--does not work
at all. Attempting to create a session variable by doing something
like
as written in the documentation fails miserably. (Note the
documentation neglects the session_start() call, which I added since I
did not have autostart enabled.)
BACKGROUND:
Here is how I swapped 4.1.2 into place to test this (what I do whenever
a new release comes out now):
* All Internet-related info is stored under \InetPub
(holdover from my IIS days)
* Apache is configured to look in \InetPub\PHP\SAPI for
the PHP4APACHE.DLL file. All appropriate settings in
HTTPD.CONF file set for running PHP as module (vs. CGI).
* When a new PHP version is released, I
1. Download the .ZIP file
2. Decompress into \InetPub (in this case creating
\InetPub\php-4.1.2-Win32\)
3. Copy PHP4TS.DLL into .\SAPI directory so it is in the
the same directory with PHP4APACHE.DLL.
4. Compare new PHP.INI-DIST and PHP.INI-RECOMMENDED
against my %SYSTEMROOT%\PHP.INI file, and make
ad
Bug #16083: Index missing in page-per-function HTML docs
From: [EMAIL PROTECTED] Operating system: RH 7.2 PHP version: 4.1.2 PHP Bug Type: Documentation problem Bug description: Index missing in page-per-function HTML docs For reasons unknown, the latest release of the PHP documentation tarball is missing a functions index, which used to be called index.functions.html. Given that there's no search function on the local DB, it was extremely useful to have that around. -- Edit bug report at http://bugs.php.net/?id=16083&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16083&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16083&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16083&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16083&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16083&r=support Expected behavior: http://bugs.php.net/fix.php?id=16083&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16083&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16083&r=submittedtwice
Bug #16082: libmm 1.1.3 session save handler = crash
From: [EMAIL PROTECTED] Operating system: Linux Redhat 7.1 PHP version: 4.1.2 PHP Bug Type: Reproducible crash Bug description: libmm 1.1.3 session save handler = crash I am trying to get php 4.1.2 working with mm support (libmm 1.1.3) to act as my session save handler. I have a 100% reproducable segfault w/ apache 1.3.23. I have been able to reproduce this on Redhat 7.1 and Mandrake 8.1, with 2 different machines. This happens with and w/o the Zend Optimizer. The gdb stack dump here shows that I was running the Optimizer at the time. My php configure line is as follows: ./configure \ --with-mm=/usr/local \ --with-apxs=/usr/local/apache/bin/apxs \ --disable-debug (normally, I have a bunch of other items in the configure line, but I wanted to narrow the crash down to the least amount of variables) The php script is very simple: Here is the gdb output: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 28561)] 0x402ae4f9 in ps_srlzr_decode_php (val=0x81066ec "", vallen=135269900) at session.c:394 394 if (++q >= endptr) goto break_outer_loop; (gdb) bt #0 0x402ae4f9 in ps_srlzr_decode_php (val=0x81066ec "", vallen=135269900) at session.c:394 #1 0x402ae8b1 in php_session_decode (val=0x81066ec "", vallen=135269900) at session.c:457 #2 0x402aeb03 in php_session_initialize () at session.c:524 #3 0x402afbb2 in php_session_start () at session.c:890 #4 0x402b0e55 in zif_session_start (ht=0, return_value=0x8100dec, this_ptr=0x0, return_value_used=0) at session.c:1264 #5 0x443ef70b in zend_assign_to_variable_reference () from /usr/local/Zend/lib/ZendOptimizer.so #6 0x443f9325 in zend_oe () from /usr/local/Zend/lib/ZendOptimizer.so #7 0x402752e4 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:814 #8 0x40282b85 in php_execute_script (primary_file=0xb440) at main.c:1307 #9 0x4027ecf2 in apache_php_module_main (r=0x80f9a74, display_source_mode=0) at sapi_apache.c:90 #10 0x4027f7ce in send_php (r=0x80f9a74, display_source_mode=0, filename=0x0) at mod_php4.c:575 #11 0x4027f822 in send_parsed_php (r=0x80f9a74) at mod_php4.c:590 #12 0x080727b7 in ap_invoke_handler () #13 0x080869ff in process_request_internal () #14 0x08086a60 in ap_process_request () #15 0x0807de6d in child_main () #16 0x0807e0db in make_child () #17 0x0807e18c in startup_children () #18 0x0807e808 in standalone_main () #19 0x0807f067 in main () #20 0x40111627 in __libc_start_main (main=0x807ecc8 , argc=1, ubp_av=0xb884, init=0x804e760 <_init>, fini=0x809c0c0 <_fini>, rtld_fini=0x4000dcc4 <_dl_fini>, stack_end=0xb87c) at ../sysdeps/generic/libc-start.c:129 -- Edit bug report at http://bugs.php.net/?id=16082&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16082&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16082&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16082&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16082&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16082&r=support Expected behavior: http://bugs.php.net/fix.php?id=16082&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16082&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16082&r=submittedtwice
Bug #16081 Updated: doesn't seem to honor fopen stdin position in code
ID: 16081 Updated by: [EMAIL PROTECTED] -Summary: doesn't seem to honor fopen stdin position in code Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Output Control Operating System: tru64 5.0a PHP Version: 4.1.2 New Comment: Maybe it's your terminal buffering? Have you tried with 'flush();' after your print statements? Previous Comments: [2002-03-14 14:51:20] [EMAIL PROTECTED] It appears that if I have a fopen to stdin anywhere in my code that PHP will prompt for stdin at the beginning of its execution instead of where I put it in the code. The following example shows it: #!/usr/local/bin/php Now as soon as I execute it, it sits and waits for me to enter stdin, then prints BEFORE AFTER It should be showing BEFORE and then prompt for STDIN, unless there is something major I am missing here. -- Edit this bug report at http://bugs.php.net/?id=16081&edit=1
Bug #16081: doesn't seem to honor fopen stdin position in code
From: [EMAIL PROTECTED] Operating system: tru64 5.0a PHP version: 4.1.2 PHP Bug Type: Output Control Bug description: doesn't seem to honor fopen stdin position in code It appears that if I have a fopen to stdin anywhere in my code that PHP will prompt for stdin at the beginning of its execution instead of where I put it in the code. The following example shows it: #!/usr/local/bin/php Now as soon as I execute it, it sits and waits for me to enter stdin, then prints BEFORE AFTER It should be showing BEFORE and then prompt for STDIN, unless there is something major I am missing here. -- Edit bug report at http://bugs.php.net/?id=16081&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16081&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16081&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16081&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16081&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16081&r=support Expected behavior: http://bugs.php.net/fix.php?id=16081&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16081&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16081&r=submittedtwice
Bug #16080 Updated: Segmentation fault
ID: 16080 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Scripting Engine problem Operating System: Linux -PHP Version: 4.1.1 +PHP Version: 4.3.0-dev New Comment: Previous Comments: [2002-03-14 14:41:59] [EMAIL PROTECTED] Reproduced with latest CVS. [2002-03-14 14:38:04] [EMAIL PROTECTED] following php code give me a segmention fault: -- Edit this bug report at http://bugs.php.net/?id=16080&edit=1
Bug #16080 Updated: Segmentation fault
ID: 16080 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed -Bug Type: *General Issues +Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.1.1 New Comment: Reproduced with latest CVS. Previous Comments: [2002-03-14 14:38:04] [EMAIL PROTECTED] following php code give me a segmention fault: -- Edit this bug report at http://bugs.php.net/?id=16080&edit=1
Bug #16080: Segmentation fault
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.1 PHP Bug Type: *General Issues Bug description: Segmentation fault following php code give me a segmention fault: -- Edit bug report at http://bugs.php.net/?id=16080&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16080&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16080&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16080&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16080&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16080&r=support Expected behavior: http://bugs.php.net/fix.php?id=16080&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16080&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16080&r=submittedtwice
Bug #16043 Updated: $_SESSION can't use in PHP 4.1.2
ID: 16043 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Windows XP PHP Version: 4.1.2 New Comment: Also applies to NT 4.0 (sp6a) both Module and CGI $_SESSION and also $HTTP_SESSION_VARS are dead. From what I can tell the sess files get created in tmp ok, however nothing ever gets written to it. Previous Comments: [2002-03-14 10:27:13] [EMAIL PROTECTED] thank you for reply... I test the $_SESSION use those 3 PHP file... 1.php === TEST'; echo 'SESSION'; foreach($_SESSION as $k => $v) echo "$k => $v"; $_SESSION['a']='a'; ?> === 2.php === TEST'; echo 'SESSION'; foreach($_SESSION as $k => $v) echo "$k => $v"; $_SESSION['b']='b'; ?> === 3.php === TEST'; echo 'SESSION'; foreach($_SESSION as $k => $v) echo "$k => $v"; $_SESSION['c']='c'; ?> === very simple... I like use PHP 4.1.x new features($_GET, $_POST, $_SESSION... etc), so I care about the $_SESSION can right work! [2002-03-13 20:33:36] [EMAIL PROTECTED] Have the same issue running the following config: * Windows 2000 SP2 * Apache 1.3.23 for Windows * PHP 4.1.2 Apache SAPI module Everything works fine with PHP 4.1.1 in place. Swapping in PHP 4.1.2, sessions break. It appears possible to store session variables INITIALLY using session_register(), but no updates to session variables are ever stored in the session file. Attempting to follow the PHP documentation and just use $_SESSION--avoiding using session_register() altogether--does not work at all. Attempting to create a session variable by doing something like as written in the documentation fails miserably. (Note the documentation neglects the session_start() call, which I added since I did not have autostart enabled.) BACKGROUND: Here is how I swapped 4.1.2 into place to test this (what I do whenever a new release comes out now): * All Internet-related info is stored under \InetPub (holdover from my IIS days) * Apache is configured to look in \InetPub\PHP\SAPI for the PHP4APACHE.DLL file. All appropriate settings in HTTPD.CONF file set for running PHP as module (vs. CGI). * When a new PHP version is released, I 1. Download the .ZIP file 2. Decompress into \InetPub (in this case creating \InetPub\php-4.1.2-Win32\) 3. Copy PHP4TS.DLL into .\SAPI directory so it is in the the same directory with PHP4APACHE.DLL. 4. Compare new PHP.INI-DIST and PHP.INI-RECOMMENDED against my %SYSTEMROOT%\PHP.INI file, and make adjustments accordingly (like the new cgi. entries). 5. Shutdown Apache service. 6. Rename '\InetPub\PHP' to '\InetPub\PHP v4.1.1' 7. Rename '\InetPub\php-4.1.2-Win32' to '\InetPub\PHP' 8. Restart Apache service. 9. Test the new config by running a VER.PHP file which contains 10. Run various test scripts to validate sessions, etc., looking at the session files created to make sure variables are created/updated/etc. Testing an old version against a new version is then simple. I simply 1. Shutdown Apache service. 2. Rename '\InetPub\PHP' to '\InetPub\PHP_version_in_use' 3. Rename '\InetPub\PHP_version_to_test' to '\InetPub\PHP' 4. Restart Apache service. and run the same tests. With the introduction of PHP 4.1.0, I have started changing my PHP test scripts to make use of $_SESSION. If you would like, I can provide a set that may help show what's going on (or not going on in this case). In a nutshell, currently PHP v4.1.2 is useless for session management, at least the Apache for Windows SAPI module. Due to the various security concerns with CGIs, etc., I am hesitant to go back to that. If I find time to test the CGI version, I'll post here. [2002-03-13 10:40:05] [EMAIL PROTECTED] as title, the global var. array $_SESSION can't use in PHP 4.1.2 (4.1.1/4.1.0 are OK) P.S. I install PHP in Apache 1.3.23 modules -- Edit this bug report at http://bugs.php.net/?id=16043&edit=1
Bug #16070 Updated: Set any variable after error occur..
ID: 16070 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Variables related Operating System: Windows, Unix BSD, Linux RedHat PHP Version: 4.1.2 New Comment: This is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Previous Comments: [2002-03-14 10:01:14] [EMAIL PROTECTED] -- Edit this bug report at http://bugs.php.net/?id=16070&edit=1
Bug #16079: Allow '.' (concat) operator on static strings
From: [EMAIL PROTECTED] Operating system: All PHP version: 4.1.1 PHP Bug Type: Feature/Change Request Bug description: Allow '.' (concat) operator on static strings I can understand requiring constants for static initialization. But can the parser be modified to support operators on constants for static initializations? This is especially true for long strings which I can't even break at the end of line for readability. (I almost submitted this as a bug :) Examples: $v = 1 + 2; // Okay static $s = 1 + 2; // Fails parse $v = "this long " ."string"; // Okay static $s = "this long " ."string"; // Fails parse Since only constants are involved the parser could collapse the expression without difficulty. This makes the code much more readable (again thinking of very long strings). In my case I'm building an array of error messages and don't want the array build to occur everytime the function is called, hence I made it static. -- Edit bug report at http://bugs.php.net/?id=16079&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16079&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16079&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16079&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16079&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16079&r=support Expected behavior: http://bugs.php.net/fix.php?id=16079&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16079&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16079&r=submittedtwice
Bug #16078 Updated: var_export() doesn't handle classes
ID: 16078 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Variables related Operating System: Linux 2.4 PHP Version: 4.0CVS-2002-03-14 New Comment: I think it will not be too hard because var_export() borrowed much of its code from var_dump() Previous Comments: [2002-03-14 13:00:39] [EMAIL PROTECTED] re-categorized [2002-03-14 12:57:48] [EMAIL PROTECTED] Can we make var_export() handle classes, too? - Colin -- Edit this bug report at http://bugs.php.net/?id=16078&edit=1
Bug #16076 Updated: apache 2.0.32 sapi_apache2.c compile failure
ID: 16076 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache2 related Operating System: linux 2.4.17 PHP Version: 4.1.2 New Comment: Addendum: tried the latest latest version http://snaps.php.net/php4-200203140900.tar.gz to see if that might make a difference. Different error, but still looks related: /usr/local/src/php4-200203140900/sapi/apache/sapi_apache.c: In function `apache_php_module_main': /usr/local/src/php4-200203140900/sapi/apache/sapi_apache.c:81: `NOT_FOUND' undeclared (first use in this function) /usr/local/src/php4-200203140900/sapi/apache/sapi_apache.c:81: (Each undeclared identifier is reported only once /usr/local/src/php4-200203140900/sapi/apache/sapi_apache.c:81: for each function it appears in.) make: *** [sapi/apache/sapi_apache.lo] Error 1 Previous Comments: [2002-03-14 12:15:15] [EMAIL PROTECTED] ./configure --with-mysql --with-apxs2=/usr/local/bin/apxs no problem make ... Making all in sapi make[1]: Entering directory `/usr/local/src/php-4.1.2/sapi' Making all in apache2filter make[2]: Entering directory `/usr/local/src/php-4.1.2/sapi/apache2filter' make[3]: Entering directory `/usr/local/src/php-4.1.2/sapi/apache2filter' /bin/sh /usr/local/src/php-4.1.2/libtool --silent --mode=compile /usr/local/src/php-4.1.2/meta_ccld -I. -I/usr/local/src/php-4.1.2/sapi/apache2filter -I/usr/local/src/php-4.1.2/main -I/usr/local/src/php-4.1.2 -I/usr/local/include -I/usr/local/src/php-4.1.2/Zend -I/usr/local/src/php-4.1.2/ext/mysql/libmysql -I/usr/local/src/php-4.1.2/ext/xml/expat -D_REENTRANT -I/usr/local/src/php-4.1.2/TSRM -DTHREAD=1 -O3 -march=i686 -pthread -DZTS -prefer-pic -c sapi_apache2.csapi_apache2.c: In function `php_apache_sapi_register_variables': sapi_apache2.c:148: warning: initialization discards qualifiers from pointer target type sapi_apache2.c: In function `php_input_filter': sapi_apache2.c:247: incompatible type for argument 4 of `ap_get_brigade' sapi_apache2.c:247: too few arguments to function `ap_get_brigade' sapi_apache2.c: In function `php_register_hook': sapi_apache2.c:408: warning: passing arg 2 of `ap_register_input_filter' from incompatible pointer type make[3]: *** [sapi_apache2.lo] Error 1 make[3]: Leaving directory `/usr/local/src/php-4.1.2/sapi/apache2filter' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/php-4.1.2/sapi/apache2filter' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/php-4.1.2/sapi' make: *** [all-recursive] Error 1 -- Edit this bug report at http://bugs.php.net/?id=16076&edit=1
Bug #16078 Updated: var_export() doesn't handle classes
ID: 16078 Updated by: [EMAIL PROTECTED] -Summary: var_export() doesn't handle classes Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Feature/Change Request +Bug Type: Variables related Operating System: Linux 2.4 PHP Version: 4.0CVS-2002-03-14 New Comment: re-categorized Previous Comments: [2002-03-14 12:57:48] [EMAIL PROTECTED] Can we make var_export() handle classes, too? - Colin -- Edit this bug report at http://bugs.php.net/?id=16078&edit=1
Bug #16078: var_export() doesn't handle classes
From: [EMAIL PROTECTED] Operating system: Linux 2.4 PHP version: 4.0CVS-2002-03-14 PHP Bug Type: Feature/Change Request Bug description: var_export() doesn't handle classes Can we make var_export() handle classes, too? - Colin -- Edit bug report at http://bugs.php.net/?id=16078&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16078&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16078&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16078&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16078&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16078&r=support Expected behavior: http://bugs.php.net/fix.php?id=16078&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16078&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16078&r=submittedtwice
Bug #16077: Large output data causes output buffering to crash
From: [EMAIL PROTECTED]
Operating system: RH Linux 2.4.9-31
PHP version: 4.1.1
PHP Bug Type: Output Control
Bug description: Large output data causes output buffering to crash
This script causes PHP to crash (sigsegv, return nothing OR to cause wget
to tell "HTTP request sent, awaiting response... End of file while parsing
headers. Retrying.") almost any time. The include.txt file I used was
larger than 100k and was just a simple text. The content of the file is
not important at all, I tried several versions.
\n";
}
$startTime = getMicrotime();
ob_start("timer");
for ($i = 0; $i < 500; $i++)
{
$fh = fopen("include.txt", "r");
$cmd = fread($fh, 1048576);
fclose($fh);
echo "$i $cmd\n";
}
?>
I compiled PHP with
./configure --prefix=/usr/local/php --disable-short-tags
--enable-safe-mode --enable-ftp --with-mysql=/usr/local/mysql --with-zlib
--enable-memory-limit
--
Edit bug report at http://bugs.php.net/?id=16077&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16077&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16077&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16077&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16077&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16077&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16077&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16077&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16077&r=submittedtwice
Bug #7237 Updated: PHP Isapi Filter fails after some consecutive uses
ID: 7237 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: IIS related Operating System: Windows NT Server 4.0 PHP Version: 4.0.3pl1 New Comment: Yes, does occur with version 4.1.2. Previous Comments: [2002-01-03 17:57:16] [EMAIL PROTECTED] No feedback. Closed. [2001-12-13 14:39:36] [EMAIL PROTECTED] Does this problem still exist with the PHP 4.1.0? [2001-05-03 12:00:10] [EMAIL PROTECTED] unfortunately, it's even worse now: 4.0.4 was unstable, but now PHP 4.0.5 in ISAPI mode brings my inetinfo.exe (W3SVC service) down, even with a simple phpinfo() Back to CGI mode everything goes fine. I'll try with other machines just in case, but this is what happens in my WinNT4 machine... [2001-05-01 05:48:40] [EMAIL PROTECTED] Please check 4.0.5. Some multi-threading issues have been improved and let us know if it still doesn't work for you. [2001-03-07 04:30:24] [EMAIL PROTECTED] First: I didn't write the comment [2001-03-06 04:51:50] so I'd like an explanation please. Who has written anything using my name? Now with the bug: It also seems to happen with 4.0.4pl1. But attention! Everything goes fine (several clients bashing the web server) until a Database query is made. We use MSSQL7. After several pages with a simple query to MSSQL7 (some of them concurrent from different machines), those pages fail to show up. However, the page with the DB query fails to show. Perhaps php_mssql module is not re-entrant, or perhaps it is a problem of the whole module thing. We are going to test this against an Oracle8 DB (php_oci8 module). 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/7237 -- Edit this bug report at http://bugs.php.net/?id=7237&edit=1
Bug #16076: apache 2.0.32 sapi_apache2.c compile failure
From: [EMAIL PROTECTED] Operating system: linux 2.4.17 PHP version: 4.1.2 PHP Bug Type: Apache2 related Bug description: apache 2.0.32 sapi_apache2.c compile failure ./configure --with-mysql --with-apxs2=/usr/local/bin/apxs no problem make ... Making all in sapi make[1]: Entering directory `/usr/local/src/php-4.1.2/sapi' Making all in apache2filter make[2]: Entering directory `/usr/local/src/php-4.1.2/sapi/apache2filter' make[3]: Entering directory `/usr/local/src/php-4.1.2/sapi/apache2filter' /bin/sh /usr/local/src/php-4.1.2/libtool --silent --mode=compile /usr/local/src/php-4.1.2/meta_ccld -I. -I/usr/local/src/php-4.1.2/sapi/apache2filter -I/usr/local/src/php-4.1.2/main -I/usr/local/src/php-4.1.2 -I/usr/local/include -I/usr/local/src/php-4.1.2/Zend -I/usr/local/src/php-4.1.2/ext/mysql/libmysql -I/usr/local/src/php-4.1.2/ext/xml/expat -D_REENTRANT -I/usr/local/src/php-4.1.2/TSRM -DTHREAD=1 -O3 -march=i686 -pthread -DZTS -prefer-pic -c sapi_apache2.csapi_apache2.c: In function `php_apache_sapi_register_variables': sapi_apache2.c:148: warning: initialization discards qualifiers from pointer target type sapi_apache2.c: In function `php_input_filter': sapi_apache2.c:247: incompatible type for argument 4 of `ap_get_brigade' sapi_apache2.c:247: too few arguments to function `ap_get_brigade' sapi_apache2.c: In function `php_register_hook': sapi_apache2.c:408: warning: passing arg 2 of `ap_register_input_filter' from incompatible pointer type make[3]: *** [sapi_apache2.lo] Error 1 make[3]: Leaving directory `/usr/local/src/php-4.1.2/sapi/apache2filter' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/php-4.1.2/sapi/apache2filter' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/php-4.1.2/sapi' make: *** [all-recursive] Error 1 -- Edit bug report at http://bugs.php.net/?id=16076&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16076&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16076&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16076&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16076&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16076&r=support Expected behavior: http://bugs.php.net/fix.php?id=16076&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16076&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16076&r=submittedtwice
Bug #16065 Updated: var_dump() infinite loop. Problem occured after today's patch(np w/ 4.1.2)
ID: 16065 Updated by: [EMAIL PROTECTED] -Summary: var_dump() infinite loop. Problem occured after today's patch(np w/ 4.1.2) Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: Arrays related Operating System: RH 7.1 PHP Version: 4.0CVS-2002-03-14 New Comment: Sorry - I misread the PR. Previous Comments: [2002-03-14 10:34:34] [EMAIL PROTECTED] This bug has been fixed in CVS. [2002-03-14 09:26:22] [EMAIL PROTECTED] This piece of code causes infinite loop. If the commments are removed than this little scripts starts to eat memory too fast. 100MB for 15secs. When the physical RAM was not available started to eat from the swap. If var_export() is used no problems(with the CVS). With 4.1.2 only causes Fatal Error - too deep recursion. Proably this has something with Yasuo's patch that tried force var_dump() to work like print_r() - showing recursion not just crashing. -- Edit this bug report at http://bugs.php.net/?id=16065&edit=1
Bug #16075: Logon fonction (usiong invoke) doesn't work in CGI, but in standalone
From: [EMAIL PROTECTED]
Operating system: WinNT 4
PHP version: 4.1.2
PHP Bug Type: COM related
Bug description: Logon fonction (usiong invoke) doesn't work in CGI, but in standalone
Trying to access Exchange datas using COM objects, something matters, even
if the code is well : impossible to logon on a MAPI Session.
Configuration : NT 4, Apache 1.3.23, PHP 4.1.2 (but before too) in cgi
mode.
the code is :
Version."";
$err=$instance->Logon("Pascal Guimier","",true,false);
$inbox=$instance->Inbox;
$collmsg=$inbox->Messages;
$msg=$collmsg->GetFirst();
while ($msg) {
print "Subject : ". $msg->Subject . "";
$msg=$collmsg->GetNext();
}
?>
And there is always an error message :
"Warning: Invoke() failed: Une exception s'est produite. Source:
Collaboration Data Objects Description: [Collaboration Data Objects -
[MAPI_E_LOGON_FAILED(80040111)]] in
d:\users\group\www\essais\com\mboxlist.php on line 5"
"Une exception s'est produite" means there was an exception.
So I tried in several manners, and what is troubling is that launching the
script at command line (>php d:\users\group\www\essais\com\mboxlist.php)
works well !
That's why I think the bug can be in COM invoke() function, that doesn't
work the shame in two cases.
But it's only a supposition.
So now I only can use my scripts in cron to make a chache in order to
fetch Exchange datas :o)
Thanks
Pascal
--
Edit bug report at http://bugs.php.net/?id=16075&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16075&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16075&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16075&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16075&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16075&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16075&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16075&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16075&r=submittedtwice
Bug #16071 Updated: foreach return bogus data on 1 row multi-dim array
ID: 16071
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Arrays related
Operating System: Win 2000
PHP Version: 4.1.0
New Comment:
Noticed the errors not in foreach, but in the pass. PHP kills the outer
array if theres only one element in it in a pass. Thats still a bug.
Previous Comments:
[2002-03-14 10:10:06] [EMAIL PROTECTED]
I have code that traps all errors in a multidimentional array. The
array is structured so each row has a numerical key (ie $errors[] =
array('err_code'=>12, 'err_file'=>'happy.php');). You get the idea. For
error handling I have a function within a class that will accept an
error array and do output based on it. The function is as follows:
function pass_err_row($errors, $default_val=NULL, $override_val=NULL) {
// Throw errors based on err_file or default
if (is_null($default_val))
{$default_val=PATH_TO_ROOT.LOC_ERROR."DEFAULT/errors.php";}
if (!is_null($override_val)) {
foreach($errors as $error_row) {
include($override_val);
}
}
else {
foreach($errors as $error_row) {
if ($error_row['handle_file']!==FALSE &&
$error_row['handle_file']!=="") {
include($error_row['handle_file']);
}
else {
include($default_val);
}
}
}
}
This works great as long as the array passed has more than one error
(each error being another array) in it. So if $errors[0] and $errors[1]
both exist, everything works. Where it gets really wacky is if only
$errors[0] exists then the foreach loops results in very strange
results. Each error array row in $errors consists of the following 8
indexes:
'err_no', 'err_text', 'err_file', 'err_line', 'system_err',
'handle_file', 'handle_code', 'severity'.
What happens is the foreach loops 8 times with $error_row being equal
not to the array in $errors[0] but being equal to an value in the sub
array. So the first result would be the equivalent of
$errors[0]['err_no']'s value. $errors is still an array, so why would
the for each instead use the sub array? very weird.
--
Edit this bug report at http://bugs.php.net/?id=16071&edit=1
Bug #16074 Updated: CVS function var_export() can't handle recursive arrays
ID: 16074 Updated by: [EMAIL PROTECTED] -Summary: CVS function var_export() can't handle recursive arrays Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Variables related Operating System: RH 7.1 PHP Version: 4.0CVS-2002-03-14 New Comment: var_export() isn't meant for recursive structures, fixing this makes no sense. Derick Previous Comments: [2002-03-14 10:39:24] [EMAIL PROTECTED] The problem is similar to var_dump(). var_dump() is fixed by Yasuo today but another one raised (see Bug#16065) var_export() has to handle recursive dependencies better and the fatal error is not an option. Here is the script: and the ouput: bash-2.04$ ../php export.php X-Powered-By: PHP/4.3.0-dev Content-type: text/html array ( 0 => array ( 0 => array ( 0 => array ( PHP Fatal error: Nesting level too deep - recursive dependency? in /usr/samba/users/andy/412dev/php4-200203140300/te/export.php on line 4 Fatal error: Nesting level too deep - recursive dependency? in /usr/samba/users/andy/412dev/php4-200203140300/te/export.php on line 4 Possible fix is another parameter(string) with var_export()-ed variable name - this will fix if the array has element which is reference to the array but will not handle this : that crashes with output : array ( 0 => 1, 1 => 2, 2 => array ( 0 => 1, 1 => 2, 2 => array ( 0 => 1, 1 => 2, 2 => array ( 0 => 1, 1 => 2, 2 => array ( PHP Fatal error: Nesting level too deep - recursive dependency? in /usr/samba/users/andy/412dev/php4-200203140300/te/export.php on line 6 Fatal error: Nesting level too deep - recursive dependency? in /usr/samba/users/andy/412dev/php4-200203140300/te/export.php on line 6 -- Edit this bug report at http://bugs.php.net/?id=16074&edit=1
Bug #16074: CVS function var_export() can't handle recursive arrays
From: [EMAIL PROTECTED] Operating system: RH 7.1 PHP version: 4.0CVS-2002-03-14 PHP Bug Type: Variables related Bug description: CVS function var_export() can't handle recursive arrays The problem is similar to var_dump(). var_dump() is fixed by Yasuo today but another one raised (see Bug#16065) var_export() has to handle recursive dependencies better and the fatal error is not an option. Here is the script: and the ouput: bash-2.04$ ../php export.php X-Powered-By: PHP/4.3.0-dev Content-type: text/html array ( 0 => array ( 0 => array ( 0 => array ( PHP Fatal error: Nesting level too deep - recursive dependency? in /usr/samba/users/andy/412dev/php4-200203140300/te/export.php on line 4 Fatal error: Nesting level too deep - recursive dependency? in /usr/samba/users/andy/412dev/php4-200203140300/te/export.php on line 4 Possible fix is another parameter(string) with var_export()-ed variable name - this will fix if the array has element which is reference to the array but will not handle this : that crashes with output : array ( 0 => 1, 1 => 2, 2 => array ( 0 => 1, 1 => 2, 2 => array ( 0 => 1, 1 => 2, 2 => array ( 0 => 1, 1 => 2, 2 => array ( PHP Fatal error: Nesting level too deep - recursive dependency? in /usr/samba/users/andy/412dev/php4-200203140300/te/export.php on line 6 Fatal error: Nesting level too deep - recursive dependency? in /usr/samba/users/andy/412dev/php4-200203140300/te/export.php on line 6 -- Edit bug report at http://bugs.php.net/?id=16074&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16074&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16074&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16074&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16074&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16074&r=support Expected behavior: http://bugs.php.net/fix.php?id=16074&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16074&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16074&r=submittedtwice
Bug #16065 Updated: var_dump() infinite loop. Problem occured after today's patch(np w/ 4.1.2)
ID: 16065 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Arrays related Operating System: RH 7.1 PHP Version: 4.0CVS-2002-03-14 New Comment: This bug has been fixed in CVS. Previous Comments: [2002-03-14 09:26:22] [EMAIL PROTECTED] This piece of code causes infinite loop. If the commments are removed than this little scripts starts to eat memory too fast. 100MB for 15secs. When the physical RAM was not available started to eat from the swap. If var_export() is used no problems(with the CVS). With 4.1.2 only causes Fatal Error - too deep recursion. Proably this has something with Yasuo's patch that tried force var_dump() to work like print_r() - showing recursion not just crashing. -- Edit this bug report at http://bugs.php.net/?id=16065&edit=1
Bug #16043 Updated: $_SESSION can't use in PHP 4.1.2
ID: 16043 Updated by: [EMAIL PROTECTED] -Summary: $_SESSION can't use in PHP 4.1.2 Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Windows XP PHP Version: 4.1.2 New Comment: thank you for reply... I test the $_SESSION use those 3 PHP file... 1.php === TEST'; echo 'SESSION'; foreach($_SESSION as $k => $v) echo "$k => $v"; $_SESSION['a']='a'; ?> === 2.php === TEST'; echo 'SESSION'; foreach($_SESSION as $k => $v) echo "$k => $v"; $_SESSION['b']='b'; ?> === 3.php === TEST'; echo 'SESSION'; foreach($_SESSION as $k => $v) echo "$k => $v"; $_SESSION['c']='c'; ?> === very simple... I like use PHP 4.1.x new features($_GET, $_POST, $_SESSION... etc), so I care about the $_SESSION can right work! Previous Comments: [2002-03-13 20:33:36] [EMAIL PROTECTED] Have the same issue running the following config: * Windows 2000 SP2 * Apache 1.3.23 for Windows * PHP 4.1.2 Apache SAPI module Everything works fine with PHP 4.1.1 in place. Swapping in PHP 4.1.2, sessions break. It appears possible to store session variables INITIALLY using session_register(), but no updates to session variables are ever stored in the session file. Attempting to follow the PHP documentation and just use $_SESSION--avoiding using session_register() altogether--does not work at all. Attempting to create a session variable by doing something like as written in the documentation fails miserably. (Note the documentation neglects the session_start() call, which I added since I did not have autostart enabled.) BACKGROUND: Here is how I swapped 4.1.2 into place to test this (what I do whenever a new release comes out now): * All Internet-related info is stored under \InetPub (holdover from my IIS days) * Apache is configured to look in \InetPub\PHP\SAPI for the PHP4APACHE.DLL file. All appropriate settings in HTTPD.CONF file set for running PHP as module (vs. CGI). * When a new PHP version is released, I 1. Download the .ZIP file 2. Decompress into \InetPub (in this case creating \InetPub\php-4.1.2-Win32\) 3. Copy PHP4TS.DLL into .\SAPI directory so it is in the the same directory with PHP4APACHE.DLL. 4. Compare new PHP.INI-DIST and PHP.INI-RECOMMENDED against my %SYSTEMROOT%\PHP.INI file, and make adjustments accordingly (like the new cgi. entries). 5. Shutdown Apache service. 6. Rename '\InetPub\PHP' to '\InetPub\PHP v4.1.1' 7. Rename '\InetPub\php-4.1.2-Win32' to '\InetPub\PHP' 8. Restart Apache service. 9. Test the new config by running a VER.PHP file which contains 10. Run various test scripts to validate sessions, etc., looking at the session files created to make sure variables are created/updated/etc. Testing an old version against a new version is then simple. I simply 1. Shutdown Apache service. 2. Rename '\InetPub\PHP' to '\InetPub\PHP_version_in_use' 3. Rename '\InetPub\PHP_version_to_test' to '\InetPub\PHP' 4. Restart Apache service. and run the same tests. With the introduction of PHP 4.1.0, I have started changing my PHP test scripts to make use of $_SESSION. If you would like, I can provide a set that may help show what's going on (or not going on in this case). In a nutshell, currently PHP v4.1.2 is useless for session management, at least the Apache for Windows SAPI module. Due to the various security concerns with CGIs, etc., I am hesitant to go back to that. If I find time to test the CGI version, I'll post here. [2002-03-13 10:40:05] [EMAIL PROTECTED] as title, the global var. array $_SESSION can't use in PHP 4.1.2 (4.1.1/4.1.0 are OK) P.S. I install PHP in Apache 1.3.23 modules -- Edit this bug report at http://bugs.php.net/?id=16043&edit=1
Bug #16073: Cannot unserialize() a string serialized with serialize()
From: [EMAIL PROTECTED]
Operating system: RH 7.1
PHP version: 4.0CVS-2002-03-14
PHP Bug Type: Variables related
Bug description: Cannot unserialize() a string serialized with serialize()
Not sure if this is a bug but serialize() cannot work with arrays that
holds elements which points to the array itself
The ouput is:
array(4) {
[0]=>
int(1)
[1]=>
int(2)
[2]=>
int(4)
[3]=>
*RECURSION*
}
string(64)
"a:4:{i:0;i:1;i:1;i:2;i:2;i:4;i:3;a:4:{i:0;i:1;i:1;i:2;i:2;i:4;}}"
bool(false)
If
$b[]=&$b;
removed the output is:
array(3) {
[0]=>
int(1)
[1]=>
int(2)
[2]=>
int(4)
}
string(30) "a:3:{i:0;i:1;i:1;i:2;i:2;i:4;}"
array(3) {
[0]=>
int(1)
[1]=>
int(2)
[2]=>
int(4)
}
That's ok.
Serialize() have either to check against recursion or encode somehow the
recursion in the serialized(great BC impact).
--
Edit bug report at http://bugs.php.net/?id=16073&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16073&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16073&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16073&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16073&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16073&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16073&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16073&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16073&r=submittedtwice
Bug #15909 Updated: Session data not updated on page jump
ID: 15909
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: Linux Gnu 2.2.12
PHP Version: 4.1.2
New Comment:
Any attempt I have made to save session variables in 4.1.2 fails now.
I can replace my php version with 4.1.1 and it works fine. I have
noticed that the session files are created in the temporary directory,
but while they contain the encode session data in php 4.1.1, they are 0
byte files in php 4.1.2. I am using IIS5.0 on Win2k. This fails in
both the CGI and ISAPI version. I can reproduce it every time simply
by stopping IIS, replacing php.exe, php4isapi.dll, php4ts.dll, and
php4ts.lib, restarting IIS, and trying it. No changes to code and no
changes to php.ini. Not even the php session manual's sample for
showing the number of times you have visited a page works!! I really
want this security fix, but I can't upgrade to it if it's going to
break sessions.
I do run a "slightly" (not where it really counts) modified php.ini
that resembles the php.ini-recommended in almost every respect.
I think this a glaringly obvious bug and can't imagine it can't be
reproduced, just try the sample - I have confirmed and reproduced this
bug on THREE IIS5.0 Win2k platforms.
Previous Comments:
[2002-03-09 22:37:59] [EMAIL PROTECTED]
According to the session docs:
If you have register_globals On, you have to use session_register()
If you have register_globals Off, $_SESSION['var'] = 123 will register
it
That means that you have to switch everything over to the $_ vars and
turn off register_globals before sessions work correctly (because the
$_REQUEST[], or user input, vars won't be available globally any
more).
If I'm wrong, let me know :)
[2002-03-08 15:06:06] [EMAIL PROTECTED]
I experienced a similar problem (PHP 4.1.2, Linux 2.2.19-6.2.11)
Works:
onepage.php
---
session_register("newvar");
$newvar = 123;
header("Location: somepage.php");
somepage.php
echo $_SESSION["newvar"]; //echoes 123
Doesn't work:
onepage.php
---
$_SESSION["newvar"] = 123;
header("Location: somepage.php");
somepage.php
echo $_SESSION["newvar"]; //"newvar" isn't set here
[2002-03-06 14:56:41] [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]
FYI, The code I'm working with uses a single session array variable
(with many elements) and a library routine to do page jumps.
Consequently I was able to fix this problem on all my pages by adding
one line of code to the pagejump library routine.
[2002-03-06 14:38:42] [EMAIL PROTECTED]
Just wanted to confirm I also experienced this problem after upgrading
to 4.1.2 for the security fix, so it's not an option to go back to an
older version of PHP.
The suggested $_SESSION[S][X] work around fixed my shopping cart but
this is going to be a huge chore to fix the entire site.
Is there an ETA on this fix?
[2002-03-06 13:11:34] [EMAIL PROTECTED]
Several pages that worked in PHP 4.0.2 no longer work in 4.1.2. The
problem is that values added to a global session variable array just
before jumping to another page are not being stored.
For example, on page courses.php the user selects a course from a list.
The code for the course is stored in a session variable $S[event_code],
and the code pagejumps (by calling a library routine that calls
header()) to page course.php, to display data for that particular
course. The problem is, the value $S[event_code] no longer exists when
we get to the second page (course.php).
I can see the value in $S[event_code] if I var_dump($S) before the
pagejump in courses.php. If I var_dump($S) just after arriving in page
course.php, I see the other contents of the $S array but not
$S[event_code].
Array $S is global and each page begins with
session_register("S");
The update takes place within a function that declares $S as global.
If I replace
$S[event_code] = $event_code;
with
$_SESSION[S][event_code] = $event_code;
the value is passed.
PHP options enable_track_vars and register_globals are ON,
session.save_handler is files, session.serialize_handler is php.
Thank you.
--
Edit this bug report at http://bugs.php.net/?id=15909&edit=1
Bug #16072: compact() causes core dump
From: [EMAIL PROTECTED] Operating system: RH 7.1 PHP version: 4.0CVS-2002-03-14 PHP Bug Type: Arrays related Bug description: compact() causes core dump Backtrace : bash-2.04$ gdb ../php core GNU gdb 5.0rh-5 Red Hat Linux 7.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `../php compact.php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libpam.so.0...done. Loaded symbols for /lib/libpam.so.0 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x400e26fd in __strtol_internal () from /lib/libc.so.6 (gdb) bt #0 0x400e26fd in __strtol_internal () from /lib/libc.so.6 #1 0x080ce4a5 in zend_hash_find (ht=0x8122a08, arKey=0x8148124 "1", nKeyLength=2, pData=0xbf800088) at /usr/include/stdlib.h:303 #2 0x0805baa2 in php_compact_var (eg_active_symbol_table=0x8122a08, return_value=0x8149504, entry=0x814813c) at /usr/samba/users/andy/412dev/php4-200203140300/ext/standard/array.c:1286 #3 0x0805bb31 in php_compact_var (eg_active_symbol_table=0x8122a08, return_value=0x8149504, entry=0x8147bdc) at /usr/samba/users/andy/412dev/php4-200203140300/ext/standard/array.c:1305 #4 0x0805bb31 in php_compact_var (eg_active_symbol_table=0x8122a08, return_value=0x8149504, entry=0x8149484) at /usr/samba/users/andy/412dev/php4-200203140300/ext/standard/array.c:1305 #5 0x0805bb31 in php_compact_var (eg_active_symbol_table=0x8122a08, return_value=0x8149504, entry=0x8149484) at /usr/samba/users/andy/412dev/php4-200203140300/ext/standard/array.c:1305 #6 0x0805bb31 in php_compact_var (eg_active_symbol_table=0x8122a08, return_value=0x8149504, entry=0x8149484) and so on ... i 've been hitting enter to #58292 but there is more. About 10-15 seconds is needed for the script to crash PHP. Not only $GLOBALS related because also causes core dump - but much faster - second or two. bash-2.04$ gdb ../php core GNU gdb 5.0rh-5 Red Hat Linux 7.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `../php compact.php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libpam.so.0...done. Loaded symbols for /lib/libpam.so.0 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x0805bb11 in php_compact_var (eg_active_symbol_table=0x8122a08, return_value=0x814dd6c, entry=0x814dca4) at /usr/samba/users/andy/412dev/php4-200203140300/ext/standard/array.c:1301 1301 zend_hash_internal_pointer_reset_ex(Z_ARRVAL_P(entry), &pos); (gdb) bt #0 0x0805bb11 in php_compact_var (eg_active_symbol_table=0x8122a08, return_value=0x814dd6c, entry=0x814dca4) at /usr/samba/users/andy/412dev/php4-200203140300/ext/standard/array.c:1301 #1 0x0805bb31 in php_compact_var (eg_active_symbol_table=0x8122a08, return_value=0x814dd6c, entry=0x814dbdc) at /usr/samba/users/andy/412dev/php4-200203140300/ext/standard/array.c:1305 #2 0x0805bb31 in php_compact_var (eg_active_symbol_table=0x8122a08, return_value=0x814dd6c, entry=0x814dca4) -- Edit bug report at http://bugs.php.net/?id=16072&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16072&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16072&r=alreadyfixed Need
Bug #16071: foreach return bogus data on 1 row multi-dim array
From: [EMAIL PROTECTED]
Operating system: Win 2000
PHP version: 4.1.0
PHP Bug Type: Arrays related
Bug description: foreach return bogus data on 1 row multi-dim array
I have code that traps all errors in a multidimentional array. The array is
structured so each row has a numerical key (ie $errors[] =
array('err_code'=>12, 'err_file'=>'happy.php');). You get the idea. For
error handling I have a function within a class that will accept an error
array and do output based on it. The function is as follows:
function pass_err_row($errors, $default_val=NULL, $override_val=NULL) { //
Throw errors based on err_file or default
if (is_null($default_val))
{$default_val=PATH_TO_ROOT.LOC_ERROR."DEFAULT/errors.php";}
if (!is_null($override_val)) {
foreach($errors as $error_row) {
include($override_val);
}
}
else {
foreach($errors as $error_row) {
if ($error_row['handle_file']!==FALSE &&
$error_row['handle_file']!=="") {
include($error_row['handle_file']);
}
else {
include($default_val);
}
}
}
}
This works great as long as the array passed has more than one error (each
error being another array) in it. So if $errors[0] and $errors[1] both
exist, everything works. Where it gets really wacky is if only $errors[0]
exists then the foreach loops results in very strange results. Each error
array row in $errors consists of the following 8 indexes:
'err_no', 'err_text', 'err_file', 'err_line', 'system_err', 'handle_file',
'handle_code', 'severity'.
What happens is the foreach loops 8 times with $error_row being equal not
to the array in $errors[0] but being equal to an value in the sub array.
So the first result would be the equivalent of $errors[0]['err_no']'s
value. $errors is still an array, so why would the for each instead use
the sub array? very weird.
--
Edit bug report at http://bugs.php.net/?id=16071&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16071&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16071&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16071&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16071&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16071&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16071&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16071&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16071&r=submittedtwice
Bug #16070: Set any variable after error occur..
From: [EMAIL PROTECTED] Operating system: Windows, Unix BSD, Linux RedHat PHP version: 4.1.2 PHP Bug Type: Variables related Bug description: Set any variable after error occur.. -- Edit bug report at http://bugs.php.net/?id=16070&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16070&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16070&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16070&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16070&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16070&r=support Expected behavior: http://bugs.php.net/fix.php?id=16070&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16070&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16070&r=submittedtwice
Bug #16063 Updated: array_pop() causes core dump, can be used to reveal information
ID: 16063 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type:Arrays related PHP Version: 4.0CVS-2002-03-14 New Comment: Here it is : bash-2.04$ ../php pop.php Segmentation fault (core dumped) bash-2.04$ gdb ../php core GNU gdb 5.0rh-5 Red Hat Linux 7.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `../php pop.php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libpam.so.0...done. Loaded symbols for /lib/libpam.so.0 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x40130e49 in free () from /lib/libc.so.6 (gdb) bt #0 0x40130e49 in free () from /lib/libc.so.6 #1 0x080bdfd8 in _efree (ptr=0x8122a08) at /usr/samba/users/andy/412dev/php4-200203140300/Zend/zend_alloc.c:246 #2 0x0805c528 in _phpi_pop (ht=1, return_value=0x81494b4, this_ptr=0x0, return_value_used=0, off_the_end=1) at /usr/samba/users/andy/412dev/php4-200203140300/ext/standard/array.c:1642 #3 0x0805c551 in zif_array_pop (ht=1, return_value=0x81494b4, this_ptr=0x0, return_value_used=0) at /usr/samba/users/andy/412dev/php4-200203140300/ext/standard/array.c:1652 #4 0x080d5ec7 in execute (op_array=0x8149614) at /usr/samba/users/andy/412dev/php4-200203140300/Zend/zend_execute.c:1598 #5 0x080ca71a in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/samba/users/andy/412dev/php4-200203140300/Zend/zend.c:810 #6 0x080b03c1 in php_execute_script (primary_file=0xbb00) at /usr/samba/users/andy/412dev/php4-200203140300/main/main.c:1381 #7 0x080dae24 in main (argc=2, argv=0xbba4) at /usr/samba/users/andy/412dev/php4-200203140300/sapi/cgi/cgi_main.c:1011 #8 0x400cd237 in __libc_start_main () from /lib/libc.so.6 (gdb) Previous Comments: [2002-03-14 09:39:34] [EMAIL PROTECTED] To properly diagnose this bug, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". [2002-03-14 09:09:05] [EMAIL PROTECTED] bash-2.04$ ../php rest.php Segmentation fault (core dumped) bash-2.04$ No problems with -- Edit this bug report at http://bugs.php.net/?id=16063&edit=1
Bug #16068 Updated: array_shft() core dump. problem similart to #16063
ID: 16068 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Arrays related Operating System: RH 7.1 PHP Version: 4.0CVS-2002-03-14 New Comment: Here it is: bash-2.04$ gdb ../php core GNU gdb 5.0rh-5 Red Hat Linux 7.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `../php shift.php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libpam.so.0...done. Loaded symbols for /lib/libpam.so.0 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x40130e49 in free () from /lib/libc.so.6 (gdb) bt #0 0x40130e49 in free () from /lib/libc.so.6 #1 0x080bdfd8 in _efree (ptr=0x8122a08) at /usr/samba/users/andy/412dev/php4-200203140300/Zend/zend_alloc.c:246 #2 0x0805c528 in _phpi_pop (ht=1, return_value=0x81494c4, this_ptr=0x0, return_value_used=0, off_the_end=0) at /usr/samba/users/andy/412dev/php4-200203140300/ext/standard/array.c:1642 #3 0x0805c56d in zif_array_shift (ht=1, return_value=0x81494c4, this_ptr=0x0, return_value_used=0) at /usr/samba/users/andy/412dev/php4-200203140300/ext/standard/array.c:1661 #4 0x080d5ec7 in execute (op_array=0x8149624) at /usr/samba/users/andy/412dev/php4-200203140300/Zend/zend_execute.c:1598 #5 0x080ca71a in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/samba/users/andy/412dev/php4-200203140300/Zend/zend.c:810 #6 0x080b03c1 in php_execute_script (primary_file=0xbb00) at /usr/samba/users/andy/412dev/php4-200203140300/main/main.c:1381 #7 0x080dae24 in main (argc=2, argv=0xbba4) at /usr/samba/users/andy/412dev/php4-200203140300/sapi/cgi/cgi_main.c:1011 #8 0x400cd237 in __libc_start_main () from /lib/libc.so.6 (gdb) Previous Comments: [2002-03-14 09:53:55] [EMAIL PROTECTED] Here it is: bash-2.04$ gdb ../php core GNU gdb 5.0rh-5 Red Hat Linux 7.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `../php shift.php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libpam.so.0...done. Loaded symbols for /lib/libpam.so.0 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x40130e49 in free () from /lib/libc.so.6 (gdb) bt #0 0x40130e49 in free () from /lib/libc.so.6 #1 0x080bdfd8 in _efree (ptr=0x8122a08) at /usr/samba/users/andy/412dev/php4-200203140300/Zend/zend_alloc.c:246 #2 0x0805c528 in _phpi_pop (ht=1, return_value=0x81494c4, this_ptr=0x0, return_value_used=0, off_the_end=0) at /usr/samba/users/andy/412dev/php4-200203140300/ext/standard/array.c:1642 #3 0x0805c56d in zif_array_shift (ht=1, return_value=0x81494c4, this_ptr=0x0, return_value_used=0) at /usr/samba/users/andy/412dev/php4-200203140300/ext/standard/array.c:1661 #4 0x080d5ec7 in execute (op_array=0x8149624) at /usr/samba/users/andy/412dev/php4-200203140300/Zend/zend_execute.c:1598 #5 0x080ca71a in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/samba/users/andy/412dev/php4-200203140300/Zend/zend.c:810 #6 0x080b03c1 in php_execute_script (primary_file=0xbb00) at /usr/samba/users/andy/412dev/php4-200203140300/main/main.c:1381
Bug #16068 Updated: array_shft() core dump. problem similart to #16063
ID: 16068 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Arrays related Operating System: RH 7.1 PHP Version: 4.0CVS-2002-03-14 New Comment: Here it is: bash-2.04$ gdb ../php core GNU gdb 5.0rh-5 Red Hat Linux 7.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `../php shift.php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libpam.so.0...done. Loaded symbols for /lib/libpam.so.0 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. L Previous Comments: [2002-03-14 09:37:07] [EMAIL PROTECTED] To properly diagnose this bug, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". [2002-03-14 09:35:36] [EMAIL PROTECTED] A second or two runtime and then core dump. -- Edit this bug report at http://bugs.php.net/?id=16068&edit=1
Bug #16069: ICONV transliteration failure
From: [EMAIL PROTECTED]
Operating system: win32, Linux
PHP version: 4.1.2
PHP Bug Type: ICONV related
Bug description: ICONV transliteration failure
conversion between CP932(a variant of Shift_JIS charset) and any Japanese
charset other than CP932 unexpectantly failed when transliteration mode is
specified like "EUC-JP//TRANSLIT" on the output encoding and the
transliteration requires some larger buffer than strlen(input_buf) *
sizeof(ucs4_t).
testing script:
";
}
for( $i = 0; $i < 20; ++$i ) {
print $i.":".iconv( "EUC-JP", "Shift_JIS", iconv( "CP932",
"EUC-JP//TRANSLIT", "abcd".str_repeat( "", $i ) ) )."";
}
?>
where "" is ONE character described as "SQUARE MIRIBAARU" (0x876D) and
"" is ONE character described as "SQUARE AARU" (0x8765) on
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT
--
Edit bug report at http://bugs.php.net/?id=16069&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16069&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16069&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16069&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16069&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16069&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16069&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16069&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16069&r=submittedtwice
Bug #16063 Updated: array_pop() causes core dump, can be used to reveal information
ID: 16063 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type:Arrays related PHP Version: 4.0CVS-2002-03-14 New Comment: To properly diagnose this bug, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Previous Comments: [2002-03-14 09:09:05] [EMAIL PROTECTED] bash-2.04$ ../php rest.php Segmentation fault (core dumped) bash-2.04$ No problems with -- Edit this bug report at http://bugs.php.net/?id=16063&edit=1
Bug #16068 Updated: array_shft() core dump. problem similart to #16063
ID: 16068 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Arrays related Operating System: RH 7.1 PHP Version: 4.0CVS-2002-03-14 New Comment: To properly diagnose this bug, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Previous Comments: [2002-03-14 09:35:36] [EMAIL PROTECTED] A second or two runtime and then core dump. -- Edit this bug report at http://bugs.php.net/?id=16068&edit=1
Bug #16068: array_shft() core dump. problem similart to #16063
From: [EMAIL PROTECTED] Operating system: RH 7.1 PHP version: 4.0CVS-2002-03-14 PHP Bug Type: Arrays related Bug description: array_shft() core dump. problem similart to #16063 A second or two runtime and then core dump. -- Edit bug report at http://bugs.php.net/?id=16068&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16068&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16068&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16068&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16068&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16068&r=support Expected behavior: http://bugs.php.net/fix.php?id=16068&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16068&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16068&r=submittedtwice
Bug #16064 Updated: array_merge_recursive() can be used for DoS
ID: 16064
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Arrays related
Operating System: RH 7.1
PHP Version: 4.0CVS-2002-03-1
New Comment:
OK. status -> open
Previous Comments:
[2002-03-14 09:31:58] [EMAIL PROTECTED]
streplace('them','him',$previous_vote);
[2002-03-14 09:30:40] [EMAIL PROTECTED]
I have talked to Zeev about this issues. Asked them may I have to fill
bug report and he said:
"They should either use hash_apply(), which automatically protects
against
recursion, or implement the recursion protection themselves (like
print_r()
does). You can/should open bug reports about them..."
In the start Zeev talks about some functions that have problems with
$GLOBALS and arrays that holds elements pointing ot itself.
[2002-03-14 09:23:45] [EMAIL PROTECTED]
I'm sure you can come up with a load of nasty things you can do with
$GLOBALS, but what do you want us to do about it? Disable $GLOBALS for
use with array_* functions (it that's even possible)? Disable $GLOBALS
at all?
[2002-03-14 09:15:54] [EMAIL PROTECTED]
On the test server all consoles hanged. 100%.CPU load. 98%
system - kswapd started to swap as a beast.
No problems with this.
--
Edit this bug report at http://bugs.php.net/?id=16064&edit=1
Bug #16067: vulnerabilities in PHPH's file uploadcode - still uncovered in 4.1.2
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.2, 4.4 PHP version: 4.1.2 PHP Bug Type: Reproducible crash Bug description: vulnerabilities in PHPH's file uploadcode - still uncovered in 4.1.2 Dear gentlemen, On the February 28 a notice appeared regarding the problem concerning files upload in the php. The description of the problem can be found at http://security.e-matters.de/advisories/012002.html "Release Date: 2002/02/27 Author:Stefan Esser [[EMAIL PROTECTED]] Application: PHP v3.0.10-v3.0.18, v4.0.1-v4.1.1 Severity: Several vulnerabilities in PHP's fileupload code allow remote compromise Risk:Critical Reference: http://security.e-matters.de/advisories/012002.html Last Modified: 1002/02/28 " We applied the patch, that was made by the php developers and is available at http://www.php.net/downloads.php (http://www.php.net/do_download.php?download_file=rfc1867.c.diff-4.1.x.gz) We applied the given patch to the php 4.1.0 and supposed that we'll no longer encounter the problem described above. An exploit appeared recently, which after having been applied to the patched php 4.1.0 on the FreeBSD (4.2, 4.4 versions), crashes the child Apache (segmentation fault). (exploit text - http://packetstormsecurity.nl/0203-exploits/phpxpl.c) I.e. the php patch officially released on February 28 doesn't solve this problem to the end. We downloaded the php version 4.1.2. The situation repeated on this php version either. We have some questions in this regard: - is the new php version release planned ( 4.1.3 for example) where there will be no such vulnerability? - are there any patches planned to release for the php versions available, to workaround such vulnerability? If such workarounds are planned - by what time should we expect it to become available ? Thank you, Dmitry Zinin -- Edit bug report at http://bugs.php.net/?id=16067&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16067&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16067&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16067&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16067&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16067&r=support Expected behavior: http://bugs.php.net/fix.php?id=16067&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16067&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16067&r=submittedtwice
Bug #16064 Updated: array_merge_recursive() can be used for DoS
ID: 16064
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Arrays related
Operating System: RH 7.1
PHP Version: 4.0CVS-2002-03-1
New Comment:
streplace('them','him',$previous_vote);
Previous Comments:
[2002-03-14 09:30:40] [EMAIL PROTECTED]
I have talked to Zeev about this issues. Asked them may I have to fill
bug report and he said:
"They should either use hash_apply(), which automatically protects
against
recursion, or implement the recursion protection themselves (like
print_r()
does). You can/should open bug reports about them..."
In the start Zeev talks about some functions that have problems with
$GLOBALS and arrays that holds elements pointing ot itself.
[2002-03-14 09:23:45] [EMAIL PROTECTED]
I'm sure you can come up with a load of nasty things you can do with
$GLOBALS, but what do you want us to do about it? Disable $GLOBALS for
use with array_* functions (it that's even possible)? Disable $GLOBALS
at all?
[2002-03-14 09:15:54] [EMAIL PROTECTED]
On the test server all consoles hanged. 100%.CPU load. 98%
system - kswapd started to swap as a beast.
No problems with this.
--
Edit this bug report at http://bugs.php.net/?id=16064&edit=1
Bug #16064 Updated: array_merge_recursive() can be used for DoS
ID: 16064 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Arrays related Operating System: RH 7.1 PHP Version: 4.0CVS-2002-03-1 New Comment: I have talked to Zeev about this issues. Asked them may I have to fill bug report and he said: "They should either use hash_apply(), which automatically protects against recursion, or implement the recursion protection themselves (like print_r() does). You can/should open bug reports about them..." In the start Zeev talks about some functions that have problems with $GLOBALS and arrays that holds elements pointing ot itself. Previous Comments: [2002-03-14 09:23:45] [EMAIL PROTECTED] I'm sure you can come up with a load of nasty things you can do with $GLOBALS, but what do you want us to do about it? Disable $GLOBALS for use with array_* functions (it that's even possible)? Disable $GLOBALS at all? [2002-03-14 09:15:54] [EMAIL PROTECTED] On the test server all consoles hanged. 100%.CPU load. 98% system - kswapd started to swap as a beast. No problems with this. -- Edit this bug report at http://bugs.php.net/?id=16064&edit=1
Bug #16066:
From: [EMAIL PROTECTED] Operating system: Linux (Debian) PHP version: 4.1.1 PHP Bug Type: Scripting Engine problem Bug description: However without the space it outputs a warning: "Warning: Use of undefined constant PHP - assumed 'PHP'" But this (correctly) doesn't output anything... If you put code after the comment it is worse. This actually dies with a "parser error", but again this works if you use the shorter tag. Outputs "Hello" as expected. The fact that it works when you use "http://bugs.php.net/?id=16066&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16066&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16066&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16066&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16066&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16066&r=support Expected behavior: http://bugs.php.net/fix.php?id=16066&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16066&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16066&r=submittedtwice
Bug #16065: var_dump() infinite loop. Problem occured after today's patch(np w/ 4.1.2)
From: [EMAIL PROTECTED] Operating system: RH 7.1 PHP version: 4.0CVS-2002-03-14 PHP Bug Type: Arrays related Bug description: var_dump() infinite loop. Problem occured after today's patch(np w/ 4.1.2) This piece of code causes infinite loop. If the commments are removed than this little scripts starts to eat memory too fast. 100MB for 15secs. When the physical RAM was not available started to eat from the swap. If var_export() is used no problems(with the CVS). With 4.1.2 only causes Fatal Error - too deep recursion. Proably this has something with Yasuo's patch that tried force var_dump() to work like print_r() - showing recursion not just crashing. -- Edit bug report at http://bugs.php.net/?id=16065&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16065&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16065&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16065&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16065&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16065&r=support Expected behavior: http://bugs.php.net/fix.php?id=16065&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16065&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16065&r=submittedtwice
Bug #16064 Updated: array_merge_recursive() can be used for DoS
ID: 16064 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Arrays related Operating System: RH 7.1 -PHP Version: 4.0CVS-2002-03-14 +PHP Version: 4.0CVS-2002-03-1 New Comment: I'm sure you can come up with a load of nasty things you can do with $GLOBALS, but what do you want us to do about it? Disable $GLOBALS for use with array_* functions (it that's even possible)? Disable $GLOBALS at all? Previous Comments: [2002-03-14 09:15:54] [EMAIL PROTECTED] On the test server all consoles hanged. 100%.CPU load. 98% system - kswapd started to swap as a beast. No problems with this. -- Edit this bug report at http://bugs.php.net/?id=16064&edit=1
Bug #16064: array_merge_recursive() can be used for DoS
From: [EMAIL PROTECTED] Operating system: RH 7.1 PHP version: 4.0CVS-2002-03-14 PHP Bug Type: Arrays related Bug description: array_merge_recursive() can be used for DoS On the test server all consoles hanged. 100%.CPU load. 98% system - kswapd started to swap as a beast. No problems with this. -- Edit bug report at http://bugs.php.net/?id=16064&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16064&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16064&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16064&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16064&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16064&r=support Expected behavior: http://bugs.php.net/fix.php?id=16064&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16064&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16064&r=submittedtwice
Bug #16063: array_pop() causes core dump, can be used to reveal information
From: [EMAIL PROTECTED] Operating system: PHP version: 4.0CVS-2002-03-14 PHP Bug Type: Arrays related Bug description: array_pop() causes core dump, can be used to reveal information bash-2.04$ ../php rest.php Segmentation fault (core dumped) bash-2.04$ No problems with -- Edit bug report at http://bugs.php.net/?id=16063&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16063&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16063&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16063&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16063&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16063&r=support Expected behavior: http://bugs.php.net/fix.php?id=16063&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16063&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16063&r=submittedtwice
Bug #16062 Updated: unable to ./configure with ldap enable
ID: 16062 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *Compile Issues Operating System: aix4.3.3 PHP Version: 4.1.2 New Comment: The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Please do NOT report the same problem twice! Previous Comments: [2002-03-14 07:54:12] [EMAIL PROTECTED] configure line -- ./configure --without-mysql --with-apxs=/usr/local/apache/bin/apxs \ --with-ldap=/webserver/download/ldapsdk After run configure --- Something is likely to be messed up here, because the configure script was not able to detect a simple feature on your platform. This is often caused by incorrect configuration parameters. Please see the file debug.log for error messages. message from debug.log --- CONFIGURE: './configure' '--without-mysql' '--enable-sigchild' '--with-apxs=/usr/local/apache/bin/apxs' '--with-oci8=/home/o racle' '--with-ldap=/home/oracle' CC: gcc CFLAGS: -g -O2 CPPFLAGS:-DAIX=43 -DUSE_PTHREAD_SERIALIZED_ACCEPT -DAIX_BIND_PROCESSOR -DUSE_HSREGEX -DUSE_EXPAT CXX: CXXFLAGS: INCLUDES:-I/usr/local/apache/include -I$(top_builddir)/Zend -I/home/oracle/include LDFLAGS: -L/home/oracle/lib -L/home/oracle/lib LIBS: -lld -lbsd_r -lodm -lm -ldl -lldapssl41 -lplds3 -lplc3 -lnspr3 -lcrypt -lbind -lm -ldl -lcrypt -lclntsh DLIBS: SAPI: apache PHP_RPATHS: /home/oracle/lib uname -a: AIX cupang 3 4 000B7B9D4C00 gcc -o conftest -g -O2 -DAIX=43 -DUSE_PTHREAD_SERIALIZED_ACCEPT -DAIX_BIND_PROCESSOR -DUSE_HSREGEX -DUSE_EXPAT -L/home/oracl e/lib -L/home/oracle/lib conftest.c -lld -lbsd_r -lodm -lm -ldl -lldapssl41 -lplds3 -lplc3 -lnspr3 -lcrypt -lbind -lm -ldl -l crypt -lclntsh >&5 ld: 0706-006 Cannot find or open library file: -l ldapssl41 ld:open(): No such file or directory ld: 0706-006 Cannot find or open library file: -l plds3 ld:open(): No such file or directory ld: 0706-006 Cannot find or open library file: -l plc3 ld:open(): No such file or directory ld: 0706-006 Cannot find or open library file: -l nspr3 ld:open(): No such file or directory collect2: ld returned 255 exit status I have tried php4latest.tar.gz. version 4.1.2 and still cannot -- Edit this bug report at http://bugs.php.net/?id=16062&edit=1
Bug #15430 Updated: socket_set_blocking doesn't work
ID: 15430
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Sockets related
Operating System: Windows 2000
PHP Version: 4.1.1
New Comment:
I have currently the same problem with PHP 4.1.1. However, when I put
the sleep(1) statement IN FRONT of the fgets() or fgetc(), my code
works even with non-blocking sockets (it's annoying but it works).
Maybe this helps you for now (until this bug has been fixed).
Previous Comments:
[2002-02-07 09:43:51] [EMAIL PROTECTED]
I'm using Apache1.3.22/PHP4.1.1 on Windows 2000.
When I use socket_set_blocking($fp, FALSE); PHP doesn't read any more
data from the socket:
...
do {
if ($ch=fgetc($fp))
echo dechex(ord($ch))." ";
...
if ($ch==chr(0x2A)) {
...
}
sleep(1);
...
} while (1);
...
This does work with socket blocking enabled but with socket blocking
disabled I don't get any more data in my PHP-Script !
--
Edit this bug report at http://bugs.php.net/?id=15430&edit=1
Bug #16062: unable to ./configure with ldap enable
From: [EMAIL PROTECTED] Operating system: aix4.3.3 PHP version: 4.1.2 PHP Bug Type: *Compile Issues Bug description: unable to ./configure with ldap enable configure line -- ./configure --without-mysql --with-apxs=/usr/local/apache/bin/apxs \ --with-ldap=/webserver/download/ldapsdk After run configure --- Something is likely to be messed up here, because the configure script was not able to detect a simple feature on your platform. This is often caused by incorrect configuration parameters. Please see the file debug.log for error messages. message from debug.log --- CONFIGURE: './configure' '--without-mysql' '--enable-sigchild' '--with-apxs=/usr/local/apache/bin/apxs' '--with-oci8=/home/o racle' '--with-ldap=/home/oracle' CC: gcc CFLAGS: -g -O2 CPPFLAGS:-DAIX=43 -DUSE_PTHREAD_SERIALIZED_ACCEPT -DAIX_BIND_PROCESSOR -DUSE_HSREGEX -DUSE_EXPAT CXX: CXXFLAGS: INCLUDES:-I/usr/local/apache/include -I$(top_builddir)/Zend -I/home/oracle/include LDFLAGS: -L/home/oracle/lib -L/home/oracle/lib LIBS: -lld -lbsd_r -lodm -lm -ldl -lldapssl41 -lplds3 -lplc3 -lnspr3 -lcrypt -lbind -lm -ldl -lcrypt -lclntsh DLIBS: SAPI: apache PHP_RPATHS: /home/oracle/lib uname -a: AIX cupang 3 4 000B7B9D4C00 gcc -o conftest -g -O2 -DAIX=43 -DUSE_PTHREAD_SERIALIZED_ACCEPT -DAIX_BIND_PROCESSOR -DUSE_HSREGEX -DUSE_EXPAT -L/home/oracl e/lib -L/home/oracle/lib conftest.c -lld -lbsd_r -lodm -lm -ldl -lldapssl41 -lplds3 -lplc3 -lnspr3 -lcrypt -lbind -lm -ldl -l crypt -lclntsh >&5 ld: 0706-006 Cannot find or open library file: -l ldapssl41 ld:open(): No such file or directory ld: 0706-006 Cannot find or open library file: -l plds3 ld:open(): No such file or directory ld: 0706-006 Cannot find or open library file: -l plc3 ld:open(): No such file or directory ld: 0706-006 Cannot find or open library file: -l nspr3 ld:open(): No such file or directory collect2: ld returned 255 exit status I have tried php4latest.tar.gz. version 4.1.2 and still cannot -- Edit bug report at http://bugs.php.net/?id=16062&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16062&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16062&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16062&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16062&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16062&r=support Expected behavior: http://bugs.php.net/fix.php?id=16062&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16062&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16062&r=submittedtwice
Bug #15303 Updated: Error compiling
ID: 15303 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GD related Operating System: rocklinux 1.4 PHP Version: 4.1.1 New Comment: Hi I had this problem too. It was my fault, I forgot I had a shared module laying around in /usr/local/lib which php was trying to use instead, pointing the configure script to the exact directory where to look for gdlib with --with-gd=/tmp/gdlib doesn't even help. It uses the one it found installed before the one you specifyed. Is this a bug? Regards, David Nordenberg Previous Comments: [2002-03-10 20:36:29] [EMAIL PROTECTED] It seems that when you install a new version of gd over an old one you have this problem, is there a way to uninstall the previous one ? Everyone that is having this problem instaled a newer version of gd over an older one ? Thanks for the oportunity I'm using php-4.2-dev [2002-03-04 04:31:03] [EMAIL PROTECTED] same thing with php version 4.1.2 and gd 1.8.4 [2002-02-03 07:09:34] [EMAIL PROTECTED] that was the wrong message. [2002-02-03 07:08:53] [EMAIL PROTECTED] The version of PHP that this bug was reported in is too old. Please try to reproduce this bug in the latest version of PHP (available from http://www.php.net/downloads.php If you are still able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". [2002-01-30 16:31:10] [EMAIL PROTECTED] Hello Dont know if this is a gd or php issus. I downloaded gd to have it to work with gd cause i wanted to generate alpha blending images on the fly. therefore i choosed the 2.0.1 beta build. When i compile gd everything is allright but when i try to compile php i get this error message gcc -I. -I/usr/src/php-4.1.1/ext/gd -I/usr/src/php-4.1.1/main -I/usr/src/php -4.1.1 -I/usr/src/php-4.1.1/Zend -I/usr/src/php-4.1.1/ext/mysql/libmysql -I/ usr/src/php-4.1.1/ext/xml/expat -I/usr/src/php-4.1.1/TSRM -g -O2 -c gd.c && touch gd.lo In file included from /usr/include/gd.h:25, from php_gd.h:33, from gd.c:36: /usr/include/gd_io.h:21: undefined or invalid # directive In file included from gd.c:36: php_gd.h:69: warning: static declaration for `gdImageColorResolve' follows non-static gd.c:92: conflicting types for `gdIOCtx' /usr/include/gd_io.h:18: previous declaration of `gdIOCtx' make[3]: *** [gd.lo] Error 1 make[3]: Leaving directory `/usr/src/php-4.1.1/ext/gd' The only option i have supplied is ./configure --with-gd Im using rocklinux 1.4 and have tried to download and install zlib libpng libjpeg freetype several times. Whats wrong? Should i send a bugreport to php or is this a gd issue? Thanx for a good software /Alexander -- Edit this bug report at http://bugs.php.net/?id=15303&edit=1
Bug #16061: Post Problem with thttpd
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4.1.2 PHP Bug Type: Other web server Bug description: Post Problem with thttpd Hi I have a problem with POST using thttpd as a webserver. I'm using php-4.1.2 and thttpd-2.21b. configure --prefix=/usr/local \ --with-config-file-path=/webmgnt/etc/ \ --with-gettext \ --with-mcrypt \ --enable-ctype \ --enable-wddx \ --with-thttpd=../thttpd-2.21b \ --enable-shared=no Everything is compiled staticly When the HTTP header and the POST data are send in one single TCP packet everything works fine. But when the POST data or even a part of it is send in an other packet the php-script can't see any of the POST variables. It seems that php only analyses the read-buffer that thttpd offers to php, but fails in reading the missing POST data from the socket. Thorsten -- Edit bug report at http://bugs.php.net/?id=16061&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16061&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16061&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16061&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16061&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16061&r=support Expected behavior: http://bugs.php.net/fix.php?id=16061&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16061&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16061&r=submittedtwice
Bug #14350 Updated: gd cant handle some png files
ID: 14350
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: GD related
Operating System: win2000
PHP Version: 4.0.6
New Comment:
PHP 4.1.2-1
libgd 2.0.1-7
Apache 1.3.23-1
Linux, Debian Woody with libgd package selected from Sid
I experience problems using both ImageCopyResampled and
ImageCopyResized on all PNGs loaded with ImageCreateFromPNG.
Source images that have a transparent background yield an all black
result image, no matter the source and destination sizes. The error is
either in ImageCreateFromPNG or the resize/resample functions, I do not
know which.
Other PNG images yield correct results when the destination size is
smaller than the source size, but generate garbage when the destination
is larger than the source.
JPEGs loaded with ImageCreateFromJpeg, on the other hand, always work.
Previous Comments:
[2001-12-05 08:48:42] [EMAIL PROTECTED]
(Im using the official php 4.0.6 build for windows from php.net, only
extension loaded is php_imap.dll).
I've written a function to rezise images (used for making thumbnails),
it's working fine, also with png-files, but not all. Below is the code
to reproduce the problem:
jul.png is working properly, download from http://inthc.net/jul.png
gba_large.png is NOT working properly, download from
http://inthc.net/gba_large.png
(gba_large.png result in a full blue window, or a full black or gray,
it changes upon reload..)
gba_large.png was created with Paint Shop Pro 7, and displays fine in
IE, Netscape & Opera.
snip start--
//$filename = "jul.png";
$filename = "gba_large.png";
$inImg = @ImageCreateFromPNG($filename);
if (!$inImg) { echo "Failed to open png!"; die; }
$size = GetImageSize($filename);
$srcW = $size[0]; $srcH = $size[1];
$dstW = 100; $dstH = 100;
$outImg = @ImageCreate($dstW, $dstH);
ImageCopyResampled($outImg, $inImg, 0,0,0,0, $dstW, $dstH, $srcW,
$srcH);
header("Content-type: image/x-png");
ImagePNG($outImg);
---snip end--
--
Edit this bug report at http://bugs.php.net/?id=14350&edit=1
Bug #8744 Updated: call to header() causes CGI error
ID: 8744 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: IIS related Operating System: Windows 2000 PHP Version: 4.1.1 New Comment: i noticed various problem working on header() function. in the worst case i get out a segmentation fault on my linux 2.4.4 running apache 1.3.22 + php 4.1.1 i will post a new bug thread about it in few minutes... bye, stain Previous Comments: [2002-03-12 15:41:15] [EMAIL PROTECTED] Hi All, I also have this problem and it is definately related to MSSQL because I also used the same code with a MySQL database and the error doesn't exist. Thanks, Steve [2002-02-16 05:20:10] [EMAIL PROTECTED] This problem also occurs when using apache, and a real url as opposed to a relative url (ie, having the php.exe engine exposed in the docroot). I cannot determine if it's the same cause, but it's definitely the same symptom. if this could get fixed, it'd fix a big security hole we have now. james. [2002-02-16 05:15:00] [EMAIL PROTECTED] Reopening. [2002-02-15 18:24:04] [EMAIL PROTECTED] I have tried 4.1.1 with win2k and the bug still exists. [2002-02-02 06:39:14] [EMAIL PROTECTED] No feedback was provided for this bug, so it is being suspended. If you are able to provide the information that was requested, please do so and change the status of the bug back to "Open". The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/8744 -- Edit this bug report at http://bugs.php.net/?id=8744&edit=1
Bug #16057 Updated: ftp_nlist() and ftp_rawlist() return nothing
ID: 16057 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: FTP related Operating System: Windows 2000 Advanced Server -PHP Version: 4.1.1 +PHP Version: 4.1.2 New Comment: I've confirmed that this bug is still present in the Windows build of 4.1.2, and yet it works as documented in the Linux build of 4.1.2. Previous Comments: [2002-03-14 02:23:50] [EMAIL PROTECTED] In the Windows build of PHP 4.1.1, the ftp_nlist() and ftp_rawlist() functions return absolutely nothing. The following script works just fine in PHP 4.1.1 on Linux, but fails under Windows, no matter what FTP server you try to connect to: "; print_r($nlist); print_r($rawlist); echo ""; ?> -- Edit this bug report at http://bugs.php.net/?id=16057&edit=1
Bug #16054 Updated: ldap ./configure error cannot open library
ID: 16054 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *Compile Issues Operating System: aix 4.3.3 PHP Version: 4.1.2 New Comment: This is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Previous Comments: [2002-03-13 21:34:41] [EMAIL PROTECTED] gcc -o conftest -g -O2 -DAIX=43 -DUSE_PTHREAD_SERIALIZED_ACCEPT -DAIX_BIND_PROCESSOR -DUSE_HSREGEX -DUSE_EXPAT -L/webserver/ download/ldapsdk/lib -L/webserver/download/ldapsdk/lib conftest.c -lldapssl41 -lplds3 -lplc3 -lnspr3 -lcrypt -lbind -lm -ldl -lcrypt 1>&5 ld: 0706-006 Cannot find or open library file: -l ldapssl41 ld:open(): No such file or directory ld: 0706-006 Cannot find or open library file: -l plds3 ld:open(): No such file or directory ld: 0706-006 Cannot find or open library file: -l plc3 ld:open(): No such file or directory ld: 0706-006 Cannot find or open library file: -l nspr3 ld:open(): No such file or directory collect2: ld returned 255 exit status -- Edit this bug report at http://bugs.php.net/?id=16054&edit=1
Bug #13718 Updated: form elements with same name problem
ID: 13718 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Feature/Change Request Operating System: All PHP Version: 4.0.6 New Comment: Then shouldn't its Status be "Duplicate" instead of "Bogus"? Additionally, of the two I think this one is the better report -- it certainly has a better proposed solution, which matches what is in the PHP TODO file to boot! Previous Comments: [2002-03-07 13:39:30] [EMAIL PROTECTED] this is a duplicate of #10502. [2002-03-06 09:10:49] [EMAIL PROTECTED] You have this feature as a "possible" in the PHP To-Do list, so I think this report ought to be reclassified from Bogus. At least then we could vote on it so you could see what the level of support for it is. Cheers! [2001-10-24 18:58:56] [EMAIL PROTECTED] I'm sorry to keep bringing this issue to light, but this actually would mimic that of your existing functionality. If you name an element in a form with a [] that does not garuntee that the variable on the other end will be an array. If there is only one element posted with that name followed by [] it will end up as a standard variable. So, I again make the plea: If you have more than one element with the same name with or without a [] it will come out an array. If you have one element with or without a [] it will come out the other end as a single variable. It is possible that you actually intended for the single element with [] to come out as an array, if that is the case, I guess you should consider this a bug report for the functionality of trailing [] in forms. [2001-10-18 11:38:37] [EMAIL PROTECTED] Oh, I'm sorry, I missunderstood you. I understand what you are getting at, ambiguity can be a problem. I guess I'll just deal with using the suggestion of indexing on a string in javascript. Thank you for all your help. [2001-10-18 11:33:49] [EMAIL PROTECTED] no, i didn't ;) i just tried to describe what would happen *if* we would follow your suggestion and that it is a not so good idea after all (although we definetly should have a look at the [] syntax regarding standard conformance) 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/13718 -- Edit this bug report at http://bugs.php.net/?id=13718&edit=1
Bug #16056 Updated: Please use reception of *any* cookie to signal PHP that cookies are enabled
ID: 16056 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Windows 2000 PHP Version: 4.1.2 New Comment: users can accept and reject cookies at will even if the browser has cookie support enabled (eg. Netscape "ask me before accepting a cookie" setting) Previous Comments: [2002-03-14 02:15:02] [EMAIL PROTECTED] fixed my email address. [2002-03-14 02:14:02] [EMAIL PROTECTED] This is just a simple request. When you visit a PHP site using sessions, on the first page view the PHPSESSID appears in all URLs, because at that point PHP supposedly does not know whether cookies are enabled. However, if the site had, on an earlier visit, set a long-term cookie (with some dummy value), then now on my first page-view of a session, the PHP site should be able to know that cookies are enabled, since this one long-term cookie would have been sent. Currently, PHP doesn't allow this -- it only checks for the PHPSESSID cookie. I think it would be an easy change, and make many people happy, to simply have it check whether any cookie was received by the server, and if so then take that as a sign that cookies are enabled and thus don't modify the links on the page. Perhaps this could be an option in the php.ini if you were worried it is not safe enough. Thanks for your time, Matt -- Edit this bug report at http://bugs.php.net/?id=16056&edit=1
Bug #16052 Updated: Some predefined variables allow GET overwrite
ID: 16052 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: RH 7.2 PHP Version: 4.1.2 New Comment: No, it was my fault. I thought, session variables were primarily available in $_SESSION, then written to the global context with "variables order". Previous Comments: [2002-03-14 02:41:00] [EMAIL PROTECTED] Funny, the docs say the "S" stands for "Server" variables: http://www.php.net/manual/en/configuration.php#ini.register-globals Furthermore, it doesn't make any comment whatsoever as to the nature of the HTTP_* variables, though the predefined variables page claims some are Apache, and some are environment. http://www.php.net/manual/en/language.variables.predefined.php In this instance, it says HTTP_ACCEPT_CHARSET and HTTP_REFERER are both Apache (presumably, "S"erver, yes?) variables. So are you saying this is a documentation bug? [2002-03-14 02:10:20] [EMAIL PROTECTED] sorry, it's EGPCS by default. [2002-03-14 02:08:47] [EMAIL PROTECTED] are you sure? HTTP_* variables are environment variables. the variables_order is normally set to EGCPS (if not, change it) where "S" is not "Server Variables" but "SESSION Variables". this behaviour thus looks intentional - first HTTP_ACCEPT_CHARSET is set by the environment, then you overwrite it with a GET. [2002-03-13 18:56:56] [EMAIL PROTECTED] Incidentally, our variables_order flag is set to "GPCS". [2002-03-13 18:47:07] [EMAIL PROTECTED] Been there, done that. So, why don't any of the other variables from purportedly the same source (s/b "S", yes?) change when I request this on the command line? The point is that either (a) the docs are broken here and the two variables in question aren't from the server, or (b) the EGPCS processing is broken, take your pick. 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/16052 -- Edit this bug report at http://bugs.php.net/?id=16052&edit=1
Bug #13104 Updated: GD problem
ID: 13104 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: GD related Operating System: Linux PHP Version: 4.0.6 New Comment: --with-gd=DIR DIR is GD "instal prefix" look 4 it into GD makefile default is /usr/local Previous Comments: [2001-09-03 10:29:41] [EMAIL PROTECTED] You need to install the PNG library from http://www.libpng.org/pub/png/ BTW: ask support questions on the PHP-GENERAL mailinglist. [2001-09-03 05:39:16] [EMAIL PROTECTED] I have installed php with GD like ./configure' '--with-apache=../apache_1.3.19' '--prefix=/opt/apache' '--with-pgsql=/opt/postgres/' '--with-oci8=/ora00/oracle/app/oracle/product/8.0.5/' '--with-oracle=/ora00/oracle/app/oracle/product/8.0.5/' '--enable-sigchild' '--with-jpeg-dir=/usr/src/jpeg-6b/' '--with-gd=/usr/src/gd-1.8.4' When I try to open png file, that appear "No PNG support in this PHP build in " error message. Please help. What should I do ? Regards -- Edit this bug report at http://bugs.php.net/?id=13104&edit=1
Bug #16059 Updated: bad root php directory
ID: 16059 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows 2000 Professionnal PHP Version: 4.1.2 New Comment: The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Previous Comments: [2002-03-14 04:11:33] [EMAIL PROTECTED] Hi, You aren't making any sense. can you provide an example of a script that's failing? [2002-03-14 04:00:17] [EMAIL PROTECTED] All DLL in Win32 Package containg a wrong redirect , unable to load php script using MySQL. All code workly perfect. string to use for mysql not work and get error Setup dir: d:\www\php And get Warning to access to dll ( C:\php4\pear\ ) This error is not found on php4.1.1 for Win32 -- Edit this bug report at http://bugs.php.net/?id=16059&edit=1
Bug #16053 Updated: Unable to Load Dynamic Libraries
ID: 16053 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Dynamic loading Operating System: Windows 2000 Adv Server PHP Version: 4.1.2 New Comment: The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Previous Comments: [2002-03-13 20:23:05] [EMAIL PROTECTED] ok, i installed PHP4.1.2 in C:\PHP4. then i try to run the php.exe, or much less, my php scripts and i keep getting about 15 or 16 of these warning errors, PHP Warning: Unable to load dynamic library 'C:\PHP4/php_pgsql.dll' - The specified module could not be found. in Unknown on line 0 but, my dlls, are in PHP4\Extensions, so when i try to change that path in the php.ini. i get this message The dynamic link Library Libct.dll could not be found in the specified path C:\php4;.;C:\winnt\system32;C:\winnt\system;C:\winnt;C:\Program Files\InternetExplorer;;C:\winnt\system32;C:\winnt;C:\winnt\system32\wbem;C:\program files\micosoft SQL server\80\tools\binn. i get 4 of these messages missing LIBCT.dll, OCI.dll, OCIW32.dll, ISQIT09a.dll then after that i get an infinate number of these: PHP Warning: Function registration failed - duplicate name - pg_connect in Unkn own on line 0 please help, iv spent about 6 hours trying to figure this trash out. -- Edit this bug report at http://bugs.php.net/?id=16053&edit=1
Bug #16055 Updated: Running 4.1.2 as module in Apache 1.3.2 crashes Apache.exe
ID: 16055 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Duplicate Bug Type: Session related Operating System: Windows XP Pro PHP Version: 4.1.2 New Comment: This is very likely to be caused by an incorrect session.save_path. There's already a report about that. Please reopen if that's not the case. Previous Comments: [2002-03-13 22:56:55] [EMAIL PROTECTED] This has been a problem in 4.1.0 and 4.1.2. A simple will crash Apache.exe. OS: Windows XP Pro (I suspect this will happen with any version of Windows) Server: Apache 1.3.2 PHP: 4.1.2, running as module [2002-03-13 22:28:31] [EMAIL PROTECTED] This has been a problem in 4.1.0 and 4.1.2. A simple will crash Apache.exe. OS: Windows XP Pro (I suspect this will happen with any version of Windows) Server: Apache 1.3.2 PHP: 4.1.2, running as module -- Edit this bug report at http://bugs.php.net/?id=16055&edit=1
Bug #16060 Updated: Memory Access Violation
ID: 16060 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Windows 2000 PHP Version: 4.1.2 New Comment: status -> feedback Previous Comments: [2002-03-14 04:09:58] [EMAIL PROTECTED] Hi, Could you provide some information for us to work from? eg, what script in particular (if any) is causing this, and also some information on your environment. it doesn't crash for me. [2002-03-14 04:05:42] [EMAIL PROTECTED] We are using PHP 4.1.2 on IIS 5.0 on Windows 2000. PHP is running in ISAPI mode. We use to have Memory Access Violation in PHP 4.1.0, but the problem disappeared in version 4.1.1. We replace the version 4.1.1 by 4.1.2 this morning, and without changing anything else, we are getting Memory Access Violation every other pages. We are forced to go back to version 4.1.1 -- Edit this bug report at http://bugs.php.net/?id=16060&edit=1
Bug #16059 Updated: bad root php directory
ID: 16059 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Unknown/Other Function Operating System: Windows 2000 Professionnal PHP Version: 4.1.2 New Comment: Hi, You aren't making any sense. can you provide an example of a script that's failing? Previous Comments: [2002-03-14 04:00:17] [EMAIL PROTECTED] All DLL in Win32 Package containg a wrong redirect , unable to load php script using MySQL. All code workly perfect. string to use for mysql not work and get error Setup dir: d:\www\php And get Warning to access to dll ( C:\php4\pear\ ) This error is not found on php4.1.1 for Win32 -- Edit this bug report at http://bugs.php.net/?id=16059&edit=1
Bug #16060 Updated: Memory Access Violation
ID: 16060 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: Windows 2000 PHP Version: 4.1.2 New Comment: Hi, Could you provide some information for us to work from? eg, what script in particular (if any) is causing this, and also some information on your environment. it doesn't crash for me. Previous Comments: [2002-03-14 04:05:42] [EMAIL PROTECTED] We are using PHP 4.1.2 on IIS 5.0 on Windows 2000. PHP is running in ISAPI mode. We use to have Memory Access Violation in PHP 4.1.0, but the problem disappeared in version 4.1.1. We replace the version 4.1.1 by 4.1.2 this morning, and without changing anything else, we are getting Memory Access Violation every other pages. We are forced to go back to version 4.1.1 -- Edit this bug report at http://bugs.php.net/?id=16060&edit=1
Bug #16060: Memory Access Violation
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.1.2 PHP Bug Type: Reproducible crash Bug description: Memory Access Violation We are using PHP 4.1.2 on IIS 5.0 on Windows 2000. PHP is running in ISAPI mode. We use to have Memory Access Violation in PHP 4.1.0, but the problem disappeared in version 4.1.1. We replace the version 4.1.1 by 4.1.2 this morning, and without changing anything else, we are getting Memory Access Violation every other pages. We are forced to go back to version 4.1.1 -- Edit bug report at http://bugs.php.net/?id=16060&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16060&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16060&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16060&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16060&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16060&r=support Expected behavior: http://bugs.php.net/fix.php?id=16060&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16060&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16060&r=submittedtwice
Bug #14529 Updated: script doesn't always finish output
ID: 14529
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Output Control
Operating System: Linux RH 7.2
PHP Version: 4.3.0-dev
New Comment:
Apologies for not including web server details (did so in another post
on another bug). Apache 1.3.20 with PHP as a DSO (no CGI compile). My
local Unix guru has suggested trying a more recent Apache release which
I will do when I get chance.
I haven't tried with 4.0.6 pre-file upload and I am loathed to do so as
I've now built PHP about a dozen times in the last week or so.
I don't have access to another linux ditro unfortunately although we
are running a production environment on Solaris. I haven't tried
anything on that yet due to its production status but can do if it
helps.
GCC details (gcc -v)
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-98)
Previous Comments:
[2002-03-13 17:27:27] [EMAIL PROTECTED]
We MAY have seen a similar problem (not using Zend Optimizer, though --
whew!). We had problems with locutions like
function postprocess($buf)
{
$buf = preg_replace("/some stuff/","some other stuff",$buf);
return $buf;
}
ob_start("postprocess");
Changing the postprocess function to
function postprocess($ibuf)
{
$obuf = preg_replace("/some stuff/","some other stuff",$ibuf);
return $obuf;
}
seems to have eliminated the problem.
[2002-03-13 10:41:37] [EMAIL PROTECTED]
A question for [EMAIL PROTECTED] :
Did you try it before the patch was applied in 4.0.6
Of the pages giving me grief, some of them have forms and some of them
don't.
I don't have the access at my end to try my scripts on a different
linux version.
[2002-03-13 08:57:03] [EMAIL PROTECTED]
i faintly remember issues with the gcc version
RedHat uses (experimental gcc prerelease from
their own labs or something)
there were definetly problems in the past that
where RedHat-only :(
do you have a chance to test on another linux
distribution or to compile on another one and
transfer the binaries to your RH system?
[2002-03-13 08:31:53] [EMAIL PROTECTED]
Which webserver and version do you use?
Derick
[2002-03-13 08:19:41] [EMAIL PROTECTED]
Further to my previous comment. I downgraded to 4.0.6 with the last
file upload patch and I am still getting the problem.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/14529
--
Edit this bug report at http://bugs.php.net/?id=14529&edit=1
Bug #16059: bad root php directory
From: [EMAIL PROTECTED] Operating system: Windows 2000 Professionnal PHP version: 4.1.2 PHP Bug Type: Unknown/Other Function Bug description: bad root php directory All DLL in Win32 Package containg a wrong redirect , unable to load php script using MySQL. All code workly perfect. string to use for mysql not work and get error Setup dir: d:\www\php And get Warning to access to dll ( C:\php4\pear\ ) This error is not found on php4.1.1 for Win32 -- Edit bug report at http://bugs.php.net/?id=16059&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16059&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16059&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16059&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16059&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16059&r=support Expected behavior: http://bugs.php.net/fix.php?id=16059&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16059&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16059&r=submittedtwice
Bug #16058: ftp_get() try to create temp file in the c:\
From: [EMAIL PROTECTED]
Operating system: Win2K
PHP version: 4.1.2
PHP Bug Type: FTP related
Bug description: ftp_get() try to create temp file in the c:\
OS - Win2K, IIS, PHP.
If i use NTFS on my C drive under Win2K, and try to get file over ftp
using ftp_get(), ftp_get() fails.
The problem is in C code in php_ftp.c:
C function tmpfile(), that used for creation of temporary files, try to
create this file on C:\ (in the root directory, according to C docs):
Source code from php_ftp.c ===
/* get to temporary file, so if there is an error, no
existing file gets clobbered
*/
if ((tmpfp = tmpfile()) == NULL) {
php_error(E_WARNING, "error opening tmpfile");
RETURN_FALSE;
}
===
But, for security reasons, root directory can't be writable by Anonymous
user, so ftp_get() fails.
ftp_get() work only if we have c:\ world writable.
--
Edit bug report at http://bugs.php.net/?id=16058&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16058&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16058&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16058&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16058&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16058&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16058&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16058&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16058&r=submittedtwice
