[PHP-DEV] PHP 4.0 Bug #9106: Floating Point and Arithmetic Exception crashes
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.2-STABLE PHP version: 4.0.4pl1 PHP Bug Type: Reproduceable crash Bug description: Floating Point and Arithmetic Exception crashes I have suffered from /kernel: pid 69000 (httpd), uid 99: exited on signal 8 repeatedly in any php script whose guts wind up calling rand(). The fix is supposedly fpsetmask(0) instead of the current code in zend.c, but this would only work for me if I set apache's MaxRequestsPerChild to one. As might be expected, this is because the fix, if placed in zend_startup, is effective ONLY for the first request served from that httpd (in DSO mode. CGI obviously would not care). If you place the fpsetmask(0) call at the beginning of zend_activate_modules, subsequent requests will benefit and the signal 8 crashes cease. -- Edit Bug report at: http://bugs.php.net/?id=9106edit=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] PHP 4.0 Bug #9107 Updated: Function with mysql_close($conn) closes top level scripts $conn
ID: 9107
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: *Function Specific
Description: Function with mysql_close($conn) closes top level scripts $conn
Sorry the PL4 was meant to be PHP4.04Pl1 :)
Previous Comments:
---
[2001-02-05 04:06:36] [EMAIL PROTECTED]
Please Also Refer to Bug Report 9049 :
I believe I am having the same problem. I think I have worked out why tho.
I have two files.
One has a function in it.
Both files require a connection to mysql database.
Both connections use the $conn as their pointer.
If you mysql_close($conn) within the function in the second file
then it closes the $conn in the script calling the function.
So you have to remove the mysql_close from your function
and even the $conn=mysql_connect from it and just pass the
$conn as a variable to the function :
eg
function foo($conn){
$result=mysql_db_query("test","select ...",$conn);
}
called from say test.html
$conn=mysql_connect("localhost","rootme","noway");
foo($conn);
was like this :
function foo()
{
$conn=mysql_connect("localhost","rootme","noway");
## query work etc..
mysql_close($conn);
return;
}
main script :
$conn=mysql_connect("localhost","rootme","noway");
#anything in here
#call function
$wotever=foo();
$result=mysql_db_query("database","query",$conn);
the last line brings up the error about the mysql link resource being wrong as the
$conn was closed in the function but somehow closed it globally too. Which is a bit of
a pain as this was ok before upgrading to Pl4
I didnt see anything in the change file about this :L So I can only assume
this is a bug.
If you need more info from me please let me know.. Thanks for all the good work guys
:)
---
Full Bug description available at: http://bugs.php.net/?id=9107
--
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: Fw: [PHP-DEV] PHP 4.0 Bug #8889: Memory is not being freed.
Why would using DSO reduce memory consumption? Using DSO makes things easier to administer and maintain, but it doesn't save any memory and it does pose a slight performance decrease... Zeev At 02:20 30/1/2001, Jason Greene wrote: MaxRequestsPerChild is perfectly safe, and I always believe in setting it. Keep in mind that if you compile all modules into apache statically, it takes up far more base mem per process. If you use all DSO's, you can significantly reduce memory usage. To find out what's in use on RH7 cat /proc/pid/maps of an apache child. You can also reduce the KeepAlive timeout value to help-out. Jason - Original Message - From: "Rasmus Lerdorf" [EMAIL PROTECTED] To: "Filip Sielimowicz" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, January 29, 2001 7:51 AM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889: Memory is not being freed. On Mon, 29 Jan 2001, Filip Sielimowicz wrote: A quick fix would be to set your MaxRequestsPerChild to a lower value. Have you ever tried to measure the time of killing and starting httpd process ? You can see that with a bare human eye. Sure. But that isn't something that happens on an actual request, so an end user isn't going to see that. -Rasmus -- 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] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- 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] CVS Account Request
Full name: Ingmar Heinrich Email: [EMAIL PROTECTED] ID: inki Purpose: private -- 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] PHP 4.0 Bug #9110: SELECT DISTINCT broken
From: [EMAIL PROTECTED] Operating system: Linux 2.2.x PHP version: 4.0.3pl1 PHP Bug Type: MySQL related Bug description: SELECT DISTINCT broken A simple query as this one complety ignores the DISTINCT statement: "SELECT DISTINCT opponent,opponent_url FROM wars WHERE (opponent_url '' AND opponent_url 'http://' ) AND played='1' ORDER BY opponent,opponent_url" I've searched this site and google.com for solutions for it, but php.net showed nothing and google had only more people reporting the same problem. I searched the bug database and didn't fin anything matching 'DISTINCT'. So this is my bugreport. -- Edit Bug report at: http://bugs.php.net/?id=9110edit=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] [Fwd: Re: [PHP] Howto return multidimensional arrays from a PHP module]
I were refered to this list...
I found an old entry in the dev archive, explaining that I could achieve
my goals, by "for each inner array you
allocate a zval*, initialize it, add data to it, and add it to the
return value."
But how exactly do I add a zval?
My guess is add_assoc_resource but where do the integer come from?
Is it the returnvalue from array_init(allocatedZvalP)???
Just a snippet I created recently...
ZEND_FUNCTION(dbx_test)
{
zval **args[2];
zval *row[2];
int result;
for (result=0; result2; ++result) {
args[result]=NULL;
}
if (ZEND_NUM_ARGS() !=2 || zend_get_parameters_array_ex(2, args) ==
FAILURE) {
WRONG_PARAM_COUNT;
}
convert_to_long_ex(args[0]);
convert_to_string_ex(args[1]);
if (array_init(return_value) != SUCCESS) {
zend_error(E_ERROR, "Unable to create array for results...");
}
for (result=0; result2; ++result) {
MAKE_STD_ZVAL(rowheader[result]);
if (array_init(rowheader[result]) != SUCCESS) {
zend_error(E_ERROR, "Unable to create array for rowheader
%d...", result);
}
}
for (result=0; result2; ++result) {
MAKE_STD_ZVAL(row[result]);
if (array_init(row[result]) != SUCCESS) {
zend_error(E_ERROR, "Unable to create array for row %d...",
result);
}
}
add_index_string(row[0], 0, "bla00", 1);
add_index_string(row[0], 1, "bla10", 1);
add_index_string(row[1], 0, "bla01", 1);
add_index_string(row[1], 1, "bla11", 1);
zend_hash_index_update(return_value-value.ht, 0, (void *)(row[0]),
sizeof(zval *), NULL);
zend_hash_index_update(return_value-value.ht, 1, (void *)(row[1]),
sizeof(zval *), NULL);
}
Good luck!
Cheerio, Marc.
--
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] PHP 4.0 Bug #9113: Apache will not restart
From: [EMAIL PROTECTED] Operating system: Suse linux 7.0 PHP version: 4.0.4pl1 PHP Bug Type: Apache related Bug description: Apache will not restart I'm using the following configuration ./configure --with-interbase=/opt/interbase \ --with-mysql --with-apxs --with-zlib \ --with-zlib-dir and It works with version 4.0.3pl1 but if I compile the 4.0.4pl1 apache would not restart. Thanks -- Edit Bug report at: http://bugs.php.net/?id=9113edit=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] PHP 4.0 Bug #8941 Updated: Openlink/ODBC cannot parse complex queries
ID: 8941 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: ODBC related Description: Openlink/ODBC cannot parse complex queries problem still exists in PHP 404 sp1 Previous Comments: --- [2001-01-26 12:27:51] [EMAIL PROTECTED] Configuration above should show PHP4.0.2 not 4.0.1pl2 --- [2001-01-26 12:26:10] [EMAIL PROTECTED] Platform: HPUX 10.20 Configuration: PHP4.0.1pl2 --with-iodbc --without-mysql --with-pdflib=/usr/local --without-gd --with-apache=../apache_1.3.14 Using Openlink MT ODBC driver against a PROGRESS database. Any version of PHP after 4.0.1pl2 cannot parse queries with a JOIN statement in it. Versions upto and including above work ok. The log file from the Openlink Server shows this from a sample (good) query: generic_pro83b: SCR_AnalyseSQL failed: SELECT * FROM VIRTUAL_LAYERS INNER JOIN LAYER_INFORMATION ON LAYER_INFORMATION.LAYER1_DESCRIPTION=VIRTUAL_LAYERS.LAYER1_DESCRIPTION generic_pro83b: parse error generic_pro83b: SELECT * FROM VIRTUAL_LAYERS INNER JOIN^ --- Full Bug description available at: http://bugs.php.net/?id=8941 -- 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] Accessing files on other virtual hosts (RE: [PHP-DEV] Reading memory before a variable)
Tried my snippet on a Linux box runnig PHP 4.0.4pl1 with an interesting
result; it displayed the source code for both PHP and HTML files from other
virtual hosts on the machine! Surly this should not be possible.
-Mrten.
Icq# 38863127
-Original Message-
From: Mrten Gustafsson [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 05, 2001 4:12 PM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] Reading memory "before" a variable
Using PHP 4.0.4 for Windows it is possible to access memory "before" a
variable using a negative index on a string variable.
Executing the snippet below outputs a lot of trash but alos the entire
source code of a file that is auto prepended.
?php
$str = '';
$hello = 'Hello';
for($i = 0; $i -1; $i--)
{
$str .= $hello[$i];
}
echo strrev($str);
?
-Mrten.
Icq# 38863127
--
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] PHP 4.0 Bug #9093 Updated: if(1) fails
ID: 9093
Updated by: waldschrott
Reported By: [EMAIL PROTECTED]
Old-Status: Closed
Status: Bogus
Bug Type: Scripting Engine problem
Assigned To:
Comments:
bogusing
Previous Comments:
---
[2001-02-03 19:04:24] [EMAIL PROTECTED]
The code causing the error looks something like this
Here is the value of $name: "some_data"
if($what_the_fuck= ($name != NULL))
{
echo "debug (passed): $what_the_fuck";
}
else
{
echo "debug (failed): $what_the_fuck";
}
And this is what is happening.
debug (failed): 1
ERROR: Template: trying to set NULL template variable name
the "what_the_fuck" variable == 1 so why is if failing. "name" == "some_data". If
($name != NULL) == 1 then if should not fail. P.S. I added the "what_the_fuck" for
clearity only.
thanks,
richie
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9093edit=2
--
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] PHP 4.0 Bug #9115: unserialization segfaults
From: [EMAIL PROTECTED]
Operating system: RH 6.2/Linux
PHP version: 4.0.4pl1
PHP Bug Type: *Session related
Bug description: unserialization segfaults
I get this consquently with 4.0.4+ (tried latest on snaps.php.net)
This happens while unserializing, but seems to be caused by a bad serialization --
this has been tested by serializing with 4.0.1pl2 and unserializing with 4.0.4pl1 --
no problems. The other way around ofcourse crashes.
Here's the bt from the segfault
(gdb) run -X
Starting program: /home/httpd/bin/httpd -X
(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x81135cd in _zval_ptr_dtor ()
(gdb) bt
#0 0x81135cd in _zval_ptr_dtor ()
#1 0x811c9f9 in zend_hash_destroy ()
#2 0x8119158 in _zval_dtor ()
#3 0x81135e2 in _zval_ptr_dtor ()
#4 0x80fe2e9 in php_var_unserialize ()
#5 0x80ceb61 in ps_srlzr_decode_php ()
#6 0x80cf004 in ps_srlzr_decode_wddx ()
#7 0x80cf1f0 in ps_srlzr_decode_wddx ()
#8 0x80cfc14 in ps_srlzr_decode_wddx ()
#9 0x80d0c90 in php_if_session_start ()
#10 0x81464a1 in execute ()
#11 0x814c28d in execute ()
#12 0x8119fc8 in zend_execute_scripts ()
#13 0x808b788 in php_execute_script ()
#14 0x812521e in apache_php_module_main ()
#15 0x8089356 in send_php ()
#16 0x8089388 in send_parsed_php ()
#17 0x8153db3 in ap_invoke_handler ()
#18 0x81675e9 in ap_some_auth_required ()
#19 0x816764c in ap_process_request ()
#20 0x815eece in ap_child_terminate ()
#21 0x815f05c in ap_child_terminate ()
#22 0x815f1b9 in ap_child_terminate ()
#23 0x815f7e6 in ap_child_terminate ()
#24 0x815ff73 in main ()
#25 0x407669cb in __libc_start_main (main=0x815fc2c main, argc=2, argv=0xba54,
init=0x806f58c _init, fini=0x81d4a2c _fini, rtld_fini=0x4000ae60 _dl_fini,
stack_end=0xba4c) at ../sysdeps/generic/libc-start.c:92
Here's a working serialization:
!cust_id|session|O:7:"session":9:{s:16:"boolAuthenticate";b:1;s:9:"strSessID";s:0:"";s:9:"intUserID";s:1:"1";s:12:"strUserLogin";s:5:"david";s:15:"strUserPassword";s:7:"";s:11:"arrUserInfo";a:26:{i:0;s:1:"1";s:7:"cust_id";s:1:"1";i:1;s:1:"2";s:9:"cust_type";s:1:"2";i:2;s:5:"David";s:9:"cust_name";s:5:"David";i:3;s:7:"Hjortsø";s:12:"cust_surname";s:7:"Hjortsø";i:4;s:13:"[EMAIL PROTECTED]";s:10:"cust_email";s:13:"[EMAIL PROTECTED]";i:5;s:12:"+45
33179292";s:14:"cust_telephone";s:12:"+45 33179292";i:6;s:12:"+45
33179299";s:8:"cust_fax";s:12:"+45 33179299";i:7;s:27:"Frederiksberggade 26, 4
Sal";s:13:"cust_address1";s:27:"Frederiksberggade 26, 4
Sal";i:8;s:0:"";s:13:"cust_address2";s:0:"";i:9;s:12:"Copenhagen
K";s:9:"cust_city";s:12:"Copenhagen
K";i:10;s:7:"Dk-1459";s:11:"cust_postal";s:7:"Dk-1459";i:11;s:3:"050";s:12:"cust_country";s:3:"050";i:12;s:15:"Deus
ex Machina";s:12:"cust_company";s:15:"Deus ex
Machina";}s:11:"intUserType";i:2;s:13:"intUserStatus";i:0;s:9:"boolLogin";b:1;}create|O:10:"createtest":5:{s:7:"arrTest";b:0;s:11:"arrSections";a:1:{i:0;a:2:{s:10:"section_id";i:1;s:12:"section_name";s:29:"Skriv
navnet på sektionen
her";}}s:8:"arrPages";a:21:{s:10:"test_title";s:0:"";s:15:"test_short_desc";s:0:"";s:9:"test_type";s:1:"b";s:14:"test_responses";s:0:"";s:10:"test_start";s:0:"";s:8:"test_end";s:0:"";s:7:"test_fc";s:6:"Yellow";s:7:"test_bc";s:6:"Yellow";s:9:"test_desc";s:0:"";s:9:"test_link";s:0:"";s:14:"qsInternetHome";N;s:16:"qsInternetAccess";N;s:15:"qsInternetUsage";N;s:8:"qsLiving";N;s:7:"qsCivil";N;s:8:"qsGender";N;s:7:"EndYear";s:0:"";s:8:"EndMonth";s:1:"1";s:10:"StartMonth";s:1:"1";s:9:"StartYear";s:0:"";s:7:"private";N;}s:11:"intLastPage";s:1:"6";s:11:"intNrPeople";N;}arrSections|a:1:{i:0;a:2:{s:10:"section_id";i:1;s:12:"section_name";s:29:"Skriv
navnet på sektionen her";}}R:39;arrQuestions|N;arrQuestions|a:1:{i:0;s:0:"";}
And here is the segfaulting one:
!cust_id|session|O:7:"session":9:{s:16:"boolAuthenticate";b:1;s:9:"strSessID";s:0:"";s:9:"intUserID";s:1:"1";s:12:"strUserLogin";s:5:"david";s:15:"strUserPassword";s:7:"";s:11:"arrUserInfo";a:26:{i:0;s:1:"1";s:7:"cust_id";s:1:"1";i:1;s:1:"2";s:9:"cust_type";s:1:"2";i:2;s:5:"David";s:9:"cust_name";s:5:"David";i:3;s:7:"Hjortsø";s:12:"cust_surname";s:7:"Hjortsø";i:4;s:13:"[EMAIL PROTECTED]";s:10:"cust_email";s:13:"[EMAIL PROTECTED]";i:5;s:12:"+45
33179292";s:14:"cust_telephone";s:12:"+45 33179292";i:6;s:12:"+45
33179299";s:8:"cust_fax";s:12:"+45 33179299";i:7;s:27:"Frederiksberggade 26, 4
Sal";s:13:"cust_address1";s:27:"Frederiksberggade 26, 4
Sal";i:8;s:0:"";s:13:"cust_address2";s:0:"";i:9;s:12:"Copenhagen
K";s:9:"cust_city";s:12:"Copenhagen
K";i:10;s:7:"Dk-1459";s:11:"cust_postal";s:7:"Dk-1459";i:11;s:3:"050";s:12:"cust_country";s:3:"050";i:12;s:15:"Deus
ex Machina";s:12:"cust_company";s:15:"Deus ex
Machina";}s:11:"intUserType";i:2;s:13:"intUserStatus";i:0;s:9:"boolLogin";b:1;}create|O:10:"createtest":5:{s:7:"arrTest";b:0;s:11:"arrSections";a:1:{i:0;a:2:{s:10:"section_id";i:1;s:12:"section_name";s:29:"Skriv
navnet på sektionen
[PHP-DEV] PHP 4.0 Bug #9112 Updated: isapi doesn't work anymore
ID: 9112 User Update by: [EMAIL PROTECTED] Status: Closed Bug Type: *Install and Config Description: isapi doesn't work anymore k no bug :( what's in a name ne-way suggestion is no solution... give it a try on next release again :( R. Previous Comments: --- [2001-02-05 10:22:31] [EMAIL PROTECTED] Dont think this is really a bug, at least I hope not :P anyway I would suggest you subscribe to [EMAIL PROTECTED] and ask your question there (to subscribe send an email to [EMAIL PROTECTED]) Might be worth checking that you have the correct files in the right place.. normally I just throw them all into the c:php4 dir (all files from sapi and extensions) then I can be sure that PHP is finding them. James --- [2001-02-05 10:16:32] [EMAIL PROTECTED] php_oci8.dll ofcourse --- [2001-02-05 10:02:01] [EMAIL PROTECTED] Hi, First let me say that u make a tremendous great product. Am no complainer. Was running php401pl2 configured as isapi filter. This was very stable only I couldn't load extensions. If I did, IIS 4.0 wouldn't start anymore. No dump no nutting, just stating one or more services didnt start. So I upgraded to the latest version today. Result doesn't work anymore as isapi-filter. In frames just one php page comes the others don't, giving parameters (ie ?par=1) gives an internal server error. Works configured as CGI, but this is very slow. Extensions still wont load, only this time I get an error "c:/php4/extensions/oci8.dll access denied". Security of this file: Everybody full control. Do I need special privileges to do this. Company policiy is that nobody may change something on there pc (control-freaks). So I am afraid I'm gona have to advise javascript and odbc crap to my superiors, sigh. Rudie --- Full Bug description available at: http://bugs.php.net/?id=9112 -- 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] PHP 4.0 Bug #9115 Updated: unserialization segfaults
ID: 9115
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: *Session related
Description: unserialization segfaults
Clarification:
I am not trying to load a session between versions of PHP!
The bug happens when using PHP 4.0.4pl1, and the backtrace is generated from that.
I have however -- to test that it was the serialization that was buggy under 4.0.4pl1
-- created the same session in 4.0.1pl2 and tried to load it inder 4.0.4pl1,
succesfully.
So whenever I use 4.0.4pl1 in apache it segfaults at that point in then application
Previous Comments:
---
[2001-02-05 10:55:56] [EMAIL PROTECTED]
I get this consquently with 4.0.4+ (tried latest on snaps.php.net)
This happens while unserializing, but seems to be caused by a bad serialization --
this has been tested by serializing with 4.0.1pl2 and unserializing with 4.0.4pl1 --
no problems. The other way around ofcourse crashes.
Here's the bt from the segfault
(gdb) run -X
Starting program: /home/httpd/bin/httpd -X
(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x81135cd in _zval_ptr_dtor ()
(gdb) bt
#0 0x81135cd in _zval_ptr_dtor ()
#1 0x811c9f9 in zend_hash_destroy ()
#2 0x8119158 in _zval_dtor ()
#3 0x81135e2 in _zval_ptr_dtor ()
#4 0x80fe2e9 in php_var_unserialize ()
#5 0x80ceb61 in ps_srlzr_decode_php ()
#6 0x80cf004 in ps_srlzr_decode_wddx ()
#7 0x80cf1f0 in ps_srlzr_decode_wddx ()
#8 0x80cfc14 in ps_srlzr_decode_wddx ()
#9 0x80d0c90 in php_if_session_start ()
#10 0x81464a1 in execute ()
#11 0x814c28d in execute ()
#12 0x8119fc8 in zend_execute_scripts ()
#13 0x808b788 in php_execute_script ()
#14 0x812521e in apache_php_module_main ()
#15 0x8089356 in send_php ()
#16 0x8089388 in send_parsed_php ()
#17 0x8153db3 in ap_invoke_handler ()
#18 0x81675e9 in ap_some_auth_required ()
#19 0x816764c in ap_process_request ()
#20 0x815eece in ap_child_terminate ()
#21 0x815f05c in ap_child_terminate ()
#22 0x815f1b9 in ap_child_terminate ()
#23 0x815f7e6 in ap_child_terminate ()
#24 0x815ff73 in main ()
#25 0x407669cb in __libc_start_main (main=0x815fc2c main, argc=2, argv=0xba54,
init=0x806f58c _init, fini=0x81d4a2c _fini, rtld_fini=0x4000ae60 _dl_fini,
stack_end=0xba4c) at ../sysdeps/generic/libc-start.c:92
Here's a working serialization:
!cust_id|session|O:7:"session":9:{s:16:"boolAuthenticate";b:1;s:9:"strSessID";s:0:"";s:9:"intUserID";s:1:"1";s:12:"strUserLogin";s:5:"david";s:15:"strUserPassword";s:7:"";s:11:"arrUserInfo";a:26:{i:0;s:1:"1";s:7:"cust_id";s:1:"1";i:1;s:1:"2";s:9:"cust_type";s:1:"2";i:2;s:5:"David";s:9:"cust_name";s:5:"David";i:3;s:7:"Hjortsø";s:12:"cust_surname";s:7:"Hjortsø";i:4;s:13:"[EMAIL PROTECTED]";s:10:"cust_email";s:13:"[EMAIL PROTECTED]";i:5;s:12:"+45
33179292";s:14:"cust_telephone";s:12:"+45 33179292";i:6;s:12:"+45
33179299";s:8:"cust_fax";s:12:"+45 33179299";i:7;s:27:"Frederiksberggade 26, 4
Sal";s:13:"cust_address1";s:27:"Frederiksberggade 26, 4
Sal";i:8;s:0:"";s:13:"cust_address2";s:0:"";i:9;s:12:"Copenhagen
K";s:9:"cust_city";s:12:"Copenhagen
K";i:10;s:7:"Dk-1459";s:11:"cust_postal";s:7:"Dk-1459";i:11;s:3:"050";s:12:"cust_country";s:3:"050";i:12;s:15:"Deus
ex Machina";s:12:"cust_company";s:15:"Deus ex
Machina";}s:11:"intUserType";i:2;s:13:"intUserStatus";i:0;s:9:"boolLogin";b:1;}create|O:10:"createtest":5:{s:7:"arrTest";b:0;s:11:"arrSections";a:1:{i:0;a:2:{s:10:"section_id";i:1;s:12:"section_name";s:29:"Skriv
navnet på sektionen
her";}}s:8:"arrPages";a:21:{s:10:"test_title";s:0:"";s:15:"test_short_desc";s:0:"";s:9:"test_type";s:1:"b";s:14:"test_responses";s:0:"";s:10:"test_start";s:0:"";s:8:"test_end";s:0:"";s:7:"test_fc";s:6:"Yellow";s:7:"test_bc";s:6:"Yellow";s:9:"test_desc";s:0:"";s:9:"test_link";s:0:"";s:14:"qsInternetHome";N;s:16:"qsInternetAccess";N;s:15:"qsInternetUsage";N;s:8:"qsLiving";N;s:7:"qsCivil";N;s:8:"qsGender";N;s:7:"EndYear";s:0:"";s:8:"EndMonth";s:1:"1";s:10:"StartMonth";s:1:"1";s:9:"StartYear";s:0:"";s:7:"private";N;}s:11:"intLastPage";s:1:"6";s:11:"intNrPeople";N;}arrSections|a:1:{i:0;a:2:{s:10:"section_id";i:1;s:12:"section_name";s:29:"Skriv
navnet på sektionen her";}}R:39;arrQuestions|N;arrQuestions|a:1:{i:0;s:0:"";}
And here is the segfaulting one:
!cust_id|session|O:7:"session":9:{s:16:"boolAuthenticate";b:1;s:9:"strSessID";s:0:"";s:9:"intUserID";s:1:"1";s:12:"strUserLogin";s:5:"david";s:15:"strUserPassword";s:7:"";s:11:"arrUserInfo";a:26:{i:0;s:1:"1";s:7:"cust_id";s:1:"1";i:1;s:1:"2";s:9:"cust_type";s:1:"2";i:2;s:5:"David";s:9:"cust_name";s:5:"David";i:3;s:7:"Hjortsø";s:12:"cust_surname";s:7:"Hjortsø";i:4;s:13:"[EMAIL PROTECTED]";s:10:"cust_email";s:13:"[EMAIL PROTECTED]";i:5;s:12:"+45
33179292";s:14:"cust_telephone";s:12:"+45 33179292";i:6;s:12:"+45
33179299";s:8:"cust_fax";s:12:"+45 33179299";i:7;s:27:"Frederiksberggade 26, 4
Sal";s:13:"cust_address1";s:27:"Frederiksberggade
[PHP-DEV] PHP 4.0 Bug #9111 Updated: Segmentation Fault
ID: 9111 User Update by: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: dBase related Description: Segmentation Fault Fixed in 4.0.4pl1 Previous Comments: --- [2001-02-05 09:36:04] [EMAIL PROTECTED] This happens upon dbase_create no mater what I do. (gdb) run -X Starting program: /home/httpd/bin/httpd -X (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. __libc_free (mem=0x6d706f6c) at malloc.c:3005 3005malloc.c: No such file or directory. (gdb) bt #0 __libc_free (mem=0x6d706f6c) at malloc.c:3005 #1 0x8121591 in free_dbf_head () #2 0x80923e2 in php_if_dbase_create () #3 0x813c340 in execute () #4 0x8141166 in execute () #5 0x808a75b in php_execute_script () #6 0x811bac0 in apache_php_module_main () #7 0x808850b in send_php () #8 0x808854c in send_parsed_php () #9 0x81487d3 in ap_invoke_handler () #10 0x815c009 in ap_some_auth_required () #11 0x815c06c in ap_process_request () #12 0x81538ee in ap_child_terminate () #13 0x8153a7c in ap_child_terminate () #14 0x8153bd9 in ap_child_terminate () #15 0x8154206 in ap_child_terminate () #16 0x8154993 in main () #17 0x4076d9cb in __libc_start_main (main=0x815464c main, argc=2, argv=0xba54, init=0x806e76c _init, fini=0x81c944c _fini, rtld_fini=0x4000ae60 _dl_fini, stack_end=0xba4c) at ../sysdeps/generic/libc-start.c:92 --- Full Bug description available at: http://bugs.php.net/?id=9111 -- 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] PHP 4.0 Bug #9116: PHP will stop returing anything in NES 4.1 SP1
From: [EMAIL PROTECTED] Operating system: Solaris 2.8 PHP version: 4.0.3pl1 PHP Bug Type: Scripting Engine problem Bug description: PHP will stop returing anything in NES 4.1 SP1 Is there a certain number of Global variables, or number of functions you can load with the nsapi filter and NES? I am using a function that uses many functions and many global variables. PHP works fine through the rest of the application, but this one sections just dies, no errors or anything. Apache works just fine with this application. ... -- Edit Bug report at: http://bugs.php.net/?id=9116edit=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] PHP 4.0 Bug #9034 Updated: pspell .12 fails to compile
ID: 9034 Updated by: vlad Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Pspell related Assigned To: vlad Comments: well, I got it fixed, but I can't commit until someone with authority gives me enough karma :( Probably gotta wait till tomorrow. Vlad Previous Comments: --- [2001-02-02 18:49:31] [EMAIL PROTECTED] well, I got it fixed, but I can't commit until someone with authority gives me enough karma :( Probably gotta wait till tomorrow. Vlad --- [2001-02-02 18:11:48] [EMAIL PROTECTED] actually it didn't get fixed, and neither did bug 9062 (essentially duplicate). Looks trivial though. I'll look into it right now. --- [2001-02-02 13:59:59] [EMAIL PROTECTED] Fixed in CVS. --Jani --- [2001-01-31 10:54:22] [EMAIL PROTECTED] I think some backward compatiblity was broken in this release of pspell (.12) Here is the output of make: ...snip... make[2]: Entering directory `/export/projects/zend-php/php4/ext/pspell' make[3]: Entering directory `/export/projects/zend-php/php4/ext/pspell' /bin/sh /export/projects/zend-php/php4/libtool --silent --mode=compile gcc -I. -I/export/projects/zend-php/php4/ext/pspell -I/export/projects/zend-php/php4/main -I/export/projects/zend-php/php4 -I/usr/local/etc/apache/include -I/export/projects/zend-php/php4/Zend -I/projects/compile/mck-3.2.0.4-solaris-sparc/c-api -I/usr/local/include -I/projects/compile/gd1.3 -I/export/projects/zend-php/php4/ext/mysql/libmysql -I/usr/local/include/pspell -I/export/projects/zend-php/php4/ext/xml/expat/xmltok -I/export/projects/zend-php/php4/ext/xml/expat/xmlparse -I/export/projects/zend-php/php4/TSRM -D_POSIX_PTHREAD_SEMANTICS -DSOLARIS2=270 -DMOD_SSL=206104 -DEAPI -DEAPI_MM -DUSE_EXPAT -DXML_BYTE_ORDER=21 -O -c pspell.c pspell.c: In function `php_if_pspell_check': pspell.c:304: too few arguments to function `pspell_manager_check' pspell.c: In function `php_if_pspell_suggest': pspell.c:340: too few arguments to function `pspell_manager_suggest' pspell.c: In function `php_if_pspell_store_replacement': pspell.c:377: warning: passing arg 3 of `pspell_manager_store_replacement' makes integer from pointer without a cast pspell.c:377: too few arguments to function `pspell_manager_store_replacement' pspell.c: In function `php_if_pspell_add_to_personal': pspell.c:414: too few arguments to function `pspell_manager_add_to_personal' pspell.c: In function `php_if_pspell_add_to_session': pspell.c:451: too few arguments to function `pspell_manager_add_to_session' make[3]: *** [pspell.lo] Error 1 make[3]: Leaving directory `/export/projects/zend-php/php4/ext/pspell' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/export/projects/zend-php/php4/ext/pspell' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/export/projects/zend-php/php4/ext' make: *** [all-recursive] Error 1 --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9034edit=2 -- 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] PHP 4.0 Bug #9034 Updated: pspell .12 fails to compile
ID: 9034 Updated by: vlad Reported By: [EMAIL PROTECTED] Old-Status: Assigned Status: Closed Bug Type: Pspell related Assigned To: vlad Comments: fixed Previous Comments: --- [2001-02-05 13:19:30] [EMAIL PROTECTED] well, I got it fixed, but I can't commit until someone with authority gives me enough karma :( Probably gotta wait till tomorrow. Vlad --- [2001-02-02 18:49:31] [EMAIL PROTECTED] well, I got it fixed, but I can't commit until someone with authority gives me enough karma :( Probably gotta wait till tomorrow. Vlad --- [2001-02-02 18:11:48] [EMAIL PROTECTED] actually it didn't get fixed, and neither did bug 9062 (essentially duplicate). Looks trivial though. I'll look into it right now. --- [2001-02-02 13:59:59] [EMAIL PROTECTED] Fixed in CVS. --Jani --- [2001-01-31 10:54:22] [EMAIL PROTECTED] I think some backward compatiblity was broken in this release of pspell (.12) Here is the output of make: ...snip... make[2]: Entering directory `/export/projects/zend-php/php4/ext/pspell' make[3]: Entering directory `/export/projects/zend-php/php4/ext/pspell' /bin/sh /export/projects/zend-php/php4/libtool --silent --mode=compile gcc -I. -I/export/projects/zend-php/php4/ext/pspell -I/export/projects/zend-php/php4/main -I/export/projects/zend-php/php4 -I/usr/local/etc/apache/include -I/export/projects/zend-php/php4/Zend -I/projects/compile/mck-3.2.0.4-solaris-sparc/c-api -I/usr/local/include -I/projects/compile/gd1.3 -I/export/projects/zend-php/php4/ext/mysql/libmysql -I/usr/local/include/pspell -I/export/projects/zend-php/php4/ext/xml/expat/xmltok -I/export/projects/zend-php/php4/ext/xml/expat/xmlparse -I/export/projects/zend-php/php4/TSRM -D_POSIX_PTHREAD_SEMANTICS -DSOLARIS2=270 -DMOD_SSL=206104 -DEAPI -DEAPI_MM -DUSE_EXPAT -DXML_BYTE_ORDER=21 -O -c pspell.c pspell.c: In function `php_if_pspell_check': pspell.c:304: too few arguments to function `pspell_manager_check' pspell.c: In function `php_if_pspell_suggest': pspell.c:340: too few arguments to function `pspell_manager_suggest' pspell.c: In function `php_if_pspell_store_replacement': pspell.c:377: warning: passing arg 3 of `pspell_manager_store_replacement' makes integer from pointer without a cast pspell.c:377: too few arguments to function `pspell_manager_store_replacement' pspell.c: In function `php_if_pspell_add_to_personal': pspell.c:414: too few arguments to function `pspell_manager_add_to_personal' pspell.c: In function `php_if_pspell_add_to_session': pspell.c:451: too few arguments to function `pspell_manager_add_to_session' make[3]: *** [pspell.lo] Error 1 make[3]: Leaving directory `/export/projects/zend-php/php4/ext/pspell' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/export/projects/zend-php/php4/ext/pspell' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/export/projects/zend-php/php4/ext' make: *** [all-recursive] Error 1 --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9034edit=2 -- 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] PHP 4.0 Bug #9062 Updated: Latest version, 0.12, breaks compatibility
ID: 9062 Updated by: vlad Reported By: [EMAIL PROTECTED] Old-Status: Closed Status: Duplicate Bug Type: Pspell related Assigned To: Comments: See bug# 9034 Previous Comments: --- [2001-02-02 13:58:36] [EMAIL PROTECTED] Fixed in CVS. Try latest CVS snapshot from http://snaps.php.net/ --Jani --- [2001-02-01 19:03:54] [EMAIL PROTECTED] The latest release of pspell, 0.12, on http://pspell.sourceforge.net breaks compatibility with the pspell php extension causing it to not compile correctly. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9062edit=2 -- 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 #9118: 3.0.18 bug - if (INF == INF) {} does not equal true
From: [EMAIL PROTECTED]
Operating system: Debian Linux
PHP version: 3.0.17
PHP Bug Type: Misbehaving function
Bug description: 3.0.18 bug - if ("INF" == "INF") {} does not equal true
I encountered a strange behaviour of comparing values. I've only encountered it with
a value of "INF". The following script should cause "INF" to be displayed in version
3.0.18 on Linux
?php
$arr =array(
"TEST",
"INF"
);
$cnt = sizeof($arr);
for ($x=0; $x $cnt; $x++) {
$item = $arr[$x];
if ("$item" == "$item") {
} else {
print "$itembr\n";
}
}
?
--
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] PHP 4.0 Bug #9119: JVM execution problem
From: [EMAIL PROTECTED] Operating system: Windows NT/2000 PHP version: 4.0.4pl1 PHP Bug Type: IIS related Bug description: JVM execution problem When I'm using php4isapi.dll module and trying to use the Java object, it works well only once. After that (when trying to reload a page) it corresponds an error: "Fatal error: Unable to load Java Library jvm.dll, error: The specified module could not be found. in C:\PHP\PHP\java.php on line 3". In phpinfo() function the Java path parameters (java.class.path, java.home and others) are correct after the first page loading, and are reseting to "No value" after reload. This error doesn't occur if I'm using php.exe as the script executor instead of the ISAPI module. -- Edit Bug report at: http://bugs.php.net/?id=9119edit=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] can't build latest cvs
Linking... Creating library ..\Release_TS_inline/php4ts.lib and object ..\Release_TS_inline/php4ts.exp php_mysql.obj : error LNK2001: unresolved external symbol _add_assoc_null php_mysql.obj : error LNK2001: unresolved external symbol _add_index_null php_pcre.obj : error LNK2001: unresolved external symbol _zend_is_callable scanf.obj : error LNK2001: unresolved external symbol _add_next_index_null ..\Release_TS_inline\php4ts.dll : fatal error LNK1120: 4 unresolved externals Error executing link.exe. harald. resistance is futile - nme.at -- 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] ODBC and iODBC
Gurus, Does it make sense to have the iODBC libraries as part of the standard PHP distribution? This is NOT the OpenLink driver library, but an LGPL Driver Manager. Basically, if php is compiled --with-iodbc then any ODBC API compliant ODBC driver can be used by setting the ODBCINI and ODBCINSTINI environment variables, since iODBC provides a standard ODBC binding point for PHP applications. Much of the work I've done recently to support PHP has been in getting the --with-iodbc configurations working (or --with-openlink for that matter - it's the same thing) and a default inclusion would enable greater use. Also, iODBC includes an SDK, so developers can build their own drivers to compete with OpenLink, Merant, Easysoft, etc. Is bundling/inclusion feasible? Best regards, Andrew Andrew Hill Director Technology Evangelism OpenLink Software http://www.openlinksw.com XML E-Business Infrastructure Technology Provider -- 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] [Fwd: Re: [PHP] Howto return multidimensional arraysfrom a PHP module]
I had the same problem. This is, how I managed to do this:
extern "C" int fun1(pval** array) { //this is in c++
//here you generate subarrays - alements are added to the parameter array
//this generates an array of strings
...
int count=;
for (int i=0;icount;i++) {
char* str=estrdup("Array element");
zval* arr_el;
MAKE_STD_ZVAL(arr_el);
ZVAL_STRING(arr_el,str,0);
zend_hash_next_index_insert
((*array)-value.ht,arr_el,sizeof(zval**),NULL);
}
return count;
}
/* {{{ proto array fun2() //this is in standard c
*/
PHP_FUNCTION(konf)
{
//here you generate array with array elements
...
if (array_init(return_value) == FAILURE) {
RETURN_FALSE;
}
for (...) {
zval* arr_element;
MAKE_STD_ZVAL(arr_element);
if (array_init(arr_element) == FAILURE) {
RETURN_FALSE;
}
zend_hash_next_index_insert(
return_value-value.ht,
(void*)arr_element,sizeof(zval*),
NULL);
fun1(arr_element); - now add elements
}
}
/* }}} */
It was something like that It generates two-dimensional array.
Ouuuff... It took me much of time to "develope" this...
And no guarantees ...
--
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] CVS Account Request
This is certainly one for the archives ;-) -Sterling Full name: Ingmar Heinrich Email: [EMAIL PROTECTED] ID: inki Purpose: private -- 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] PHP 4.0 Bug #9041 Updated: Extra #! at top of web output.
ID: 9041
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: *Configuration Issues
Description: Extra #! at top of web output.
The retarded thing about this is that the EXACT SAME binary works fine when Apache
calls it as a CGI. A simple /bin/sh CGI on both machines works correctly.
I'm out of clues.
Previous Comments:
---
[2001-01-31 17:52:09] [EMAIL PROTECTED]
Hello.
I'm running PHP4 as a CGI under Netscape Enterprise.
It's compiled with:
'./configure' '--prefix=/opt/php' '--with-config-file-path=/opt/php/etc'
'--disable-pear' '--enable-discard-path' '--with-mysql=no' '--enable-trans-sid'
'--with-oci8=/opt/oracle/8.1.7'
Whenever I call a .cgi that has the #!/path/to/php syntax at the top, the output
always has a '#!/path/to/php' line at the top.
--- snip
#!/opt/php/bin/php
!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN"
html
headSTYLE TYPE="text/css"!--
A { text-decoration: none; }
--- clip
My php.ini is pretty default. There's no doc_root specified when this happens.
I would think that PHP wouldn't want to include this extra line.
---
Full Bug description available at: http://bugs.php.net/?id=9041
--
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] PHP 4.0 Bug #9041 Updated: Extra #! at top of web output.
ID: 9041
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: *Configuration Issues
Assigned To:
Comments:
This is caused by the fact that the #! is not inside ?php tags and thus isnt parsed
by PHP, perhaps we can introduce a command line arg that ignores #! on the first line
of a file perhaps
php -c
I dont think there is a special case yet atleast this certainly points to the fact
there isnt.
James
Previous Comments:
---
[2001-02-05 16:12:22] [EMAIL PROTECTED]
This is caused by the fact that the #! is not inside ?php tags and thus isnt parsed
by PHP, perhaps we can introduce a command line arg that ignores #! on the first line
of a file perhaps
php -c
I dont think there is a special case yet atleast this certainly points to the fact
there isnt.
James
---
[2001-02-05 16:08:14] [EMAIL PROTECTED]
The retarded thing about this is that the EXACT SAME binary works fine when Apache
calls it as a CGI. A simple /bin/sh CGI on both machines works correctly.
I'm out of clues.
---
[2001-01-31 17:52:09] [EMAIL PROTECTED]
Hello.
I'm running PHP4 as a CGI under Netscape Enterprise.
It's compiled with:
'./configure' '--prefix=/opt/php' '--with-config-file-path=/opt/php/etc'
'--disable-pear' '--enable-discard-path' '--with-mysql=no' '--enable-trans-sid'
'--with-oci8=/opt/oracle/8.1.7'
Whenever I call a .cgi that has the #!/path/to/php syntax at the top, the output
always has a '#!/path/to/php' line at the top.
--- snip
#!/opt/php/bin/php
!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN"
html
headSTYLE TYPE="text/css"!--
A { text-decoration: none; }
--- clip
My php.ini is pretty default. There's no doc_root specified when this happens.
I would think that PHP wouldn't want to include this extra line.
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9041edit=2
--
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] PHP 4.0 Bug #9041 Updated: Extra #! at top of web output.
Actually PHP does check for #! in the first line and skips that line if
needed. It works on Linux and used to work on Solaris until 4.0.4pl1..
On Mon, 05 Feb 2001, [EMAIL PROTECTED] wrote:
ID: 9041
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: *Configuration Issues
Assigned To:
Comments:
This is caused by the fact that the #! is not inside ?php tags and thus isnt parsed
by PHP, perhaps we can introduce a command line arg that ignores #! on the first line
of a file perhaps
php -c
I dont think there is a special case yet atleast this certainly points to the fact
there isnt.
James
Previous Comments:
---
[2001-02-05 16:12:22] [EMAIL PROTECTED]
This is caused by the fact that the #! is not inside ?php tags and thus isnt parsed
by PHP, perhaps we can introduce a command line arg that ignores #! on the first line
of a file perhaps
php -c
I dont think there is a special case yet atleast this certainly points to the fact
there isnt.
James
---
[2001-02-05 16:08:14] [EMAIL PROTECTED]
The retarded thing about this is that the EXACT SAME binary works fine when Apache
calls it as a CGI. A simple /bin/sh CGI on both machines works correctly.
I'm out of clues.
---
[2001-01-31 17:52:09] [EMAIL PROTECTED]
Hello.
I'm running PHP4 as a CGI under Netscape Enterprise.
It's compiled with:
'./configure' '--prefix=/opt/php' '--with-config-file-path=/opt/php/etc'
'--disable-pear' '--enable-discard-path' '--with-mysql=no' '--enable-trans-sid'
'--with-oci8=/opt/oracle/8.1.7'
Whenever I call a .cgi that has the #!/path/to/php syntax at the top, the output
always has a '#!/path/to/php' line at the top.
--- snip
#!/opt/php/bin/php
!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN"
html
headSTYLE TYPE="text/css"!--
A { text-decoration: none; }
--- clip
My php.ini is pretty default. There's no doc_root specified when this happens.
I would think that PHP wouldn't want to include this extra line.
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9041edit=2
--
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]
-Andrei
"Everything has its wonders, even darkness and silence, and I learn,
whatever state I may be in, therein to be content." - Helen Keller
--
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] PHP 4.0 Bug #9041 Updated: Extra #! at top of web output.
ID: 9041
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Old-Status: Analyzed
Status: Open
Bug Type: *Configuration Issues
Assigned To:
Comments:
it is in there.. My bad must be somthing else..
James
Previous Comments:
---
[2001-02-05 16:12:23] [EMAIL PROTECTED]
This is caused by the fact that the #! is not inside ?php tags and thus isnt parsed
by PHP, perhaps we can introduce a command line arg that ignores #! on the first line
of a file perhaps
php -c
I dont think there is a special case yet atleast this certainly points to the fact
there isnt.
James
---
[2001-02-05 16:12:22] [EMAIL PROTECTED]
This is caused by the fact that the #! is not inside ?php tags and thus isnt parsed
by PHP, perhaps we can introduce a command line arg that ignores #! on the first line
of a file perhaps
php -c
I dont think there is a special case yet atleast this certainly points to the fact
there isnt.
James
---
[2001-02-05 16:08:14] [EMAIL PROTECTED]
The retarded thing about this is that the EXACT SAME binary works fine when Apache
calls it as a CGI. A simple /bin/sh CGI on both machines works correctly.
I'm out of clues.
---
[2001-01-31 17:52:09] [EMAIL PROTECTED]
Hello.
I'm running PHP4 as a CGI under Netscape Enterprise.
It's compiled with:
'./configure' '--prefix=/opt/php' '--with-config-file-path=/opt/php/etc'
'--disable-pear' '--enable-discard-path' '--with-mysql=no' '--enable-trans-sid'
'--with-oci8=/opt/oracle/8.1.7'
Whenever I call a .cgi that has the #!/path/to/php syntax at the top, the output
always has a '#!/path/to/php' line at the top.
--- snip
#!/opt/php/bin/php
!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN"
html
headSTYLE TYPE="text/css"!--
A { text-decoration: none; }
--- clip
My php.ini is pretty default. There's no doc_root specified when this happens.
I would think that PHP wouldn't want to include this extra line.
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9041edit=2
--
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] PHP 4.0 Bug #9041 Updated: Extra #! at top of web output.
ID: 9041
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: *Configuration Issues
Description: Extra #! at top of web output.
Here are the CGI's I'm using:
#!/opt/php/bin/php
? phpinfo(); ?
#!/bin/sh
echo Content-type: text/html\\n\\n;
echo "foo!"
Now this might not help any, but I truss'd the web server process (Netscape,
remember.) and here a few snippits output.
sh CGI.
read(23, " C o n t e n t - t y p e".., 8192)= 31
send(17, " H T T P / 1 . 1 2 0 0".., 118, 0) = 118
send(17, "\n f o o !\n", 6, 0) = 6
PHP CGI.
read(22, " X - P o w e r e d - B y".., 8192)= 5120
send(17, " H T T P / 1 . 1 2 0 0".., 146, 0) = 146
send(17, " # ! / o p t / p h p / b".., 5065, 0) = 5065
Graphic for PHP CGI page.
send(19, " H T T P / 1 . 1 2 0 0".., 146, 0) = 146
send(19, " G I F 8 9 a82\0 C\0D5FF".., 2962, 0) = 2962
I can't tell if the web server is inserting this line or if PHP is. However, when I
run these two CGIs on the command line, I never see this extra line. I guess I'm
thinking that PHP does weird shit when it's not run in a shell.
Any other information I can provide?
Previous Comments:
---
[2001-02-05 16:21:27] [EMAIL PROTECTED]
it is in there.. My bad must be somthing else..
James
---
[2001-02-05 16:12:23] [EMAIL PROTECTED]
This is caused by the fact that the #! is not inside ?php tags and thus isnt parsed
by PHP, perhaps we can introduce a command line arg that ignores #! on the first line
of a file perhaps
php -c
I dont think there is a special case yet atleast this certainly points to the fact
there isnt.
James
---
[2001-02-05 16:12:22] [EMAIL PROTECTED]
This is caused by the fact that the #! is not inside ?php tags and thus isnt parsed
by PHP, perhaps we can introduce a command line arg that ignores #! on the first line
of a file perhaps
php -c
I dont think there is a special case yet atleast this certainly points to the fact
there isnt.
James
---
[2001-02-05 16:08:14] [EMAIL PROTECTED]
The retarded thing about this is that the EXACT SAME binary works fine when Apache
calls it as a CGI. A simple /bin/sh CGI on both machines works correctly.
I'm out of clues.
---
[2001-01-31 17:52:09] [EMAIL PROTECTED]
Hello.
I'm running PHP4 as a CGI under Netscape Enterprise.
It's compiled with:
'./configure' '--prefix=/opt/php' '--with-config-file-path=/opt/php/etc'
'--disable-pear' '--enable-discard-path' '--with-mysql=no' '--enable-trans-sid'
'--with-oci8=/opt/oracle/8.1.7'
Whenever I call a .cgi that has the #!/path/to/php syntax at the top, the output
always has a '#!/path/to/php' line at the top.
--- snip
#!/opt/php/bin/php
!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN"
html
headSTYLE TYPE="text/css"!--
A { text-decoration: none; }
--- clip
My php.ini is pretty default. There's no doc_root specified when this happens.
I would think that PHP wouldn't want to include this extra line.
---
The remainder of the comments for this report are too long. To view the rest of the
comments, please view the bug report online.
Full Bug description available at: http://bugs.php.net/?id=9041
--
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] PHP 4.0 Bug #9120: unexpected behavior of chop(), ltrim(), rtrim(), and trim()
From: [EMAIL PROTECTED] Operating system: OpenBSD 2.7 PHP version: 4.0.3pl1 PHP Bug Type: Strings related Bug description: unexpected behavior of chop(), ltrim(), rtrim(), and trim() chop(), trim(), ltrim(), and rtrim() do not remove \v, \r, or \n. # chop(); echo "pprechop()"; echo "br--br"; $x = " ab cd ef \v\r\n" ; echo strlen($x) . " characters: |" . $x . "|br"; $y = chop($x); echo strlen($y) . " characters: |" . $y . "|/pre/p"; # ltrim(); echo "ppreltrim()"; echo "br--br"; $x = "\v\r\n ab cd ef " ; echo strlen($x) . " characters: |" . $x . "|br"; $y = ltrim($x); echo strlen($y) . " characters: |" . $y . "|/pre/p"; # rtrim(); echo "pprertrim()"; echo "br--br"; $x = " ab cd ef \v\r\n" ; echo strlen($x) . " characters: |" . $x . "|br"; $y = rtrim($x); echo strlen($y) . " characters: |" . $y . "|/pre/p"; # # trim(); echo "ppretrim()"; echo "br--br"; $x = " \v\r\n ab cd ef \v\r\n " ; echo strlen($x) . " characters: |" . $x . "|br"; $y = trim($x); echo " " . strlen($y) . " characters: |" . $y . "|/pre/p"; -- Edit Bug report at: http://bugs.php.net/?id=9120edit=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] PHP 4.0 Bug #9106 Updated: Floating Point and Arithmetic Exception crashes
ID: 9106 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: Reproduceable crash Description: Floating Point and Arithmetic Exception crashes the change helps, but today i managed another FPE. so there's something else to be fixed here. Previous Comments: --- [2001-02-05 04:02:51] [EMAIL PROTECTED] I have suffered from /kernel: pid 69000 (httpd), uid 99: exited on signal 8 repeatedly in any php script whose guts wind up calling rand(). The fix is supposedly fpsetmask(0) instead of the current code in zend.c, but this would only work for me if I set apache's MaxRequestsPerChild to one. As might be expected, this is because the fix, if placed in zend_startup, is effective ONLY for the first request served from that httpd (in DSO mode. CGI obviously would not care). If you place the fpsetmask(0) call at the beginning of zend_activate_modules, subsequent requests will benefit and the signal 8 crashes cease. --- Full Bug description available at: http://bugs.php.net/?id=9106 -- 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] PHP 4.0 Bug #9121: the dbase functions either segfault or generate the following debug information
From: [EMAIL PROTECTED]
Operating system: redhat 6.2
PHP version: 4.0 Latest CVS (05/02/2001)
PHP Bug Type: dBase related
Bug description: the dbase functions either segfault or generate the following debug
information
?php
?php
$dbf = dbase_open("eitmact.DBF", 0);
$numrecs = dbase_numrecords($dbf);
print "Number of records: " . $numrecs . "\n";
print "\n";
for ($i=0;$i=$numrecs;$i++) {
$row = dbase_get_record($dbf, $i);
}
?
---
dbase.c(478) : Block 0x082E20B0 status:
Beginning: OK (allocated on dbase.c:448, 9 bytes)
End: Overflown (magic=0x20202020 instead of 0x2A8FCC84)
---
dbase.c(478) : Block 0x082E20B0 status:
Beginning: OK (allocated on dbase.c:448, 9 bytes)
End: Overflown (magic=0x20202020 instead of 0x2A8FCC84)
At least 4 bytes overflown
---
[Mon Feb 5 14:07:14 2001] Script: 'test.php'
---
dbase.c(478) : Block 0x082E4968 status:
Beginning: OK (allocated on dbase.c:448, 2 bytes)
End: Overflown (magic=0x20202020 instead of 0x2A8FCC84)
At least 4 bytes overflown
---
[Mon Feb 5 14:07:14 2001] Script: 'test.php'
---
dbase.c(478) : Block 0x082E4850 status:
Beginning: OK (allocated on dbase.c:448, 1 bytes)
End: Overflown (magic=0x20202020 instead of 0x2A8FCC84)
At least 4 bytes overflown---
[Mon Feb 5 14:07:14 2001] Script: 'test.php'
---
dbase.c(478) : Block 0x082E4968 status:
Beginning: OK (allocated on dbase.c:448, 2 bytes)
End: Overflown (magic=0x20202020 instead of 0x2A8FCC84)
At least 4 bytes overflown
---
[Mon Feb 5 14:07:14 2001] Script: 'test.php'
---
dbase.c(478) : Block 0x082E4850 status:
Beginning: OK (allocated on dbase.c:448, 1 bytes)
End: Overflown (magic=0x20202020 instead of 0x2A8FCC84)
At least 4 bytes overflown
./configure \
--enable-bcmath \
--enable-wddx \
--with-xml \
--with-zlib \
--with-regex=system \
--enable-debug \
--enable-magic-quotes=yes \
--enable-force-cgi-redirect \
--with-gd=/usr/local/ \
--with-jpeg-dir=/usr/local \
--with-png-dir=/usr/local \
--enable-gd-imgstrttf=/usr/local \
--enable-memory-limit \
--with-sybase=/usr/local/freetds \
--with-config-file-path=/etc/php4/cgi \
--bindir=/usr/local/apache/cgi-bin \
--with-cpdflib=/usr/local \
--enable-ttf=/usr/local \
--enable-dbase
gdb backtrace
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `php -f t.php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libpam.so.0...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /usr/local/freetds/lib/libsybdb.so.0...done.
Reading symbols from /usr/lib/libttf.so.2...done.
Reading symbols from /usr/lib/libpng.so.2...done.
Reading symbols from /usr/lib/libjpeg.so.62...done.
Reading symbols from /lib/libresolv.so.2...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libcrypt.so.1...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /usr/lib/libz.so.1...done.
#0 chunk_alloc (ar_ptr=0x40209d60, nb=184) at malloc.c:2814
2814malloc.c: No such file or directory.
(gdb) bt
#0 chunk_alloc (ar_ptr=0x40209d60, nb=184) at malloc.c:2814
#1 0x401745ce in __libc_malloc (bytes=176) at malloc.c:2696
#2 0x4016d83b in _IO_new_fopen (filename=0x40202731 "/etc/localtime", mode=0x402027a2
"r") at iofopen.c:42
#3 0x401a5406 in __tzfile_read (file=0x40202731 "/etc/localtime", extra=0,
extrap=0x0) at tzfile.c:149
#4 0x401a43e7 in tzset_internal (always=538976104) at tzset.c:172
#5 0x401a50db in __tz_convert (timer=0xbfffe3b0, use_localtime=1, tp=0xbfffe1ac) at
tzset.c:582
#6 0x401a0cc1 in __localtime_r (t=0xbfffe3b0, tp=0xbfffe1ac) at localtime.c:33
#7 0x80693b2 in php_message_handler_for_zend (message=6, data=0x0) at main.c:557
#8 0x8113b9d in zend_message_dispatcher (message=6, data=0x0) at zend.c:551
#9 0x8103a26 in _mem_block_check (ptr=0x82bfcdc, silent=0, __zend_filename=0x81743ad
"dbase.c", __zend_lineno=478,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at zend_alloc.c:572
#10 0x8103cc4 in _mem_block_check
Re: [PHP-DEV] Accessing files on other virtual hosts (RE: [PHP-DEV] Reading memory before a variable)
Marten,
This should be fixed in the latest CVS. Thanks for reporting it with an
easily reproducible code snippet!
Zeev
At 17:55 5/2/2001, Mrten Gustafsson wrote:
Tried my snippet on a Linux box runnig PHP 4.0.4pl1 with an interesting
result; it displayed the source code for both PHP and HTML files from other
virtual hosts on the machine! Surly this should not be possible.
-Mrten.
Icq# 38863127
-Original Message-
From: Mrten Gustafsson [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 05, 2001 4:12 PM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] Reading memory "before" a variable
Using PHP 4.0.4 for Windows it is possible to access memory "before" a
variable using a negative index on a string variable.
Executing the snippet below outputs a lot of trash but alos the entire
source code of a file that is auto prepended.
?php
$str = '';
$hello = 'Hello';
for($i = 0; $i -1; $i--)
{
$str .= $hello[$i];
}
echo strrev($str);
?
-Mrten.
Icq# 38863127
--
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]
--
Zeev Suraski [EMAIL PROTECTED]
CTO co-founder, Zend Technologies Ltd. http://www.zend.com/
--
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] PHP 4.0 Bug #9122: General Instability - Access Violations and so on
From: [EMAIL PROTECTED] Operating system: Win2k + SP1 PHP version: 4.0.4pl1 PHP Bug Type: IIS related Bug description: General Instability - Access Violations and so on This is partly just another "Omygod, I'm getting access violations with IIS and PHP (ISAPI)" report, but I noticed one symptom which might be of interest. While the crashing behaviour seems to be random, PHP seems to forget what TRUE and FALSE means sometime soon before it starts to crash. This is with the 4.04pl1 Win32 binary downloaded from this site. No additional modules enabled. Very stock Win2K install with SP1. I am running all PHP applications in IIS with Application Protection set to High. When PHP goes down, I can generally stop IISADMIN, kill any remaining DLL host tasks and restart IISADMIN and continue to work. -- Edit Bug report at: http://bugs.php.net/?id=9122edit=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] PostgreSQL maintainer? Fixing problems?
Matthew Hagerty wrote: Greetings, Can someone tell me if there is a PostgreSQL maintainer? Yes. :-) (http://cvs.php.net/viewcvs.cgi/php4/EXTENSIONS?rev=1.5content-type=text/vnd.viewcvs-markup) It's Jouni. Lot's of people patch it, though, look at the CVS for it for details. Is someone working on the serious issues with pg_connect()? Looking in bugs.php.net, there's outstanding issues with duplicate pg_connect() calls, and it has a workaround: only use one connection statement. Is this what you're running into? Bug 7298 lists a possible code patch for it. -Ron -- Personal: [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/ Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/ The opinions expressed in this email are not neccesarrily those of myself, my employers, or any of the other little voices in my head. -- 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] PHP 4.0 Bug #6404 Updated: Getting HTTP 500 - Internal Servererror
ID: 6404 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Feedback Status: Closed Bug Type: PWS related Assigned To: Comments: No feedback, considered fixed in later versions. --Jani Previous Comments: --- [2001-01-06 01:22:49] [EMAIL PROTECTED] do you still experience this behavior with newer versions? --- [2000-11-01 09:18:18] [EMAIL PROTECTED] reclassified --- [2000-08-28 12:20:11] [EMAIL PROTECTED] Hello, I am using Win98 2.Ed. with PWS 4. I installed PHP 4.0.1pl2 the way you describe on your webpage and in the documentation files. My testfile only contains ? phpinfo(); ? In DOS it seems to work (printing the output into a file works fine) but when opening it through a browser I get: HTTP 500 - Internal Servererror Internet Explorer I also read your bug-reports, yet. But even solutions there couldn't help me solving this. Please help... Greetings Bjoern Bartels --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=6404edit=2 -- 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] GPG extension?
I've been considering starting work on a GPG extension for PHP, similar to the Perl GPG interface (http://gpg.sourceforge.net). Anyone working on this already? John -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- 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] #! scripts as PHP scripts
The current CGI implementation supports a different way of running PHP scripts as if they were executables, using #!/usr/local/bin/php style header. The current implementation also inconsistently handles files of that format that are executed as regular PHP scripts (i.e., under the Apache module, or even when running through the PHP CGI under a Web server). In most circumstances, the CGI implementation will 'swallow' the first line if it begins with #. That's despite the fact that inside the context of a CGI (cgi=1), this line is pretty much meaningless, and worse, it's quite legitimate to have a file begin with #... In one case only (if the startup code couldn't determine which file to open, and reverts to argv0), then it will actually treat this line properly and display it as regular output. In my opinion - if people want to run such files as CGI's, they should be using .cgi extension and +x them, and not run them through the php.exe CGI as .php files. At any rate, we need to decide which of the two behaviors is correct, because right now, both are possible (Netscape Server appears to be one of the only servers that display the rare case, in which this line is not swallowed and displayed as regular text). Other opinions..? Zeev -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- 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] #! scripts as PHP scripts
At 02:31 AM 2/6/01 +0200, Zeev Suraski wrote: In my opinion - if people want to run such files as CGI's, they should be using .cgi extension and +x them, and not run them through the php.exe CGI as .php files. At any rate, we need to decide which of the two behaviors is correct, because right now, both are possible (Netscape Server appears to be one of the only servers that display the rare case, in which this line is not swallowed and displayed as regular text). Other opinions..? Until 4.0.4pl1, I've never had a problem with running scripts that had #!/usr/local/bin/php as the first line. I could do: php -q foo.php or: ./foo.php (after chmod +x) And it worked - and still works on Linux. Solaris is a different matter, though... -Andrei -- 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] #! scripts as PHP scripts
At 02:36 6/2/2001, Andrei Zmievski wrote: At 02:31 AM 2/6/01 +0200, Zeev Suraski wrote: In my opinion - if people want to run such files as CGI's, they should be using .cgi extension and +x them, and not run them through the php.exe CGI as .php files. At any rate, we need to decide which of the two behaviors is correct, because right now, both are possible (Netscape Server appears to be one of the only servers that display the rare case, in which this line is not swallowed and displayed as regular text). Other opinions..? Until 4.0.4pl1, I've never had a problem with running scripts that had #!/usr/local/bin/php as the first line. I could do: php -q foo.php or: ./foo.php (after chmod +x) And it worked - and still works on Linux. Solaris is a different matter, though... As I said, in most cases it will swallow that line, even when (IMHO) it's not supposed to, like in the former case you describe (the way it is essentially means that you can't have a file that begins with #, no biggy, but still weird). In one exception (when it can't figure out the filepath from the environment and reverts to argv0), it doesn't check for this # line, and thus, will spit it out as regular output if it's there (look at cgi_main.c, around line 720). Generally, I think the right solution would be making only ./foo.php (after chmod +x) work. php -q foo.php shouldn't treat foo.php as if it was a shell script. This solution has two major drawbacks: - It might break people's setups. - It's not very easy (and perhaps not possible) to detect in which mode we are. We determine whether we're in CGI or not by looking at the environment variables, but those will be around even if we're running as an #! executable, as long as we're running as a CGI... Unless someone has a bright idea as to how to deal with it, I think the best thing to do would be fixing the inconsistent case to be consistent with the other cases, even if this whole behavior is a bit wrong... Zeev -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- 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] PHP 4.0 Bug #9123: Multiple pg_connect or a pg_connect with multiple pg_pconnects breaks
From: [EMAIL PROTECTED] Operating system: Linux 2.2.18 PHP version: 4.0.4pl1 PHP Bug Type: PostgreSQL related Bug description: Multiple pg_connect or a pg_connect with multiple pg_pconnects breaks First off... none of these problems existed with 4.0.2 Multiple pg_pconnect per page works fine Multiple pg_connect per page fails with an invalid link resource error. a SINGLE pg_connect with multiple pg_pconnect fails with same error. There error is reported upon accessing a pg_connect'ed connection (NOT the pg_pconnect) and looks as follows Warning: 5 is not a valid PostgreSQL link resource in Joe -- Edit Bug report at: http://bugs.php.net/?id=9123edit=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]
