#36452 [Opn-Bgs]: cannot load php_mysql.dll or php_gd2.dll libraries after upgrading from 5.0.2
ID: 36452 Updated by: [EMAIL PROTECTED] Reported By: redscourge at gmail dot com -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: windows xp sp2 PHP Version: 5.1.2 New Comment: Everything works fine.. Check if you don't have any old dlls in Windows dirs (C:\windows and C:\windows\system32). Also, if you have mysal installed, with its dir in the path, check the version of its libmysql.dll file, because it may be causing the problem. If still doesn't work, read *carefully* the on-line manual: http://php.net/install.windows.manual Previous Comments: [2006-02-19 03:40:24] redscourge at gmail dot com Description: i just tried to upgrade from php 5.0.2 to 5.1.2 today. i replaced all files properly, and tried first going line by line thru 5.1.2's php.ini file and toggling on the features that i had in my previous php.ini version, so that any new stuff added since then is in its new default, but settings that affect my setup are as they should be. i verified the file permissions, moved the updated php5ts.dll and php5apache2.dll files to my apache folder, then started up my apache server, version 2.0.55. i loaded my front page, and BAM! i get nothing. then i tried a few things, and apache2 was telling me on startup that it couldnt find the php_mysql.dll or php_gd2.dll libraries that i enabled in the php.ini file, that were there, that were being pointed at properly by the php.ini file, and yet it didnt work. i tried replacing those .dll files with the old ones from my previous installation, didnt work. tried keeping the new version dll's and putting all my original version files back, didnt work. this leads me to believe that the new php_mysql.dll file and php_gd2.dll file are either corrupt, or do not work with apache 2.0.55 i know for damn sure i did nothing wrong, as i retried this several times from scratch, and only when all 5.0.2 files present did php load the dll's correctly. Reproduce code: --- my webpage depends on retrieving SQL code to produce all html output, and since it couldnt load the mysql dll, i got a blank html source file served on the main page, and any page that makes use of sql. Expected result: i expected my damn site to work, seeing as how i know the php.ini file was fine, im lead to believe that php 5.1.2 is a released version and should therefore work, and because i made sure i didnt forget anything at all. Actual result: -- shit all -- Edit this bug report at http://bugs.php.net/?id=36452edit=1
#36451 [Opn-Bgs]: Array doesn't pop when array is created inside array_pop
ID: 36451 Updated by: [EMAIL PROTECTED] Reported By: epoc_32 at yahoo dot co dot ukXXX -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows XP PHP Version: 5.1.2 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. http://php.net/references Previous Comments: [2006-02-19 02:50:39] epoc_32 at yahoo dot co dot ukXXX Description: If you create an array inside array_pop(), expecting that array to be popped then it isn't even though the last element of that array is returned as expected. Creating the array on the previous line makes array_pop() behave as expected. This behaviour doesn't occur in PHP4.3.x on FreeBSD. I only noticed it when I upgraded to PHP 5.1.2 on my home WinXP machine though it's possible it was broken but I didn't notice it in 5.0.x Reproduce code: --- $a=array(0, 1, 2, 3, 4, 5); // Set array first. $offcut=array_pop($a); // Then pop array. $length=count($a); echopreArray offcut: .$offcut.\nArray length: .$length.\nLast element: .$a[$length-1]./pre\n; $offcut=array_pop($a=array(0, 1, 2, 3, 4, 5)); // Set and pop at the same time. $length=count($a); echopreArray offcut: .$offcut.\nArray length: .$length.\nLast element: .$a[$length-1]./pre\n; Expected result: Array offcut: 5 Array length: 5 Last element: 4 Array offcut: 5 Array length: 5 Last element: 4 Actual result: -- Array offcut: 5 Array length: 5 Last element: 4 Array offcut: 5 Array length: 6 Last element: 5 -- Edit this bug report at http://bugs.php.net/?id=36451edit=1
#27132 [Bgs-Opn]: ncurses_getch() interrupted by receipt of a handled signal
ID: 27132
User updated by: neuhauser at chello dot cz
Reported By: neuhauser at chello dot cz
-Status: Bogus
+Status: Open
Bug Type: ncurses related
Operating System: *
PHP Version: 5CVS, 4CVS (2005-12-22) (cvs)
Assigned To: hholzgra
New Comment:
I'm happy to read that the problem was my fault. I have re-read the
declare() description and the ncurses extension documentation, and see
no hints as to what I did wrong. Can you please describe the
interactions between declare() and ncurses_getch()?
On a related note: the extension has been experimental for the last
three years or so, but is marked stable on pecl.php.net. What's the
real state of the extension, and what can I expect from its
documentation?
Previous Comments:
[2006-01-05 23:18:35] [EMAIL PROTECTED]
this 'bug' was caused by misuse of declare()
[2006-01-05 21:30:02] [EMAIL PROTECTED]
This will not be fixed in core. And the extension has been moved to
PECL now.
[2005-12-19 09:02:21] [EMAIL PROTECTED]
Hartmut: If you're not going to do anything about this, please
de-assign it with some comment. And preferrably move the whole
extension to PECL the same time..
[2004-02-03 09:51:52] neuhauser at chello dot cz
Description:
receipt of a signal interrupts ncurses_getch(), which
should never happen
curs_getch(3X):
The behavior of getch and friends in the presence
of handled signals is unspecified in the SVr4 and
XSI Curses documentation. Under historical curses
implementations, it varied depending on whether
the operating system's implementation of handled
signal receipt interrupts a read(2) call in
progress or not, and also (in some implementations)
depending on whether an input timeout or
non-blocking mode hsd been set.
Programmers concerned about portability should be
prepared for either of two cases: (a) signal
receipt does not interrupt getch; (b) signal
receipt interrupts getch and causes it to return
ERR with errno set to EINTR.
Under the ncurses implementation, handled signals
never interrupt getch.
(emphasis added)
Reproduce code:
---
compare the behavior of this PHP snippet
?php
function sigalrm()
{
global $c;
$s = sprintf(sigalrm: '%d'\n, $c);
ncurses_addstr($s);
ncurses_refresh();
}
ncurses_init();
ncurses_cbreak();
ncurses_nl();
ncurses_noecho();
pcntl_signal(SIGALRM, 'sigalrm');
declare(ticks = 1);
for (;;) {
pcntl_alarm(1);
$c = ncurses_getch();
if ('q' == chr($c)) {
exit(0);
}
}
ncurses_end();
exit(0);
with its C equivalent
#include unistd.h
#include signal.h
#include curses.h
int c;
void sigalrm()
{
char s[40];
sprintf(s, sigalrm: '%d'\n, c);
addstr(s);
refresh();
}
int main(int argc, char** argv)
{
initscr();
cbreak();
nl();
noecho();
signal(SIGALRM, sigalrm);
for (;;) {
alarm(1);
c = getch();
if ('q' == c) {
return 0;
}
}
endwin();
return 0;
}
Expected result:
I was expecting to see the same output as given by the C version:
single
sigalrm: '0'
line until next keypress, then the zero would be replaced with ascii
code of the pressed key
Actual result:
--
endless series of
sigalrm: '-1'
lines, which suggests that receipt of the alarm, although handled,
interrupts the getch() call which then returns ERR.
(as a sidenote, http://www.php.net/manual/en/ref.ncurses.php says On
error ncurses functions return NCURSES_ERR, but said constant doesn't
exist in 4.3.3 or 4.3.4, both cli)
--
Edit this bug report at http://bugs.php.net/?id=27132edit=1
#36454 [NEW]: Destructor, include/require and path with ./
From: nightstorm at tlen dot pl
Operating system: Windows XP
PHP version: 5.1.2
PHP Bug Type: Scripting Engine problem
Bug description: Destructor, include/require and path with ./
Description:
In the reproduce code we include a file test.php showing 'Hello World'
six times:
- Outside a destructor: test.php
- Outside a destructor: D:\server\www\test\test.php (full path)
- Outside a destructor: ./test.php
These three cases work. We don't change include path and try them in a
destructor:
- Outside a destructor: test.php - works
- Outside a destructor: D:\server\www\test\test.php (full path) -
works
- Outside a destructor: ./test.php - No such file or directory, even if
the file exists.
Outside a destructor, PHP parses correctly the include path, inside it
seems to be broken, because a fatal error is generated. PHP manual doesn't
explain why the last case doesn't work, I also can't find any reason. I
hope you'll fix it quickly.
---Configuration---
Windows XP SP 2 (NTFS)
PHP 5.1.2
Apache 2.0.55
Ze1.compatibility = 0
Include path = .;C:\php5\pear (PHP 5 default)
Safe mode = off
Reproduce code:
---
test.php:
?php
echo 'Hello world!br/';
?
problem.php:
?php
require('test.php');
require('D:\server\www\test\test.php');
require('./test.php');
class foo{
function __destruct()
{
require('test.php');
require('D:\server\www\test\test.php');
require('./test.php');
}
}
$foo = new foo;
?
Expected result:
Hello world!
Hello world!
Hello world!
Hello world!
Hello world!
Hello world!
Actual result:
--
Hello world!
Hello world!
Hello world!
Hello world!
Hello world!
Warning: foo::require(./test.php) [function.require]: failed to open
stream: No such file or directory in D:\server\www\test\problem.php on
line 11
Fatal error: foo::require() [function.require]: Failed opening required
'./test.php' (include_path='.;C:\php5\pear') in
D:\server\www\test\problem.php on line 11
--
Edit bug report at http://bugs.php.net/?id=36454edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36454r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36454r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36454r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36454r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36454r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36454r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36454r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36454r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36454r=support
Expected behavior:http://bugs.php.net/fix.php?id=36454r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36454r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36454r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36454r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36454r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36454r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36454r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36454r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36454r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36454r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36454r=mysqlcfg
#36455 [NEW]: php_apache_shutdown_wrapper calls itself until segfault
From: haleden at colorado dot edu Operating system: redhat 7 PHP version: 5.1.2 PHP Bug Type: Apache related Bug description: php_apache_shutdown_wrapper calls itself until segfault Description: there are a bunch of reports out there that have been labeled bogus that i bet were not. i began to have problems starting apache 1.3.27 reliably after installing the php module. i found that if i commented out the php module, apache would start. then, if i went in and uncommented the php module, and did a apachectl restart, things were fine. i finally got some time to dig deeper, and ran it under gdb and found that it was crashing in a deep stack of nested calls to php_apache_shutdown_wrapper. looking at the source, i see that php_apache_shutdown_wrapper calls apache_sapi_module.shutdown which is defined to be php_apache_shutdown_wrapper. i suspect that at one time apache_sapi_module.shutdown pointed to php_apache_request_shutdown and things worked until someone decided that the wrapper should be called but forgot to change the wrapper to call php_apache_request_shutdown. as to why it was happening at startup, i conjecture that apache keeps track of modules in some way and if a module didn't shutdown cleanly before, it calls the shutdown hook to clean up before starting again. by starting it without the module, that check was cleared, and it would not run the shutdown hook the next time. i'm not an expert at all of this stuff, but i made the change to the wrapper and it seems to work--further testing and sanity checking advised. thanks, hal Reproduce code: --- see above description for apache config changes Expected result: apache starts sucessfully each time when php module defined Actual result: -- apache doesn't always start successfully when php module defined -- Edit bug report at http://bugs.php.net/?id=36455edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36455r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36455r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36455r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36455r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36455r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36455r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36455r=needscript Try newer version:http://bugs.php.net/fix.php?id=36455r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36455r=support Expected behavior:http://bugs.php.net/fix.php?id=36455r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36455r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36455r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36455r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36455r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36455r=dst IIS Stability:http://bugs.php.net/fix.php?id=36455r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36455r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36455r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36455r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36455r=mysqlcfg
#36455 [Opn]: php_apache_shutdown_wrapper calls itself until segfault
ID: 36455
User updated by: haleden at colorado dot edu
Reported By: haleden at colorado dot edu
Status: Open
Bug Type: Apache related
Operating System: redhat 7
PHP Version: 5.1.2
New Comment:
oops, forgot to say that the changes go in:
sapi/apache/mod_php5.c
...
int php_apache_shutdown_wrapper(void)
{
apache_php_initialized = 0;
/* apache_sapi_module.shutdown(apache_sapi_module);*/
php_apache_request_shutdown(apache_sapi_module);
...
Previous Comments:
[2006-02-19 20:54:47] haleden at colorado dot edu
Description:
there are a bunch of reports out there that have been
labeled bogus that i bet were not.
i began to have problems starting apache 1.3.27 reliably
after installing the php module.
i found that if i commented out the php module, apache would
start. then, if i went in and uncommented the php module,
and did a apachectl restart, things were fine.
i finally got some time to dig deeper, and ran it under gdb
and found that it was crashing in a deep stack of nested
calls to php_apache_shutdown_wrapper.
looking at the source, i see that
php_apache_shutdown_wrapper calls
apache_sapi_module.shutdown which is defined to be
php_apache_shutdown_wrapper. i suspect that at one time
apache_sapi_module.shutdown pointed to
php_apache_request_shutdown and things worked until someone
decided that the wrapper should be called but forgot to
change the wrapper to call php_apache_request_shutdown.
as to why it was happening at startup, i conjecture that
apache keeps track of modules in some way and if a module
didn't shutdown cleanly before, it calls the shutdown hook
to clean up before starting again. by starting it without
the module, that check was cleared, and it would not run the
shutdown hook the next time.
i'm not an expert at all of this stuff, but i made the
change to the wrapper and it seems to work--further testing
and sanity checking advised.
thanks,
hal
Reproduce code:
---
see above description for apache config changes
Expected result:
apache starts sucessfully each time when php module defined
Actual result:
--
apache doesn't always start successfully when php module
defined
--
Edit this bug report at http://bugs.php.net/?id=36455edit=1
#36451 [Bgs-Opn]: Array doesn't pop when array is created inside array_pop
ID: 36451 User updated by: epoc_32 at yahoo dot co dot ukXXX Reported By: epoc_32 at yahoo dot co dot ukXXX -Status: Bogus +Status: Open Bug Type: Scripting Engine problem Operating System: Windows XP PHP Version: 5.1.2 New Comment: This isn't a support question, I'm not asking for help in a script. It's a minor bug in the way the script is parsed when nesting functions. The code in which I discovered the bug used explode() inside array_pop(), I only used my example code to simplyfy things. array_pop() is returning the last element of the array but isn't truncating the array inside it. As I say, things work as expected in PHP4 so why would PHP5 return the last element of the array without truncating it? Previous Comments: [2006-02-19 13:38:50] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. http://php.net/references [2006-02-19 02:50:39] epoc_32 at yahoo dot co dot ukXXX Description: If you create an array inside array_pop(), expecting that array to be popped then it isn't even though the last element of that array is returned as expected. Creating the array on the previous line makes array_pop() behave as expected. This behaviour doesn't occur in PHP4.3.x on FreeBSD. I only noticed it when I upgraded to PHP 5.1.2 on my home WinXP machine though it's possible it was broken but I didn't notice it in 5.0.x Reproduce code: --- $a=array(0, 1, 2, 3, 4, 5); // Set array first. $offcut=array_pop($a); // Then pop array. $length=count($a); echopreArray offcut: .$offcut.\nArray length: .$length.\nLast element: .$a[$length-1]./pre\n; $offcut=array_pop($a=array(0, 1, 2, 3, 4, 5)); // Set and pop at the same time. $length=count($a); echopreArray offcut: .$offcut.\nArray length: .$length.\nLast element: .$a[$length-1]./pre\n; Expected result: Array offcut: 5 Array length: 5 Last element: 4 Array offcut: 5 Array length: 5 Last element: 4 Actual result: -- Array offcut: 5 Array length: 5 Last element: 4 Array offcut: 5 Array length: 6 Last element: 5 -- Edit this bug report at http://bugs.php.net/?id=36451edit=1
#36451 [Opn-Bgs]: Array doesn't pop when array is created inside array_pop
ID: 36451 Updated by: [EMAIL PROTECTED] Reported By: epoc_32 at yahoo dot co dot ukXXX -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows XP PHP Version: 5.1.2 New Comment: Please read the section about Passing arguments by reference I posted. Previous Comments: [2006-02-19 22:00:43] epoc_32 at yahoo dot co dot ukXXX This isn't a support question, I'm not asking for help in a script. It's a minor bug in the way the script is parsed when nesting functions. The code in which I discovered the bug used explode() inside array_pop(), I only used my example code to simplyfy things. array_pop() is returning the last element of the array but isn't truncating the array inside it. As I say, things work as expected in PHP4 so why would PHP5 return the last element of the array without truncating it? [2006-02-19 13:38:50] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. http://php.net/references [2006-02-19 02:50:39] epoc_32 at yahoo dot co dot ukXXX Description: If you create an array inside array_pop(), expecting that array to be popped then it isn't even though the last element of that array is returned as expected. Creating the array on the previous line makes array_pop() behave as expected. This behaviour doesn't occur in PHP4.3.x on FreeBSD. I only noticed it when I upgraded to PHP 5.1.2 on my home WinXP machine though it's possible it was broken but I didn't notice it in 5.0.x Reproduce code: --- $a=array(0, 1, 2, 3, 4, 5); // Set array first. $offcut=array_pop($a); // Then pop array. $length=count($a); echopreArray offcut: .$offcut.\nArray length: .$length.\nLast element: .$a[$length-1]./pre\n; $offcut=array_pop($a=array(0, 1, 2, 3, 4, 5)); // Set and pop at the same time. $length=count($a); echopreArray offcut: .$offcut.\nArray length: .$length.\nLast element: .$a[$length-1]./pre\n; Expected result: Array offcut: 5 Array length: 5 Last element: 4 Array offcut: 5 Array length: 5 Last element: 4 Actual result: -- Array offcut: 5 Array length: 5 Last element: 4 Array offcut: 5 Array length: 6 Last element: 5 -- Edit this bug report at http://bugs.php.net/?id=36451edit=1
#36456 [NEW]: proc_terminte($process,22) cause system hang
From: sqchen at citiz dot net
Operating system: redhat 7.3
PHP version: 5.1.2
PHP Bug Type: Unknown/Other Function
Bug description: proc_terminte($process,22) cause system hang
Description:
proc_terminte($process,22) cause system hangs
Reproduce code:
---
$process = proc_open('/bin/ls', $descriptorspec, $pipes, $cwd, $env);
proc_terminte($process,22)
Expected result:
something happens
Actual result:
--
system hang
--
Edit bug report at http://bugs.php.net/?id=36456edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36456r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36456r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36456r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36456r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36456r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36456r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36456r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36456r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36456r=support
Expected behavior:http://bugs.php.net/fix.php?id=36456r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36456r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36456r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36456r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36456r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36456r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36456r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36456r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36456r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36456r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36456r=mysqlcfg
#35638 [Opn]: Adding udate to imap_fetch_overview results?
ID: 35638 User updated by: charlesb at ekit-inc dot com Reported By: charlesb at ekit-inc dot com Status: Open Bug Type: Feature/Change Request Operating System: Solaris/i86 PHP Version: 4.4.1 New Comment: Guys, Any chance you could do this soon? Last week I had to port a significant portion of our webmail system to python because PHP's imap functions weren't fast enough. Having imap_fetch_overview return the arrival date would mean we could do away with a second call to the imap server, keep our inbox display nice and fast, and stay with PHP. Thanks, Charles Previous Comments: [2005-12-11 23:18:18] charlesb at ekit-inc dot com Description: Would it be possible to add the arrival date for an email (preferably in unixtime) to the results for imap_fetch_overview? It would help us _alot_ with our webmail. Thanks, Charles -- Edit this bug report at http://bugs.php.net/?id=35638edit=1
#36457 [NEW]: glob(*.txt, 50) segment fault on linux
From: sqchen at citiz dot net Operating system: redhat 7.3 PHP version: 5.1.2 PHP Bug Type: Unknown/Other Function Bug description: glob(*.txt, 50) segment fault on linux Description: glob(*.txt, 50) segment fault on linux Reproduce code: --- glob(*.txt, 50) ans also when the second parameter is 48 or 64 or some others Actual result: -- segfault -- Edit bug report at http://bugs.php.net/?id=36457edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36457r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36457r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36457r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36457r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36457r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36457r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36457r=needscript Try newer version:http://bugs.php.net/fix.php?id=36457r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36457r=support Expected behavior:http://bugs.php.net/fix.php?id=36457r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36457r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36457r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36457r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36457r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36457r=dst IIS Stability:http://bugs.php.net/fix.php?id=36457r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36457r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36457r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36457r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36457r=mysqlcfg
#36458 [NEW]: function sleep accept negative value
From: quick_defect at yahoo dot com Operating system: redhat PHP version: 5.1.2 PHP Bug Type: Unknown/Other Function Bug description: function sleep accept negative value Description: First,if given negative value, I have to interrupt the execution of scripts because it sleep for very long time.(I did not exactly know how long) Second,if given a int which cause overflow, it also do not work very well. Reproduce code: --- sleep(-1); $max=mt_getrandmax(); $of=-$max-2; sleep($of); Expected result: exception or turn it to a legal value Actual result: -- sleep for a very long time -- Edit bug report at http://bugs.php.net/?id=36458edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36458r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36458r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36458r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36458r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36458r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36458r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36458r=needscript Try newer version:http://bugs.php.net/fix.php?id=36458r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36458r=support Expected behavior:http://bugs.php.net/fix.php?id=36458r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36458r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36458r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36458r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36458r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36458r=dst IIS Stability:http://bugs.php.net/fix.php?id=36458r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36458r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36458r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36458r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36458r=mysqlcfg
#36458 [Opn-Fbk]: function sleep accept negative value
ID: 36458 Updated by: [EMAIL PROTECTED] Reported By: quick_defect at yahoo dot com -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: redhat PHP Version: 5.1.2 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2006-02-20 04:24:46] quick_defect at yahoo dot com Description: First,if given negative value, I have to interrupt the execution of scripts because it sleep for very long time.(I did not exactly know how long) Second,if given a int which cause overflow, it also do not work very well. Reproduce code: --- sleep(-1); $max=mt_getrandmax(); $of=-$max-2; sleep($of); Expected result: exception or turn it to a legal value Actual result: -- sleep for a very long time -- Edit this bug report at http://bugs.php.net/?id=36458edit=1
#36429 [Fbk-Opn]: Httpd crashes
ID: 36429 User updated by: pk at nodex dot ru Reported By: pk at nodex dot ru -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Linux Slackware 10.2 PHP Version: 4.4.2 New Comment: There is some trouble to provide small script. Becouse bug was seen on Mambo CMS. No any other applications. Like PHPMyAdmin or any other. Previous Comments: [2006-02-17 21:57:43] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2006-02-17 17:36:47] pk at nodex dot ru Description: Httpd crashes when executes Actual result: -- httpd: dl-open.c:438: dl_open_worker: Assertion `imap-l_type == lt_loaded' failed. /root/php-4.4.2/Zend/zend_operators.c(1068) : Freeing 0x0894CA3C (82 bytes), script=/usr/home/gamesite/html/index.php Last leak repeated 7 times /root/php-4.4.2/Zend/zend_hash.c(453) : Freeing 0x0891333C (128 bytes), script=/usr/home/gamesite/html/index.php Last leak repeated 33 times /root/php-4.4.2/Zend/zend_operators.c(1061) : Freeing 0x088D1AC4 (7662 bytes), script=/usr/home/gamesite/html/index.php /root/php-4.4.2/Zend/zend_variables.c(111) : Actual location (location was relayed) /root/php-4.4.2/ext/standard/php_smart_str.h(83) : Freeing 0x089024EC (169 bytes), script=/usr/home/gamesite/html/index.php /root/php-4.4.2/Zend/zend_execute.c(2069) : Freeing 0x08A42274 (12 bytes), script=/usr/home/gamesite/html/index.php Last leak repeated 7 times /root/php-4.4.2/Zend/zend_execute.c(1839) : Freeing 0x08A43A54 (12 bytes), script=/usr/home/gamesite/html/index.php Last leak repeated 16 times /root/php-4.4.2/Zend/zend_execute.c(512) : Freeing 0x0892B23C (12 bytes), script=/usr/home/gamesite/html/index.php Last leak repeated 56 times /root/php-4.4.2/Zend/zend_compile.c(1703) : Freeing 0x08912AAC (12 bytes), script=/usr/home/gamesite/html/index.php Last leak repeated 36 times /root/php-4.4.2/Zend/zend_operators.c(1059) : Freeing 0x088D0F6C (60 bytes), script=/usr/home/gamesite/html/index.php /root/php-4.4.2/Zend/zend_hash.c(275) : Freeing 0x088CA534 (59 bytes), script=/usr/home/gamesite/html/index.php Last leak repeated 1015 times /root/php-4.4.2/Zend/zend_API.c(844) : Freeing 0x08918554 (2 bytes), script=/usr/home/gamesite/html/index.php Last leak repeated 35 times /root/php-4.4.2/Zend/zend_API.c(843) : Freeing 0x08953C5C (12 bytes), script=/usr/home/gamesite/html/index.php Last leak repeated 35 times /root/php-4.4.2/Zend/zend_execute.c(784) : Freeing 0x0894D674 (12 bytes), script=/usr/home/gamesite/html/index.php Last leak repeated 7 times /root/php-4.4.2/Zend/zend_execute.c(1842) : Freeing 0x0890298C (17 bytes), script=/usr/home/gamesite/html/index.php /root/php-4.4.2/Zend/zend_variables.c(111) : Actual location (location was relayed) Last leak repeated 7 times /root/php-4.4.2/Zend/zend_execute.c(297) : Freeing 0x089545CC (12 bytes), script=/usr/home/gamesite/html/index.php Last leak repeated 1 time /root/php-4.4.2/Zend/zend_API.c(680) : Freeing 0x0892AAF4 (18 bytes), script=/usr/home/gamesite/html/index.php Last leak repeated 600 times /root/php-4.4.2/Zend/zend_execute.c(1916) : Freeing 0x08902F8C (12 bytes), script=/usr/home/gamesite/html/index.php Last leak repeated 3 times /root/php-4.4.2/Zend/zend_execute.c(1670) : Freeing 0x088FE66C (12 bytes), script=/usr/home/gamesite/html/index.php Last leak repeated 42 times /root/php-4.4.2/Zend/zend_execute.c(1812) : Freeing 0x088FDD6C (12 bytes), script=/usr/home/gamesite/html/index.php Last leak repeated 2 times /root/php-4.4.2/Zend/zend_API.c(679) : Freeing 0x088FDD2C (12 bytes), script=/usr/home/gamesite/html/index.php Last leak repeated 600 times /root/php-4.4.2/Zend/zend_execute.c(795) : Freeing 0x088D9344 (12 bytes), script=/usr/home/gamesite/html/index.php Last leak repeated 1 time /root/php-4.4.2/Zend/zend_execute.c(501) : Freeing 0x0893A67C (12 bytes), script=/usr/home/gamesite/html/index.php Last leak repeated 85 times /root/php-4.4.2/Zend/zend_execute.c(477) : Freeing 0x088FFF74 (11 bytes), script=/usr/home/gamesite/html/index.php /root/php-4.4.2/Zend/zend_variables.c(111) : Actual location (location was relayed) Last leak repeated 5 times /root/php-4.4.2/ext/standard/string.c(569) : Freeing 0x08953714 (12 bytes), script=/usr/home/gamesite/html/index.php Last leak repeated 17 times /root/php-4.4.2/Zend/zend_execute.c(787) : Freeing 0x086CFB5C (44 bytes),
