#33709 [Opn->Bgs]: Problems with mail and str_replace

2005-07-14 Thread tony2001
 ID:   33709
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jjohnson at salesteamautomation dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Mail related
 Operating System: Windows XP
 PHP Version:  4.4.0
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

Works just fine here. Ask somewhere else what's wrong with your "HTML".


Previous Comments:


[2005-07-15 01:34:42] jjohnson at salesteamautomation dot com

This is also a problem with version 4.4.0.



[2005-07-15 01:00:47] jjohnson at salesteamautomation dot com

Just a note on the above comment.  str_replace is what causes corrupted
emails.  The content looks fine on the sender end, but the receiver end
has problems.



[2005-07-15 00:58:58] jjohnson at salesteamautomation dot com

Here's the shortest script I can create to replicate the bug.  The code
is not that long, but it seems to be dependent on the data.  I shortened
the data as much as I could.

$breaks = '

·
Phone only - $1,300 per
year 
·
Both - $1,500 per
year 

';
$works = '

·
Phone only - $1,300 per
year 
·
Both - $1,500 per
year 

';
$breaks = str_replace("\n",'',$breaks);
$header = "MIME-Version: 1.0\nContent-Type: text/html;
charset=iso-8859-1\n";
$result = mail("[EMAIL PROTECTED]", 'breaks', $breaks,
$header, '');
$result = mail("[EMAIL PROTECTED]", 'works', $works,
$header, '');



[2005-07-14 23:59:10] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.

Please provide a *short* and *readable* reproduce script. Thanks.



[2005-07-14 23:51:36] jjohnson at salesteamautomation dot com

Description:

We're having a problem with mail and str_replace.  If we use
str_replace on certain emails before sending them, we get extra
characters in the email that is sent.  Right before sending, the email
looks fine.  When it is received, however, it has extra characters.  If
str_replace is not used, the received email does not have extra
characters.

Reproduce code:
---
$content_template = '·
Web only - $1,100 per
year 
·
Phone only - $1,300 per
year 
·
Both - $1,500 per
year 
*There is a one time set-up fee of $499 which we
will waive with a three year agreement.';
$content = "· Web only - $1,100 per year ".
"· Phone only - $1,300 per year ".
"· Both - $1,500 per year ".
"*There is a one time set-up fee of $499 which we will waive with a
three
year agreement. ";
class EmailTest{
function EmailTest($email_from, $email_to, $subject,
$content_template, $content){
$this->email_from   = $email_from;
$this->email_to = $email_to;
$this->subject  = $subject;
$this->content  = $content;
$this->content_template = $content_template;
}
}
$email =& new EmailTest( "[EMAIL PROTECTED]",
"[EMAIL PROTECTED]", "SilentWhistle Follow-up",
$content_template, $content);
$email->content_template =
str_replace("\n",'',$email->content_template);
$email->content = str_replace('', '', $email->content_template);
$email->content = $email->content_template;
$header = "MIME-Version: 1.0\nContent-Type: text/html;
charset=iso-8859-1\n";
$result = mail($email->email_to, $email->subject, $email->content,
$header, '');

Expected result:

This is the expected email:

· Web only - $1,100 per year 
· Phone only - $1,300 per year 
· Both - $1,500 per year 
*There is a one time set-up fee of $499 which we will waive with a
three year agreement.

This is the html from the expected email:

·
Web only - $1,100 per
year 
·
Phone only - $1,300 per
year 
·
Both - $1,500 per
year 
*There is a one time set-up fee of $499 which we
will waive with a three year 

#33707 [Asn]: Errors in select statements not reported

2005-07-14 Thread tony2001
 ID:   33707
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mangst at inventec dot ch
 Status:   Assigned
 Bug Type: PDO related
 Operating System: Windows 2000
 PHP Version:  5CVS-2005-07-14 (dev)
 Assigned To:  wez
 New Comment:

>I don't view this as a bug. 
You can't reproduce it? I can.

>We report errors when the driver tells us there are errors;
> PDO isn't doing anything wrong, per se.
But there was an error, it's just hidden.
This code works fine:
prepare('select blah from dual');
$rs = $st->execute();

var_dump($rs);
var_dump($st->errorInfo());
?>

And this doesn't (only with OCI):
query('select blah from dual');

var_dump($rs);
var_dump($db->errorInfo());
?>
This happens because with MySQL it fails on prepare stage, but OCI
passes prepare and fails only while executing the statement, so the
error goes to the statement handle. 


Previous Comments:


[2005-07-14 23:58:04] [EMAIL PROTECTED]

I don't view this as a bug.  We report errors when the driver tells us
there are errors; PDO isn't doing anything wrong, per se.

I also don't see how copying the errors up from the statement to the
dbh when execute() is called will help either.




[2005-07-14 23:37:35] [EMAIL PROTECTED]

That happens because Oracle's OCIStmtPrepare() doesn't validate the
query, it just allocates/prepares stmt handle for execution. Then PDO
happily executes this statement and all errors go to the stmt handle
(which is destroyed right after that).
Wez, from what I can see, with OCI we should always copy einfo struct
from the stmt handle to the dbh handle if stmt's execution failed.
Thoughts?



[2005-07-14 22:07:02] mangst at inventec dot ch

Description:

When a SQL statement is executed with PDO::query, PDO::errorInfo[0]
always reports "0" even when an error has occurred and PDO::query
returned .

Reproduce code:
---
getMessage());
}
$rs = $db->query('select nvarchar(8) from dual');
echo 'Statement handle: ';
var_dump($rs);
echo "\r\nError info of database handle: ";
var_dump($db->errorInfo());
$db = null;
?>

Expected result:

Somthing like:
Statement handle: bool(false)
Error info of database handle: array(1) { [0]=> string(5) "42000" [1]=>
"" [2]=> string(x) "ORA-00904: "NVARCHAR": invalid identifier"}

Actual result:
--
Statement handle: bool(false)
Error info of database handle: array(1) { [0]=> string(5) "0" }





-- 
Edit this bug report at http://bugs.php.net/?id=33707&edit=1


#33709 [Opn]: Problems with mail and str_replace

2005-07-14 Thread jjohnson at salesteamautomation dot com
 ID:   33709
 User updated by:  jjohnson at salesteamautomation dot com
 Reported By:  jjohnson at salesteamautomation dot com
 Status:   Open
 Bug Type: Mail related
 Operating System: Windows XP
-PHP Version:  4.3.11
+PHP Version:  4.4.0
 New Comment:

This is also a problem with version 4.4.0.


Previous Comments:


[2005-07-15 01:00:47] jjohnson at salesteamautomation dot com

Just a note on the above comment.  str_replace is what causes corrupted
emails.  The content looks fine on the sender end, but the receiver end
has problems.



[2005-07-15 00:58:58] jjohnson at salesteamautomation dot com

Here's the shortest script I can create to replicate the bug.  The code
is not that long, but it seems to be dependent on the data.  I shortened
the data as much as I could.

$breaks = '

·
Phone only - $1,300 per
year 
·
Both - $1,500 per
year 

';
$works = '

·
Phone only - $1,300 per
year 
·
Both - $1,500 per
year 

';
$breaks = str_replace("\n",'',$breaks);
$header = "MIME-Version: 1.0\nContent-Type: text/html;
charset=iso-8859-1\n";
$result = mail("[EMAIL PROTECTED]", 'breaks', $breaks,
$header, '');
$result = mail("[EMAIL PROTECTED]", 'works', $works,
$header, '');



[2005-07-14 23:59:10] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.

Please provide a *short* and *readable* reproduce script. Thanks.



[2005-07-14 23:51:36] jjohnson at salesteamautomation dot com

Description:

We're having a problem with mail and str_replace.  If we use
str_replace on certain emails before sending them, we get extra
characters in the email that is sent.  Right before sending, the email
looks fine.  When it is received, however, it has extra characters.  If
str_replace is not used, the received email does not have extra
characters.

Reproduce code:
---
$content_template = '·
Web only - $1,100 per
year 
·
Phone only - $1,300 per
year 
·
Both - $1,500 per
year 
*There is a one time set-up fee of $499 which we
will waive with a three year agreement.';
$content = "· Web only - $1,100 per year ".
"· Phone only - $1,300 per year ".
"· Both - $1,500 per year ".
"*There is a one time set-up fee of $499 which we will waive with a
three
year agreement. ";
class EmailTest{
function EmailTest($email_from, $email_to, $subject,
$content_template, $content){
$this->email_from   = $email_from;
$this->email_to = $email_to;
$this->subject  = $subject;
$this->content  = $content;
$this->content_template = $content_template;
}
}
$email =& new EmailTest( "[EMAIL PROTECTED]",
"[EMAIL PROTECTED]", "SilentWhistle Follow-up",
$content_template, $content);
$email->content_template =
str_replace("\n",'',$email->content_template);
$email->content = str_replace('', '', $email->content_template);
$email->content = $email->content_template;
$header = "MIME-Version: 1.0\nContent-Type: text/html;
charset=iso-8859-1\n";
$result = mail($email->email_to, $email->subject, $email->content,
$header, '');

Expected result:

This is the expected email:

· Web only - $1,100 per year 
· Phone only - $1,300 per year 
· Both - $1,500 per year 
*There is a one time set-up fee of $499 which we will waive with a
three year agreement.

This is the html from the expected email:

·
Web only - $1,100 per
year 
·
Phone only - $1,300 per
year 
·
Both - $1,500 per
year 
*There is a one time set-up fee of $499 which we
will waive with a three year agreement.

Actual result:
--
This is the received email:

· Web only - $1,100 per year 
·  ;Phone only - $1,300 per year 
· Both - $1,500 per year 
*There is a one time set-up fee of $499 which we will waive with a
three year agreement. 

This is the html from the received email:

·
Web only - $1,100 per
year 
· 
 ;   
Phone only - $1,300 per
year 
·
Both - $1,500 per
year 
*There is a one time set-up fee of $499 which we
will waive with a three year agreement.






-- 
Edit this bug report at http://b

#33709 [Opn]: Problems with mail and str_replace

2005-07-14 Thread jjohnson at salesteamautomation dot com
 ID:   33709
 User updated by:  jjohnson at salesteamautomation dot com
 Reported By:  jjohnson at salesteamautomation dot com
 Status:   Open
 Bug Type: Mail related
 Operating System: Windows XP
 PHP Version:  4.3.11
 New Comment:

Just a note on the above comment.  str_replace is what causes corrupted
emails.  The content looks fine on the sender end, but the receiver end
has problems.


Previous Comments:


[2005-07-15 00:58:58] jjohnson at salesteamautomation dot com

Here's the shortest script I can create to replicate the bug.  The code
is not that long, but it seems to be dependent on the data.  I shortened
the data as much as I could.

$breaks = '

·
Phone only - $1,300 per
year 
·
Both - $1,500 per
year 

';
$works = '

·
Phone only - $1,300 per
year 
·
Both - $1,500 per
year 

';
$breaks = str_replace("\n",'',$breaks);
$header = "MIME-Version: 1.0\nContent-Type: text/html;
charset=iso-8859-1\n";
$result = mail("[EMAIL PROTECTED]", 'breaks', $breaks,
$header, '');
$result = mail("[EMAIL PROTECTED]", 'works', $works,
$header, '');



[2005-07-14 23:59:10] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.

Please provide a *short* and *readable* reproduce script. Thanks.



[2005-07-14 23:51:36] jjohnson at salesteamautomation dot com

Description:

We're having a problem with mail and str_replace.  If we use
str_replace on certain emails before sending them, we get extra
characters in the email that is sent.  Right before sending, the email
looks fine.  When it is received, however, it has extra characters.  If
str_replace is not used, the received email does not have extra
characters.

Reproduce code:
---
$content_template = '·
Web only - $1,100 per
year 
·
Phone only - $1,300 per
year 
·
Both - $1,500 per
year 
*There is a one time set-up fee of $499 which we
will waive with a three year agreement.';
$content = "· Web only - $1,100 per year ".
"· Phone only - $1,300 per year ".
"· Both - $1,500 per year ".
"*There is a one time set-up fee of $499 which we will waive with a
three
year agreement. ";
class EmailTest{
function EmailTest($email_from, $email_to, $subject,
$content_template, $content){
$this->email_from   = $email_from;
$this->email_to = $email_to;
$this->subject  = $subject;
$this->content  = $content;
$this->content_template = $content_template;
}
}
$email =& new EmailTest( "[EMAIL PROTECTED]",
"[EMAIL PROTECTED]", "SilentWhistle Follow-up",
$content_template, $content);
$email->content_template =
str_replace("\n",'',$email->content_template);
$email->content = str_replace('', '', $email->content_template);
$email->content = $email->content_template;
$header = "MIME-Version: 1.0\nContent-Type: text/html;
charset=iso-8859-1\n";
$result = mail($email->email_to, $email->subject, $email->content,
$header, '');

Expected result:

This is the expected email:

· Web only - $1,100 per year 
· Phone only - $1,300 per year 
· Both - $1,500 per year 
*There is a one time set-up fee of $499 which we will waive with a
three year agreement.

This is the html from the expected email:

·
Web only - $1,100 per
year 
·
Phone only - $1,300 per
year 
·
Both - $1,500 per
year 
*There is a one time set-up fee of $499 which we
will waive with a three year agreement.

Actual result:
--
This is the received email:

· Web only - $1,100 per year 
·  ;Phone only - $1,300 per year 
· Both - $1,500 per year 
*There is a one time set-up fee of $499 which we will waive with a
three year agreement. 

This is the html from the received email:

·
Web only - $1,100 per
year 
· 
 ;   
Phone only - $1,300 per
year 
·
Both - $1,500 per
year 
*There is a one time set-up fee of $499 which we
will waive with a three year agreement.






-- 
Edit this bug report at http://bugs.php.net/?id=33709&edit=1


#33709 [Fbk->Opn]: Problems with mail and str_replace

2005-07-14 Thread jjohnson at salesteamautomation dot com
 ID:   33709
 User updated by:  jjohnson at salesteamautomation dot com
 Reported By:  jjohnson at salesteamautomation dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Mail related
 Operating System: Windows XP
 PHP Version:  4.3.11
 New Comment:

Here's the shortest script I can create to replicate the bug.  The code
is not that long, but it seems to be dependent on the data.  I shortened
the data as much as I could.

$breaks = '

·
Phone only - $1,300 per
year 
·
Both - $1,500 per
year 

';
$works = '

·
Phone only - $1,300 per
year 
·
Both - $1,500 per
year 

';
$breaks = str_replace("\n",'',$breaks);
$header = "MIME-Version: 1.0\nContent-Type: text/html;
charset=iso-8859-1\n";
$result = mail("[EMAIL PROTECTED]", 'breaks', $breaks,
$header, '');
$result = mail("[EMAIL PROTECTED]", 'works', $works,
$header, '');


Previous Comments:


[2005-07-14 23:59:10] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.

Please provide a *short* and *readable* reproduce script. Thanks.



[2005-07-14 23:51:36] jjohnson at salesteamautomation dot com

Description:

We're having a problem with mail and str_replace.  If we use
str_replace on certain emails before sending them, we get extra
characters in the email that is sent.  Right before sending, the email
looks fine.  When it is received, however, it has extra characters.  If
str_replace is not used, the received email does not have extra
characters.

Reproduce code:
---
$content_template = '·
Web only - $1,100 per
year 
·
Phone only - $1,300 per
year 
·
Both - $1,500 per
year 
*There is a one time set-up fee of $499 which we
will waive with a three year agreement.';
$content = "· Web only - $1,100 per year ".
"· Phone only - $1,300 per year ".
"· Both - $1,500 per year ".
"*There is a one time set-up fee of $499 which we will waive with a
three
year agreement. ";
class EmailTest{
function EmailTest($email_from, $email_to, $subject,
$content_template, $content){
$this->email_from   = $email_from;
$this->email_to = $email_to;
$this->subject  = $subject;
$this->content  = $content;
$this->content_template = $content_template;
}
}
$email =& new EmailTest( "[EMAIL PROTECTED]",
"[EMAIL PROTECTED]", "SilentWhistle Follow-up",
$content_template, $content);
$email->content_template =
str_replace("\n",'',$email->content_template);
$email->content = str_replace('', '', $email->content_template);
$email->content = $email->content_template;
$header = "MIME-Version: 1.0\nContent-Type: text/html;
charset=iso-8859-1\n";
$result = mail($email->email_to, $email->subject, $email->content,
$header, '');

Expected result:

This is the expected email:

· Web only - $1,100 per year 
· Phone only - $1,300 per year 
· Both - $1,500 per year 
*There is a one time set-up fee of $499 which we will waive with a
three year agreement.

This is the html from the expected email:

·
Web only - $1,100 per
year 
·
Phone only - $1,300 per
year 
·
Both - $1,500 per
year 
*There is a one time set-up fee of $499 which we
will waive with a three year agreement.

Actual result:
--
This is the received email:

· Web only - $1,100 per year 
·  ;Phone only - $1,300 per year 
· Both - $1,500 per year 
*There is a one time set-up fee of $499 which we will waive with a
three year agreement. 

This is the html from the received email:

·
Web only - $1,100 per
year 
· 
 ;   
Phone only - $1,300 per
year 
·
Both - $1,500 per
year 
*There is a one time set-up fee of $499 which we
will waive with a three year agreement.






-- 
Edit this bug report at http://bugs.php.net/?id=33709&edit=1


#33533 [Fbk->Opn]: PDO_ODBC: Segmentation Fault with selecting informix text column

2005-07-14 Thread scott dot barnett at thuringowa dot qld dot gov dot au
 ID:   33533
 User updated by:  scott dot barnett at thuringowa dot qld dot gov dot au
 Reported By:  scott dot barnett at thuringowa dot qld dot gov dot au
-Status:   Feedback
+Status:   Open
 Bug Type: PDO related
 Operating System: CentOS 4.1 / Redhat Enterprise 4
 PHP Version:  5CVS-2005-07-04
 New Comment:

Program received signal SIGSEGV, Segmentation fault.
0x0060f7a2 in ?? () from /lib/ld-linux.so.2
(gdb) bt
#0  0x0060f7a2 in ?? () from /lib/ld-linux.so.2
#1  0x0064fc76 in kill () from /lib/tls/libc.so.6
#2  0x00ec4f14 in _emalloc (size=2147483648, __zend_filename=0xf5c5b4
"/usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c",
__zend_lineno=393, __zend_orig_filename=0x0,
__zend_orig_lineno=0) at
/usr/src/apache/php5-200507122030/Zend/zend_alloc.c:191
#3  0x00d58c90 in odbc_stmt_describe (stmt=0x9979184, colno=1) at
/usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c:393
#4  0x00d5140c in pdo_stmt_describe_columns (stmt=0x9979184) at
/usr/src/apache/php5-200507122030/ext/pdo/pdo_stmt.c:168
#5  0x00d508c3 in zif_PDO_query (ht=2, return_value=0x9916b9c,
return_value_ptr=0x0, this_ptr=0x99169f4, return_value_used=1) at
/usr/src/apache/php5-200507122030/ext/pdo/pdo_dbh.c:912
#6  0x00f03eaa in zend_do_fcall_common_helper_SPEC
(execute_data=0xbffa4390) at
/usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:184
#7  0x00f04713 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xbffa4390) at
/usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:299
#8  0x00f03b8b in execute (op_array=0x9911b04) at
/usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:87
#9  0x00edd699 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/apache/php5-200507122030/Zend/zend.c:1087
#10 0x00e9c995 in php_execute_script (primary_file=0xbffa6710) at
/usr/src/apache/php5-200507122030/main/main.c:1672
#11 0x00f48616 in php_handler (r=0x9902bf8) at
/usr/src/apache/php5-200507122030/sapi/apache2handler/sapi_apache2.c:555
#12 0x0809953a in ap_run_handler (r=0x9902bf8) at config.c:152
#13 0x08099905 in ap_invoke_handler (r=0x9902bf8) at config.c:364
#14 0x0808255d in ap_process_request (r=0x9902bf8) at
http_request.c:249
#15 0x0807e225 in ap_process_http_connection (c=0x98fc960) at
http_core.c:251
#16 0x080a2a02 in ap_run_process_connection (c=0x98fc960) at
connection.c:43
#17 0x08097d15 in child_main (child_num_arg=0) at prefork.c:610
#18 0x08097f09 in make_child (s=0x9791a08, slot=0) at prefork.c:650
#19 0x08097fd0 in startup_children (number_to_start=5) at
prefork.c:722
#20 0x080986a3 in ap_mpm_run (_pconf=0xbffa6a60, plog=0x97c6190,
s=0xbffa6a64) at prefork.c:941
#21 0x0809d7a3 in main (argc=2, argv=0xbffa6c04) at main.c:618
(gdb) f 3
#3  0x00d58c90 in odbc_stmt_describe (stmt=0x9979184, colno=1) at
/usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c:393
393 S->cols[colno].data = emalloc(colsize+1);
(gdb) p *col
$1 = {name = 0x99751d4 "textcol", namelen = 7, maxlen = 2147483647,
param_type = PDO_PARAM_NULL, precision = 0, dbdo_data = 0x0}


Previous Comments:


[2005-07-14 10:23:45] [EMAIL PROTECTED]

Thanks. Could you also do this:
---

bt
f 3
p *col
---
And paste the output here. 
Thanks in advance.



[2005-07-14 01:21:08] scott dot barnett at thuringowa dot qld dot gov
dot au

#0  0x0060f7a2 in ?? () from /lib/ld-linux.so.2
#1  0x0064fc76 in kill () from /lib/tls/libc.so.6
#2  0x00ec4f14 in _emalloc (size=2147483648,
__zend_filename=0xf5c5b4
"/usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c",
__zend_lineno=393, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at /usr/src/apache/php5-200507122030/Zend/zend_alloc.c:191
#3  0x00d58c90 in odbc_stmt_describe (stmt=0x8c2a244, colno=1)
at /usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c:393
#4  0x00d5140c in pdo_stmt_describe_columns (stmt=0x8c2a244)
at /usr/src/apache/php5-200507122030/ext/pdo/pdo_stmt.c:168
#5  0x00d508c3 in zif_PDO_query (ht=2, return_value=0x8bc7c7c,
return_value_ptr=0x0,
this_ptr=0x8bc7ad4, return_value_used=1)
at /usr/src/apache/php5-200507122030/ext/pdo/pdo_dbh.c:912
#6  0x00f03eaa in zend_do_fcall_common_helper_SPEC
(execute_data=0xbff8a6e0)
at /usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:184
#7  0x00f04713 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xbff8a6e0)
at /usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:299
#8  0x00f03b8b in execute (op_array=0x8bc2bbc)
at /usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:87
#9  0x00edd699 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/src/apache/php5-200507122030/Zend/zend.c:1087
#10 0x00e9c995 in php_execute_script (primary_file=0xbff8ca60)
at /usr/src/apache/php5-200507122030/main/main.c:1672
#11 0x00f48616 in php_handler (r=0x8b

#33709 [Opn->Fbk]: Problems with mail and str_replace

2005-07-14 Thread tony2001
 ID:   33709
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jjohnson at salesteamautomation dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Mail related
 Operating System: Windows XP
 PHP Version:  4.3.11
 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.

Please provide a *short* and *readable* reproduce script. Thanks.


Previous Comments:


[2005-07-14 23:51:36] jjohnson at salesteamautomation dot com

Description:

We're having a problem with mail and str_replace.  If we use
str_replace on certain emails before sending them, we get extra
characters in the email that is sent.  Right before sending, the email
looks fine.  When it is received, however, it has extra characters.  If
str_replace is not used, the received email does not have extra
characters.

Reproduce code:
---
$content_template = '·
Web only - $1,100 per
year 
·
Phone only - $1,300 per
year 
·
Both - $1,500 per
year 
*There is a one time set-up fee of $499 which we
will waive with a three year agreement.';
$content = "· Web only - $1,100 per year ".
"· Phone only - $1,300 per year ".
"· Both - $1,500 per year ".
"*There is a one time set-up fee of $499 which we will waive with a
three
year agreement. ";
class EmailTest{
function EmailTest($email_from, $email_to, $subject,
$content_template, $content){
$this->email_from   = $email_from;
$this->email_to = $email_to;
$this->subject  = $subject;
$this->content  = $content;
$this->content_template = $content_template;
}
}
$email =& new EmailTest( "[EMAIL PROTECTED]",
"[EMAIL PROTECTED]", "SilentWhistle Follow-up",
$content_template, $content);
$email->content_template =
str_replace("\n",'',$email->content_template);
$email->content = str_replace('', '', $email->content_template);
$email->content = $email->content_template;
$header = "MIME-Version: 1.0\nContent-Type: text/html;
charset=iso-8859-1\n";
$result = mail($email->email_to, $email->subject, $email->content,
$header, '');

Expected result:

This is the expected email:

· Web only - $1,100 per year 
· Phone only - $1,300 per year 
· Both - $1,500 per year 
*There is a one time set-up fee of $499 which we will waive with a
three year agreement.

This is the html from the expected email:

·
Web only - $1,100 per
year 
·
Phone only - $1,300 per
year 
·
Both - $1,500 per
year 
*There is a one time set-up fee of $499 which we
will waive with a three year agreement.

Actual result:
--
This is the received email:

· Web only - $1,100 per year 
·  ;Phone only - $1,300 per year 
· Both - $1,500 per year 
*There is a one time set-up fee of $499 which we will waive with a
three year agreement. 

This is the html from the received email:

·
Web only - $1,100 per
year 
· 
 ;   
Phone only - $1,300 per
year 
·
Both - $1,500 per
year 
*There is a one time set-up fee of $499 which we
will waive with a three year agreement.






-- 
Edit this bug report at http://bugs.php.net/?id=33709&edit=1


#33707 [Asn]: Errors in select statements not reported

2005-07-14 Thread wez
 ID:   33707
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mangst at inventec dot ch
 Status:   Assigned
 Bug Type: PDO related
 Operating System: Windows 2000
 PHP Version:  5CVS-2005-07-14 (dev)
 Assigned To:  wez
 New Comment:

I don't view this as a bug.  We report errors when the driver tells us
there are errors; PDO isn't doing anything wrong, per se.

I also don't see how copying the errors up from the statement to the
dbh when execute() is called will help either.



Previous Comments:


[2005-07-14 23:37:35] [EMAIL PROTECTED]

That happens because Oracle's OCIStmtPrepare() doesn't validate the
query, it just allocates/prepares stmt handle for execution. Then PDO
happily executes this statement and all errors go to the stmt handle
(which is destroyed right after that).
Wez, from what I can see, with OCI we should always copy einfo struct
from the stmt handle to the dbh handle if stmt's execution failed.
Thoughts?



[2005-07-14 22:07:02] mangst at inventec dot ch

Description:

When a SQL statement is executed with PDO::query, PDO::errorInfo[0]
always reports "0" even when an error has occurred and PDO::query
returned .

Reproduce code:
---
getMessage());
}
$rs = $db->query('select nvarchar(8) from dual');
echo 'Statement handle: ';
var_dump($rs);
echo "\r\nError info of database handle: ";
var_dump($db->errorInfo());
$db = null;
?>

Expected result:

Somthing like:
Statement handle: bool(false)
Error info of database handle: array(1) { [0]=> string(5) "42000" [1]=>
"" [2]=> string(x) "ORA-00904: "NVARCHAR": invalid identifier"}

Actual result:
--
Statement handle: bool(false)
Error info of database handle: array(1) { [0]=> string(5) "0" }





-- 
Edit this bug report at http://bugs.php.net/?id=33707&edit=1


#33709 [NEW]: Problems with mail and str_replace

2005-07-14 Thread jjohnson at salesteamautomation dot com
From: jjohnson at salesteamautomation dot com
Operating system: Windows XP
PHP version:  4.3.11
PHP Bug Type: Mail related
Bug description:  Problems with mail and str_replace

Description:

We're having a problem with mail and str_replace.  If we use str_replace
on certain emails before sending them, we get extra characters in the
email that is sent.  Right before sending, the email looks fine.  When it
is received, however, it has extra characters.  If str_replace is not
used, the received email does not have extra characters.

Reproduce code:
---
$content_template = '·
Web only - $1,100 per
year 
·
Phone only - $1,300 per
year 
·
Both - $1,500 per year

*There is a one time set-up fee of $499 which we will
waive with a three year agreement.';
$content = "· Web only - $1,100 per year ".
"· Phone only - $1,300 per year ".
"· Both - $1,500 per year ".
"*There is a one time set-up fee of $499 which we will waive with a three
year agreement. ";
class EmailTest{
function EmailTest($email_from, $email_to, $subject, $content_template,
$content){
$this->email_from   = $email_from;
$this->email_to = $email_to;
$this->subject  = $subject;
$this->content  = $content;
$this->content_template = $content_template;
}
}
$email =& new EmailTest( "[EMAIL PROTECTED]",
"[EMAIL PROTECTED]", "SilentWhistle Follow-up",
$content_template, $content);
$email->content_template = str_replace("\n",'',$email->content_template);
$email->content = str_replace('', '', $email->content_template);
$email->content = $email->content_template;
$header = "MIME-Version: 1.0\nContent-Type: text/html;
charset=iso-8859-1\n";
$result = mail($email->email_to, $email->subject, $email->content,
$header, '');

Expected result:

This is the expected email:

· Web only - $1,100 per year 
· Phone only - $1,300 per year 
· Both - $1,500 per year 
*There is a one time set-up fee of $499 which we will waive with a three
year agreement.

This is the html from the expected email:

·
Web only - $1,100 per
year 
·
Phone only - $1,300 per
year 
·
Both - $1,500 per year

*There is a one time set-up fee of $499 which we will
waive with a three year agreement.

Actual result:
--
This is the received email:

· Web only - $1,100 per year 
·  ;Phone only - $1,300 per year 
· Both - $1,500 per year 
*There is a one time set-up fee of $499 which we will waive with a three
year agreement. 

This is the html from the received email:

·
Web only - $1,100 per
year 
· 
 ;   
Phone only - $1,300 per
year 
·
Both - $1,500 per year

*There is a one time set-up fee of $499 which we will
waive with a three year agreement.


-- 
Edit bug report at http://bugs.php.net/?id=33709&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=33709&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=33709&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=33709&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33709&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33709&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=33709&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=33709&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=33709&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33709&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=33709&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=33709&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=33709&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33709&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=33709&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33709&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=33709&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33709&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=33709&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=33709&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=33709&r=mysqlcfg


#33697 [Opn->Fbk]: segfault on dump_mem

2005-07-14 Thread tony2001
 ID:   33697
 Updated by:   [EMAIL PROTECTED]
 Reported By:  pavlomt at hotmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: DOM XML related
 Operating System: SLES9 (x86_64)
 PHP Version:  4.4.0
 New Comment:

That doesn't help much, we need a reproduce code to replicate (and fix)
the problem. Just telling that it segfaults on some line in some code
doesn't give any info.
Please try to cook not very big script that doesn't require any
external resources like DBs, network connections etc.
Thanks.


Previous Comments:


[2005-07-14 22:53:53] pavlomt at hotmail dot com

sorry, it's faults on  $this->r_xsl->process($this->r_xml, $array);,
not in echo.



[2005-07-14 22:02:04] pavlomr at hotmail dot com

Sorry, with short scripts - no segfaults.
segfaults occupied in complex multi-module project with dynamically
generated xml data.



[2005-07-14 20:37:38] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.





[2005-07-14 16:13:25] pavlomt at hotmail dot com

Description:

php compiled on 32 bit x86, running as appache2 module
(apache2-2.0.49-27.8 from SLES9-32bit)

'./configure' '--host=i686-suse-linux' '--build=i686-suse-linux'
'--target=i586-suse-linux' '--program-prefix=' '--prefix=/usr'
'--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin'
'--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include'
'--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--with-apxs2=/usr/sbin/apxs2-prefork'
'--disable-debug' '--with-config-file-path=/etc' '--with-zlib-dir=/usr'
'--with-xml=shared' '--with-expat-dir=/usr'
'--enable-inline-optimization' '--enable-memory-limit'
'--enable-magic-quotes' '--enable-safe-mode' '--enable-sigchild'
'--disable-ctype' '--enable-session' '--with-informix=/opt/ICSDK'
'--with-mysql=shared' '--with-bz2=shared' '--with-zlib' '--with-pear'
'--with-dom' '--with-dom-xslt' '--with-dom-exslt'



Reproduce code:
---
$this->r_result = $this->r_xsl->process($this->r_xml, $array);

//  $this->r_xml->dump_mem(1); //- no segfault !!!
echo $this->r_xsl->result_dump_mem( $this->r_result);
//segfault
//  echo $this->r_result->dump_mem(0); //segfault

segfaults not depends on 0/1 parameter to dump_mem.

dynamically bulded xml-result of multiple database selects
more than 20 lines

Actual result:
--
rogram received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1434784864 (LWP 5835)]
0x5579e226 in free () from /lib/tls/libc.so.6
(gdb) backtrace
#0  0x5579e226 in free () from /lib/tls/libc.so.6
#1  0x55cd1cfb in xsltFreeKeys () from /usr/lib/libxslt.so.1
#2  0x55cc4f8a in xsltFreeStylesheet () from /usr/lib/libxslt.so.1
#3  0x55a7006c in php_free_xslt_stylesheet (rsrc=0x846bc74)
at /usr/src/packages/BUILD/php-4.4.0/ext/domxml/php_domxml.c:834
#4  0x55b21223 in list_entry_destructor (ptr=0x846bc74)
at /usr/src/packages/BUILD/php-4.4.0/Zend/zend_list.c:177
#5  0x55b1ede8 in zend_hash_apply_deleter (ht=0x55b816a0, p=0x8433c0c)
at /usr/src/packages/BUILD/php-4.4.0/Zend/zend_hash.c:611
#6  0x55b1ef47 in zend_hash_graceful_reverse_destroy (ht=0x55b816a0)
at /usr/src/packages/BUILD/php-4.4.0/Zend/zend_hash.c:677
#7  0x55b14704 in shutdown_executor () at
/usr/src/packages/BUILD/php-4.4.0/Zend/zend_execute_API.c:211
#8  0x55b1abe4 in zend_deactivate () at
/usr/src/packages/BUILD/php-4.4.0/Zend/zend.c:693
#9  0x55aefcbe in php_request_shutdown (dummy=0x0) at
/usr/src/packages/BUILD/php-4.4.0/main/main.c:997
#10 0x55b2e285 in php_handler (r=0x820a458)
at
/usr/src/packages/BUILD/php-4.4.0/sapi/apache2handler/sapi_apache2.c:443
#11 0x08069288 in ap_run_handler ()
#12 0x0806c8a7 in ap_invoke_handler ()
#13 0x0806688c in ap_internal_redirect ()
#14 0x559f1df3 in handler_redirect () from
/usr/lib/apache2-prefork/mod_rewrite.so
#15 0x08069288 in ap_run_handler ()
#16 0x0806c8a7 in ap_invoke_handler ()
#17 0x080669fb in ap_process_request ()
#18 0x08061168 in ap_process_http_connection ()
#19 0x080746b8 in ap_run_process_connection ()
#20 0x080747f0 in ap_process_connection ()
#21 0x08067ea5 in child_main ()
#22 0x080680fc in make_child ()
#23 0x08068b85 in ap_mpm_run ()
#24 0x0806f627 in main

#33707 [Opn->Asn]: Errors in select statements not reported

2005-07-14 Thread tony2001
 ID:   33707
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mangst at inventec dot ch
-Status:   Open
+Status:   Assigned
 Bug Type: PDO related
 Operating System: Windows 2000
 PHP Version:  5CVS-2005-07-14 (dev)
-Assigned To:  
+Assigned To:  wez
 New Comment:

That happens because Oracle's OCIStmtPrepare() doesn't validate the
query, it just allocates/prepares stmt handle for execution. Then PDO
happily executes this statement and all errors go to the stmt handle
(which is destroyed right after that).
Wez, from what I can see, with OCI we should always copy einfo struct
from the stmt handle to the dbh handle if stmt's execution failed.
Thoughts?


Previous Comments:


[2005-07-14 22:07:02] mangst at inventec dot ch

Description:

When a SQL statement is executed with PDO::query, PDO::errorInfo[0]
always reports "0" even when an error has occurred and PDO::query
returned .

Reproduce code:
---
getMessage());
}
$rs = $db->query('select nvarchar(8) from dual');
echo 'Statement handle: ';
var_dump($rs);
echo "\r\nError info of database handle: ";
var_dump($db->errorInfo());
$db = null;
?>

Expected result:

Somthing like:
Statement handle: bool(false)
Error info of database handle: array(1) { [0]=> string(5) "42000" [1]=>
"" [2]=> string(x) "ORA-00904: "NVARCHAR": invalid identifier"}

Actual result:
--
Statement handle: bool(false)
Error info of database handle: array(1) { [0]=> string(5) "0" }





-- 
Edit this bug report at http://bugs.php.net/?id=33707&edit=1


#33697 [Fbk->Opn]: segfault on dump_mem

2005-07-14 Thread pavlomt at hotmail dot com
 ID:   33697
 User updated by:  pavlomt at hotmail dot com
 Reported By:  pavlomt at hotmail dot com
-Status:   Feedback
+Status:   Open
 Bug Type: DOM XML related
 Operating System: SLES9 (x86_64)
 PHP Version:  4.4.0
 New Comment:

sorry, it's faults on  $this->r_xsl->process($this->r_xml, $array);,
not in echo.


Previous Comments:


[2005-07-14 22:02:04] pavlomr at hotmail dot com

Sorry, with short scripts - no segfaults.
segfaults occupied in complex multi-module project with dynamically
generated xml data.



[2005-07-14 20:37:38] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.





[2005-07-14 16:13:25] pavlomt at hotmail dot com

Description:

php compiled on 32 bit x86, running as appache2 module
(apache2-2.0.49-27.8 from SLES9-32bit)

'./configure' '--host=i686-suse-linux' '--build=i686-suse-linux'
'--target=i586-suse-linux' '--program-prefix=' '--prefix=/usr'
'--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin'
'--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include'
'--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--with-apxs2=/usr/sbin/apxs2-prefork'
'--disable-debug' '--with-config-file-path=/etc' '--with-zlib-dir=/usr'
'--with-xml=shared' '--with-expat-dir=/usr'
'--enable-inline-optimization' '--enable-memory-limit'
'--enable-magic-quotes' '--enable-safe-mode' '--enable-sigchild'
'--disable-ctype' '--enable-session' '--with-informix=/opt/ICSDK'
'--with-mysql=shared' '--with-bz2=shared' '--with-zlib' '--with-pear'
'--with-dom' '--with-dom-xslt' '--with-dom-exslt'



Reproduce code:
---
$this->r_result = $this->r_xsl->process($this->r_xml, $array);

//  $this->r_xml->dump_mem(1); //- no segfault !!!
echo $this->r_xsl->result_dump_mem( $this->r_result);
//segfault
//  echo $this->r_result->dump_mem(0); //segfault

segfaults not depends on 0/1 parameter to dump_mem.

dynamically bulded xml-result of multiple database selects
more than 20 lines

Actual result:
--
rogram received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1434784864 (LWP 5835)]
0x5579e226 in free () from /lib/tls/libc.so.6
(gdb) backtrace
#0  0x5579e226 in free () from /lib/tls/libc.so.6
#1  0x55cd1cfb in xsltFreeKeys () from /usr/lib/libxslt.so.1
#2  0x55cc4f8a in xsltFreeStylesheet () from /usr/lib/libxslt.so.1
#3  0x55a7006c in php_free_xslt_stylesheet (rsrc=0x846bc74)
at /usr/src/packages/BUILD/php-4.4.0/ext/domxml/php_domxml.c:834
#4  0x55b21223 in list_entry_destructor (ptr=0x846bc74)
at /usr/src/packages/BUILD/php-4.4.0/Zend/zend_list.c:177
#5  0x55b1ede8 in zend_hash_apply_deleter (ht=0x55b816a0, p=0x8433c0c)
at /usr/src/packages/BUILD/php-4.4.0/Zend/zend_hash.c:611
#6  0x55b1ef47 in zend_hash_graceful_reverse_destroy (ht=0x55b816a0)
at /usr/src/packages/BUILD/php-4.4.0/Zend/zend_hash.c:677
#7  0x55b14704 in shutdown_executor () at
/usr/src/packages/BUILD/php-4.4.0/Zend/zend_execute_API.c:211
#8  0x55b1abe4 in zend_deactivate () at
/usr/src/packages/BUILD/php-4.4.0/Zend/zend.c:693
#9  0x55aefcbe in php_request_shutdown (dummy=0x0) at
/usr/src/packages/BUILD/php-4.4.0/main/main.c:997
#10 0x55b2e285 in php_handler (r=0x820a458)
at
/usr/src/packages/BUILD/php-4.4.0/sapi/apache2handler/sapi_apache2.c:443
#11 0x08069288 in ap_run_handler ()
#12 0x0806c8a7 in ap_invoke_handler ()
#13 0x0806688c in ap_internal_redirect ()
#14 0x559f1df3 in handler_redirect () from
/usr/lib/apache2-prefork/mod_rewrite.so
#15 0x08069288 in ap_run_handler ()
#16 0x0806c8a7 in ap_invoke_handler ()
#17 0x080669fb in ap_process_request ()
#18 0x08061168 in ap_process_http_connection ()
#19 0x080746b8 in ap_run_process_connection ()
#20 0x080747f0 in ap_process_connection ()
#21 0x08067ea5 in child_main ()
#22 0x080680fc in make_child ()
#23 0x08068b85 in ap_mpm_run ()
#24 0x0806f627 in main ()
(gdb)





-- 
Edit this bug report at http://bugs.php.net/?id=33697&edit=1


#29865 [Com]: serialize produces invalid output

2005-07-14 Thread php dot net at sharpdreams dot com
 ID:   29865
 Comment by:   php dot net at sharpdreams dot com
 Reported By:  [EMAIL PROTECTED]
 Status:   Verified
 Bug Type: Strings related
 Operating System: *
 PHP Version:  5CVS-2005-03-07
 New Comment:

Still busted in recent CVS, win32 & FreeBSD. Seems to work in 5.0.4.
This ought to be fixed before the next b3, or at least prior to release
of 5.1.


Previous Comments:


[2005-03-23 14:05:55] maka3d at yahoo dot com dot br

// An other test

class WithPublic {
public $name = 'Marcos';
}

class WithProtec {
protected $name = 'Marcos';
}

class WithPrivat {
private $name = 'Marcos';
}

function showChars($str) {
$len = strlen($str);
for($i = 0; $i < $len; $i++) {
$ord = ord($str{$i});
$char = $ord == 0 ? '?' : chr($ord);
//printf("%03d = %s\n", $ord, $char);
echo $char;
}
}

showChars(serialize(new WithPublic()));
echo "\n";
showChars(serialize(new WithProtec()));
echo "\n";
showChars(serialize(new WithPrivat()));



[2005-01-22 13:57:12] [EMAIL PROTECTED]

This is still a problem in the latest head, simple test case:

$ ./php5_1 -r 'class Foo { protected $bar = 1; } $v = new Foo; echo
serialize($v);' | hexdump

000 3a4f 3a33 4622 6f6f 3a22 3a31 737b 363a
010 223a 2a00 6200 7261 3b22 3a69 3b31 007d
01f



[2005-01-06 20:23:42] jhargis at gmail dot com

I have noticed similar.  

username;
  }
}

$ob_User = New User();
$wUser = serialize($ob_User);
echo $wUser;
$wUser2 = unserialize($wUser); 
echo $wUser2->getU() . "\n";
?>

Protected/private members appear to have the 0x00 bytes around the
notation.  For the time, I base64 the serialized string so I can store
it in the DB without having to deal with it as a binary.  Also, this
may be related to why when using WDDX as the serialization handler it
only picks up the last member var when you need implement __sleep.



[2004-08-27 13:37:32] [EMAIL PROTECTED]

Description:

Using serialize() with a class produces invalid output.

Reproduce code:
---
I haven't had a chance to properly investigate why this particular code
causes a problem, but Derick seemed ontop of it already.

priv_member = $val;
   }

   function comp_func_cr($a, $b)
   {
   if ($a->priv_member === $b->priv_member) return 0;
   return ($a->priv_member > $b->priv_member)? 1:-1;
   }
   
   function comp_func_key($a, $b)
   {
   if ($a === $b) return 0;
   return ($a > $b)? 1:-1;
   }
}
$a = array("0.1" => new cr(9), "0.5" => new cr(12), 0 => new cr(23),
1=> new cr(4), 2 => new cr(-15),);
$b = array("0.2" => new cr(9), "0.5" => new cr(22), 0 => new cr(3), 1=>
new cr(4), 2 => new cr(-15),);

$result = array_udiff_uassoc($a, $b, array("cr", "comp_func_cr"),
array("cr", "comp_func_key"));
$foo = serialize($result);
echo $foo;
?>

Actual result:
--
  61 3a 33 3a 7b 73 3a 33  3a 22 30 2e 31 22 3b 4f   a:3:{s:3
:"0.1";O
0010  3a 32 3a 22 63 72 22 3a  31 3a 7b 73 3a 31 35 3a   :2:"cr":
1:{s:15:
0020  22 00 63 72 00 70 72 69  76 5f 6d 65 6d 62 65 72   ".cr.pri
v_member
0030  22 3b 69 3a 39 3b 7d 73  3a 33 3a 22 30 2e 35 22   ";i:9;}s
:3:"0.5"
0040  3b 4f 3a 32 3a 22 63 72  22 3a 31 3a 7b 73 3a 31   ;O:2:"cr
":1:{s:1
0050  35 3a 22 00 63 72 00 70  72 69 76 5f 6d 65 6d 62   5:".cr.p
riv_memb
0060  65 72 22 3b 69 3a 31 32  3b 7d 69 3a 30 3b 4f 3a   er";i:12
;}i:0;O:
0070  32 3a 22 63 72 22 3a 31  3a 7b 73 3a 31 35 3a 22   2:"cr":1
:{s:15:"
0080  00 63 72 00 70 72 69 76  5f 6d 65 6d 62 65 72 22   .cr.priv
_member"
0090  3b 69 3a 32 33 3b 7d 7d;i:23;}}

As you can see from this hexdump, there are 0 bytes being produced.
This should not happen.





-- 
Edit this bug report at http://bugs.php.net/?id=29865&edit=1


#33648 [Asn->Csd]: Using --with-regex=system causes compile failure

2005-07-14 Thread iliaa
 ID:   33648
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ergin at ergin dot dyndns dot org
-Status:   Assigned
+Status:   Closed
 Bug Type: Compile Failure
 Operating System: *
 PHP Version:  5CVS, 4CVS (2005-07-12)
 Assigned To:  andrei
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2005-07-12 15:41:55] [EMAIL PROTECTED]

Assigned to Andrei, he broke it.

As to the problem: remove --with-regex=system from your configure line
and it will work fine.



[2005-07-12 08:56:25] ergin at ergin dot dyndns dot org

Here is my configure line...

- START -

%configure \
--prefix=%{_prefix} \
--with-config-file-path=%{_sysconfdir} \
--enable-force-cgi-redirect \
--disable-debug \
--enable-pic \
--disable-rpath \
--enable-inline-optimization \
--with-dom=shared \
--with-bz2 \
--with-db3 \
--with-exec-dir=%{_bindir} \
--with-freetype-dir=%{_prefix} \
--with-gd \
--with-gdbm \
--with-gettext \
--with-gmp \
--with-jpeg-dir=%{_prefix} \
--with-mm \
--with-openssl \
--with-png \
--with-regex=system \
--with-ttf \
--with-xml \
--with-expat-dir=%{_prefix} \
--with-zlib \
--with-layout=GNU \
--enable-bcmath \
--enable-debugger \
--enable-ftp \
--enable-magic-quotes \
--enable-safe-mode \
--enable-sockets \
--enable-sysvsem \
--enable-sysvshm \
--enable-discard-path \
--enable-mime-magic \
--enable-track-vars \
--enable-trans-sid \
 --enable-yp \
--enable-wddx \
--without-oci8 \
--with-iconv --enable-mbstring --enable-mbregex \
--with-imap=shared,/usr/local/src/imap-2002e --with-imap-ssl
--with-kerberos=/usr/kerberos \
--with-ldap=shared \
--with-mysql=shared,/usr \
--with-pgsql=shared \
--with-curl=shared \
--with-mcrypt=shared \
--with-snmp=%{_prefix} \
--with-snmp=shared \
--enable-ucd-snmp-hack \
--with-unixODBC=shared \
--with-xmlrpc=shared \
--with-mhash=shared \
--enable-memory-limit \
--enable-bcmath \
--enable-shmop \
--enable-versioning \
--enable-sockets --enable-pcntl --enable-sigchild \
$*

 END --



[2005-07-11 22:38:14] ergin at ergin dot dyndns dot org

Description:

Got following message when I tried to build RPMS for new PHP version
php-4.4.0 (OBS!!! couldn't choose it from drop menu - PHP version)

.





Actual result:
--
/usr/src/redhat/BUILD/php-4.4.0/ext/standard/reg.c: In fucntion
'_php_regcomp':
/usr/src/redhat/BUILD/php-4.4.0/ext/standard/reg.c:53 structure has no
member named 're_magic'
/usr/src/redhat/BUILD/php-4.4.0/ext/standard/reg.c:72 structure has no
member named 're_magic'
make *** [ext/standard/reg.lo] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.66063







-- 
Edit this bug report at http://bugs.php.net/?id=33648&edit=1


#33708 [Opn->Fbk]: Problem with php module recode

2005-07-14 Thread tony2001
 ID:   33708
 Updated by:   [EMAIL PROTECTED]
 Reported By:  kirameku at email dot cz
-Status:   Open
+Status:   Feedback
 Bug Type: Recode related
 Operating System: RedHat ES4 x86_64
 PHP Version:  4.4.0
 New Comment:

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.





Previous Comments:


[2005-07-14 22:20:38] kirameku at email dot cz

Description:

Problem with php module recode on platform x86_64. 
recode ( string request, string string ) => Segmentation fault.








-- 
Edit this bug report at http://bugs.php.net/?id=33708&edit=1


#33708 [NEW]: Problem with php module recode

2005-07-14 Thread kirameku at email dot cz
From: kirameku at email dot cz
Operating system: RedHat ES4 x86_64
PHP version:  4.4.0
PHP Bug Type: Recode related
Bug description:  Problem with php module recode

Description:

Problem with php module recode on platform x86_64. 
recode ( string request, string string ) => Segmentation fault.




-- 
Edit bug report at http://bugs.php.net/?id=33708&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=33708&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=33708&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=33708&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33708&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33708&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=33708&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=33708&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=33708&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33708&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=33708&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=33708&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=33708&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33708&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=33708&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33708&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=33708&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33708&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=33708&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=33708&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=33708&r=mysqlcfg


#33707 [NEW]: Errors in select statements not reported

2005-07-14 Thread mangst at inventec dot ch
From: mangst at inventec dot ch
Operating system: Windows 2000
PHP version:  5CVS-2005-07-14 (dev)
PHP Bug Type: PDO related
Bug description:  Errors in select statements not reported

Description:

When a SQL statement is executed with PDO::query, PDO::errorInfo[0] always
reports "0" even when an error has occurred and PDO::query returned
.

Reproduce code:
---
getMessage());
}
$rs = $db->query('select nvarchar(8) from dual');
echo 'Statement handle: ';
var_dump($rs);
echo "\r\nError info of database handle: ";
var_dump($db->errorInfo());
$db = null;
?>

Expected result:

Somthing like:
Statement handle: bool(false)
Error info of database handle: array(1) { [0]=> string(5) "42000" [1]=>
"" [2]=> string(x) "ORA-00904: "NVARCHAR": invalid identifier"}

Actual result:
--
Statement handle: bool(false)
Error info of database handle: array(1) { [0]=> string(5) "0" }

-- 
Edit bug report at http://bugs.php.net/?id=33707&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=33707&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=33707&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=33707&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33707&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33707&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=33707&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=33707&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=33707&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33707&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=33707&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=33707&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=33707&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33707&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=33707&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33707&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=33707&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33707&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=33707&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=33707&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=33707&r=mysqlcfg


#33704 [Bgs->Opn]: similar to bug#19804

2005-07-14 Thread jokar30 at hotmail dot com
 ID:   33704
 User updated by:  jokar30 at hotmail dot com
 Reported By:  jokar30 at hotmail dot com
-Status:   Bogus
+Status:   Open
 Bug Type: mcrypt related
 Operating System: sparc solaris 9
 PHP Version:  5.0.3
 New Comment:

Thank you for your reply...
That means I should use mcrypt and not libmcrypt?

In this case, I should use ./configure'
'--with-mcrypt=/opt/mcrypt-x.y.z'
'--with-mhash=/opt/php-5.0.4/ext/mhash'
'--with-apxs=/usr/apache/bin/apxs' 
???


Previous Comments:


[2005-07-14 21:27:49] [EMAIL PROTECTED]

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

And it doesn't make sense, as mcrypt now has all their modules builtin
anyway so you don't need those directores. I guess you installed
libmcrypt incorrectly.



[2005-07-14 20:05:50] jokar30 at hotmail dot com

Description:

Hello,

I have done nearly everything and I still get the supported ciphers and
supported modes = none on the phpinfo(). 
I have set 
mcrypt.algorithms_dir = /opt/libmcrypt-2.5.6/modules/algorithms/
mcrypt.modes_dir = /opt/libmcrypt-2.5.6/modules/modes/
I have changed the chmod 755 to /usr/local/lib/libmcrypt 
I have cofigured php5.0.4 with ./configure'
'--with-mcrypt=/opt/libmcrypt-2.5.6'
'--with-mhash=/opt/php-5.0.4/ext/mhash'
'--with-apxs=/usr/apache/bin/apxs' 

Any help would be appreciated ;-)

Thank you






-- 
Edit this bug report at http://bugs.php.net/?id=33704&edit=1


#33694 [Opn->Asn]: IIS needs restart when invalid MSSQL statement run

2005-07-14 Thread fmk
 ID:   33694
 Updated by:   [EMAIL PROTECTED]
 Reported By:  spam at meyrick dot co dot nz
-Status:   Open
+Status:   Assigned
 Bug Type: MSSQL related
 Operating System: Windows 2003 Server Enterprise
 PHP Version:  4.4.0
-Assigned To:  
+Assigned To:  fmk


Previous Comments:


[2005-07-14 11:03:03] spam at meyrick dot co dot nz

Description:

I am using IIS6 (Win2k3 Server, SQL Server 2000, PHP 4.3.4 DLL)

I am connecting to MSSQL using username/pwd and pconnect

no probs there.

My problem is that if I execute a horribly incorrect SQL statement one
of the perminant connections to MSSQL is disabled giving 'unable to
connec to database' (pconnect() == false) errors 50% of the time..

For example:

Table: [Stock Items]:
StockItemID int no nulls identity
SupplierID int no nulls  <--**
test varchar(50) allow null
...

$sql = "INSERT INTO [Stock Items] (test) VALUES ('this should fail')";
$result = mssql_query($sql);


Warning: mssql_query(): message: Cannot insert the value NULL into
column 'SupplierID', table 'Database Name.dbo.Stock Items'; column does
not allow nulls. INSERT fails. (severity 16) in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 49

Warning: mssql_query(): message: The statement has been terminated.
(severity 0) in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 49

Warning: mssql_query(): General SQL Server error: Check messages from
the SQL Server. (severity 5) in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 49

Warning: mssql_query(): Query failed in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 49

Warning: mssql_query(): Attempt to initiate a new SQL Server operation
with results pending. (severity 7) in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 186



The last error is the one that is the kick in the guts as now EVERY sql
statement until the page finishes loading will fail.

When the page is refreshed pconnect() will work 50% of the time (if
they get a valid connection it works, if they get the dead connection
it fails).

The only way I can fix this problem is restarting IIS which is a pain.


I can replicate the problem by killing the process from MSSQL
Enterprise manager.

Any help would be great.

ps. an answer of "just fix your sql statement" is not what I'm looking
for as it is not allways related to invalid sql statements, running
large querieis using ODBC over the www seems to cause the exact same
problem, so does re/syncronizing a large replicated sql database.

Thanks.


Reproduce code:
---
Table: [Stock Items]:
StockItemID int no nulls identity
SupplierID int no nulls  <--**
test varchar(50) allow null
...

$sql = "INSERT INTO [Stock Items] (test) VALUES ('this should fail')";
$result = mssql_query($sql);


Expected result:

$result == valid mssql result

Actual result:
--
Warning: mssql_query(): message: Cannot insert the value NULL into
column 'SupplierID', table 'Database Name.dbo.Stock Items'; column does
not allow nulls. INSERT fails. (severity 16) in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 49

Warning: mssql_query(): message: The statement has been terminated.
(severity 0) in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 49

Warning: mssql_query(): General SQL Server error: Check messages from
the SQL Server. (severity 5) in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 49

Warning: mssql_query(): Query failed in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 49

Warning: mssql_query(): Attempt to initiate a new SQL Server operation
with results pending. (severity 7) in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 186


+ dead pconnection to MSSQL server until IIS (php dll) is restarted





-- 
Edit this bug report at http://bugs.php.net/?id=33694&edit=1


#33697 [Com]: segfault on dump_mem

2005-07-14 Thread pavlomr at hotmail dot com
 ID:   33697
 Comment by:   pavlomr at hotmail dot com
 Reported By:  pavlomt at hotmail dot com
 Status:   Feedback
 Bug Type: DOM XML related
 Operating System: SLES9 (x86_64)
 PHP Version:  4.4.0
 New Comment:

Sorry, with short scripts - no segfaults.
segfaults occupied in complex multi-module project with dynamically
generated xml data.


Previous Comments:


[2005-07-14 20:37:38] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.





[2005-07-14 16:13:25] pavlomt at hotmail dot com

Description:

php compiled on 32 bit x86, running as appache2 module
(apache2-2.0.49-27.8 from SLES9-32bit)

'./configure' '--host=i686-suse-linux' '--build=i686-suse-linux'
'--target=i586-suse-linux' '--program-prefix=' '--prefix=/usr'
'--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin'
'--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include'
'--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--with-apxs2=/usr/sbin/apxs2-prefork'
'--disable-debug' '--with-config-file-path=/etc' '--with-zlib-dir=/usr'
'--with-xml=shared' '--with-expat-dir=/usr'
'--enable-inline-optimization' '--enable-memory-limit'
'--enable-magic-quotes' '--enable-safe-mode' '--enable-sigchild'
'--disable-ctype' '--enable-session' '--with-informix=/opt/ICSDK'
'--with-mysql=shared' '--with-bz2=shared' '--with-zlib' '--with-pear'
'--with-dom' '--with-dom-xslt' '--with-dom-exslt'



Reproduce code:
---
$this->r_result = $this->r_xsl->process($this->r_xml, $array);

//  $this->r_xml->dump_mem(1); //- no segfault !!!
echo $this->r_xsl->result_dump_mem( $this->r_result);
//segfault
//  echo $this->r_result->dump_mem(0); //segfault

segfaults not depends on 0/1 parameter to dump_mem.

dynamically bulded xml-result of multiple database selects
more than 20 lines

Actual result:
--
rogram received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1434784864 (LWP 5835)]
0x5579e226 in free () from /lib/tls/libc.so.6
(gdb) backtrace
#0  0x5579e226 in free () from /lib/tls/libc.so.6
#1  0x55cd1cfb in xsltFreeKeys () from /usr/lib/libxslt.so.1
#2  0x55cc4f8a in xsltFreeStylesheet () from /usr/lib/libxslt.so.1
#3  0x55a7006c in php_free_xslt_stylesheet (rsrc=0x846bc74)
at /usr/src/packages/BUILD/php-4.4.0/ext/domxml/php_domxml.c:834
#4  0x55b21223 in list_entry_destructor (ptr=0x846bc74)
at /usr/src/packages/BUILD/php-4.4.0/Zend/zend_list.c:177
#5  0x55b1ede8 in zend_hash_apply_deleter (ht=0x55b816a0, p=0x8433c0c)
at /usr/src/packages/BUILD/php-4.4.0/Zend/zend_hash.c:611
#6  0x55b1ef47 in zend_hash_graceful_reverse_destroy (ht=0x55b816a0)
at /usr/src/packages/BUILD/php-4.4.0/Zend/zend_hash.c:677
#7  0x55b14704 in shutdown_executor () at
/usr/src/packages/BUILD/php-4.4.0/Zend/zend_execute_API.c:211
#8  0x55b1abe4 in zend_deactivate () at
/usr/src/packages/BUILD/php-4.4.0/Zend/zend.c:693
#9  0x55aefcbe in php_request_shutdown (dummy=0x0) at
/usr/src/packages/BUILD/php-4.4.0/main/main.c:997
#10 0x55b2e285 in php_handler (r=0x820a458)
at
/usr/src/packages/BUILD/php-4.4.0/sapi/apache2handler/sapi_apache2.c:443
#11 0x08069288 in ap_run_handler ()
#12 0x0806c8a7 in ap_invoke_handler ()
#13 0x0806688c in ap_internal_redirect ()
#14 0x559f1df3 in handler_redirect () from
/usr/lib/apache2-prefork/mod_rewrite.so
#15 0x08069288 in ap_run_handler ()
#16 0x0806c8a7 in ap_invoke_handler ()
#17 0x080669fb in ap_process_request ()
#18 0x08061168 in ap_process_http_connection ()
#19 0x080746b8 in ap_run_process_connection ()
#20 0x080747f0 in ap_process_connection ()
#21 0x08067ea5 in child_main ()
#22 0x080680fc in make_child ()
#23 0x08068b85 in ap_mpm_run ()
#24 0x0806f627 in main ()
(gdb)





-- 
Edit this bug report at http://bugs.php.net/?id=33697&edit=1


#33704 [Opn->Bgs]: similar to bug#19804

2005-07-14 Thread derick
 ID:   33704
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jokar30 at hotmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: mcrypt related
 Operating System: sparc solaris 9
 PHP Version:  5.0.3
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

And it doesn't make sense, as mcrypt now has all their modules builtin
anyway so you don't need those directores. I guess you installed
libmcrypt incorrectly.


Previous Comments:


[2005-07-14 20:05:50] jokar30 at hotmail dot com

Description:

Hello,

I have done nearly everything and I still get the supported ciphers and
supported modes = none on the phpinfo(). 
I have set 
mcrypt.algorithms_dir = /opt/libmcrypt-2.5.6/modules/algorithms/
mcrypt.modes_dir = /opt/libmcrypt-2.5.6/modules/modes/
I have changed the chmod 755 to /usr/local/lib/libmcrypt 
I have cofigured php5.0.4 with ./configure'
'--with-mcrypt=/opt/libmcrypt-2.5.6'
'--with-mhash=/opt/php-5.0.4/ext/mhash'
'--with-apxs=/usr/apache/bin/apxs' 

Any help would be appreciated ;-)

Thank you






-- 
Edit this bug report at http://bugs.php.net/?id=33704&edit=1


#33706 [Opn->Bgs]: $_POST bug

2005-07-14 Thread tony2001
 ID:   33706
 Updated by:   [EMAIL PROTECTED]
 Reported By:  deucalion at lycos dot co dot uk
-Status:   Open
+Status:   Bogus
 Bug Type: SOAP related
 Operating System: Windows2000,XP
 PHP Version:  5.0.4
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.




Previous Comments:


[2005-07-14 21:03:51] deucalion at lycos dot co dot uk

Description:

$_post does not working in the SOAPclient. 

Reproduce code:
---




U.S ZipCodesTemperatureService



Type search term: 





http://www.xmethods.net/sd/2001/DemoTemperatureService.wsdl",array
(

"trace" => 1,

"exceptions" => 0)); 

$params= array ( "zipcode" => $_POST['zipcode'] );

$client->call("getTemp",$params");

print "\n"; 

print "Request :\n".htmlspecialchars($client->__getLastRequest())
."\n";

print
"Response:\n".htmlspecialchars($client->__getLastResponse())."\n";

print "";

}

?>







Expected result:

Request :

http://schemas.xmlsoap.org/soap/envelope/";
xmlns:ns1="urn:xmethods-Temperature-Demo"
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";>zipcode

Response:

http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";>

http://schemas.xmlsoap.org/soap/encoding/";>
52.0







Actual result:
--
SERVER NOT FOUND. 





-- 
Edit this bug report at http://bugs.php.net/?id=33706&edit=1


#33705 [Opn->Bgs]: Mysql inserts 2 rows, one of them blank

2005-07-14 Thread tony2001
 ID:   33705
 Updated by:   [EMAIL PROTECTED]
 Reported By:  halehnb at hotmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: MySQL related
 Operating System: Windows XP
 PHP Version:  4.4.0
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.




Previous Comments:


[2005-07-14 20:56:45] halehnb at hotmail dot com

Description:

I am inserting into 2 tables, and each time in addition to inserting a
row with the correct data, a phantom, blank row is inserted. This seems
similar to bug #10599 "background attribute in the body tag causes a
double insert", but I am not using the "background" tag, and I can't
find my error. I am using "background-color" in CSS but I don't see how
this could be a problem. What is also weird is that for the
"sur_subcategory" table, the data is being inserted near the top of the
database table, and not at the bottom like one would expect. Another
anomoly: when I use Mozilla (1.4) it double inserts into both tables,
but when I use IE (6.0), it only double inserts into one table
(sur_category_subcategory). 



Reproduce code:
---
$step1 = '';

// sur_subcat table insert
$step1 = sprintf("INSERT INTO sur_subcategory (subcat_name) VALUES
('%s')",$subname);
$result1 = mysql_query($step1);

// get subcat_id to put into sur_cat_sub table
$step2 = sprintf("SELECT subcat_id FROM sur_subcategory WHERE
subcat_name = '%s'", $subname);
$result = mysql_query($step2);
$subcat_id = mysql_result($result,0); 

// insert into sur_cat_sub table
$step3 = sprintf("INSERT INTO sur_category_subcategory
(category_id,subcat_id,subcat_name) 
VALUES 
('%d','%d','%s')",$category_id,$subcat_id,$subname);
$result3 = mysql_query($step3);
?>

Your subcategory has been submitted.");
mysql_close();
?>

Expected result:

What I want is for a SINGLE row with the subcat_name to be inserted
into table sur_subcategory, and a SINGLE row with the category_id,
subcat_id and subcat_name to be inserted into the 
sur_category_subcategory table.

Actual result:
--
When I insert into sur_subcategory, a row with the correct information
is created. However, another row with incorrect information is created
too. The same happens when I try to insert into
sur_category_subcategory. Example:

when $subname = "halehtest1", and the first mysql insert is done, the
sur_subcategory table looks like:

-- 
-- Table structure for table `sur_subcategory`
-- 

CREATE TABLE `sur_subcategory` (
  `subcat_id` smallint(8) unsigned NOT NULL auto_increment,
  `subcat_name` varchar(30) NOT NULL default '',
  PRIMARY KEY  (`subcat_id`)
) TYPE=MyISAM AUTO_INCREMENT=126 ;

-- 
-- Dumping data for table `sur_subcategory`
-- 

INSERT INTO `sur_subcategory` VALUES (124, 'halehtest1');
INSERT INTO `sur_subcategory` VALUES (125, '');







-- 
Edit this bug report at http://bugs.php.net/?id=33705&edit=1



#33706 [NEW]: $_POST bug

2005-07-14 Thread deucalion at lycos dot co dot uk
From: deucalion at lycos dot co dot uk
Operating system: Windows2000,XP  
PHP version:  5.0.4
PHP Bug Type: SOAP related
Bug description:  $_POST bug

Description:

$_post does not working in the SOAPclient. 

Reproduce code:
---




U.S ZipCodesTemperatureService



Type search term: 





http://www.xmethods.net/sd/2001/DemoTemperatureService.wsdl",array
(

"trace" => 1,

"exceptions" => 0)); 

$params= array ( "zipcode" => $_POST['zipcode'] );

$client->call("getTemp",$params");

print "\n"; 

print "Request :\n".htmlspecialchars($client->__getLastRequest()) ."\n";

print "Response:\n".htmlspecialchars($client->__getLastResponse())."\n";

print "";

}

?>







Expected result:

Request :

http://schemas.xmlsoap.org/soap/envelope/";
xmlns:ns1="urn:xmethods-Temperature-Demo"
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";>zipcode

Response:

http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";>

http://schemas.xmlsoap.org/soap/encoding/";>
52.0







Actual result:
--
SERVER NOT FOUND. 

-- 
Edit bug report at http://bugs.php.net/?id=33706&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=33706&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=33706&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=33706&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33706&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33706&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=33706&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=33706&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=33706&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33706&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=33706&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=33706&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=33706&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33706&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=33706&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33706&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=33706&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33706&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=33706&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=33706&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=33706&r=mysqlcfg


#33705 [NEW]: Mysql inserts 2 rows, one of them blank

2005-07-14 Thread halehnb at hotmail dot com
From: halehnb at hotmail dot com
Operating system: Windows XP
PHP version:  4.4.0
PHP Bug Type: MySQL related
Bug description:  Mysql inserts 2 rows, one of them blank

Description:

I am inserting into 2 tables, and each time in addition to inserting a row
with the correct data, a phantom, blank row is inserted. This seems similar
to bug #10599 "background attribute in the body tag causes a double
insert", but I am not using the "background" tag, and I can't find my
error. I am using "background-color" in CSS but I don't see how this could
be a problem. What is also weird is that for the "sur_subcategory" table,
the data is being inserted near the top of the database table, and not at
the bottom like one would expect. Another anomoly: when I use Mozilla
(1.4) it double inserts into both tables, but when I use IE (6.0), it only
double inserts into one table (sur_category_subcategory). 



Reproduce code:
---
$step1 = '';

// sur_subcat table insert
$step1 = sprintf("INSERT INTO sur_subcategory (subcat_name) VALUES
('%s')",$subname);
$result1 = mysql_query($step1);

// get subcat_id to put into sur_cat_sub table
$step2 = sprintf("SELECT subcat_id FROM sur_subcategory WHERE subcat_name
= '%s'", $subname);
$result = mysql_query($step2);
$subcat_id = mysql_result($result,0); 

// insert into sur_cat_sub table
$step3 = sprintf("INSERT INTO sur_category_subcategory
(category_id,subcat_id,subcat_name) 
VALUES 
('%d','%d','%s')",$category_id,$subcat_id,$subname);
$result3 = mysql_query($step3);
?>

Your subcategory has been submitted.");
mysql_close();
?>

Expected result:

What I want is for a SINGLE row with the subcat_name to be inserted into
table sur_subcategory, and a SINGLE row with the category_id, subcat_id
and subcat_name to be inserted into the  sur_category_subcategory table.

Actual result:
--
When I insert into sur_subcategory, a row with the correct information is
created. However, another row with incorrect information is created too.
The same happens when I try to insert into sur_category_subcategory.
Example:

when $subname = "halehtest1", and the first mysql insert is done, the
sur_subcategory table looks like:

-- 
-- Table structure for table `sur_subcategory`
-- 

CREATE TABLE `sur_subcategory` (
  `subcat_id` smallint(8) unsigned NOT NULL auto_increment,
  `subcat_name` varchar(30) NOT NULL default '',
  PRIMARY KEY  (`subcat_id`)
) TYPE=MyISAM AUTO_INCREMENT=126 ;

-- 
-- Dumping data for table `sur_subcategory`
-- 

INSERT INTO `sur_subcategory` VALUES (124, 'halehtest1');
INSERT INTO `sur_subcategory` VALUES (125, '');



-- 
Edit bug report at http://bugs.php.net/?id=33705&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=33705&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=33705&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=33705&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33705&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33705&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=33705&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=33705&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=33705&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33705&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=33705&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=33705&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=33705&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33705&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=33705&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33705&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=33705&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33705&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=33705&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=33705&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=33705&r=mysqlcfg


#32859 [Asn]: Error when attempting to write Clob to oracle

2005-07-14 Thread Diomedes_01 at yahoo dot com
 ID:   32859
 User updated by:  Diomedes_01 at yahoo dot com
 Reported By:  Diomedes_01 at yahoo dot com
 Status:   Assigned
 Bug Type: OCI8 related
 Operating System: Solaris 9 (Server)
 PHP Version:  5.0.4
 Assigned To:  tony2001
 New Comment:

Latest update:

I reverted back to the PHP 4.3.9 environment against the same database.
I was able to successfully handle any lob operations.

When we switched again to PHP 5.0.4 (I rebuilt just to be safe), the
problem still persists.

One thing to note: we are building against the Oracle 10g release but
we had to make some modifications to the configure file to get it to
built against the 32 bit libraries. (The oracle default lib directory
points to the 64 bit libraries that are incompatible with PHP)
We had to perform similar steps when building against Oracle 9i as
well.

Note that building PHP 4.3.9 against the same 10g 32 bit libraries does
work correctly.


Previous Comments:


[2005-06-30 00:04:17] [EMAIL PROTECTED]

Please try both your PHP 4.x installation and PHP 5.x installation
against the same database and compare the results.

In addition, your PHP 5.x build should have included the writeTemporary
method.  If it is missing from your build, then it sounds like there was
a problem detecting temporary lob support in your environment, and we'd
like to track down the cause of that problem in more detail.



[2005-06-14 06:55:39] Diomedes_01 at yahoo dot com

With regards to my problem, it was not an issue of the clob not being
initialized. I noticed this problem on CLOBs that were already in
existence. Using a stored procedure we have that updates the value of
the CLOB, that was when I noticed the error.

One thing I will verify with our DBA is the possibility that the recent
upgrade of the database to UTF-8 could be contributing to the problem. I
will try to replicate the issue with PHP 5.0.4 against our older UTF-7
ASCII database.



[2005-06-13 08:41:26] [EMAIL PROTECTED]

So you tried to write CLOB without setting it empty with EMPTY_CLOB() ?
Am I right?



[2005-06-13 02:03:35] ab5602 at wayne dot edu

This appears to possibly be parsing problem with the oci_parse function
not returning a real placeholder location. The placeholder :fieldname
does not work if used in this fashion during an sql statement in
v5.0.4, I've found this to work in previous versions:

update table mytable set clob1=:clob;

However, I've found it to work in v5.0.4 if the sql is rewritten such
as:

update table mytable set clob1=empty_clob() returning clob1 as :clob;



[2005-04-28 19:48:32] Diomedes_01 at yahoo dot com

Unfortunately, my website is behind a firewall and contains company
sensitive information; so I cannot grant access.

The reproducible code is already included; please note that I attempted
to continue using my previous PHP4 code (that worked beforehand) and it
failed. That code was:

WriteTemporary($comments);
   OCIExecute ($sth, OCI_DEFAULT) or display_main_error();
   $clob->close();
   $clob->free();
   OCIFreeStatement($sth);
?>

When I attempted to execute the above code, I received a fatal error
from PHP indicating that the writeTemporary method was not found.
According to what I read in the documentation, it appears to not be
part of the new OCI class.

So when I followed the documentation and re-implemented the code
following the instructions provided; which by the way, look like so:
(straight from your online help)

= 4.0.6). 
 * Example PL/SQL stored procedure signature is:
 *
 * PROCEDURE save_data
 *  Argument Name  TypeIn/Out
Default?
 *  -- --- --

 *  KEYNUMBER(38)  IN
 *  DATA  CLOBIN
 *
 */

   $conn = oci_connect($user, $password);
   $stmt = oci_parse($conn, "begin save_data(:key, :data); end;");
   $clob = oci_new_descriptor($conn, OCI_D_LOB);
   oci_bind_by_name($stmt, ':key', $key);
   oci_bind_by_name($stmt, ':data', $clob, -1, OCI_B_CLOB);
   $clob->write($data);
   oci_execute($stmt, OCI_DEFAULT);
   oci_commit($conn);
   $clob->free();
   oci_free_statement($stmt);
?> 

Here is the documentation URL:
http://us2.php.net/manual/en/function.oci-new-descriptor.php

That is when I receive a problem with regards to the 'write' method.

So either this is a bug or a documentation problem; I know the stored
procedure I am using works and that the variables being passed are
valid. It works in SQL*Plus and it works if I revert back to PHP4

#33697 [Opn->Fbk]: segfault on dump_mem

2005-07-14 Thread tony2001
 ID:   33697
 Updated by:   [EMAIL PROTECTED]
 Reported By:  pavlomt at hotmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: DOM XML related
 Operating System: SLES9 (x86_64)
 PHP Version:  4.4.0
 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.




Previous Comments:


[2005-07-14 16:13:25] pavlomt at hotmail dot com

Description:

php compiled on 32 bit x86, running as appache2 module
(apache2-2.0.49-27.8 from SLES9-32bit)

'./configure' '--host=i686-suse-linux' '--build=i686-suse-linux'
'--target=i586-suse-linux' '--program-prefix=' '--prefix=/usr'
'--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin'
'--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include'
'--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--with-apxs2=/usr/sbin/apxs2-prefork'
'--disable-debug' '--with-config-file-path=/etc' '--with-zlib-dir=/usr'
'--with-xml=shared' '--with-expat-dir=/usr'
'--enable-inline-optimization' '--enable-memory-limit'
'--enable-magic-quotes' '--enable-safe-mode' '--enable-sigchild'
'--disable-ctype' '--enable-session' '--with-informix=/opt/ICSDK'
'--with-mysql=shared' '--with-bz2=shared' '--with-zlib' '--with-pear'
'--with-dom' '--with-dom-xslt' '--with-dom-exslt'



Reproduce code:
---
$this->r_result = $this->r_xsl->process($this->r_xml, $array);

//  $this->r_xml->dump_mem(1); //- no segfault !!!
echo $this->r_xsl->result_dump_mem( $this->r_result);
//segfault
//  echo $this->r_result->dump_mem(0); //segfault

segfaults not depends on 0/1 parameter to dump_mem.

dynamically bulded xml-result of multiple database selects
more than 20 lines

Actual result:
--
rogram received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1434784864 (LWP 5835)]
0x5579e226 in free () from /lib/tls/libc.so.6
(gdb) backtrace
#0  0x5579e226 in free () from /lib/tls/libc.so.6
#1  0x55cd1cfb in xsltFreeKeys () from /usr/lib/libxslt.so.1
#2  0x55cc4f8a in xsltFreeStylesheet () from /usr/lib/libxslt.so.1
#3  0x55a7006c in php_free_xslt_stylesheet (rsrc=0x846bc74)
at /usr/src/packages/BUILD/php-4.4.0/ext/domxml/php_domxml.c:834
#4  0x55b21223 in list_entry_destructor (ptr=0x846bc74)
at /usr/src/packages/BUILD/php-4.4.0/Zend/zend_list.c:177
#5  0x55b1ede8 in zend_hash_apply_deleter (ht=0x55b816a0, p=0x8433c0c)
at /usr/src/packages/BUILD/php-4.4.0/Zend/zend_hash.c:611
#6  0x55b1ef47 in zend_hash_graceful_reverse_destroy (ht=0x55b816a0)
at /usr/src/packages/BUILD/php-4.4.0/Zend/zend_hash.c:677
#7  0x55b14704 in shutdown_executor () at
/usr/src/packages/BUILD/php-4.4.0/Zend/zend_execute_API.c:211
#8  0x55b1abe4 in zend_deactivate () at
/usr/src/packages/BUILD/php-4.4.0/Zend/zend.c:693
#9  0x55aefcbe in php_request_shutdown (dummy=0x0) at
/usr/src/packages/BUILD/php-4.4.0/main/main.c:997
#10 0x55b2e285 in php_handler (r=0x820a458)
at
/usr/src/packages/BUILD/php-4.4.0/sapi/apache2handler/sapi_apache2.c:443
#11 0x08069288 in ap_run_handler ()
#12 0x0806c8a7 in ap_invoke_handler ()
#13 0x0806688c in ap_internal_redirect ()
#14 0x559f1df3 in handler_redirect () from
/usr/lib/apache2-prefork/mod_rewrite.so
#15 0x08069288 in ap_run_handler ()
#16 0x0806c8a7 in ap_invoke_handler ()
#17 0x080669fb in ap_process_request ()
#18 0x08061168 in ap_process_http_connection ()
#19 0x080746b8 in ap_run_process_connection ()
#20 0x080747f0 in ap_process_connection ()
#21 0x08067ea5 in child_main ()
#22 0x080680fc in make_child ()
#23 0x08068b85 in ap_mpm_run ()
#24 0x0806f627 in main ()
(gdb)





-- 
Edit this bug report at http://bugs.php.net/?id=33697&edit=1


#33704 [NEW]: similar to bug#19804

2005-07-14 Thread jokar30 at hotmail dot com
From: jokar30 at hotmail dot com
Operating system: sparc solaris 9
PHP version:  5.0.3
PHP Bug Type: mcrypt related
Bug description:  similar to bug#19804

Description:

Hello,

I have done nearly everything and I still get the supported ciphers and
supported modes = none on the phpinfo(). 
I have set 
mcrypt.algorithms_dir = /opt/libmcrypt-2.5.6/modules/algorithms/
mcrypt.modes_dir = /opt/libmcrypt-2.5.6/modules/modes/
I have changed the chmod 755 to /usr/local/lib/libmcrypt 
I have cofigured php5.0.4 with ./configure'
'--with-mcrypt=/opt/libmcrypt-2.5.6'
'--with-mhash=/opt/php-5.0.4/ext/mhash' '--with-apxs=/usr/apache/bin/apxs'


Any help would be appreciated ;-)

Thank you


-- 
Edit bug report at http://bugs.php.net/?id=33704&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=33704&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=33704&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=33704&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33704&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33704&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=33704&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=33704&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=33704&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33704&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=33704&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=33704&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=33704&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33704&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=33704&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33704&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=33704&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33704&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=33704&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=33704&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=33704&r=mysqlcfg


#33702 [Opn->Bgs]: Imap function very slow.

2005-07-14 Thread derick
 ID:   33702
 Updated by:   [EMAIL PROTECTED]
 Reported By:  shoe99 at hotmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: IMAP related
 Operating System: Windows XP PRO SP2
 PHP Version:  5.0.4
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

.


Previous Comments:


[2005-07-14 17:56:47] shoe99 at hotmail dot com

Description:

Sorry, My report is not bug report, but I don't know how the normal
user that realy use PHP for a long time tell some experience about
using PHP...

I feel PHP Imap Function very very slow. I think at this time PHP Imap
Function can not make a great webmail like Gmail(The fastest) Yahoo or
Hotmail etc. Why? I use Imap Function to make Imap webmail and compared
with Squirrelmail(Not use Imap Function) on the same environments...Why
Squirrelmail much faster?

No any extention installed.
Tried the lastest CVS version.
Both CGI and ISAPI

..

Just say something, because so love PHP...
I knew the bug status will set to Bogus.
Thank you :)






-- 
Edit this bug report at http://bugs.php.net/?id=33702&edit=1


#33702 [NEW]: Imap function very slow.

2005-07-14 Thread shoe99 at hotmail dot com
From: shoe99 at hotmail dot com
Operating system: Windows XP PRO SP2
PHP version:  5.0.4
PHP Bug Type: IMAP related
Bug description:  Imap function very slow.

Description:

Sorry, My report is not bug report, but I don't know how the normal user
that realy use PHP for a long time tell some experience about using
PHP...

I feel PHP Imap Function very very slow. I think at this time PHP Imap
Function can not make a great webmail like Gmail(The fastest) Yahoo or
Hotmail etc. Why? I use Imap Function to make Imap webmail and compared
with Squirrelmail(Not use Imap Function) on the same environments...Why
Squirrelmail much faster?

No any extention installed.
Tried the lastest CVS version.
Both CGI and ISAPI

..

Just say something, because so love PHP...
I knew the bug status will set to Bogus.
Thank you :)


-- 
Edit bug report at http://bugs.php.net/?id=33702&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=33702&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=33702&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=33702&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33702&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33702&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=33702&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=33702&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=33702&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33702&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=33702&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=33702&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=33702&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33702&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=33702&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33702&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=33702&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33702&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=33702&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=33702&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=33702&r=mysqlcfg


#33699 [NEW]: MAX_FILE_SIZE should use same syntax as upload_max_filesize

2005-07-14 Thread jnp at anneli dot dk
From: jnp at anneli dot dk
Operating system: 
PHP version:  5.0.4
PHP Bug Type: Feature/Change Request
Bug description:  MAX_FILE_SIZE should use same syntax as upload_max_filesize

Description:

Form handling for file upload.

MAX_FILE_SIZE should use same syntax as upload_max_filesize so the value
from ini_get can be used directly (or upload_max_filesize should be
calculated and stored as number of bytes)

Having 2 different syntaxes for the same thing is messy.




-- 
Edit bug report at http://bugs.php.net/?id=33699&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=33699&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=33699&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=33699&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33699&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33699&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=33699&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=33699&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=33699&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33699&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=33699&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=33699&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=33699&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33699&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=33699&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33699&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=33699&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33699&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=33699&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=33699&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=33699&r=mysqlcfg


#33698 [NEW]: Conflicts with multiple interfaces sharing common method names

2005-07-14 Thread jason at hybd dot net
From: jason at hybd dot net
Operating system: Irrelevent
PHP version:  5.0.4
PHP Bug Type: Scripting Engine problem
Bug description:  Conflicts with multiple interfaces sharing common method names

Description:

This is debateable if this is a bug or not. Personally, I don't regard it
as a bug.

Classes that implement >1 interface that share common methods raise fatal
errors. Because of the abstract nature of interfaces, no error or warning
should be rasied.

I know PHP <> Java, but Java doesn't raise any errors, and PHP5's OO model
is very close to Java's

Reproduce code:
---
interface FirstInterface
{
function execute();
}

interface SecondInterface
{
function execute();
}

class MyClass implements FirstInterface, SecondInterface
{
function execute()
{
echo "Hello World";
}
}

$obj = new MyClass();
$obj->execute();

Expected result:

Hello World

Actual result:
--
Can't inherit abstract function SecondInterface::execute()

-- 
Edit bug report at http://bugs.php.net/?id=33698&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=33698&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=33698&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=33698&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33698&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33698&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=33698&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=33698&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=33698&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33698&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=33698&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=33698&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=33698&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33698&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=33698&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33698&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=33698&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33698&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=33698&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=33698&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=33698&r=mysqlcfg


#33685 [WFx]: configure: error: libjpeg.(a|so) not found.

2005-07-14 Thread matt at azoogleads dot com
 ID:   33685
 User updated by:  matt at azoogleads dot com
 Reported By:  matt at azoogleads dot com
 Status:   Wont fix
 Bug Type: PHP options/info functions
 Operating System: RHEL 4 ES/x86_64
 PHP Version:  4.4.0
 New Comment:

Please disregard my last post, all is fine.  I didn't have the
freetype-devel package installed ;-)


Previous Comments:


[2005-07-14 16:06:10] matt at azoogleads dot com

I created the symlinks you mentioned which got around the libjpeg issue
(thanks!), only to run into the error "configure: error: freetype2 not
found!"  

I've tried using --with-freetype-dir=/opt, --with-freetype-dir=/usr and
--with-freetype-dir without any luck.  Am I going to run into trouble if
I run PHP 4.4.0 under 64-bit Linux?



[2005-07-14 01:18:27] [EMAIL PROTECTED]

I didn't notice the x86_64 there. This bug is fixed in PHP 5.1 (current
CVS HEAD). It will not be fixed in PHP 4.

Workaround: 

# ln -s /usr/include /opt/include
# ln -s /usr/lib64 /opt/lib

And use these options and values for them:
--with-mysql=/opt
--with-jpeg-dir=/opt
--with-png-dir=/opt




[2005-07-13 23:08:24] matt at azoogleads dot com

I wasn't able to make out anything obvious in the config.log file
(searching for any reference to 'jpeg').  Here's a copy of config.log
for your reference:

http://ca.geocities.com/[EMAIL PROTECTED]/config.log



[2005-07-13 22:45:45] [EMAIL PROTECTED]

Check the config.log for the real reason why the check failed.
Configure outputs 'checking for the location of libjpeg... yes' because
you have '--with-jpeg-dir', not that it found it.




[2005-07-13 22:10:29] matt at azoogleads dot com

Description:

I'm having the same problem described in Bug #32369, where I'm trying
to compile JPEG support into 4.4.0 on RHEL 4 ES/x86_64 and although the
location of libjpeg is detected (see below), and both libjpeg.so and
libjpeg.a files exist under /usr/lib64, the configure script terminates
with the error "configure: error: libjpeg.(a|so) not found."  This also
seem to occur with PHP 4.3.11.


checking for GD support... yes
checking for the location of libjpeg... yes
checking for the location of libpng... no
checking for the location of libXpm... no
checking for FreeType 1.x support... no
checking for FreeType 2... yes
checking for T1lib support... no
checking whether to enable truetype string function in GD... no
checking whether to enable JIS-mapped Japanese font support in GD...
no
checking for fabsf... yes
checking for floorf... yes
configure: error: libjpeg.(a|so) not found.


Specifying "--with-jpeg-dir=/usr" or "--with-jpeg-dir=/usr/lib64"
doesn't fix the problem.

Reproduce code:
---
./configure
 --with-mysql=/usr \
 --with-apxs2=/usr/local/apache2/bin/apxs \
 --with-zlib \
 --with-ftp \
 --with-gd \
 --with-jpeg-dir \
 --with-freetype-dir \
 --enable-pcntl \
 --with-openssl 
 --with-curl \
 --with-dom \

Actual result:
--
The location of libjpeg will be detected, however the configure script
will terminate with the error "configure: error: libjpeg.(a|so) not
found."





-- 
Edit this bug report at http://bugs.php.net/?id=33685&edit=1



#33643 [Asn]: Fatal error: Only variables can be passed by reference

2005-07-14 Thread rasmus
 ID:  33643
 Updated by:  [EMAIL PROTECTED]
 Reported By: Jason at hybd dot net
 Status:  Assigned
 Bug Type:Scripting Engine problem
 PHP Version: 5.1.0b2
 Assigned To: derick
 New Comment:

This sort of thing needs to throw an error in any version of PHP I
think:

  function foo() { return "blah"; }
  function bar(&$arg) { $arg = 1; }
  bar(foo());

While this should work:

  function & foo() { static $a; return $a; }
  function bar(&$arg) { $arg = 1; }
  bar(foo());

And it does in PHP5.1 at least.  The first case indicates a clear bug
in the code that we really should be catching.  I suppose we could
compromise and throw a warning in PHP4 and then fall back to passing
the argument by value, but that is changing the actual workings of the
script and is likely going to be wrong.  I think this needs to be part
of the reference fixes in PHP4.4.  Sucks that it wasn't caught before
the 4.4.0 release, but that's the way it goes.


Previous Comments:


[2005-07-14 14:15:08] [EMAIL PROTECTED]

Let's take this to [EMAIL PROTECTED] I'll write a mail later



[2005-07-14 13:06:00] [EMAIL PROTECTED]

The "Fatal error:" in HEAD and PHP_5_0 occurs because of fix for bug
#33257. The patch was not applied into PHP 4.4  because it wasn't
affected by this bug (PHP 4 doesn't allow static properties).

Now I found reproducable case for PHP_4_4. :(


Expected result:

Fatal error: Only variables can be passed by reference 

Or:
---
foo
foo
bar
bar

Actual result:
--
foo

bar
bar


The current behavoir of HEAD is proper from my point of view. PHP_4_4
may be fixed but it will break BC again.

Derick, Andi?




[2005-07-14 11:16:56] [EMAIL PROTECTED]

I think we need to discuss this a bit more, PHP 4.4 indeed gives no
warning or notice on this. Andi, Dmitry?



[2005-07-14 11:01:13] [EMAIL PROTECTED]

Actual result (4.x after removing "public static"):

4.3.10: No error
4.4.0: No error
5.0.4: No error
5.1.0: Fatal error

Is this really the expected result? I thought 4.4.0 should produce
something too. In which cases 4.4.0 produces errors?



[2005-07-14 01:08:15] [EMAIL PROTECTED]

This is not gonna change, it's now how it's supposed to be.





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/33643

-- 
Edit this bug report at http://bugs.php.net/?id=33643&edit=1


#33697 [NEW]: segfault on dump_mem

2005-07-14 Thread pavlomt at hotmail dot com
From: pavlomt at hotmail dot com
Operating system: SLES9 (x86_64)
PHP version:  4.4.0
PHP Bug Type: DOM XML related
Bug description:  segfault on dump_mem

Description:

php compiled on 32 bit x86, running as appache2 module
(apache2-2.0.49-27.8 from SLES9-32bit)

'./configure' '--host=i686-suse-linux' '--build=i686-suse-linux'
'--target=i586-suse-linux' '--program-prefix=' '--prefix=/usr'
'--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin'
'--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include'
'--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--with-apxs2=/usr/sbin/apxs2-prefork'
'--disable-debug' '--with-config-file-path=/etc' '--with-zlib-dir=/usr'
'--with-xml=shared' '--with-expat-dir=/usr' '--enable-inline-optimization'
'--enable-memory-limit' '--enable-magic-quotes' '--enable-safe-mode'
'--enable-sigchild' '--disable-ctype' '--enable-session'
'--with-informix=/opt/ICSDK' '--with-mysql=shared' '--with-bz2=shared'
'--with-zlib' '--with-pear' '--with-dom' '--with-dom-xslt'
'--with-dom-exslt'



Reproduce code:
---
$this->r_result = $this->r_xsl->process($this->r_xml, $array);

//  $this->r_xml->dump_mem(1); //- no segfault !!!
echo $this->r_xsl->result_dump_mem( $this->r_result); //segfault
//  echo $this->r_result->dump_mem(0); //segfault

segfaults not depends on 0/1 parameter to dump_mem.

dynamically bulded xml-result of multiple database selects
more than 20 lines

Actual result:
--
rogram received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1434784864 (LWP 5835)]
0x5579e226 in free () from /lib/tls/libc.so.6
(gdb) backtrace
#0  0x5579e226 in free () from /lib/tls/libc.so.6
#1  0x55cd1cfb in xsltFreeKeys () from /usr/lib/libxslt.so.1
#2  0x55cc4f8a in xsltFreeStylesheet () from /usr/lib/libxslt.so.1
#3  0x55a7006c in php_free_xslt_stylesheet (rsrc=0x846bc74)
at /usr/src/packages/BUILD/php-4.4.0/ext/domxml/php_domxml.c:834
#4  0x55b21223 in list_entry_destructor (ptr=0x846bc74)
at /usr/src/packages/BUILD/php-4.4.0/Zend/zend_list.c:177
#5  0x55b1ede8 in zend_hash_apply_deleter (ht=0x55b816a0, p=0x8433c0c)
at /usr/src/packages/BUILD/php-4.4.0/Zend/zend_hash.c:611
#6  0x55b1ef47 in zend_hash_graceful_reverse_destroy (ht=0x55b816a0)
at /usr/src/packages/BUILD/php-4.4.0/Zend/zend_hash.c:677
#7  0x55b14704 in shutdown_executor () at
/usr/src/packages/BUILD/php-4.4.0/Zend/zend_execute_API.c:211
#8  0x55b1abe4 in zend_deactivate () at
/usr/src/packages/BUILD/php-4.4.0/Zend/zend.c:693
#9  0x55aefcbe in php_request_shutdown (dummy=0x0) at
/usr/src/packages/BUILD/php-4.4.0/main/main.c:997
#10 0x55b2e285 in php_handler (r=0x820a458)
at
/usr/src/packages/BUILD/php-4.4.0/sapi/apache2handler/sapi_apache2.c:443
#11 0x08069288 in ap_run_handler ()
#12 0x0806c8a7 in ap_invoke_handler ()
#13 0x0806688c in ap_internal_redirect ()
#14 0x559f1df3 in handler_redirect () from
/usr/lib/apache2-prefork/mod_rewrite.so
#15 0x08069288 in ap_run_handler ()
#16 0x0806c8a7 in ap_invoke_handler ()
#17 0x080669fb in ap_process_request ()
#18 0x08061168 in ap_process_http_connection ()
#19 0x080746b8 in ap_run_process_connection ()
#20 0x080747f0 in ap_process_connection ()
#21 0x08067ea5 in child_main ()
#22 0x080680fc in make_child ()
#23 0x08068b85 in ap_mpm_run ()
#24 0x0806f627 in main ()
(gdb)

-- 
Edit bug report at http://bugs.php.net/?id=33697&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=33697&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=33697&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=33697&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33697&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33697&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=33697&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=33697&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=33697&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33697&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=33697&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=33697&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=33697&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33697&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=33697&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33697&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=33697&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33697&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=33697&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?i

#33685 [WFx]: configure: error: libjpeg.(a|so) not found.

2005-07-14 Thread matt at azoogleads dot com
 ID:   33685
 User updated by:  matt at azoogleads dot com
 Reported By:  matt at azoogleads dot com
 Status:   Wont fix
 Bug Type: PHP options/info functions
 Operating System: RHEL 4 ES/x86_64
 PHP Version:  4.4.0
 New Comment:

I created the symlinks you mentioned which got around the libjpeg issue
(thanks!), only to run into the error "configure: error: freetype2 not
found!"  

I've tried using --with-freetype-dir=/opt, --with-freetype-dir=/usr and
--with-freetype-dir without any luck.  Am I going to run into trouble if
I run PHP 4.4.0 under 64-bit Linux?


Previous Comments:


[2005-07-14 01:18:27] [EMAIL PROTECTED]

I didn't notice the x86_64 there. This bug is fixed in PHP 5.1 (current
CVS HEAD). It will not be fixed in PHP 4.

Workaround: 

# ln -s /usr/include /opt/include
# ln -s /usr/lib64 /opt/lib

And use these options and values for them:
--with-mysql=/opt
--with-jpeg-dir=/opt
--with-png-dir=/opt




[2005-07-13 23:08:24] matt at azoogleads dot com

I wasn't able to make out anything obvious in the config.log file
(searching for any reference to 'jpeg').  Here's a copy of config.log
for your reference:

http://ca.geocities.com/[EMAIL PROTECTED]/config.log



[2005-07-13 22:45:45] [EMAIL PROTECTED]

Check the config.log for the real reason why the check failed.
Configure outputs 'checking for the location of libjpeg... yes' because
you have '--with-jpeg-dir', not that it found it.




[2005-07-13 22:10:29] matt at azoogleads dot com

Description:

I'm having the same problem described in Bug #32369, where I'm trying
to compile JPEG support into 4.4.0 on RHEL 4 ES/x86_64 and although the
location of libjpeg is detected (see below), and both libjpeg.so and
libjpeg.a files exist under /usr/lib64, the configure script terminates
with the error "configure: error: libjpeg.(a|so) not found."  This also
seem to occur with PHP 4.3.11.


checking for GD support... yes
checking for the location of libjpeg... yes
checking for the location of libpng... no
checking for the location of libXpm... no
checking for FreeType 1.x support... no
checking for FreeType 2... yes
checking for T1lib support... no
checking whether to enable truetype string function in GD... no
checking whether to enable JIS-mapped Japanese font support in GD...
no
checking for fabsf... yes
checking for floorf... yes
configure: error: libjpeg.(a|so) not found.


Specifying "--with-jpeg-dir=/usr" or "--with-jpeg-dir=/usr/lib64"
doesn't fix the problem.

Reproduce code:
---
./configure
 --with-mysql=/usr \
 --with-apxs2=/usr/local/apache2/bin/apxs \
 --with-zlib \
 --with-ftp \
 --with-gd \
 --with-jpeg-dir \
 --with-freetype-dir \
 --enable-pcntl \
 --with-openssl 
 --with-curl \
 --with-dom \

Actual result:
--
The location of libjpeg will be detected, however the configure script
will terminate with the error "configure: error: libjpeg.(a|so) not
found."





-- 
Edit this bug report at http://bugs.php.net/?id=33685&edit=1


#33643 [Opn->Asn]: Fatal error: Only variables can be passed by reference

2005-07-14 Thread derick
 ID:  33643
 Updated by:  [EMAIL PROTECTED]
 Reported By: Jason at hybd dot net
-Status:  Open
+Status:  Assigned
 Bug Type:Scripting Engine problem
 PHP Version: 5.1.0b2
-Assigned To: 
+Assigned To: derick
 New Comment:

Let's take this to [EMAIL PROTECTED] I'll write a mail later


Previous Comments:


[2005-07-14 13:06:00] [EMAIL PROTECTED]

The "Fatal error:" in HEAD and PHP_5_0 occurs because of fix for bug
#33257. The patch was not applied into PHP 4.4  because it wasn't
affected by this bug (PHP 4 doesn't allow static properties).

Now I found reproducable case for PHP_4_4. :(


Expected result:

Fatal error: Only variables can be passed by reference 

Or:
---
foo
foo
bar
bar

Actual result:
--
foo

bar
bar


The current behavoir of HEAD is proper from my point of view. PHP_4_4
may be fixed but it will break BC again.

Derick, Andi?




[2005-07-14 11:16:56] [EMAIL PROTECTED]

I think we need to discuss this a bit more, PHP 4.4 indeed gives no
warning or notice on this. Andi, Dmitry?



[2005-07-14 11:01:13] [EMAIL PROTECTED]

Actual result (4.x after removing "public static"):

4.3.10: No error
4.4.0: No error
5.0.4: No error
5.1.0: Fatal error

Is this really the expected result? I thought 4.4.0 should produce
something too. In which cases 4.4.0 produces errors?



[2005-07-14 01:08:15] [EMAIL PROTECTED]

This is not gonna change, it's now how it's supposed to be.





[2005-07-11 22:04:22] Jason at hybd dot net

May I be a pain and just ask will there be any chance that this bug
will be resolved at some point in the future, or will you push others
to work round this bug. May i suggest, seeing as this does break a lot
of things, would it be possible to make this something like a
ze1_compatiblity_mode to help people phase this change in?

I assume this fixes blugs like 32685. I assume is a similar issue as I
had relating to in 32963, and I assume many other people have reported
similar bugs.



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/33643

-- 
Edit this bug report at http://bugs.php.net/?id=33643&edit=1


#33643 [Opn]: Fatal error: Only variables can be passed by reference

2005-07-14 Thread dmitry
 ID:  33643
 Updated by:  [EMAIL PROTECTED]
 Reported By: Jason at hybd dot net
 Status:  Open
 Bug Type:Scripting Engine problem
 PHP Version: 5.1.0b2
 New Comment:

The "Fatal error:" in HEAD and PHP_5_0 occurs because of fix for bug
#33257. The patch was not applied into PHP 4.4  because it wasn't
affected by this bug (PHP 4 doesn't allow static properties).

Now I found reproducable case for PHP_4_4. :(


Expected result:

Fatal error: Only variables can be passed by reference 

Or:
---
foo
foo
bar
bar

Actual result:
--
foo

bar
bar


The current behavoir of HEAD is proper from my point of view. PHP_4_4
may be fixed but it will break BC again.

Derick, Andi?



Previous Comments:


[2005-07-14 11:16:56] [EMAIL PROTECTED]

I think we need to discuss this a bit more, PHP 4.4 indeed gives no
warning or notice on this. Andi, Dmitry?



[2005-07-14 11:01:13] [EMAIL PROTECTED]

Actual result (4.x after removing "public static"):

4.3.10: No error
4.4.0: No error
5.0.4: No error
5.1.0: Fatal error

Is this really the expected result? I thought 4.4.0 should produce
something too. In which cases 4.4.0 produces errors?



[2005-07-14 01:08:15] [EMAIL PROTECTED]

This is not gonna change, it's now how it's supposed to be.





[2005-07-11 22:04:22] Jason at hybd dot net

May I be a pain and just ask will there be any chance that this bug
will be resolved at some point in the future, or will you push others
to work round this bug. May i suggest, seeing as this does break a lot
of things, would it be possible to make this something like a
ze1_compatiblity_mode to help people phase this change in?

I assume this fixes blugs like 32685. I assume is a similar issue as I
had relating to in 32963, and I assume many other people have reported
similar bugs.



[2005-07-11 20:34:34] [EMAIL PROTECTED]

Yes, it is undocumented. But same goes for PHP 4.4.0 too. 
Reclassified. (this break was intentional and fixed a lot of references
related bugs)




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/33643

-- 
Edit this bug report at http://bugs.php.net/?id=33643&edit=1


#33695 [Opn->Bgs]: localconv() returning invalid thousands_sep for France

2005-07-14 Thread derick
 ID:   33695
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tony at marston-home dot demon dot co dot uk
-Status:   Open
+Status:   Bogus
 Bug Type: *Languages/Translation
 Operating System: Windows XP
 PHP Version:  5.0.4
 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

If the windows locale information defines the non breaking character as
the thousands_sep value - then we can't do anything about this. This is
not a PHP bug.


Previous Comments:


[2005-07-14 11:50:56] tony at marston-home dot demon dot co dot uk

Description:

I am using the following code:

$locale = setlocale(LC_ALL, 'FRA');
$data   = localeconv();
$thousands_sep = $data['thousands_sep'];
$ascii = ord($thousands_sep);

The value in $ascii is 160 (?) when it should be 32 (space).

When I use this with number_format() the result is written to an XML
file then transformed into HTML using XSL. The XSL transformation
process fails because it is not valid UTF-8.



Reproduce code:
---
$locale = setlocale(LC_ALL, 'FRA');
$data   = localeconv();
$thousands_sep = $data['thousands_sep'];
$ascii = ord($thousands_sep);


Expected result:

ord($thousands_sep) should be 32 (space), not 160

Actual result:
--
ord($thousands_sep) is 160





-- 
Edit this bug report at http://bugs.php.net/?id=33695&edit=1


#33695 [NEW]: localconv() returning invalid thousands_sep for France

2005-07-14 Thread tony at marston-home dot demon dot co dot uk
From: tony at marston-home dot demon dot co dot uk
Operating system: Windows XP
PHP version:  5.0.4
PHP Bug Type: *Languages/Translation
Bug description:  localconv() returning invalid thousands_sep for France

Description:

I am using the following code:

$locale = setlocale(LC_ALL, 'FRA');
$data   = localeconv();
$thousands_sep = $data['thousands_sep'];
$ascii = ord($thousands_sep);

The value in $ascii is 160 (?) when it should be 32 (space).

When I use this with number_format() the result is written to an XML file
then transformed into HTML using XSL. The XSL transformation process fails
because it is not valid UTF-8.



Reproduce code:
---
$locale = setlocale(LC_ALL, 'FRA');
$data   = localeconv();
$thousands_sep = $data['thousands_sep'];
$ascii = ord($thousands_sep);


Expected result:

ord($thousands_sep) should be 32 (space), not 160

Actual result:
--
ord($thousands_sep) is 160

-- 
Edit bug report at http://bugs.php.net/?id=33695&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=33695&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=33695&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=33695&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33695&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33695&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=33695&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=33695&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=33695&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33695&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=33695&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=33695&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=33695&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33695&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=33695&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33695&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=33695&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33695&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=33695&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=33695&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=33695&r=mysqlcfg


#33643 [Opn]: Fatal error: Only variables can be passed by reference

2005-07-14 Thread derick
 ID:  33643
 Updated by:  [EMAIL PROTECTED]
 Reported By: Jason at hybd dot net
 Status:  Open
-Bug Type:Documentation problem
+Bug Type:Scripting Engine problem
 PHP Version: 5.1.0b2
 New Comment:

I think we need to discuss this a bit more, PHP 4.4 indeed gives no
warning or notice on this. Andi, Dmitry?


Previous Comments:


[2005-07-14 11:01:13] [EMAIL PROTECTED]

Actual result (4.x after removing "public static"):

4.3.10: No error
4.4.0: No error
5.0.4: No error
5.1.0: Fatal error

Is this really the expected result? I thought 4.4.0 should produce
something too. In which cases 4.4.0 produces errors?



[2005-07-14 01:08:15] [EMAIL PROTECTED]

This is not gonna change, it's now how it's supposed to be.





[2005-07-11 22:04:22] Jason at hybd dot net

May I be a pain and just ask will there be any chance that this bug
will be resolved at some point in the future, or will you push others
to work round this bug. May i suggest, seeing as this does break a lot
of things, would it be possible to make this something like a
ze1_compatiblity_mode to help people phase this change in?

I assume this fixes blugs like 32685. I assume is a similar issue as I
had relating to in 32963, and I assume many other people have reported
similar bugs.



[2005-07-11 20:34:34] [EMAIL PROTECTED]

Yes, it is undocumented. But same goes for PHP 4.4.0 too. 
Reclassified. (this break was intentional and fixed a lot of references
related bugs)




[2005-07-11 20:28:07] Jason at hybd dot net

Sorry, it's all fair and well making this bogus, but this change breaks
LOADS of existing code, so it is not a bug and it's behavior is
NOT documented. The least you could have done is justify why this is
not a bug and why this change was introduced into the language!

This is really a PHP bug because thi has worked in all versions of PHP
prior to this. There has been nothing in the way of warning or anything
in recent releases to phase in this change in behaviour like there was
with the call by reference thing.

Do you expect many thousands of programmers to change their code
because if this stupid querk.



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/33643

-- 
Edit this bug report at http://bugs.php.net/?id=33643&edit=1


#33694 [NEW]: IIS needs restart when invalid MSSQL statement run

2005-07-14 Thread spam at meyrick dot co dot nz
From: spam at meyrick dot co dot nz
Operating system: Windows 2003 Server Enterprise
PHP version:  4.4.0
PHP Bug Type: MSSQL related
Bug description:  IIS needs restart when invalid MSSQL statement run

Description:

I am using IIS6 (Win2k3 Server, SQL Server 2000, PHP 4.3.4 DLL)

I am connecting to MSSQL using username/pwd and pconnect

no probs there.

My problem is that if I execute a horribly incorrect SQL statement one of
the perminant connections to MSSQL is disabled giving 'unable to connec to
database' (pconnect() == false) errors 50% of the time..

For example:

Table: [Stock Items]:
StockItemID int no nulls identity
SupplierID int no nulls  <--**
test varchar(50) allow null
...

$sql = "INSERT INTO [Stock Items] (test) VALUES ('this should fail')";
$result = mssql_query($sql);


Warning: mssql_query(): message: Cannot insert the value NULL into column
'SupplierID', table 'Database Name.dbo.Stock Items'; column does not allow
nulls. INSERT fails. (severity 16) in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 49

Warning: mssql_query(): message: The statement has been terminated.
(severity 0) in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 49

Warning: mssql_query(): General SQL Server error: Check messages from the
SQL Server. (severity 5) in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 49

Warning: mssql_query(): Query failed in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 49

Warning: mssql_query(): Attempt to initiate a new SQL Server operation
with results pending. (severity 7) in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 186



The last error is the one that is the kick in the guts as now EVERY sql
statement until the page finishes loading will fail.

When the page is refreshed pconnect() will work 50% of the time (if they
get a valid connection it works, if they get the dead connection it
fails).

The only way I can fix this problem is restarting IIS which is a pain.


I can replicate the problem by killing the process from MSSQL Enterprise
manager.

Any help would be great.

ps. an answer of "just fix your sql statement" is not what I'm looking for
as it is not allways related to invalid sql statements, running large
querieis using ODBC over the www seems to cause the exact same problem, so
does re/syncronizing a large replicated sql database.

Thanks.


Reproduce code:
---
Table: [Stock Items]:
StockItemID int no nulls identity
SupplierID int no nulls  <--**
test varchar(50) allow null
...

$sql = "INSERT INTO [Stock Items] (test) VALUES ('this should fail')";
$result = mssql_query($sql);


Expected result:

$result == valid mssql result

Actual result:
--
Warning: mssql_query(): message: Cannot insert the value NULL into column
'SupplierID', table 'Database Name.dbo.Stock Items'; column does not allow
nulls. INSERT fails. (severity 16) in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 49

Warning: mssql_query(): message: The statement has been terminated.
(severity 0) in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 49

Warning: mssql_query(): General SQL Server error: Check messages from the
SQL Server. (severity 5) in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 49

Warning: mssql_query(): Query failed in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 49

Warning: mssql_query(): Attempt to initiate a new SQL Server operation
with results pending. (severity 7) in
C:\Inetpub\websites\sitename\public_html\acweb\includes\functions\database.php
on line 186


+ dead pconnection to MSSQL server until IIS (php dll) is restarted

-- 
Edit bug report at http://bugs.php.net/?id=33694&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=33694&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=33694&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=33694&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33694&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33694&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=33694&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=33694&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=33694&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33694&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=33694&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=33694&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=33694&r=submittedtwice
register_globals: 

#33693 [NEW]: mssql uniqueidentifier in select crashes php

2005-07-14 Thread r dot vanicek at seznam dot cz
From: r dot vanicek at seznam dot cz
Operating system: Linux (Debian 3.1)
PHP version:  4.4.0
PHP Bug Type: Sybase-ct (ctlib) related
Bug description:  mssql uniqueidentifier in select crashes php

Description:

I am connecting from PHP to Sybase and MSSQL. I have sybase-ct extension
enabled. I use freetds-0.63. When I select from MSSQL any column of type
"uniqueidentifier", PHP crashes on fetch.

The problem is conversion. Sybase-ct module does not handle
CS_UNIQUE_TYPE,  and tries to store the 38 byte string that freetds
returns to it into 16 byte string. Freetds refuses to do so and signals an
error, which is probably fatal.

Test suite: see reproduce code.

The solution I suggest is to intoduce CS_UNIQUE_TYPE into php_sybase_ct.c,
function php_sybase_fetch_result_set for example like this:

case CS_DECIMAL_TYPE:
result->datafmt[i].maxlength = 
result->datafmt[i].precision + 3;
/* numeric(10) vs numeric(10, 1) */
result->numerics[i] = (result->datafmt[i].scale 
== 0) ? 3 : 2;
break;
case CS_UNIQUE_TYPE:
result->datafmt[i].maxlength = 38;
result->numerics[i] = 0;
break;
default:
result->datafmt[i].maxlength++;
result->numerics[i] = 0;
break;



This solution works for me quite well.


Reproduce code:
---
create table TEST (a int, b varchar, c uniqueidentifier);
insert into TEST values (1,'hello',newid());

sybase_connect( "srv", "uid", "pwd" );
sybase_select_db( "dbname" );

// this works fine
$res = sybase_query( "select a,b from TEST" );
$row = sybase_fetch_array( $res );

// this crashes
$res = sybase_query( "select a,b,c from TEST" );
$row = sybase_fetch_array( $res );

It is all the same if you use mssql_ functions instead of sybase_
functions.


Expected result:

eg. row containing
1
'hello'
'EB668095-F85D-4C59-A202-120C5CE1B65'

Actual result:
--
crash, in Apache error.log I see this:

[notice] child pid 18857 exit signal Segmentation fault (11)
error_handler: Data-conversion resulted in overflow.


-- 
Edit bug report at http://bugs.php.net/?id=33693&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=33693&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=33693&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=33693&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33693&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33693&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=33693&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=33693&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=33693&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33693&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=33693&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=33693&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=33693&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33693&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=33693&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33693&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=33693&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33693&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=33693&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=33693&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=33693&r=mysqlcfg


#33533 [Opn->Fbk]: PDO_ODBC: Segmentation Fault with selecting informix text column

2005-07-14 Thread tony2001
 ID:   33533
 Updated by:   [EMAIL PROTECTED]
 Reported By:  scott dot barnett at thuringowa dot qld dot gov dot au
-Status:   Open
+Status:   Feedback
 Bug Type: PDO related
 Operating System: CentOS 4.1 / Redhat Enterprise 4
 PHP Version:  5CVS-2005-07-04
 New Comment:

Thanks. Could you also do this:
---

bt
f 3
p *col
---
And paste the output here. 
Thanks in advance.


Previous Comments:


[2005-07-14 01:21:08] scott dot barnett at thuringowa dot qld dot gov
dot au

#0  0x0060f7a2 in ?? () from /lib/ld-linux.so.2
#1  0x0064fc76 in kill () from /lib/tls/libc.so.6
#2  0x00ec4f14 in _emalloc (size=2147483648,
__zend_filename=0xf5c5b4
"/usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c",
__zend_lineno=393, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at /usr/src/apache/php5-200507122030/Zend/zend_alloc.c:191
#3  0x00d58c90 in odbc_stmt_describe (stmt=0x8c2a244, colno=1)
at /usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c:393
#4  0x00d5140c in pdo_stmt_describe_columns (stmt=0x8c2a244)
at /usr/src/apache/php5-200507122030/ext/pdo/pdo_stmt.c:168
#5  0x00d508c3 in zif_PDO_query (ht=2, return_value=0x8bc7c7c,
return_value_ptr=0x0,
this_ptr=0x8bc7ad4, return_value_used=1)
at /usr/src/apache/php5-200507122030/ext/pdo/pdo_dbh.c:912
#6  0x00f03eaa in zend_do_fcall_common_helper_SPEC
(execute_data=0xbff8a6e0)
at /usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:184
#7  0x00f04713 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xbff8a6e0)
at /usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:299
#8  0x00f03b8b in execute (op_array=0x8bc2bbc)
at /usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:87
#9  0x00edd699 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/src/apache/php5-200507122030/Zend/zend.c:1087
#10 0x00e9c995 in php_execute_script (primary_file=0xbff8ca60)
at /usr/src/apache/php5-200507122030/main/main.c:1672
#11 0x00f48616 in php_handler (r=0x8bb3be0)
at
/usr/src/apache/php5-200507122030/sapi/apache2handler/sapi_apache2.c:555
#12 0x0809953a in ap_run_handler (r=0x8bb3be0) at config.c:152
#13 0x08099905 in ap_invoke_handler (r=0x8bb3be0) at config.c:364
#14 0x0808255d in ap_process_request (r=0x8bb3be0) at
http_request.c:249
#15 0x0807e225 in ap_process_http_connection (c=0x8bad948) at
http_core.c:251
#16 0x080a2a02 in ap_run_process_connection (c=0x8bad948) at
connection.c:43
#17 0x08097d15 in child_main (child_num_arg=0) at prefork.c:610
#18 0x08097f09 in make_child (s=0x8a42a08, slot=0) at prefork.c:650
#19 0x08097fd0 in startup_children (number_to_start=5) at
prefork.c:722
#20 0x080986a3 in ap_mpm_run (_pconf=0xbff8cdb0, plog=0x8a77190,
s=0xbff8cdb4) at prefork.c:941
#21 0x0809d7a3 in main (argc=2, argv=0xbff8cf54) at main.c:618



[2005-07-13 11:42:38] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.





[2005-07-13 01:36:18] scott dot barnett at thuringowa dot qld dot gov
dot au

Thanks wez, I've got PDO-ODBC working now with snapshot
php5-200507122030.

If I use PDO this shows up in err_log:
FATAL:  emalloc():  Unable to allocate -2147483648 bytes
FATAL:  emalloc():  Unable to allocate -2147483648 bytes
FATAL:  emalloc():  Unable to allocate -2147483648 bytes

If I use the ifx_ functions this shows up in err_log:
[Wed Jul 13 09:26:51 2005] [notice] child pid 15980 exit signal
Segmentation fault (11)
[Wed Jul 13 09:26:51 2005] [notice] child pid 15981 exit signal
Segmentation fault (11)

Same problems basically, only happens when querying Informix text
fields, char and int are fine.



[2005-07-12 12:57:32] [EMAIL PROTECTED]

Remove old stuff:

- pear uninstall pdo_odbc
- pear uninstall pdo

Grab a PHP 5.1 snapshot from http://snaps.php.net:

- Extract it
- cd into the dir
- ./configure  --with-pdo-odbc=unixODBC
- make
- make install

then test it



[2005-07-12 07:40:11] scott dot barnett at thuringowa dot qld dot gov
dot au

Rightio, it was user error. I did an strace and I had php.ini in the
wrong place, I've corrected it. Previously I configured the extensions
dir as a configure option and compiled my own pdo.so and pdo_odbc.so so
it worked ok.

"php -m" shows up PDO and pdo_sqlite. I thought PDO was going to be
inc

#33692 [NEW]: imagettftext produces no output

2005-07-14 Thread a dot vent at procommerz dot de
From: a dot vent at procommerz dot de
Operating system: Debian Linux 3.0 "Woody"
PHP version:  4.4.0
PHP Bug Type: GD related
Bug description:  imagettftext produces no output

Description:

The ImageTTFText function produces no result, but also no  
error. I've tried several font files (Microsoft TT core 
fonts and also from other sources), several paths (the  
same dir as the PHP script, relative to DocRoot, absolute 
path a.s.o.).  
  
It looks like not calling imagettftext - the function  
silently does nothing...  
  
I have Debian "Woody" with Apache 1.3.29 / PHP 4.4.0. The  
GD lib is the bundled one (phpinfo says: "2.0.28  
compatible"). The Freetype lib version is 1.4pre, as  
provided from Debian package manager. 
 
PHP configure options: 
 
'./configure' '--with-apxs=/var/www/bin/apxs' 
'--with-mysql' '--enable-ftp' '--enable-shared' 
'--with-iconv' '--with-gd' '--with-curl' 
'--with-jpeg-dir=/usr' '--with-png-dir=/usr' 
'--with-dom=/usr' '--with-zlib' '--enable-cli'  
'--with-ttf=/usr' 
 
Output snippet from phpinfo: 
 
GD Support  
enabled  
 
GD Version  
bundled (2.0.28 compatible)  
 
FreeType Support  
enabled  
 
FreeType Linkage  
with TTF library  
 
GIF Read Support  
enabled  
 
GIF Create Support  
enabled  
 
JPG Support  
enabled  
 
PNG Support  
enabled  
 
WBMP Support  
enabled  
 
XBM Support  
enabled 

Reproduce code:
---


Expected result:

Displays an image with white-colored text "Hello World" in 
Arial font face on grey background.  

Actual result:
--
Displays an grey-colored image without any text (empty  
grey box). No error messages. 

-- 
Edit bug report at http://bugs.php.net/?id=33692&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=33692&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=33692&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=33692&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33692&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33692&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=33692&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=33692&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=33692&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33692&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=33692&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=33692&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=33692&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33692&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=33692&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33692&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=33692&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33692&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=33692&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=33692&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=33692&r=mysqlcfg


#33147 [Opn]: proc_open(): "pty pseudo terminal not supported on this system"

2005-07-14 Thread sniper
 ID:   33147
 Updated by:   [EMAIL PROTECTED]
 Reported By:  skissane at iips dot mq dot edu dot au
 Status:   Open
 Bug Type: Program Execution
 Operating System: *
 PHP Version:  5CVS-2005-05-27
 New Comment:

I'm still waiting for someone to give me a short and reliable piece of
code (shell or C) to test if the functionality is present on the
system..



Previous Comments:


[2005-06-20 09:51:30] skissane at iips dot mq dot edu dot au

This is not really a feature/change request -- the feature is already
supported in the code; the configure system just needs to be set up so
the support can be turned on/off.



[2005-05-30 08:20:43] skissane at iips dot mq dot edu dot au

Updated test case: added SKIPIF (requires Michael Spector's
--enable-pty patch).

--TEST--
Bug #33147 (proc_open: basic test of Unix98 PTYs functionality)
--SKIPIF--

--FILE--
 array("pty"),
   1 => array("pty"),
   2 => array("pty")
);
$process = proc_open("echo this is working", $descriptorspec, $pipes);
if (is_resource($process)) {
echo "OK\n";
while (!feof($pipes[1]))
echo fread($pipes[1],1024);
}
?>
--EXPECT--
OK
this is working



[2005-05-30 03:07:59] skissane at iips dot mq dot edu dot au

Wez (or someone else with CVS comitter rights): why not just check
Michael Spector's patch into CVS?
http://www.mail-archive.com/internals@lists.php.net/msg14854.html.

That should close this issue. No more of your time required :)



[2005-05-27 01:29:27] skissane at iips dot mq dot edu dot au

Tested with the patch you supplied. (Patch would not apply, so I had to
apply most of it by hand.) My test case works with the test you
supplied, and --enable-pty supplied as a config option.



[2005-05-26 10:16:03] [EMAIL PROTECTED]

Please test the patch in this letter:
http://www.mail-archive.com/internals@lists.php.net/msg14854.html



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/33147

-- 
Edit this bug report at http://bugs.php.net/?id=33147&edit=1


#33681 [Bgs]: PHP5+OLEDB(COM)+IIS pools DB connections, PHP5+OLEDB(COM)+Apache2 does not!

2005-07-14 Thread fjortiz at comunet dot es
 ID:   33681
 User updated by:  fjortiz at comunet dot es
 Reported By:  fjortiz at comunet dot es
 Status:   Bogus
 Bug Type: COM related
 Operating System: Win2K Server
 PHP Version:  5CVS-2005-07-13
 Assigned To:  wez
 New Comment:

remember that PHP5+IIS works fine, and PHP5+Apache2 does not. 
So this IS definitely a PHP5+Apache2 issue. I'll try asking the Apache2
guys (but I know the answer in advance: "ask the PHP guys")

Anyway, thanks for your efforts.


Previous Comments:


[2005-07-13 19:21:21] [EMAIL PROTECTED]

This isn't really a PHP bug.  It's more of an Apache bug, but even
then, it's not really Apaches fault either.

Assuming that the OLE DB stuff is actually routing out over ODBC, then
connection pooling much be explicitly enabled in the application by
making a couple of ODBC API calls.  Nothing in the PHP core nor in
Apache does this for you, because it can't possibly know that it
should.

I'm going to suggest a workaround for you; if it doesn't work, then
there is nothing more we can do to help.

Possible Workaround - load the PDO ODBC driver.
Using the latest PHP 5.1 snap (the one you have already will do):

Edit your php.ini file and add this line
extension=php_pdo_odbc.dll

Restart apache and re-run your tests

Why might this work? the php_pdo_odbc.dll makes the API calls that
enable connection ODBC pooling.

If it doesn't work, you can try migrating your script to use PDO and
the odbc driver itself.





[2005-07-13 19:04:32] [EMAIL PROTECTED]

Assigned to the maintainer.




[2005-07-13 18:23:02] fjortiz at comunet dot es

tried with latest version (5.1.0-dev) on Win32 but still the same.
Sorry.



[2005-07-13 17:54:23] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip





[2005-07-13 17:06:44] fjortiz at comunet dot es

Description:

Ok, this seems a tricky one, so sorry for the long post. It's related
to the way Apache2 and IIS work with COM objects. So maybe some
combined Apache2/IIS/Database/COM skills are needed.

I want to connect to a DB (MSSQL in this case), but I need some
features unavailable under php_mssql (asked to F. Kromman, thanks). So
I'm forced to use COM/OLEDB via ADODB.Connection. COM works great now
under PHP5 but...

I have this problem: 

If I use this combination:
PHP5+OLEDB(COM)+IIS: IIS keeps a pool of persistent connections so the
next PHP scripts re-use this open connection and doesn't have to open a
new one.

PHP5+OLEDB(COM)+Apache2: Apache2 works fine with the queries but at the
end of my PHP script, the connection is closed, and every subsecuent PHP
script has to open a new connection.

It's not a critical issue as long as your DB server is on the same
machine as the Web Server:

Open new connection on Apache2: 0.02 secs.
Re-use existing connection on IIS: 0.002 secs.

But it does matter if both are on different machines and/or while on
very heavy traffic web-sites.

My theory: not a COM guru, but maybe Apache2 lacks being compiled with
some COM Apartment threading model which IIS already has. I'm really
sad about being impelled to work with this COM/OLEDB shit but I'd
really like to get this working on PHP5+Apache2 (will have to swap to
PHP5+IIS if there is no way to solve this).

Thanks in advance


Reproduce code:
---
Open($dsn);

// sample query to get all the SQL Server processes for your Database,
along with the App that created them
// (Apache, IIS, others...)
$query="select distinct sd.name, sp.program_name from
master..sysprocesses sp
inner join master..sysdatabases sd on sd.dbid=sp.dbid 
where sd.name='$DB'
order by 1,2";

$rs = $db->Execute($query);

// some output
print "";
while (!$rs->EOF)   {
print
"".$rs->Fields["program_name"]->Value."".$rs->Fields["name"]->Value."\n";
$rs->MoveNext();
}
print "";
$db->Close();  // doesn't really matter, IIS keeps connection open,
Apache2 closes it even if this line is commented

?>

Expected result:

We list all the SQL Server open processes, during and after PHP script
execution:

select distinct sd.name, sp.program_name from master..sysprocesses sp
inner join master..sysdatabases sd on sd.dbid=sp.dbid 
where sd.name='nc208'
order by 1,2

While executing PHP5+Apache2:
databaseApache HTTP Server
databaseSQL Query Analyzer
 
databaseSQL Query Analyzer - Object

#32925 [Ver->Fbk]: HTTP Authentication is not carried through upon redirects.

2005-07-14 Thread sniper
 ID:   32925
 Updated by:   [EMAIL PROTECTED]
 Reported By:  wb at pro-net dot co dot uk
-Status:   Verified
+Status:   Feedback
 Bug Type: HTTP related
 Operating System: FreeBSD
 PHP Version:  5.0.4
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip




Previous Comments:


[2005-05-03 13:21:40] wb at pro-net dot co dot uk

Description:

When using fopen() it seems that authentication details are not passed
through upon a redirect and you will get a HTTP/1.1 401 Authorization
Required.

The server i am trying has a virtual host of the following...


ServerName some.redirect.com
RewriteEngine on
RewriteRule ^/(.*) http://www.redirect.com/redirect/$1 [R,L]


Which will just redirect the request to another location where
authentication is needed.


Reproduce code:
---
http://user:[EMAIL PROTECTED]/', 'rb');
print_r($fp);
?>


Expected result:

Resource id #2


Actual result:
--
PHP Warning:  fopen(): HTTP request failed! HTTP/1.1 401 Authorization
Required





-- 
Edit this bug report at http://bugs.php.net/?id=32925&edit=1