Re: [PHP-DEV] Bug #14120 Updated: libtool needs help.
On Sun, Dec 30, 2001 at 08:00:29PM -0600, Larry Rosenman wrote : * Markus Fischer [EMAIL PROTECTED] [011230 15:04]: FYI, I found the bug, and it's really libtools. I submitted a patch to them, and posted it. Sorry if I got under people's skin. Nm, and a happy new year ;) -- Please always Cc to me when replying to me on the lists. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14778 Updated: Function self-caller crash php
ID: 14778
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Reproducible crash
Operating System: windows ME
PHP Version: 4.1.0
New Comment:
a) known b) just one of zillion ways to dos c) expected d) won't be fixed soon/never
e) bogus
Previous Comments:
[2001-12-30 21:28:24] [EMAIL PROTECTED]
It's not a Bug, but crash PHP. Maybe it's proposital way to prevent a type of DoS.
Sometimes it's usefull or it's need use a function that call itself. An example is a
recursive array routine.
?PHP
function crash($foo) {
crash($foo);
}
crash(foo);
?
What I like to show is: windows crash PHP when this code run. This is expected or the
right is show a Fatal Error mensage?
Edit this bug report at http://bugs.php.net/?id=14778edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14777 Updated: Style Sheets not interpreted when sent through Apache/PHP
ID: 14777
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Apache related
Operating System: Windows ME
PHP Version: 4.1.0
New Comment:
Hi,
I found the solution:
The Internet Explorer needs the following DOCTYPE-Definition:
!DOCTYPE html public -//W3C//DTD HTML 4.0 transitional//EN
Thanks a lot for your help!
Previous Comments:
[2001-12-30 17:53:28] [EMAIL PROTECTED]
Actually, it's to do with the IE engine not interpreting css correctly. Remember, that
the scroll bar code is a: microsoft proprietary, and b: not standard compliant. Thus,
the error is in the ie engine in the way it inteprets html. I have found that this
works sometimes and sometimes not on .php files, and the same is true for .html files.
Go yell at Microsoft. :)
[2001-12-30 17:49:38] [EMAIL PROTECTED]
Thanks, I tried changing the wrong DOCTYPE-Definition (I replaced all extensions .html
with .php via Search and Replace, so also the DOCTYPE-Definition was wrong
afterwords), aswell as deleting it from the file, but it didn't work out
unfortunately.
Have you got another clue?
[2001-12-30 15:40:30] [EMAIL PROTECTED]
i forgot to +bogus
[2001-12-30 15:31:12] [EMAIL PROTECTED]
check your DOCTYPE definition:
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0//EN
it's WRONG. either chose the right one or leave it out.
Kind Regards,
Daniel Lorch
[2001-12-30 14:39:52] [EMAIL PROTECTED]
Hi!
I've got the following configuration:
PHP 4.1.0 running as ISAPI-Module on Apache 1.3.22
The following problem results only (!) if I use .php as extension.
I originally programmed the entire site with the extension .html. I used IE-specific
CSS-elements to change the color/style of the scrollbar. It all worked fine.
Then I wanted to use .php as extension instead, so that I could use a prepend if
necessary (e.g. include a config.php, etc.). It seemed to work fine still, PHP code is
executed, the page is shown as usual. Only that the scrollbar is not shown with its
changed appearance anymore. If I change back to .html everythings fine again.
I can't explain this because I have in mind, that everything that is outside of
?php-Tags is sent unchanged to the browser. And the Source-Code (right-click in
Internet-Explorer) shows no differences between the two files. Still it doesn't seem
to work with .php
Hereby the necessary files:
hp_mitte.php:
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0//EN
html
head
titlePfarrgemeinde St. Maria Geburt, Duderstadt-Gerblingerode/title
script type=text/javascript!--
function checkFrameset()
{if(!parent.oben) location.href=index.php;}
--/script
style type=text/css!--
body {margin-bottom:0px; margin-top:0px; margin-left:0px; margin-right:0px;
scrollbar-face-color:#FF; scrollbar-highlight-color:#43CBFF;
scrollbar-shadow-color:#43CBFF; scrollbar-3dlight-color:#43CBFF;
scrollbar-arrow-color:#43CBFF; scrollbar-track-color:#D5D5D5;
scrollbar-darkshadow-color:#43CBFF;}
table {border:0px;}
--/style
/head
body onLoad=checkFrameset()
table cellspacing=0 cellpadding=0 width=100% height=100%
tr bgcolor=#D5D5D5
td height=24px colspan=3
font style=font: bold 12pt Arial, Helvetica, sans-serif;
nbsp;nbsp;Startseite
/font
/td
/tr
tr
td align=center colspan=3 valign=middle
img src=images/kirche.jpg /br /
font style=font:10pt Arial, Helvetica, sans-serif;
Pfarrkirche St. Maria Geburt
/font
/td
/tr
/table
body
/html
index.php:
!DOCTYPE php PUBLIC -//W3C//DTD php 4.0 Frameset//EN
html
head
titlePfarrgemeinde St. Maria Geburt, Duderstadt-Gerblingerode/title
/head
frameset frameborder=no border=0 framespacing=0 rows=30px,*,24px
frame src=hp_oben.php noresize=noresize scrolling=no name=oben
marginheight=0 marginwidth=0
frameset border=0 frameborder=no framespacing=0 cols=159px,*,9px
frame src=hp_links.php noresize=noresize scrolling=no name=links
marginheight=0 marginwidth=0
frame src=hp_mitte.php noresize=noresize name=mitte scrolling=yes
marginheight=0 marginwidth=0
frame src=hp_rechts.php noresize=noresize scrolling=no name=rechts
marginheight=0 marginwidth=0
/frameset
frame src=hp_unten.php noresize=noresize scrolling=no name=unten
marginheight=0 marginwidth=0
noframes
body
/body
/noframes
/frameset
/html
The other files are not really important, you can have empty files and the same
problem results (or results not depending on the file-extension).
I hope you can help me!
Sincelery
Daniel
[PHP-DEV] Bug #14770 Updated: phps truncates long sources
ID: 14770 Updated by: cardinal Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Scripting Engine problem Operating System: Linux Mandrake 8.1 kernel 2.4.8 PHP Version: 4.1.0 New Comment: I'm afraid to ask for an example of a 'long source', but could you provide some details about the size of the code, and what sort of results you're seeing? Previous Comments: [2001-12-30 07:19:45] [EMAIL PROTECTED] PHP 4.1.0 with Apache 1.3.22 truncates sources I have also PHP 4.0.6 with Apache 1.3.20 that does not have the bug ./congfigure --with-mysql --with-apache=../apache-1.3.22 --enable-track-vars long sources only are truncated short display correctly Edit this bug report at http://bugs.php.net/?id=14770edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #6852 Updated: Misc. bugs
ID: 6852 Updated by: vlad Reported By: [EMAIL PROTECTED] Old Status: Open Status: Assigned Bug Type: dBase related Operating System: FreeBSD 4.0 PHP Version: 4.0.2 Old Assigned To: Assigned To: vlad New Comment: Bug #1 is valid, though I know of applications that add add a null byte there, just like php does. This seems to be relatively harmless, because most of the apps are smart wnough to recognize that change, yet it is not in the specs, so it got fixed. Scream if it breaks anything. Bug #2 is valid, yet as of now there is really no support for .dbt files anyway, so the only difference that would make is during creation of a new dbf file. Fixed. Bug #3 - I'm not sure to which revision of the file kpeters refers to, definitely not line 288 anymore:( I need to look into what he meant. Will do so tomorrow. Assigning to self for now... Previous Comments: [2000-09-24 16:34:42] [EMAIL PROTECTED] Please do not report multiple bugs in one report, also please use the short desc in the future, it is there for a reason, so that people can see immediately what the bug is about. before posting another bug report please read http://bugs.php.net/bugs-dos-and-donts.php. Thanks anyway James [2000-09-22 08:21:31] [EMAIL PROTECTED] //-- Bug 1 //-- dbase.c, line 622 reads: dbh-db_hlen = sizeof(struct dbf_dhead) + 2 + num_fields * sizeof(struct dbf_dfield); Should read: dbh-db_hlen = sizeof(struct dbf_dhead) + 1 + num_fields * sizeof(struct dbf_dfield); Reason: There is only *one* header record terminator byte (0xD) //-- Bug 2 //-- dbase.c, line 683 reads: cur_f-db_flen = 9; Should read: cur_f-db_flen = 10; Reason: Memo refs in Xbase are always of length 10 //-- Bug 3 //-- dbase.c, line 288: Code needs to be inserted below here that truncates the dbf file if deleted records have been encountered, i.e. if rec_cnt new_cnt. For this, pack_dbf would need to return a 'trunc_required' flag. Code could also sit in dbf_rec.c function pack_dbf Edit this bug report at http://bugs.php.net/?id=6852edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] MOPS Benchmark
'lo there, given the recent benchmark discussion on this list and my stumbling over Parrot last night (that comes with MOPS benchmark scripts for a variety of scripting languages), I ran a quick test: Language | Elapsed time | MOPS --+--+- Python| 88 seconds | 2.27 Perl | 102 seconds | 1.96 PHP (+ ZendOptimizer) | 142 seconds | 1.41 PHP | 158 seconds | 1.27 I'm quite surprised that much slower than Python and Perl :-( I used PHP 4.2.0-dev and the current Zend Optimizer, as well as the current versions of ActivePerl and ActivePython on an AMD Duron 800 machine running Windows 2000. Here's the script I benchmarked PHP with: ?php set_time_limit(0); $i2 = 0; # setI2, 0 $i3 = 1; # setI3, 1 $i4 = 1; # setI4, 1 # print Iterations:$i4\n;# print Iterations: # print I4 # print \n # $i1 = 2; # setI1, 2 $i5 = $i4 * $i1; # mulI5, I4, I1 # print Estimated ops: $i5\n;# print Estimated ops: # print I5 # print \n # $n1 = time();# time N1 # while ($i4 != 0) # REDO: $i4 = $i4 - $i3; # subI4, I4, I3 # if I4, REDO # # DONE: $n5 = time();# time N5 # $n2 = $n5 - $n1; # subN2, N5, N1 # print Elapsed time: $n2\n;# print Elapsed time: # print N2 # print \n # $n1 = $i5; # iton N1, I5 $n1 = $n1 / $n2; # divN1, N1, N2 $n2 = 100.0; # setN2, 100.0 $n1 = $n1 / $n2; # divN1, N1, N2 # print M op/s:$n1\n;# print M op/s: # print N1 # print \n # # end ? The scripts used for Perl and Python can be found in the Parrot CVS. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14687 Updated: Ignoring @'s after set_error_handler() is used
ID: 14687
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Scripting Engine problem
Operating System: Redhat 7.0, Solaris 7
PHP Version: 4.0.6
New Comment:
Ah, ok, thanks. - I understand now. It was only the meaning of the @ operator I didn't
follow.
I'd misinterpreted the docs.
I thought that prepending an @ set the errorNum to 0 ( either that or it suppressed
the call to the error handler), when in fact it sets the global error level to 0 for
the @-ed expression.
I thought the @ was: 'Supress errors'
Actually it's: 'Trigger an error as normal, but with the error level temporarily set
to 0'
Thanks,
Matt
Previous Comments:
[2001-12-28 09:09:27] [EMAIL PROTECTED]
It's the programmer's responsibility to honor error_reporting in the error handler.
The error handler will be called even if the error that occured is not inside the
error_reporting mask - to allow you to conduct logging, recovery, etc.
You can easily honor it by using the return value of error_reporting(), and compare it
(using ) with the error level that you got.
[2001-12-24 10:16:05] [EMAIL PROTECTED]
?php
function myErrorHandler($errorNum) {
echo $errorNum\n;
}
set_error_handler(myErrorHandler);
#error_reporting (E_ALL);#doesn't change the bug behaviour
@$j=$i;
?
This echos:
8
Yet according to: http://www.php.net/manual/en/function.set-error-handler.php
Of particular note is that this value will be 0 if the statement that caused the
error was prepended by the @ error-control operator.
I've tried this on 4.0.4pl1 and 4.0.6
The changelog for 4.1.0 doesn't mention a fix.
The @ works fine for lines executed before set_error_handler().
Here's one of the configure lines, though (to me) it doesn't seem likely to be a
compiley issue...
'./configure' '--with-db' '--enable-dba' '--with-gdbm' '--with-xml'
'--with-oci8=/usr/local/oracle/' '--with-apxs=/usr/local/apache-1.3.14/bin/apxs'
'--with-mysql=/usr/local/mysql' '--with-gd' '--with-sablot'
Thanks!
Edit this bug report at http://bugs.php.net/?id=14687edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13887 Updated: session data lost on virtual server
ID: 13887 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Session related Operating System: Linux PHP Version: 4.0.6 New Comment: No feedback. Closing. Previous Comments: [2001-12-10 10:11:05] [EMAIL PROTECTED] The write handler is called upon the end of the request, which takes place regardless of keep-alive support in a web-server. Please supply a more accurate description of what you are seeing. [2001-10-31 10:42:36] [EMAIL PROTECTED] The problem is that PHP is not saving the session file properly befor the server process is terminated. The problem ony occurs when a server process terminates (like if the server's keepalive setting expires, or if the HTTP 1.0 protocol is being used [1.0 doesn't support keepalive]). Because of the way we run our virtual servers, keepalive has no effect (the server processes terminate after each request) so the session bug shows up _every_ time. Edit this bug report at http://bugs.php.net/?id=13887edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] MOPS Benchmark
Sebastian Bergmann wrote: PHP | 158 seconds | 1.27 Now I'm even more surprised: PHP (Zend Engine 2) | 177 seconds | 1.13 -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] MOPS Benchmark
Hello Sebastian, PIII 2x800 Linux 2.4.16-SMP php-4.1.1(cgi) W/O ZendOptimizer Iterations:1 Estimated ops: 2 Elapsed time: 219 M op/s:0.91324200913242 With ZendOptimizer Iterations:1 Estimated ops: 2 Elapsed time: 94 M op/s:2.1276595744681 SB given the recent benchmark discussion on this list and my stumbling SB over Parrot last night (that comes with MOPS benchmark scripts for a SB variety of scripting languages), I ran a quick test: SB Language | Elapsed time | MOPS SB --+--+- SB Python| 88 seconds | 2.27 SB Perl | 102 seconds | 1.96 SB PHP (+ ZendOptimizer) | 142 seconds | 1.41 SB PHP | 158 seconds | 1.27 SB The scripts used for Perl and Python can be found in the Parrot CVS. Can you send me this test-suite ? Best regards, Andrew Sitnikov e-mail : [EMAIL PROTECTED] GSM: (+372) 56491109 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] MOPS Benchmark
Andrew Sitnikov wrote: Can you send me this test-suite ? cvs -d :pserver:[EMAIL PROTECTED]:/home/perlcvs login (Just hit Enter at password prompt) cvs -d :pserver:[EMAIL PROTECTED]:/home/perlcvs co parrot parrot/examples/mops/ is what you're looking for. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] MOPS Benchmark
Sebastian Bergmann wrote: given the recent benchmark discussion on this list and my stumbling over Parrot last night (that comes with MOPS benchmark scripts for a variety of scripting languages), I ran a quick test: Updated table: Language | Elapsed time | MOPS --+--+- Python| 88 seconds | 2.27 Perl | 102 seconds | 1.96 Ruby | 124 seconds | 1.59 PHP (+ ZendOptimizer) | 142 seconds | 1.41 PHP | 158 seconds | 1.27 PHP (Zend Engine 2) | 177 seconds | 1.13 -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #6852 Updated: Misc. bugs
ID: 6852 Updated by: vlad Reported By: [EMAIL PROTECTED] Old Status: Assigned Status: Closed Bug Type: dBase related Operating System: FreeBSD 4.0 PHP Version: 4.0.2 Assigned To: vlad New Comment: ... and bug 3... you were using revision 1.30 for your line numbers :). From looking at it... I am not sure what you are saying here. Do you imply that we have to pack() the file before adding a new record? I do not think so. If you were talking about dbase_pack() not truncating the file, I fixed it in dbf_rec.c ...closed Previous Comments: [2001-12-31 05:34:29] [EMAIL PROTECTED] Bug #1 is valid, though I know of applications that add add a null byte there, just like php does. This seems to be relatively harmless, because most of the apps are smart wnough to recognize that change, yet it is not in the specs, so it got fixed. Scream if it breaks anything. Bug #2 is valid, yet as of now there is really no support for .dbt files anyway, so the only difference that would make is during creation of a new dbf file. Fixed. Bug #3 - I'm not sure to which revision of the file kpeters refers to, definitely not line 288 anymore:( I need to look into what he meant. Will do so tomorrow. Assigning to self for now... [2000-09-24 16:34:42] [EMAIL PROTECTED] Please do not report multiple bugs in one report, also please use the short desc in the future, it is there for a reason, so that people can see immediately what the bug is about. before posting another bug report please read http://bugs.php.net/bugs-dos-and-donts.php. Thanks anyway James [2000-09-22 08:21:31] [EMAIL PROTECTED] //-- Bug 1 //-- dbase.c, line 622 reads: dbh-db_hlen = sizeof(struct dbf_dhead) + 2 + num_fields * sizeof(struct dbf_dfield); Should read: dbh-db_hlen = sizeof(struct dbf_dhead) + 1 + num_fields * sizeof(struct dbf_dfield); Reason: There is only *one* header record terminator byte (0xD) //-- Bug 2 //-- dbase.c, line 683 reads: cur_f-db_flen = 9; Should read: cur_f-db_flen = 10; Reason: Memo refs in Xbase are always of length 10 //-- Bug 3 //-- dbase.c, line 288: Code needs to be inserted below here that truncates the dbf file if deleted records have been encountered, i.e. if rec_cnt new_cnt. For this, pack_dbf would need to return a 'trunc_required' flag. Code could also sit in dbf_rec.c function pack_dbf Edit this bug report at http://bugs.php.net/?id=6852edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] MOPS Benchmark
On Mon, 31 Dec 2001 13:47:08 +0100 Sebastian Bergmann [EMAIL PROTECTED] wrote: Sebastian Bergmann wrote: given the recent benchmark discussion on this list and my stumbling over Parrot last night (that comes with MOPS benchmark scripts for a variety of scripting languages), I ran a quick test: 0.52 with php alone as module and 1.22 with Python 1.5 with my old good PIII-600 :), huh -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14692 Updated: Crash
ID: 14692
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old Status: Suspended
Status: Closed
Bug Type: mcrypt related
Operating System: Linux
PHP Version: 4.1.0
New Comment:
It's fixed in mcrypt now. This will be in the next release of it (2.4.19).
Derick
Previous Comments:
[2001-12-26 04:46:58] [EMAIL PROTECTED]
From: Nikos Mavroyanopoulos [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [mcrypt-dev] Crash
On Tue, 25 Dec 2001 18:57:29 +0100 (CET)
Derick Rethans [EMAIL PROTECTED] wrote:
Hello,
I get a crash with the 2nd program (and I know gost is not a
algorithm_mode, but it shouldn't crash IMO).
Yes, it shouldn't crash. I'll check it (after the vacations!).
Thank you.
[2001-12-25 11:41:06] [EMAIL PROTECTED]
This is not a PHP bug, but in libmcrypt. I reported this to the author of the library.
This is the C code I used for it:
#include unistd.h
#include mcrypt.h
void main (void)
{
int res;
res = mcrypt_module_is_block_algorithm (gost, NULL);
}
This one works, the next does not (segfaults):
#include unistd.h
#include mcrypt.h
void main (void)
{
int res;
res = mcrypt_module_is_block_algorithm_mode (gost, NULL);
}
regards,
Derick
[2001-12-25 11:18:30] [EMAIL PROTECTED]
i use php-4.1.1
[2001-12-25 11:18:16] [EMAIL PROTECTED]
I know what it is buggy script, but it not the justification for Segmentation.
Your script work for me and print false
[2001-12-25 11:09:03] [EMAIL PROTECTED]
Hello,
your script is buggy, GOST, is not a mode, but an algorithm.
It indeed crashes with this code, but to me it seems like it is an libmcrypt problem.
If you use this:
?
if (mcrypt_module_is_block_algorithm(MCRYPT_GOST))
echo true\n;
else
echo false\n;
?
it works, but it returns true if it is NOT a block algorithm, which is a bug in the
extension.
(mcrypt returns 1 if it is a block algorithm).
Can you confirm that it does not crash with the script I pasted?
Derick
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/?id=14692
Edit this bug report at http://bugs.php.net/?id=14692edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Forwarding: I found a FIX for a but and don't know who to contact.
Forwarded message (original was to [EMAIL PROTECTED]): --- Excuse me if I am writing to you, but this also concerns you: How may I contact PHP developers so to send them a bugfix? The php site doesn't say that, or I had not been able to find out. BTW, the bug is a very dangerous one: with ibase-php, all the numeric scaled fields (i.e. with decimals) are translated into php numbers without leading zeroes after the decimal dot. I.e.: PI= 3.1428... is correctly translated, but MY SALE = 19.09$ is translated into 19.6$ ! ARRG, this puts at risk all the e-commerce translations with PHP and Interbase... I posted a bugfix as bug report 14755. Please, tell me who could put this 10 lines bugfix in the code interbase.c code... All you can do is to post that bugreport. This is the usual flow of a bugfix going to be accepted. You may also write to [EMAIL PROTECTED] directly of you would like to get things going faster. This is holiday time now, so please count on this thing! Goba [one [EMAIL PROTECTED]] - END OF FORWARDED MESSAGE And so I did... Thanks to everyone for your help. Giancarlo -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14768 Updated: Upgrade to 4.1.0 breaks database connection
Hi Markus ;) Is there a problem with mysql_pconnect() in 4.1.0? Sorry for asking, but I can now only access my email from time to time and there's lots to read here. ID: 14768 Updated by: mfischer Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: MySQL related Operating System: Windows XP PHP Version: 4.1.0 New Comment: Are you using mysql_pconnect() Previous Comments: [2001-12-30 07:03:37] [EMAIL PROTECTED] Just to clarify - I'm using the standard Win32 binaries as downloadable from the php.net site. [2001-12-30 07:00:22] [EMAIL PROTECTED] Today I upgraded PHP on my WinXP system from 4.0.6 to 4.1.0 as I was finding 4.0.6 slow and thought 4.1.0 may help. After the upgrade, all MySQL connectivity was broken - none of my scripts installed could connect. MySQL was running fine (and winmysqladmin from the mysql\bin directory was able to connect fine). Restarting MySQL and IIS did not help. I was able to downgrade back to 4.0.6 (from the backup directory created during install), which immediately fixed the problem. Edit this bug report at http://bugs.php.net/?id=14768edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re[2]: [PHP-DEV] MOPS Benchmark
Hello Sebastian, Language | Elapsed time (sec)| MOPS --+---+- Python| 96.5 | 2.07 Perl | 94 | 2.13 PHP (+ ZendOptimizer) | 94 | 2.13 PHP | 220 | 0.90 C | 0.66 | 304 Hardware: PIII 2x800 Software: OS - Linux 2.4.16-SMP PHP - 4.1.1 Zend Optimaizer 1.2.0 Python 1.5.2 Perl 5.005_03 Best regards, Andrew Sitnikov e-mail : [EMAIL PROTECTED] GSM: (+372) 56491109 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14768 Updated: Upgrade to 4.1.0 breaks database connection
On Sun, Dec 30, 2001 at 11:00:47PM +0100, Krzysztof Jarecki wrote : Hi Markus ;) Is there a problem with mysql_pconnect() in 4.1.0? Sorry for asking, but I can now only access my email from time to time and there's lots to read here. Yes, it is. And its fixed in 4.1.1 -- Please always Cc to me when replying to me on the lists. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14747 Updated: Return exitcodes to shell ($?)
ID: 14747 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Suspended Status: Closed Bug Type: Feature/Change Request Operating System: Windows 2000 with mks-tools PHP Version: 4.0.6 New Comment: My mistake. Previous Comments: [2001-12-29 16:22:35] [EMAIL PROTECTED] Sorry, I just tried your suggestion under Linux and it works. But under Windows2000 with the mks-Toolkit and there it dosn't work. Thnx Bernd [2001-12-29 15:27:22] [EMAIL PROTECTED] just use exit(number) it returns the exit code (and also prints the value). The printing will be removed in PHP5 (if it is a number). Derick [2001-12-28 16:39:37] [EMAIL PROTECTED] Hi, I tried to use PHP in connection with shellprogramming. I would be fine if you could return exit codes to shellscripts. So that you can use something like if [ $? -eq 0 ] to test if the PHP-Script had run succesful. So wouldn`t need to use Perl in future. Edit this bug report at http://bugs.php.net/?id=14747edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14555 Updated: apache fails: libsablot.so.0: undefined symbol: XML_SetParamEntityParsing
ID: 14555 Updated by: sterling Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: XSLT related Operating System: debian woody PHP Version: 4.1.0 New Comment: Not a PHP bug. Previous Comments: [2001-12-17 22:33:47] [EMAIL PROTECTED] balder:~# nm /usr/local/lib/libsablot.so.0 | grep XML_SetParamEntityParsing U XML_SetParamEntityParsing Unlinked I guess, I don't really know what it means in this context, maybe something I should investigate with gingerall/sablot lists. [2001-12-17 17:57:19] [EMAIL PROTECTED] Please post the output of this: nm /usr/local/lib/libsablot.so.0 | grep XML_SetParamEntityParsing [2001-12-17 17:54:08] [EMAIL PROTECTED] That gives one line with XML_SetParamEntityParsing, so I assume it is in there. There was no probs compiling and installing Sablot, I have NOT found any similar issue on the gingerall pages or any other mailing lists/newsgroups I've searched. [2001-12-17 02:44:23] [EMAIL PROTECTED] What does the output of strings /usr/local/lib/libsablot.so.0|grep XML_SetParamEntityParsing gives you? If you're missing the symbol your libsablot installation is broken. Feedback. [2001-12-16 22:02:05] [EMAIL PROTECTED] Config, compile and install works fine, apache fails to start: Apache: Starting Syntax error on line 226 of /usr/local/conf/httpd.conf: Cannot load /usr/local/libexec/libphp4.so into server: /usr/local/lib/libsablot.so.0: undefined symbol: XML_SetParamEntityParsing /usr/local/bin/apachectl start: httpd could not be started ./configure \ --with-apxs \ --with-mysql \ --with-zlib \ --with-bz2 \ --with-curl \ --with-dom \ --enable-ftp \ --with-gd\ --enable-gd-native-ttf \ --with-gmp \ --enable-sockets \ --with-openssl \ --with-ldap \ --enable-xslt\ --with-xslt-sablot \ --with-iconv apache 1.3.22 sablot 0.71 expat 1.95.2 libxml 2.4.10 xmltok 1.1 Apache and PHP was compiled and installed manually, the rest has been done with .deb packages/apt. Additional: In order to successfully compile, configure didnt stop, had to install dev-files for xmltok, libxml and sasl (used deb's) Edit this bug report at http://bugs.php.net/?id=14555edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14709 Updated: segmentation fault
ID: 14709
Updated by: sterling
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: XSLT related
Operating System: Linux 2.4.3-12 (Apache/1.3.20)
PHP Version: 4.1.0
New Comment:
You probably compiled apache with the builtin expat lite, please re-install apache
using the same expat that sablotron uses.
Previous Comments:
[2001-12-27 01:06:46] [EMAIL PROTECTED]
[Note: PHP version is 4.1.1 -- the drop-down box has 4.1.0 as latest version]
Script:
?
$processor = xslt_create();
$args = array();
$args[ '/xml' ] = '?xml version=1.0?root /';
$args[ '/xsl' ] = '?xml version=1.0?root /';
for( $i = 0; $i 1000; ++$i )
{
if( !$result = xslt_process( $processor, 'arg:/xml', 'arg:/xsl', NULL, $args )
)
{
echo 'failed';
}
}
xslt_free( $processor );
echo 'done';
?
Config line:
'./configure' '--with-config-file-path=/etc' '--with-pgsql'
'--with-apxs=/usr/apache/bin/apxs' '--with-xml' '--enable-xslt' '--with-xslt-sablot'
'--with-mysql=no' '--with-gd' '--enable-debug'
Description:
When I visit this script, and hit refresh (several times) Apache terminates with a
segmentation fault. The bug appears to be random because there are times when the
script finishes without a crash.
Backtrace:
#0 __libc_free (mem=0x2) at malloc.c:3036
#1 0x0809ab8e in hashTableDestroy () at eval.c:41
#2 0x08099b4d in dtdDestroy () at eval.c:41
#3 0x0809425d in XML_ParserFree () at eval.c:41
#4 0x40370e4a in TreeConstructer::parseDataLineUsingExpat (this=0xbfffdd90,
S=@0x811cff8, t=0x8130520,
d=0x81304c0) at parser.cpp:126
#5 0x40383034 in Tree::parse (this=0x8130520, S=@0x811cff8, d=0x81304c0) at
tree.cpp:600
#6 0x40375951 in Processor::addLineParse (this=0x811d0a8, S=@0x811cff8,
newTree=@0x811d0a8,
absolute=@0xbfffde40, isXSL=0) at guard.h:157
#7 0x4037602e in Processor::readTreeFromURI (this=0x811d0a8, S=@0x811cff8,
newTree=@0x811d0a8,
location=@0xbfffdf10, base=@0xbfffdef0, isXSL=0) at proc.cpp:602
#8 0x40373d91 in Processor::open (this=0x811d0a8, S=@0x811cff8, sheetURI=0x811dadc
arg:/xsl,
inputURI=0x811dc14 arg:/xml) at proc.cpp:277
#9 0x40379633 in SablotRunProcessor (processor_=0x811d0a8, sheetURI=0x811dadc
arg:/xsl,
inputURI=0x811dc14 arg:/xml, resultURI=0x402d9683 arg:/_result, params=0x0,
arguments=0x811dc54)
at sablot.cpp:407
#10 0x402af84a in zif_xslt_process (ht=5, return_value=0x811db5c, this_ptr=0x0,
return_value_used=1)
at sablot.c:514
#11 0x401dcca1 in execute (op_array=0x81123a4) at ./zend_execute.c:1590
#12 0x401ed66c in zend_execute_scripts (type=8, retval=0x0, file_count=3) at
zend.c:814
#13 0x401ff82a in php_execute_script (primary_file=0xb6e0) at main.c:1307
#14 0x401fa65a in apache_php_module_main (r=0x810a034, display_source_mode=0) at
sapi_apache.c:90
#15 0x401fb4c8 in send_php (r=0x810a034, display_source_mode=0,
filename=0x810f5e4 /home/apache/html/geeba/crash.php) at mod_php4.c:575
#16 0x401fb535 in send_parsed_php (r=0x810a034) at mod_php4.c:590
#17 0x0806a7ff in ap_invoke_handler () at eval.c:41
#18 0x0807e5eb in process_request_internal () at eval.c:41
#19 0x0807e64c in ap_process_request () at eval.c:41
#20 0x08075a9d in child_main () at eval.c:41
#21 0x08075c48 in make_child () at eval.c:41
#22 0x08075dbc in startup_children () at eval.c:41
#23 0x0807640f in standalone_main () at eval.c:41
#24 0x08076c37 in main () at eval.c:41
#25 0x4008f177 in __libc_start_main (main=0x8076898 main, argc=2, ubp_av=0xbb14,
init=0x804ed14 _init, fini=0x80abac0 _fini, rtld_fini=0x4000e184 _dl_fini,
stack_end=0xbb0c)
at ../sysdeps/generic/libc-start.c:129
Hope this helps. Thank you very much,
Valeriy
Edit this bug report at http://bugs.php.net/?id=14709edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14142 Updated: curl_exec called twice crash
ID: 14142
Updated by: sterling
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: cURL related
Operating System: FreeBSD 4.1
PHP Version: 4.1.0RC2
New Comment:
fixed in 4.1.*
Previous Comments:
[2001-11-20 06:47:29] [EMAIL PROTECTED]
Forgot the compile options :
'./configure' '--with-gd=/usr/home/domi4/src/gd-1.8.4' '--enable-exif'
'--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--enable-gd-native-ttf'
'--with-mysql=/usr/local' '--disable-pear'
'--with-config-file-path=/usr/home/domi4/etc' '--enable-debug=no'
'--enable-force-cgi-redirect=yes' '--with-zlib' '--with-openssl=/usr/local/ssl'
'--with-curl=/usr/home/domi4/src/curl-7.9' '--with-dom=/usr/home/domi4/'
[2001-11-20 06:43:36] [EMAIL PROTECTED]
When calling curl_exec twice with RETURNTRANSFER option there's a (reproductible) core
dump. Here's a test case :
$ch=curl_init();
curl_setopt($ch,CURLOPT_RETURNTRANSFER,1);
curl_setopt($ch,CURLOPT_URL,'http://www.yahoo.com');
curl_exec($ch);
echo('this text is displayed');
curl_exec($ch);
echo('this text is not displayed (core dump instead)');
The problem shows up in 4.1.0RC1 AND 4.1.0RC2 (but not 4.0.6). If you remove the
RETURNTRANSFER option then it works fine. I'm affraid I don't have the knowledge to
compile a debug version and give more infos.
Edit this bug report at http://bugs.php.net/?id=14142edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14371 Updated: RETURN_TRANSFER dies if site doesn't ping
ID: 14371
Updated by: sterling
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: cURL related
Operating System: Linux 2.2.12-20
PHP Version: 4.0.6
New Comment:
Fixed in cvs and 4.1.*
Previous Comments:
[2001-12-06 22:24:27] [EMAIL PROTECTED]
Using --with-curl and libcurl 7.8 (SSL 0.9.5):
If you use the following function with a url that pings, but does not answer, it will
die. I have a script set up to continue for timeouts, but it does not continue, it
dies. If you change CURLOPT_RETURNTRANSFER to 0, it will not die, but also does not
return the data in a variable as I need it to.
I would give you a url to try, but chances are that it will be back up by the time you
get to this. This works *fine* for sites not found, pages not found, dns errors,
timeouts, etc. It is only a problem if the computer is in the DNS records but does
not respond (to ping).
function get_data($url, $timeout=15) {
$timeout = (int)$timeout;
$ch = curl_init ();
curl_setopt ($ch, CURLOPT_URL, $url);
curl_setopt ($ch, CURLOPT_MUTE, 0);
curl_setopt ($ch, CURLOPT_TIMEOUT, $timeout);
curl_setopt ($ch, CURLOPT_NOBODY, 0);
curl_setopt ($ch, CURLOPT_HEADER, 0);
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1);
$page = curl_exec ($ch);
#print curl_error($ch);
#print br;
#print page: $page;
#$i = curl_getinfo($ch);
#print_r($i);
curl_close ($ch);
return trim($page);
}
'./configure' '--with-apxs=/usr/sbin/apxs' '--prefix=/usr'
'-with-config-file-path=/etc/httpd' '-enable-safe-mode' '--with-exec-dir=/usr/bin'
'--with-system-regex' '--disable-debug' '--with-zlib' '-enable-debugger'
'--enable-track-vars' '--enable-ftp' '--enable-wddx' '--with-gdbm' '--with-mysql=/usr'
'--with-pgsql' '--with-xml' '--with-curl=/usr/local'
Edit this bug report at http://bugs.php.net/?id=14371edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14517 Updated: SSL: couldn't create a context!
ID: 14517 Updated by: sterling Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: cURL related Operating System: Slackware 7.1 PHP Version: 4.1.0 New Comment: It has, compile PHP without the --with-openssl configure line. Previous Comments: [2001-12-14 10:35:35] [EMAIL PROTECTED] curl_error($ch); outputs this error SSL: couldn't create a context! This error was originally reported in PHP-4.0.6 although I don't think it has been looked into yet. =o) Unfortunately I will be unable to upgrade my version of PHP past 4.0.5 where this was not an issue. Edit this bug report at http://bugs.php.net/?id=14517edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14683 Updated: RETURNTRANSFER causes core dump
ID: 14683 Updated by: sterling Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: cURL related Operating System: Linux Mandrake 8.0 PHP Version: 4.1.0 New Comment: Fixed in CVS. Previous Comments: [2001-12-24 05:01:47] [EMAIL PROTECTED] If i have RETURNTRANSFER enabled, and am trying to get a page which returns absolutely nothing (due to early exit() ), i get a core dump that i can reproduce... some valuable information: it is a CGI version of php compiled with wddx , BCMath, track vars, discard path, ftp, and mysql .. compiled against libcurl 7.9.2 here's a backtrace: #0 0x0806a5b1 in zif_curl_exec (ht=1, return_value=0x8189064, this_ptr=0x0, return_value_used=1) at curl.c:906 #1 0x4033670b in zend_assign_to_variable_reference () from /panel/app/optimizer/ZendOptimizer.so #2 0x40340325 in zend_oe () from /panel/app/optimizer/ZendOptimizer.so #3 0x080e3953 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:814 #4 0x0805f485 in php_execute_script (primary_file=0xb7d0) at main.c:1309 #5 0x0805d66c in main (argc=2, argv=0xb874) at cgi_main.c:738 #6 0x401f70de in __libc_start_main () from /lib/libc.so.6 Edit this bug report at http://bugs.php.net/?id=14683edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: MOPS Benchmark
Mmmm, since this is -dev I'm just going to #include usual extensive benchmark disclaimers case in point, the php and perl version are not written same way aka same logic and data structures. Rewriting the perl version with a while contruct actually speeds it up (and re-inforces the fact that these are sensitive to small things among other issues). My results are very close to Andrew Sitnikov's. 2x1Ghz 2.4.7-10smp Iterations:1 Estimated ops: 2 perl 5.6.0 w/ while Elapsed time: 53 M op/s:3.77 perl 5.6.0 default Elapsed time: 69 M op/s:2.89 php 4.1.0 (and 4.0.6) Elapsed time: 215 M op/s:0.93 python 1.5.2 Elapsed time: 92 M op/s:2.15 python -OO 1.5.2 Elapsed time: 81 M op/s:2.45 Would be interesting to profile these and see where the time goes. - August -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: MOPS Benchmark
August Zajonc wrote: My results are very close to Andrew Sitnikov's. Guys, please don't flood the list with benchmarks. The differences in speed between the tested languages are obvious from my table, minuscle differences on other hardware is obsolete, IMHO. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14507 Updated: sessions and mm produce an error on starting apache
ID: 14507 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Duplicate Status: Open Bug Type: Session related Operating System: Sparc/Solaris 8 Old PHP Version: 4.1.0 PHP Version: 4.1.1 New Comment: The Problem still exists in PHP Version 4.1.1 any hints/solutions? Previous Comments: [2001-12-19 23:02:03] [EMAIL PROTECTED] I created new report for this bug which explains why this happens. Duplicate #14612 -- Yasuo Ohgaki [2001-12-14 07:38:29] [EMAIL PROTECTED] I did a make distclean and a rebuild with the following options: ./configure\ --with-mysql=/usr/local/mysql\ --with-db3 \ --enable-sysvsem\ --enable-sysvshm\ --with-mm=/usr/local\ --with-openssl \ --enable-track-vars\ --enable-trans-sid\ --enable-shmop\ --with-gd \ --with-jpeg-dir=/usr/local/lib \ --with-png-dir=/usr/local/lib \ --enable-inline-optimization \ --enable-bcmath \ --with-gettext \ --with-mcrypt \ --with-zlib \ --disable-debug \ --with-apxs=/usr/local/apache/bin/apxs All this didn't solve the problem, I'm still getting: PHP Fatal error: Cannot find save handler mm in Unknown on line 0 [2001-12-14 06:05:43] [EMAIL PROTECTED] Please try a `make clean´ and reinstall PHP. I'd appreciate it, if you could let us know whether that fixes your problem. Thanks [2001-12-14 05:27:47] [EMAIL PROTECTED] More notes from user: File /tmp/session_mm.sem has root:other 600 owner/perms; delting it will re-create it upon startup, error still there. [2001-12-14 04:47:57] [EMAIL PROTECTED] Duplicate of #14496 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/?id=14507 Edit this bug report at http://bugs.php.net/?id=14507edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: MOPS Benchmark
Reproducability matters to some degree. Also, there are some pretty large differences between your table and others. you show php running 1.5x slower than perl. Andew and mine show straight php running 4x slower. Given benchmarks rather wide variances I think a couple of extra data points are useful. If it turned out your and others performance under windows was consistently higher than those on beefier machines under linux that would be extremely interesting. Or is the AMD processor in this case? That would again be interesting. It'd certainly like the secret of your performance. - AZ - Original Message - From: Sebastian Bergmann [EMAIL PROTECTED] Newsgroups: php.dev To: [EMAIL PROTECTED] Sent: Monday, December 31, 2001 11:04 AM Subject: Re: [PHP-DEV] Re: MOPS Benchmark August Zajonc wrote: My results are very close to Andrew Sitnikov's. Guys, please don't flood the list with benchmarks. The differences in speed between the tested languages are obvious from my table, minuscle differences on other hardware is obsolete, IMHO. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: MOPS Benchmark
August Zajonc wrote: Reproducability matters to some degree. Also, there are some pretty large differences between your table and others. Sorry, you're right. I just wanted to prevent a flood of results on this list. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14781: ftp_login failure after mysql_connect
From: [EMAIL PROTECTED] Operating system: Linux Redhat 6.2/7.2 PHP version: 4.1.1 PHP Bug Type: Unknown/Other Function Bug description: ftp_login failure after mysql_connect I wanted to connect to a ftp server, get some files and insert them into a database. I started connecting to the ftp server, then logging in and that worked fine. Then I added a mysql_connect and now I get an error on ftp_login that says that it can not find ftpbuf. (tried on two systems: Linux Redhat 6.2, Linux Redhat 7.2). I'm not sure if this is a failure of ftp functions, mysql, a documentation problem or me being too stupid. After dropping all unneccessary code, the file looks like that: ?php $hHandle=mysql_connect(localhost, nobody, ) or die (no connection.\n); mysql_close ($hHandle); #this can be dropped $hFtp = ftp_connect (localhost) #this works || die (Could not connect.\n); # next line results in an error: $iLoginResult=ftp_login($hFtp, nobody, ) || die (Error: Unable to login\n); ? I got the following error message: Warning: Unable to find ftpbuf 1 in scipt on line XX, (which is the ftp_login line (ftp_connect works!)). If you drop mysql_connect, its working fine... I'm using build in mysql support (for version 3.23.39), ftp is of course enabled too. Hopefully this is a stupid question and there is an easy answer... Thanks in advance and a happy new year, flim -- Edit bug report at: http://bugs.php.net/?id=14781edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Using PHP in my own apps
Hi, I was wondering how i could use PHP to interpret scripts for my own apps using php4ts.dll ? the best way to start is not the PHP sources. have a look at apaches DSO support (or the windows counterpart - the DLL files. there should be some notes on them in the same documentation): http://httpd.apache.org/docs/dso.html if you succeed to implement this interface, you will be able to include future PHP releases without touching the PHP sources. Kind Regards, Daniel Lorch -- if(empty($a) == true ? true : false) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] IMPORTANT
Hah! Got you all :) Anyway: Hello everybody, I want to take this opportunity to wish you all a Happy New Year. Together with these wishes, I also wish you all happy and constructive discussions on these lists, where all different opinions are carefully considered and may lead to a renewed spirit, which will make PHP 5 happen. Happy New Year! Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Moving extensions to PECL
I think the following standard extensions should be moved to PECL: ext/cybercash ext/icap ext/pfpro ext/yaz This is definitely not an inclusive list; it's just a start. I can't imagine a lot of people using these modules, so they seem like good candidates for removal from the base PHP distribution. Are there any well-founded objections to this (either in practice or principle)? -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Happy New Year
Hello everybody, I want to take this opportunity to wish you all a Happy New Year. Together with these wishes, I also wish you all happy and constructive discussions on these lists, where all different opinions are carefully considered and may lead to a renewed spirit, which will make PHP 5 happen. Happy New Year! Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Moving extensions to PECL
On 2001-31-12 11:38, Jon Parise wrote: I think the following standard extensions should be moved to PECL: ext/cybercash ext/icap ext/pfpro ext/yaz This is definitely not an inclusive list; it's just a start. I can't imagine a lot of people using these modules, so they seem like good candidates for removal from the base PHP distribution. Are there any well-founded objections to this (either in practice or principle)? We should probably add cybermut to the list as well. -- Zak Greant PHP Quality Assurance Team http://qa.php.net/ We must be the change we wish to see. - M. K. Ghandi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Moving extensions to PECL
On Mon, Dec 31, 2001 at 11:49:02AM -0700, Zak Greant wrote: I think the following standard extensions should be moved to PECL: ext/cybercash ext/icap ext/pfpro ext/yaz This is definitely not an inclusive list; it's just a start. I can't imagine a lot of people using these modules, so they seem like good candidates for removal from the base PHP distribution. Are there any well-founded objections to this (either in practice or principle)? We should probably add cybermut to the list as well. Sure, that sounds fine. I suppose removing some of these less frequently used extensions will also help make the QA team's job a little easier, too. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14365 Updated: require_once() causes segfault
ID: 14365
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Operating System: RedHat Linux 7.2
Old PHP Version: 4.0.6
PHP Version: 4.1.1
New Comment:
Still segfaults with 4.1.1:
#0 0x4024b14c in php_fopen_with_path (
filename=0x833e124 ../src/load_prefs.php, mode=0x402f2d94 rb,
path=0x402f40ba .:/usr/local/lib/php, opened_path=0x403c37d8,
tsrm_ls=0x83877a8) at fopen_wrappers.c:374
pathbuf = 0x0
ptr = 0x833e124 ../src/load_prefs.php
end = 0x0
exec_fname = 0x0
trypath = '\000' repeats 124 times,
¾ë\023@´V\031@Dð;@\224\000@|ë\n@\003\000\000\000ìï;@\034\000@\000\000\000\000/usr/local/aolserver-3.4.2/servers/webmail/pages/squirrelmail-1.2.0-rc3/plugins/filters/filters.php,
'\000' repeats 745 times,
¾ë\023@´V\031@´ó;@\004\004@|ë\n@\003\000\000\000\\ó;@\214\003@\000\000\000\000/usr/loca...
trydir = '\000' repeats 4094 times
safe_mode_include_dir = '\000' repeats 4094 times
sb = {st_dev = 0, __pad1 = 0, st_ino = 0, st_mode = 0, st_nlink = 0,
st_uid = 0, st_gid = 0, st_rdev = 0, __pad2 = 0, st_size = 0,
st_blksize = 0, st_blocks = 0, st_atime = 0, __unused1 = 0, st_mtime = 0,
__unused2 = 0, st_ctime = 0, __unused3 = 0, __unused4 = 0, __unused5 = 0}
fp = (FILE *) 0x833e124
path_length = 0
safe_mode_include_dir_length = 0
exec_fname_length = 0
#1 0x4024b6f7 in php_fopen_url_wrapper (
path=0x833e124 ../src/load_prefs.php, mode=0x402f2d94 rb, options=1,
issock=0x403bffd0, socketd=0x403bffd4, opened_path=0x403c37d8,
tsrm_ls=0x83877a8) at fopen_wrappers.c:556
path = 0x833e124 ../src/load_prefs.php
fp = (FILE *) 0x9
p = 0x83877a8 \230\016!\b\025
protocol = 0x0
n = 0
#2 0x40247fce in php_fopen_wrapper_for_zend (
filename=0x833e124 ../src/load_prefs.php, opened_path=0x403c37d8)
at main.c:524
issock = 0
socketd = 0
old_chunk_size = 8192
retval = (FILE *) 0x83877a8
tsrm_ls = (void ***) 0x83877a8
#3 0x4022e55d in execute (op_array=0x8519370, tsrm_ls=0x83877a8)
at ./zend_execute.c:2082
opened_path = 0x0
dummy = 1
file_handle = {type = 0 '\000', filename = 0x8386f0c c?\006\r,
opened_path = 0x0, handle = {fd = 1076172697, fp = 0x40251799},
free_filename = 232 'è'}
new_op_array = (zend_op_array *) 0x0
original_return_value = (zval **) 0x403c40ec
return_value_used = 0
inc_filename = (zval *) 0x850a258
tmp_inc_filename = {value = {lval = 1073933696,
dval = 6.308106422594733, str = {
val = 0x4002ed80 U\211åS\203ì\004èäúÿÿ\201ÃLÊ, len = 1075395456},
ht = 0x4002ed80, obj = {ce = 0x4002ed80, properties = 0x40193b80}},
type = 164 '¤', is_ref = 55 '7', refcount = 16444}
failure_retval = 0 '\000'
opline = (zend_op *) 0x850a240
function_state = {function_symbol_table = 0x8211930,
function = 0x8519370, reserved = {0x403c3844, 0x0, 0x403c4094, 0x8265818}}
fbc = (zend_function *) 0x0
object = {ptr = 0x0}
Ts = (temp_variable (*)[0]) 0x403bfffc
original_in_execution = 1 '\001'
#4 0x4022be6b in execute (op_array=0x83cb080, tsrm_ls=0x83877a8)
at ./zend_execute.c:1630
calling_symbol_table = (HashTable *) 0x828dbc4
original_return_value = (zval **) 0x403c59ec
return_value_used = 1
opline = (zend_op *) 0x863ebb0
function_state = {function_symbol_table = 0x828dc34,
function = 0x8519370, reserved = {0x38, 0x3, 0x4030e85c, 0x8263000}}
fbc = (zend_function *) 0x0
object = {ptr = 0x0}
Ts = (temp_variable (*)[0]) 0x403c387c
original_in_execution = 1 '\001'
#5 0x4022be6b in execute (op_array=0x85d9e80, tsrm_ls=0x83877a8)
at ./zend_execute.c:1630
calling_symbol_table = (HashTable *) 0x83b2afc
original_return_value = (zval **) 0x403ca2e8
return_value_used = 0
opline = (zend_op *) 0x85cc7f4
function_state = {function_symbol_table = 0x828dbc4,
function = 0x83cb080, reserved = {0x403c6be4, 0x3, 0x84842dc, 0x82629b0}}
fbc = (zend_function *) 0x83cb080
object = {ptr = 0x0}
Ts = (temp_variable (*)[0]) 0x403c4f4c
original_in_execution = 1 '\001'
#6 0x4022be6b in execute (op_array=0x85c7fa8, tsrm_ls=0x83877a8)
at ./zend_execute.c:1630
calling_symbol_table = (HashTable *) 0x839747c
original_return_value = (zval **) 0x403cb240
return_value_used = 0
opline = (zend_op *) 0x85c1610
function_state = {function_symbol_table = 0x83b2afc,
function = 0x85d9e80, reserved = {0x403ca494, 0x3, 0x4030e85c, 0x8263250}}
fbc = (zend_function *) 0x85d9e80
object = {ptr = 0x0}
Ts = (temp_variable (*)[0]) 0x403c6bfc
Re: [PHP-DEV] Using PHP in my own apps
On Mon, Dec 31, 2001 at 07:14:32PM +0100, Daniel Lorch wrote: Hi, I was wondering how i could use PHP to interpret scripts for my own apps using php4ts.dll ? the best way to start is not the PHP sources. have a look at apaches DSO support (or the windows counterpart - the DLL files. there should be some notes on them in the same documentation): http://httpd.apache.org/docs/dso.html if you succeed to implement this interface, you will be able to include future PHP releases without touching the PHP sources. Yes, but you could also interface with PHP's SAPI. PHP is interfaced with say Apache using the code in sapi/apache. It might be better to interface at this level. BTW, BIND 9 has a simple database interface that I've used to write an LDAP backend. I've toyed with the sick idea of having a PHP back- end for BIND. Then you would run a PHP script on every DNS loookup. Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Moving extensions to PECL
On Mon, 31 Dec 2001, Jon Parise wrote: On Mon, Dec 31, 2001 at 11:49:02AM -0700, Zak Greant wrote: I think the following standard extensions should be moved to PECL: ext/cybercash ext/icap ext/pfpro ext/yaz This is definitely not an inclusive list; it's just a start. I can't imagine a lot of people using these modules, so they seem like good candidates for removal from the base PHP distribution. Are there any well-founded objections to this (either in practice or principle)? We should probably add cybermut to the list as well. What about the 'fribidi' extension then ? ;) I would think the following extensions should also go to PECL: filepro aspell crack ctype cyrus dio dotnet mailparse midgard muscat notes qtdom readline recode satellite vpopmail Joao p.s.: let the flame wars begin! ;) -- João Prado Maia [EMAIL PROTECTED] http://phpbrasil.com - php com um jeitinho brasileiro -- Precisando de consultoria em desenvolvimento para a Internet ? Impleo.net - http://impleo.net/?lang=br -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Moving extensions to PECL
On Mon, Dec 31, 2001 at 01:58:42PM -0500, Joao Prado Maia wrote: This is definitely not an inclusive list; it's just a start. I can't imagine a lot of people using these modules, so they seem like good candidates for removal from the base PHP distribution. What about the 'fribidi' extension then ? ;) Okay, before this gets out of hand: I do _not_ want to create a list of extensions to pull from the base distribution. My intensions are simply to try moving a few standard extensions out of the base PHP distribution and into PECL to help test the PECL build infrastructure and to standardize the procedure for moving extensions out of the base distribution. I probably should have made that clearer before. I don't want this to turn into a this extension is too big and is seldom used kind of thread. We've had enough of those in the past. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Moving extensions to PECL
On Mon, 31 Dec 2001, Jon Parise wrote: Okay, before this gets out of hand: I do _not_ want to create a list of extensions to pull from the base distribution. My intensions are simply to try moving a few standard extensions out of the base PHP distribution and into PECL to help test the PECL build infrastructure and to standardize the procedure for moving extensions out of the base distribution. I probably should have made that clearer before. I don't want this to turn into a this extension is too big and is seldom used kind of thread. We've had enough of those in the past. +10 on this :) Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Moving extensions to PECL
Jon Parise [EMAIL PROTECTED] wrote: Are there any well-founded objections to this (either in practice or principle)? no objections, but one thing that should be considered is what happens to the documentation for these extensions when they are no longer a part of the core distribution. (and i won't claim to have any answers to that.) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Moving extensions to PECL
Jim Winstead wrote: no objections, but one thing that should be considered is what happens to the documentation for these extensions when they are no longer a part of the core distribution. QA too. I suppose removing some of these less frequently used extensions will also help make the QA team's job a little easier, too. sounds dangerous to me. regards Wagner -- When did ignorance become a point of view? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Moving extensions to PECL
Jim Winstead wrote: no objections, but one thing that should be considered is what happens to the documentation for these extensions when they are no longer a part of the core distribution. QA too. I suppose removing some of these less frequently used extensions will also help make the QA team's job a little easier, too. sounds dangerous to me. The QA Teams job needs to be made as easy as possible, at the moment those people still working activly on QA a lot have a very hard time balancing time between testing for new bugs, localising and fixing bugs as well as making sure releases are up to scratch and new bugs arnt introduced. Anything to make their job easier is a big plus. - James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Moving extensions to PECL
On Mon, Dec 31, 2001 at 08:12:25PM -, James Moore wrote: The QA Teams job needs to be made as easy as possible, at the moment those people still working activly on QA a lot have a very hard time balancing time between testing for new bugs, localising and fixing bugs as well as making sure releases are up to scratch and new bugs arnt introduced. Anything to make their job easier is a big plus. right. i think that moving extensions out of the core will make things easier on both ends -- new releases of the core can go out without having to wait on lesser-used extensions to be tested (or go out with buggy lesser-used extensions), and new releases of those extensions can be made on their own schedule. someone fixed a major bug in pear/PECL/cybermut? run the regression tests and do a release. no more waiting three months for a release of the core to be put together. look at the current situation with the mnogosearch extension -- 4.1.0 and 4.1.1 don't support the latest mnogosearch api. it will probably be at least three months before a distribution of php that does is released. if mnogosearch were a part of PECL, a new version could be released and usable with the existing core distribution whenever its developers thought it was ready. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Moving extensions to PECL
look at the current situation with the mnogosearch extension -- 4.1.0 and 4.1.1 don't support the latest mnogosearch api. it will probably be at least three months before a distribution of php that does is released. if mnogosearch were a part of PECL, a new version could be released and usable with the existing core distribution whenever its developers thought it was ready. I completly agree. Without enter an endless thread :)), just a question of core definition. I can compare core with win32 api (or libc), and mfc with pecl (or gtk) ;). pa -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14782: key_exists renamed to array_key_exists
From: [EMAIL PROTECTED] Operating system: all PHP version: 4.1.1 PHP Bug Type: Feature/Change Request Bug description: key_exists renamed to array_key_exists I have a very large PHP application running on my Linux web server that uses the 4.0.6 function key_exists. The problem is that I have 30 copies of this application running on the server. If I upgrade my server to php 4.1.1, I will be forced to upgrade all 30 sites with a new version of my application where array_key_exists is used instead. This is a HUGE undertaking. Is there any way to put the key_exists alias back in so that PHP compatiblity is not broken? Thank you -- Edit bug report at: http://bugs.php.net/?id=14782edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Moving extensions to PECL
In conjunction with this, increasing the findability of the PECL might be a good idea. At the least an explict search at php.net either in documentation or whole site should result in at least one hit other than a changelog entry. - AZ - Original Message - From: Jon Parise [EMAIL PROTECTED] Newsgroups: php.dev To: [EMAIL PROTECTED] Sent: Monday, December 31, 2001 1:38 PM Subject: Moving extensions to PECL I think the following standard extensions should be moved to PECL: ext/cybercash ext/icap ext/pfpro ext/yaz This is definitely not an inclusive list; it's just a start. I can't imagine a lot of people using these modules, so they seem like good candidates for removal from the base PHP distribution. Are there any well-founded objections to this (either in practice or principle)? -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14783: Using unlink causes segfault
From: [EMAIL PROTECTED]
Operating system: RH6.2/Apache/libxml2.4.12
PHP version: 4.1.1
PHP Bug Type: DOM XML related
Bug description: Using unlink causes segfault
Symptoms:
- using unlink() causes segfault
Script to reproduce:
?php
$xml = END_XML
?xml version=1.0?
test
foo id=xHello/foo
foo id=yWorld/foo
/test
END_XML;
$dom = xmldoc($xml);
// this so I can see it.
header('Content-type: text/plain');
$ctx = $dom-xpath_new_context();
$res = xpath_eval($ctx,//foo);
foreach ($res-nodeset as $child) {
$child-unlink();
}
echo $dom-dumpmem();
?
Other notes:
- some cursory debugging I did suggested that it was the cleanup routines
at the end of the script that were causing the crash. Looking at
php_domxml.c, the recursive node memory cleanup appears to be choking on a
pointer already freed during the unlink() call.
--
Edit bug report at: http://bugs.php.net/?id=14783edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14782 Updated: key_exists renamed to array_key_exists
ID: 14782 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Feature/Change Request Operating System: all PHP Version: 4.1.1 New Comment: Hi Mike, Unless one of the developers objects, I will add the alias - however, if the change is made, it would not show up 'til the next release. I would recommend that you modify your files anyway. It is a small amount of work using gawk or vim. :) Alternately, you can modify your local copy of PHP until next release. Add the following line to ext/standard/basic_functions.c: PHP_FALIAS(key_exists, array_key_exists, NULL) The line should go after the line that looks like: PHP_FE(array_key_exists,NULL) Once you have made the change and saved, recompile PHP. Previous Comments: [2001-12-31 15:33:39] [EMAIL PROTECTED] I have a very large PHP application running on my Linux web server that uses the 4.0.6 function key_exists. The problem is that I have 30 copies of this application running on the server. If I upgrade my server to php 4.1.1, I will be forced to upgrade all 30 sites with a new version of my application where array_key_exists is used instead. This is a HUGE undertaking. Is there any way to put the key_exists alias back in so that PHP compatiblity is not broken? Thank you Edit this bug report at http://bugs.php.net/?id=14782edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14782 Updated: key_exists renamed to array_key_exists
ID: 14782 Updated by: zak Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Feature/Change Request Operating System: all PHP Version: 4.1.1 Old Assigned To: Assigned To: zak New Comment: Assigning to myself Previous Comments: [2001-12-31 16:21:14] [EMAIL PROTECTED] Hi Mike, Unless one of the developers objects, I will add the alias - however, if the change is made, it would not show up 'til the next release. I would recommend that you modify your files anyway. It is a small amount of work using gawk or vim. :) Alternately, you can modify your local copy of PHP until next release. Add the following line to ext/standard/basic_functions.c: PHP_FALIAS(key_exists, array_key_exists, NULL) The line should go after the line that looks like: PHP_FE(array_key_exists,NULL) Once you have made the change and saved, recompile PHP. [2001-12-31 15:33:39] [EMAIL PROTECTED] I have a very large PHP application running on my Linux web server that uses the 4.0.6 function key_exists. The problem is that I have 30 copies of this application running on the server. If I upgrade my server to php 4.1.1, I will be forced to upgrade all 30 sites with a new version of my application where array_key_exists is used instead. This is a HUGE undertaking. Is there any way to put the key_exists alias back in so that PHP compatiblity is not broken? Thank you Edit this bug report at http://bugs.php.net/?id=14782edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14782 Updated: key_exists renamed to array_key_exists
ID: 14782 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Feature/Change Request Operating System: all PHP Version: 4.1.1 Assigned To: zak New Comment: As Someone Who Shall Not Be Named Because They Are Also On Vacation has pointed out to me off list, it would be a bad thing to have functions disappearing and reappearing between versions. The function shall stay as is - please adjust your scripts accordingly. Thank you. Previous Comments: [2001-12-31 16:37:26] [EMAIL PROTECTED] Assigning to myself [2001-12-31 16:21:14] [EMAIL PROTECTED] Hi Mike, Unless one of the developers objects, I will add the alias - however, if the change is made, it would not show up 'til the next release. I would recommend that you modify your files anyway. It is a small amount of work using gawk or vim. :) Alternately, you can modify your local copy of PHP until next release. Add the following line to ext/standard/basic_functions.c: PHP_FALIAS(key_exists, array_key_exists, NULL) The line should go after the line that looks like: PHP_FE(array_key_exists,NULL) Once you have made the change and saved, recompile PHP. [2001-12-31 15:33:39] [EMAIL PROTECTED] I have a very large PHP application running on my Linux web server that uses the 4.0.6 function key_exists. The problem is that I have 30 copies of this application running on the server. If I upgrade my server to php 4.1.1, I will be forced to upgrade all 30 sites with a new version of my application where array_key_exists is used instead. This is a HUGE undertaking. Is there any way to put the key_exists alias back in so that PHP compatiblity is not broken? Thank you Edit this bug report at http://bugs.php.net/?id=14782edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Moving extensions to PECL
Before we move stuff to PECL can you give us an overview of how this is supported? How do I get a list of extensions which are in PECL, download what I want and add them to my PHP tree for a static compile or build them dynamically? I assume you guys automated these things. Please can you give us an overview? Thanks, Andi At 01:38 PM 12/31/2001 -0500, Jon Parise wrote: I think the following standard extensions should be moved to PECL: ext/cybercash ext/icap ext/pfpro ext/yaz This is definitely not an inclusive list; it's just a start. I can't imagine a lot of people using these modules, so they seem like good candidates for removal from the base PHP distribution. Are there any well-founded objections to this (either in practice or principle)? -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11993 Updated: mysql_close closes incorrect db handler
ID: 11993 Updated by: zak Reported By: [EMAIL PROTECTED] Status: Open Bug Type: MySQL related Operating System: Debian 2.19 PHP Version: 4.1.0 Old Assigned To: Assigned To: zak New Comment: I will take a look at this. Previous Comments: [2001-12-13 11:13:44] [EMAIL PROTECTED] sorry, i can not try with php4.1.0RC3. I tried out with the latest php4.1.0, and no changes, the problem still exists. ati [2001-12-13 06:26:24] [EMAIL PROTECTED] No feedback. Closing. [2001-11-20 19:55:37] [EMAIL PROTECTED] Can you try if the problem still persists with latest RC http://www.php.net/~zeev/php-4.1.0RC3.tar.gz Feedback. [2001-10-24 00:59:24] [EMAIL PROTECTED] missing status [2001-07-11 13:58:35] [EMAIL PROTECTED] hi zak, thanks for your answer. in my opinion, php must have some matrix, where you stores the number of connect and close calls with the connection id. this will probably solve the problem. ps: i use these multiple connections in oop environment, where a global connection id, is not the best idea. or? ati 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/?id=11993 Edit this bug report at http://bugs.php.net/?id=11993edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13456 Updated: mysql_query() returns incorrect result whith do not perform real MySQL state
ID: 13456 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Assigned Status: Closed Bug Type: MySQL related Operating System: Linix PHP Version: 4.0.6 Old Assigned To: Zeev Assigned To: New Comment: Zeev fixed this. The fix should appear in the release that follows PHP 4.1.1 Previous Comments: [2001-11-20 18:52:15] [EMAIL PROTECTED] Being unkind, I assign this to Zeev ... :-) [2001-09-26 13:13:33] [EMAIL PROTECTED] We use MySQL 3.22.32 and recive false using mysql_query() wherever SQL is correct and has effect on database. So, in file ext/mysql/php_mysql.c line 99 must be at least such line: #if MYSQL_VERSION_ID 32233 instead of #if MYSQL_VERSION_ID 32224 Edit this bug report at http://bugs.php.net/?id=13456edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13589 Updated: Persistent connections stay open and accumulate
ID: 13589 Updated by: zak Reported By: [EMAIL PROTECTED] Status: Open Bug Type: MySQL related Operating System: RedHat 7.1 PHP Version: 4.0.6 Old Assigned To: Assigned To: zak New Comment: Assigning to myself Previous Comments: [2001-11-20 12:55:15] [EMAIL PROTECTED] However, this is something else. This need to be investigated first. [2001-11-20 12:31:00] [EMAIL PROTECTED] This is what Derick said about this (in #14149): This is not a bug, the MySQL extension will open a new connection if the _current apache child_ has no open connection to MySQL. With this in mind, it's very normal to see that apache has multiple connections open to MySQL. [2001-10-07 17:33:26] [EMAIL PROTECTED] While trying to use persistent connections for performance on an ad server, connections to the MySQL server stay open and accumulate over time until it hits the max_connections setting is hit. Once this happens, MySQL refuses to allow connections. After looking at the MySQL process list, it seams that connections are not always recycled. In theory, idle established connections' Commands should be Sleep but curiously, it looks like connections not being recycled have Query command and a state of NULL. Presently using MySQL 3.23.36. Edit this bug report at http://bugs.php.net/?id=13589edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14419 Updated: Please use Character-enable mysql_escape
ID: 14419
Updated by: zak
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Assigned
Bug Type: MySQL related
Operating System: All
PHP Version: 4.1.0
Old Assigned To:
Assigned To: zak
New Comment:
Thanks for the suggestion!
I will investigate this.
Previous Comments:
[2001-12-11 03:41:15] [EMAIL PROTECTED]
in file php-4.1.0/ext/mysql/php_mysql.c line 1365
---
Z_STRLEN_P(return_value) = mysql_escape_string(Z_STRVAL_P(return_value),
Z_STRVAL_PP(str), Z_STRLEN_PP(str));
---
could you change from
mysq_escape_string into mysql_
to something like
#if MYSQL_VERSION_ID 32321
len = mysql_escape_string(out, in, size);
#else
if (self) {
check_connection(self);
len = mysql_real_escape_string((self-connection), out, in, size);
}
else
len = mysql_escape_string(out, in, size);
#endif
(quote from mysql python module)
Edit this bug report at http://bugs.php.net/?id=14419edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14498 Updated: undefined symbol: my_message_no_curses
ID: 14498 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Open Status: Assigned Bug Type: MySQL related Operating System: Cobalt Linux 5.0 PHP Version: 4.1.0 Old Assigned To: Assigned To: zak New Comment: By not specifying a path to the MySQL libraries, you are using PHP's built-in library. I would guess this is a problem with MySQL - I will check it out. Previous Comments: [2001-12-13 17:36:06] [EMAIL PROTECTED] Compiled MySQL 3.23.46 with these configure options: ./configure \ --prefix=/usr/local/mysql \ --enable-assembler \ --with-low-memory Compiled PHP 4.10 with these options: ./configure --with-apxs=/usr/sbin/apxs \ --with-mysql=/usr/local/mysql \ --with-imap=/usr/local/src/imap-2000c \ --with-imap-ssl \ --with-zlib \ --enable-track-vars \ --with-gettext \ --with-gd \ --with-jpeg-dir=/usr/local/lib \ --with-mm=/usr/local/lib/mm \ --enable-sysvshm \ --enable-ftp Starting Apache 1.3.22 with apachectl start gives me this: Syntax error on line 238 of /etc/httpd/conf/httpd.conf: Cannot load /usr/lib/apache/libphp4.so into server: /usr/local/mysql/lib/mysql/libmysqlclient.so.10: undefined symbol: my_message_no_curses I can work-around this bug by NOT specifying the dir when configuring PHP i.e. (--with-mysql as opposed to --with-mysql=/usr/local/mysql) Edit this bug report at http://bugs.php.net/?id=14498edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11652 Updated: mysql_data_seek() and mysql_unbuffered_query() warning text
ID: 11652 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Open Status: Assigned Bug Type: MySQL related Operating System: All PHP Version: 4.0.6 Assigned To: zak New Comment: doh. Previous Comments: [2001-06-25 05:01:21] [EMAIL PROTECTED] When using mysql_data_seek() in conjunction with mysql_unbuffered_query() which obviously is not possible, I get a Warning: Offset 5 is invalid for MySQL result index [...] whilst the warning perhaps should have said that mysql_data_seek() aand mysql_unbuffered_query() cannot be used together. This might also be a documentation problem Edit this bug report at http://bugs.php.net/?id=11652edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11993 Updated: mysql_close closes incorrect db handler
ID: 11993 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Open Status: Assigned Bug Type: MySQL related Operating System: Debian 2.19 PHP Version: 4.1.0 Assigned To: zak New Comment: doh. Previous Comments: [2001-12-31 18:56:34] [EMAIL PROTECTED] I will take a look at this. [2001-12-13 11:13:44] [EMAIL PROTECTED] sorry, i can not try with php4.1.0RC3. I tried out with the latest php4.1.0, and no changes, the problem still exists. ati [2001-12-13 06:26:24] [EMAIL PROTECTED] No feedback. Closing. [2001-11-20 19:55:37] [EMAIL PROTECTED] Can you try if the problem still persists with latest RC http://www.php.net/~zeev/php-4.1.0RC3.tar.gz Feedback. [2001-10-24 00:59:24] [EMAIL PROTECTED] missing status 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/?id=11993 Edit this bug report at http://bugs.php.net/?id=11993edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13589 Updated: Persistent connections stay open and accumulate
ID: 13589 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Open Status: Assigned Bug Type: MySQL related Operating System: RedHat 7.1 PHP Version: 4.0.6 Assigned To: zak New Comment: doh. Previous Comments: [2001-12-31 19:08:34] [EMAIL PROTECTED] Assigning to myself [2001-11-20 12:55:15] [EMAIL PROTECTED] However, this is something else. This need to be investigated first. [2001-11-20 12:31:00] [EMAIL PROTECTED] This is what Derick said about this (in #14149): This is not a bug, the MySQL extension will open a new connection if the _current apache child_ has no open connection to MySQL. With this in mind, it's very normal to see that apache has multiple connections open to MySQL. [2001-10-07 17:33:26] [EMAIL PROTECTED] While trying to use persistent connections for performance on an ad server, connections to the MySQL server stay open and accumulate over time until it hits the max_connections setting is hit. Once this happens, MySQL refuses to allow connections. After looking at the MySQL process list, it seams that connections are not always recycled. In theory, idle established connections' Commands should be Sleep but curiously, it looks like connections not being recycled have Query command and a state of NULL. Presently using MySQL 3.23.36. Edit this bug report at http://bugs.php.net/?id=13589edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13933 Updated: error_log and HTTP redirect using header conflict
ID: 13933 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Open Status: Assigned Bug Type: Output Control Operating System: Windows NT4 SP6 PHP Version: 4.0.6 Old Assigned To: zak Assigned To: yasuo New Comment: Assigning this to Yasuo :) Previous Comments: [2001-12-12 04:51:21] [EMAIL PROTECTED] Zak, is this bug analyzed? I'm trying to sort out output buffering problems. Thanks. [2001-12-10 20:40:37] [EMAIL PROTECTED] Assigning it to myself so that I don't forget about it. :) [2001-12-05 04:24:00] [EMAIL PROTECTED] I finally found time to test. Here it goes. First of all, PHP config is: error_log is not set display_errors is off log_errors is on error_reporting is standard (E_ALL ~E_NOTICE) Then, the page I'm testing: ? error_log (this is a test, 0); header(Location: index.php); ? And finally, the results: - in Apache's log file, I get these two lines: [Wed Dec 05 10:09:59 2001] [error] [client 172.22.50.91] this is a test [Wed Dec 05 10:09:59 2001] [error] [client 172.22.50.91] PHP Warning: Cannot add header information - headers already sent in d:\wwwroot\htdocs\csf_recette\titi.php on line 3 - the source of the generated page displayed in IE is as follow, eventhough nothing has been output: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN HTMLHEAD META http-equiv=Content-Type content=text/html; charset=iso-8859-1/HEAD BODY/BODY/HTML Conclusion: - error_log works fine, it does what I expect, but it might do a little more; - PHP complains about something being output *before* the call to header. I've tried removing this call (to header), my message is logged, and I *still* get the same output; - thus, somehow, the call to error_log produces PHP or Apache to generate this unexpected HTML code while logging; I've tried almost the same settings on another server (difference in php.ini is display_errors on) and it works quite fine. Could there be other parts of PHP's configuration, or even Apache's conf, altering the expected behaviour ? [2001-11-12 19:54:19] [EMAIL PROTECTED] Status - feedback (Zak! try to remember? :) [2001-11-12 17:01:23] [EMAIL PROTECTED] Sounds like error_log() was generating an error message because the error_log directive was not set. Once the error message was generated, output would be sent to the browser, causing the headers to be sent and the header() call to fail. Try unsetting the error_log directive in php.ini and run a script that only calls error_log(). 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/?id=13933 Edit this bug report at http://bugs.php.net/?id=13933edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14295 Updated: Scope of globals has changed
ID: 14295 Updated by: zak Reported By: [EMAIL PROTECTED] Old Status: Open Status: Assigned Bug Type: Variables related Operating System: Win2k PHP Version: 4.0.6 Assigned To: zak New Comment: I should really get around to examining this. :) Previous Comments: [2001-12-06 08:51:28] [EMAIL PROTECTED] I'm unable to reach you at [EMAIL PROTECTED]! Where should I send the password to? [2001-12-06 08:46:19] [EMAIL PROTECTED] Forgot to say this: Please let me know if you find the problem ; ) [2001-12-06 08:40:49] [EMAIL PROTECTED] zak: I have set up a webserver and ftp for you to do the tests you need. The account is running on the system which produces the problem. Feel free to use it as you like. NOTE: The server might be offline for a short while sometimes. This is because of redialing and submitting a new IP to DynDNS.org every 24 hours. Additionally the server will be down on Sunday, 12/9/01 00:00:00 Am to 10:00:00 Am european time. If you should have additional questions or wishes related to the account do not hesitate to ask me. HTTP and FTP: phpnet.homeip.net The password for the FTP will reach you by email. [2001-12-06 07:41:47] [EMAIL PROTECTED] Thanks for trying the scripts! If we are lucky, this bug report will help us find what weird thing makes $PHP_SELF behave strangely under Win32. Could you please try the same test with a different global value? [2001-12-05 01:49:07] [EMAIL PROTECTED] Zak: I did try it and could reproduce with your code. I found out, that it only happens when i'm running my scripts on Win2k. On Linux my scripts are running as expected and I don't need to declare $PHP_SELF global again. The only difference in my PHP configuration is: On Win2k virtual dirs is enabled, on Linux it's disabled. Well, I don't know where to set virtual directory support on/off, so I can't verify. 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/?id=14295 Edit this bug report at http://bugs.php.net/?id=14295edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14295 Updated: Scope of globals has changed
ID: 14295
Updated by: zak
Reported By: [EMAIL PROTECTED]
Old Status: Assigned
Status: Bogus
Bug Type: Variables related
Operating System: Win2k
PHP Version: 4.0.6
Old Assigned To: zak
Assigned To:
New Comment:
Hi Volker,
Thanks for setting up the web server for me. It made
testing a lot faster.
Thankfully, I could not reproduce the problem on your web
server. Flagging bug as bogus.
For proof of bogosity, see :
http://phpnet.homeip.net/v1.php
http://phpnet.homeip.net/v2.php
http://phpnet.homeip.net/v1.phps
http://phpnet.homeip.net/v2.phps
Also, here is a diff out the output of calling v2.php
directly and calling it via an include call in v1.php
None of the globals are missing in either case.
Additionally, the two are almost the same -- except for
the differences noted below.
--- v1.php Mon Dec 31 17:35:12 2001
+++ v2.php Mon Dec 31 17:35:02 2001
@@ -1,5 +1,5 @@
pre
-PHP_SELF: /v1.php
+PHP_SELF: /v2.php
hrbALLUSERSPROFILE:/b string(42) C:\\Dokumente und
Einstellungen\\All Users
hrbCommonProgramFiles:/b string(33)
C:\\Programme\\Gemeinsame Dateien
@@ -36,8 +36,8 @@
hrbHTTP_X_FORWARDED_FOR:/b string(13)
207.34.113.45
hrbPATH:/b string(55)
C:\\WINNT\\system32;C:\\WINNT;C:\\WINNT\\System32\\Wbem
hrbREMOTE_ADDR:/b string(13) 207.34.94.239
-hrbREMOTE_PORT:/b string(5) 51995
-hrbSCRIPT_FILENAME:/b string(27)
d:/www/phpnet/htdocs/v1.php
+hrbREMOTE_PORT:/b string(5) 51252
+hrbSCRIPT_FILENAME:/b string(27)
d:/www/phpnet/htdocs/v2.php
hrbSERVER_ADDR:/b string(14) 217.224.230.39
hrbSERVER_ADMIN:/b string(11) [EMAIL PROTECTED]
hrbSERVER_NAME:/b string(17) phpnet.homeip.net
@@ -50,10 +50,10 @@
hrbSERVER_PROTOCOL:/b string(8) HTTP/1.0
hrbREQUEST_METHOD:/b string(3) GET
hrbQUERY_STRING:/b string(0)
-hrbREQUEST_URI:/b string(7) /v1.php
-hrbSCRIPT_NAME:/b string(7) /v1.php
-hrbPATH_TRANSLATED:/b string(27)
d:/www/phpnet/htdocs/v1.php
-hrbPHP_SELF:/b string(7) /v1.php
+hrbREQUEST_URI:/b string(7) /v2.php
+hrbSCRIPT_NAME:/b string(7) /v2.php
+hrbPATH_TRANSLATED:/b string(27)
d:/www/phpnet/htdocs/v2.php
+hrbPHP_SELF:/b string(7) /v2.php
hrbargv:/b array(0) {
}
hrbargc:/b int(0)
@@ -95,9 +95,9 @@
[REMOTE_ADDR]=
string(13) 207.34.94.239
[REMOTE_PORT]=
- string(5) 51995
+ string(5) 51252
[SCRIPT_FILENAME]=
- string(27) d:/www/phpnet/htdocs/v1.php
+ string(27) d:/www/phpnet/htdocs/v2.php
[SERVER_ADDR]=
string(14) 217.224.230.39
[SERVER_ADMIN]=
@@ -124,13 +124,13 @@
[QUERY_STRING]=
string(0)
[REQUEST_URI]=
- string(7) /v1.php
+ string(7) /v2.php
[SCRIPT_NAME]=
- string(7) /v1.php
+ string(7) /v2.php
[PATH_TRANSLATED]=
- string(27) d:/www/phpnet/htdocs/v1.php
+ string(27) d:/www/phpnet/htdocs/v2.php
[PHP_SELF]=
- string(7) /v1.php
+ string(7) /v2.php
[argv]=
array(0) {
}
Previous Comments:
[2001-12-31 19:18:01] [EMAIL PROTECTED]
I should really get around to examining this. :)
[2001-12-06 08:51:28] [EMAIL PROTECTED]
I'm unable to reach you at [EMAIL PROTECTED]!
Where should I send the password to?
[2001-12-06 08:46:19] [EMAIL PROTECTED]
Forgot to say this: Please let me know if you find the problem ; )
[2001-12-06 08:40:49] [EMAIL PROTECTED]
zak:
I have set up a webserver and ftp for you to do the tests you need. The account is
running on the system which produces the problem. Feel free to use it as you like.
NOTE:
The server might be offline for a short while sometimes. This is because of redialing
and submitting a new IP to DynDNS.org every 24 hours.
Additionally the server will be down on Sunday, 12/9/01 00:00:00 Am to 10:00:00 Am
european time.
If you should have additional questions or wishes related to the account do not
hesitate to ask me.
HTTP and FTP: phpnet.homeip.net
The password for the FTP will reach you by email.
[2001-12-06 07:41:47] [EMAIL PROTECTED]
Thanks for trying the scripts! If we are lucky, this bug
report will help us find what weird thing makes $PHP_SELF
behave strangely under Win32.
Could you please try the same test with a different global
value?
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/?id=14295
Edit this bug report at http://bugs.php.net/?id=14295edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
[PHP-DEV] Bug #14784: shmop_write causes segfault
From: [EMAIL PROTECTED]
Operating system: Linux (RH 6.2 / 2.4.3)
PHP version: 4.1.1
PHP Bug Type: Reproducible crash
Bug description: shmop_write causes segfault
I have been experimenting with semaphores/shmop to provide
query caching for an application I am working on. The
purpose, of course, bears no bearing on the issue I am
reporting however as I am just doing testing of the two
extensions at this point.
I used this article as the starting point for my testing -
http://zez.org/article/articleprint/46/.
So I put together this script:
--
function mtime()
{
return array_sum( explode( , microtime() ) );
}
function supecho( $text )
{
echo Pb$text/b/p\r\n;
flush();
}
function subecho( $text )
{
echo Pb -- $text/b/p\r\n;
flush();
}
supecho( Starting semaphore testing... );
// Start semaphore handling
$semaphoreID= sem_get( 0xee3 , 1 , 0666 ); // Get a
semaphore named 0xee3
supecho( Attempting to get a semaphore );
if( $semaphoreID )
{
subecho( success );
supecho( Attempt to obtain our shared memory segment );
$testID = shmop_open( 0xff3, ac, 0, 0);
if( $testID ) // Already exists
{
subecho( Success (opening with 'a' flag) );
$sharedID = shmop_open( 0xff3, a, 0, 0);
}
else // create it
{
subecho( Does not exist... );
supecho( Attempting to create shared memory section
with 'c' flag and 0xxf3 address );
$sharedID = shmop_open( 0xff3, c, 0644, 100);
if( $sharedID )
{
subecho( Success );
}
else
{
subecho( Failure );
}
}
if( $sharedID )
{
subecho( Attempt to obtain a shared memory segment
success );
supecho( Going for a semaphore acquisition );
sem_acquire( $semaphoreID );
subecho( Semaphore acquired );
$myString = a;
supecho( Shared mem segment size (in bytes):
.shmop_size( $sharedID ) );
supecho( Starting to read total segment );
$start = mtime();
subecho( Reading shared memory segment into memory --|
.shmop_read( $sharedID, 0, shmop_size( $sharedID ) ) );
subecho( ( ( shmop_size( $sharedID )) / ( mtime() -
$start ) ). bytes/second );
/* THIS WRITE STATEMENT CAUSES A SEGFAULT
+
+
+
\\ //
-
*/
subecho( Writing .shmop_write( $sharedID, $myString, 0
). bytes to block );
/*
^
// \\
+
+
+
THIS WRITE STATEMENT CAUSES A SEGFAULT
*/
supecho( Closing shmop segment );
shmop_close( $sharedID );
subecho( Done );
supecho( Going for a semaphore release );
sem_release( $semaphoreID );
subecho( Semaphore released );
}
else
{
subecho( Attempt to obtain a shared memory segment
failed );
}
}
else
{
subecho( Attempt to get a semaphore failed );
}
--
When I run the script with the smhop_write call commented
out, it runs fine and releases both the shmop segment and
semaphore at the end. However, when it runs with the
shmop_write call, it segfaults immediately after calling
[PHP-DEV] Bug #14785: cannot save data with session_register() in functions
From: [EMAIL PROTECTED]
Operating system: Debian Linux
PHP version: 4.1.0
PHP Bug Type: Session related
Bug description: cannot save data with session_register() in functions
session_register() doesnt seem to save anything in functions, eg.
session_start();
function bob() {
$var = somethinghere;
session_register(var);
}
bob();
echo session_encode();
the above only registers the var name, not the data in it.
if it helps theres a way around it, all you gota do is make the $var global
so instead of having $var have $GLOBALS['var'] and it works fine.
might be little bug, but it stuffed me up 4 nights in a row.
oh and the way i compiled php was just with apt-get install php4 in debian,
(newbie here)
--
Edit bug report at: http://bugs.php.net/?id=14785edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14716 Updated: PHP 4.1.1 DSO: apache startup fail
ID: 14716 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: Linux, RH 6.1 base, Kernel2.2.19 PHP Version: 4.1.0 New Comment: This seems to have been remedied by supplying --with-regex=php. Supplying --with-regex=apache caused a build failure. Previous Comments: [2001-12-27 06:41:23] [EMAIL PROTECTED] /usr/local/apacheS/bin/apachectl start gives me: Syntax error on line 968 of /usr/local/apacheS/conf/httpd.conf: BrowserMatch regex could not be compiled. ../bin/apachectl start: httpd could not be started Before installing the libphp4.so module, the server was fine. This problem seems to occur regardless of whether or not I comment the modssl and modperl module lines. Something about the options below that don't work together? Please let me know. :( I have compiled PHP4.1.1 with this configure line: ./configure --with-mysql=/usr/local --with-ldap --enable-mailparse --with-db3 --with-gdbm --with-ndbm --with-ttf --with-freetype-dir=/usr/local/include/freetype/ --with-imap --with-openssl=/usr/local/ssl/ --with-imap-ssl=/usr/local/ssl --with-gd --enable-dmalloc --with-bz2 --enable-ftp --with-apxs=/usr/local/apacheS/bin/apxs --sysconfdir=/etc --with-jpeg-dir=/usr/ --with-zlib-dir=/usr/local --with-png-dir=/usr/local --with-xpm-dir=/usr/X11R6 --with-mcrypt=/usr/local --with-mhash=/usr/local/ --enable-gd-native-ttf --with-java=/usr/jdk1.3/ --enable-track-vars Everything is OK, no debug.log generated. Edit this bug report at http://bugs.php.net/?id=14716edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14786: configure failure without trailing slash
From: [EMAIL PROTECTED] Operating system: RH Linux 6.1 PHP version: 4.1.1 PHP Bug Type: PHP options/info functions Bug description: configure failure without trailing slash When supplying the path to openssl and including the mcrypt option, the below failure occurs unless the opensslpath has a trailing slash. checking for mcrypt support... yes checking for mcrypt_module_open in -lmcrypt... no checking for init_mcrypt in -lmcrypt... no configure: error: Sorry ./configure --with-mysql=/usr/local --with-ldap --with-db3 --with-gdbm --with-imap --with-openssl=/usr/local/ssl/ --with-imap-ssl=/usr/local/ssl --sysconfdir=/etc --enable-track-vars --with-config-file-path=/etc --enable-force-cgi-redirect --with-zlib --with-regex=php --enable-sockets --with-mm --with-apxs=/usr/local/apache1322/bin/apxs --with-gd --enable-dmalloc --with-bz2 --with-jpeg-dir=/usr/ --with-zlib-dir=/usr/local --with-png-dir=/usr/local --with-xpm-dir=/usr/X11R6 --with-mcrypt=/usr/local/ --with-mhash=/usr/local/ --enable-gd-native-ttf --enable-gmp --with-freetype-dir=/usr/local/include/freetype/ -- Edit bug report at: http://bugs.php.net/?id=14786edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
