#32977 [NEW]: Alternative pg_query_params returning query
From: direvus at gmail dot com Operating system: Debian Linux PHP version: 5.0.4 PHP Bug Type: Feature/Change Request Bug description: Alternative pg_query_params returning query Description: pg_query_params is a neat function, and I think it would be useful to have a separate function which resolves the statement (makes all the parameter substitutions) and then returns the completed SQL statement string, rather than immediately executing it and returning the result set. You could, for example, have pg_resolve_params return the query string, and then have pg_query_params which essentially returns pg_query( pg_resolve_params( [...args...] ) ); Thoughts? BJ -- Edit bug report at http://bugs.php.net/?id=32977edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32977r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32977r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32977r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32977r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32977r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32977r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32977r=needscript Try newer version: http://bugs.php.net/fix.php?id=32977r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32977r=support Expected behavior: http://bugs.php.net/fix.php?id=32977r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32977r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32977r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32977r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32977r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32977r=dst IIS Stability: http://bugs.php.net/fix.php?id=32977r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32977r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32977r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32977r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32977r=mysqlcfg
#32973 [Opn-Bgs]: Problem with unbuffered prep. statements
ID: 32973
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: MySQLi related
Operating System: Linux
PHP Version: 5CVS-2005-05-07 (dev)
New Comment:
It makes no sense to do some magic and closing unbuffered statements
when executing mysql_prepare.
$stmt1 = $mysql-prepare(SELECT foo FROM bar);
$stmt1-execute();
$stmt2-prepare(SELECT foo FROM user);
So why should 2nd prepare automatically clean resultset from first
statement instead of giving an error ??
It's well documented that you have to either store the resultset or to
close the statement before executing any other command (execept you're
using cursors with MySQL 5.0).
The same is also true when executing unbuffered queries in ext/mysql
and ext/mysqli.
Previous Comments:
[2005-05-07 08:51:52] [EMAIL PROTECTED]
Description:
Prepare does not clean the wire before the next prepare. It should be
discussed whether it should be done but this bug is created to have a
track of this issue.
Reproduce code:
---
?php
$st = $db-prepare(SELECT 1 AS test);
$st-execute();
$st-bind_result($x);
$st-fetch();
var_dump($x);
$st = $db-prepare(SELECT 1.23 AS test);
var_dump($st);
$st-execute();
$st-bind_result($x);
$st-fetch();
var_dump($x);
?
Expected result:
int(1)
object(mysqli_stmt)#3 (0) {
}
string(4) 1.23
Actual result:
--
int(1)
bool(false)
PHP Fatal error: Call to a member function execute() on a non-object
in /home/andrey/tst/ttt.php on line 11
--
Edit this bug report at http://bugs.php.net/?id=32973edit=1
#32838 [Opn]: child processes opened with proc_open freeze the script
ID: 32838 User updated by: mjpph at stardust dot fi Reported By: mjpph at stardust dot fi Status: Open Bug Type: Program Execution Operating System: Linux PHP Version: 5.0.4 New Comment: It looks like the newest snapshot has fixed the issue. I've been now running the scripts for 55 hours without one single failure. Before this atleast one, most likely half of the scripts would have freezed already. I'll send some more feedback after few more days of testing. Previous Comments: [2005-05-06 09:07:54] mjpph at stardust dot fi Ok I'll try that snapshot. One thing I notice too, all version seem to have PTY support of the proc_open disabled. It can be easily seen by checking ext/standard/proc_open.c which has two pty-related defines which start by 0 . I changed these and got fully working proc_open PTY support on my system. This didn't have any effect on the freezing problem though. Maybe the PTY support is still buggy or someone has tested something and forgot to enable it? Just as a sidenote. [2005-05-06 03:21:59] [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-05-05 15:16:41] mjpph at stardust dot fi More info. I have a identical script running on a machine with PHP 5.0.0RC3, it has no problems mentioned here. All scripts run perfectly well. When I run the identical script on 5.0.4 it freezes after some time of runtime almost without exceptions. Both are CLI versions compiled from the source. The hltv-runner started to freeze after I upgraded PHP from 5.0.0RC3 to 5.0.4, it never did before the upgrade. [2005-05-02 18:10:33] mjpph at stardust dot fi I'm using PHP's CLI version. Also I noticed that when I upgraded an earlier 5.x PHP to 5.0.4 it started to freeze one process runner which has always worked perfectly. The script was unchanged. Test code can be anything that just simply opens a child process which has atleast relatively high output and keeps listening to it for a long time (several hours, days). I'll add two simple test scripts asap. [2005-04-28 00:10:25] [EMAIL PROTECTED] Also specify which SAPI you are using: eg: Apache, CLI, CGI. Note that launching a CGI child process from either Apache or an existing CGI process is going to bite you unless you clean up the environmental variables you pass on to the child process. 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/32838 -- Edit this bug report at http://bugs.php.net/?id=32838edit=1
#32932 [Opn-Csd]: Oracle LDAP: ldap_get_entries invalid pointer
ID: 32932 Updated by: [EMAIL PROTECTED] Reported By: frameloss at gmail dot com -Status: Open +Status: Closed Bug Type: LDAP related Operating System: Fedora Core 3 -PHP Version: 5.0.4 +PHP Version: 4.3.11, 5.0.4 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-05-06 20:11:30] frameloss at gmail dot com (gdb) set args /usr/local/apache/htdocs/reporting/test/ldap-orig.php (gdb) run Starting program: /root/SOURCE/Web/PHP/snap-5-6-2005/php5-200505061630/sapi/cli/php /usr/local/apache/htdocs/reporting/test/ldap-orig.php [Thread debugging using libthread_db enabled] [New Thread -1208383808 (LWP 2916)] ldap_connect function availablebrpre/preh3LDAP query test/h3... Connecting ... resource(4) of type (ldap link) connect result is pre Resource id #4/prebr /Binding ...Bind result is 1br /Searching for username ...Search result is Resource id #5br /Number of entires returned is 1br /Getting entries ...p*** glibc detected *** free(): invalid pointer: 0xb7cf3e40 *** Program received signal SIGABRT, Aborted. [Switching to Thread -1208383808 (LWP 2916)] 0x001e07a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (gdb) bt #0 0x001e07a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00827955 in raise () from /lib/tls/libc.so.6 #2 0x00829319 in abort () from /lib/tls/libc.so.6 #3 0x0085af9a in __libc_message () from /lib/tls/libc.so.6 #4 0x00861528 in _int_free () from /lib/tls/libc.so.6 #5 0x00861afa in free () from /lib/tls/libc.so.6 #6 0x080ebbc8 in zif_ldap_get_entries (ht=2, return_value=0x951972c, this_ptr=0x0, return_value_used=1) at /root/SOURCE/Web/PHP/snap-5-6-2005/php5-200505061630/ext/ldap/ldap.c:1085 #7 0x082bf226 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff26660) at zend_vm_execute.h:175 #8 0x082c340a in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xbff26660) at zend_vm_execute.h:1544 #9 0x082bef3f in execute (op_array=0x951794c) at zend_vm_execute.h:78 #10 0x0829a12b in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/SOURCE/Web/PHP/snap-5-6-2005/php5-200505061630/Zend/zend.c:1063 #11 0x08259c45 in php_execute_script (primary_file=0xbff28a80) at /root/SOURCE/Web/PHP/snap-5-6-2005/php5-200505061630/main/main.c:1653 #12 0x0830f9d2 in main (argc=2, argv=0xbff28b44) at /root/SOURCE/Web/PHP/snap-5-6-2005/php5-200505061630/sapi/cli/php_cli.c:954 (gdb) [2005-05-06 03:14:13] [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 And if it still fails, provide new GDB backtrace. [2005-05-04 17:25:15] frameloss at gmail dot com Backtrace, using CLI php . . . (gdb) set args /usr/local/apache/htdocs/reporting/test/ldap.php (gdb) run Starting program: /root/SOURCE/Web/PHP/php-5.0.4/sapi/cli/php /usr/local/apache/htdocs/reporting/test/ldap.php [Thread debugging using libthread_db enabled] [New Thread -1208379712 (LWP 3230)] ldap_connect function availablebrpre/preh3LDAP query test/h3... Connecting ... resource(4) of type (ldap link) connect result is pre Resource id #4/prebr /Binding ...Bind result is 1br /Searching for username ...Search result is Resource id #5br /Number of entires returned is 1br /Getting entries ...p*** glibc detected *** free(): invalid pointer: 0xb7cf4e40 *** Program received signal SIGABRT, Aborted. [Switching to Thread -1208379712 (LWP 3230)] 0x001e07a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (gdb) bt #0 0x001e07a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x009b5955 in raise () from /lib/tls/libc.so.6 #2 0x009b7319 in abort () from /lib/tls/libc.so.6 #3 0x009e8f9a in __libc_message () from /lib/tls/libc.so.6 #4 0x009ef528 in _int_free () from /lib/tls/libc.so.6 #5 0x009efafa in free () from /lib/tls/libc.so.6 #6 0x080e25b8 in zif_ldap_get_entries (ht=2, return_value=0x8633e94, this_ptr=0x0, return_value_used=1) at /root/SOURCE/Web/PHP/php-5.0.4/ext/ldap/ldap.c:998 #7 0x0825b999 in zend_do_fcall_common_helper (execute_data=0xbfe04fe0, opline=0x86393ac, op_array=0x8631d54) at /root/SOURCE/Web/PHP/php-5.0.4/Zend/zend_execute.c:2727 #8 0x0825c188 in zend_do_fcall_handler (execute_data=0xbfe04fe0, opline=0x86393ac, op_array=0x8631d54) at /root/SOURCE/Web/PHP/php-5.0.4/Zend/zend_execute.c:2859 #9 0x08256b56 in execute (op_array=0x8631d54) at /root/SOURCE/Web/PHP/php-5.0.4/Zend/zend_execute.c:1406 #10 0x08232d8d in zend_execute_scripts (type=8,
#31646 [Com]: imap_mail_compose() don't work when body[][charset] has been set
ID: 31646 Comment by: gandie at rootshell dot cz Reported By: webmaster at alikuvkoutek dot cz Status: No Feedback Bug Type: IMAP related Operating System: Linux PHP Version: 5CVS-2005-01-21 (dev) New Comment: BACKTRACE: #0 0xb79007d4 in free () from /lib/libc.so.6 #1 0x082e51ee in fs_give () #2 0x08351b47 in _IO_stdin_used () #3 0x in ?? () #4 0x in ?? () #5 0x0851d1a0 in ?? () #6 0x0882e528 in ?? () #7 0x0882e588 in ?? () #8 0x0882e520 in ?? () #9 0x082fe788 in mail_free_body_parameter () #10 0x0882e578 in ?? () #11 0x0851d1a0 in ?? () #12 0x0882e528 in ?? () #13 0x082fe5a2 in mail_free_body_data () #14 0xbfffacc4 in ?? () #15 0x0882e598 in ?? () #16 0xbfffacc0 in ?? () #17 0x082fe548 in mail_free_body () #18 0x0882e520 in ?? () #19 0x0882e694 in ?? () #20 0x0882bcbc in ?? () #21 0x0810cfc0 in zif_imap_mail_compose () #22 0x in ?? () (gdb) frame 21 #21 0x0810cfc0 in zif_imap_mail_compose () (gdb) frame 22 #22 0x in ?? () Previous Comments: [2005-02-07 01:00:04] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2005-01-21 21:30:12] [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. Also, I should note that I can't reproduce it with both 5.x snapshots. [2005-01-21 20:58:43] webmaster at alikuvkoutek dot cz ? $envelope[from]= '[EMAIL PROTECTED]'; $envelope[return_path]= '[EMAIL PROTECTED]'; $envelope[custom_headers][] = X-Priority: 3; $body[1][type]=TYPETEXT; $body[1][subtype]=plain; $body[1][encoding]=ENCQUOTEDPRINTABLE ; $body[1][charset]='windows-1250'; // when removed, all is ok $body[1][contents.data]='text'; $envelope = unserialize(serialize($envelope)); $body = unserialize(serialize($body)); echo nl2br( imap_mail_compose($envelope, $body) ); ? hr / [2005-01-21 20:47:20] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2005-01-21 19:27:01] webmaster at alikuvkoutek dot cz Description: When set $body[][charset], the imap_mail_compose() don't work. The script is terminated on that line and no output is generated. The source code and information from phpinfo() is available over the URL (links are on the top of the page). Reproduce code: --- http://www.alikuvkoutek.cz/t.php -- Edit this bug report at http://bugs.php.net/?id=31646edit=1
#31646 [NoF-Opn]: imap_mail_compose() don't work when body[][charset] has been set
ID: 31646 User updated by: webmaster at alikuvkoutek dot cz Reported By: webmaster at alikuvkoutek dot cz -Status: No Feedback +Status: Open Bug Type: IMAP related Operating System: Linux -PHP Version: 5CVS-2005-01-21 (dev) +PHP Version: 5CVS-2005-05-05 (dev) New Comment: Build Date May 5 2005 09:49:05 See backtrace from gandie. Previous Comments: [2005-05-08 21:48:05] gandie at rootshell dot cz BACKTRACE: #0 0xb79007d4 in free () from /lib/libc.so.6 #1 0x082e51ee in fs_give () #2 0x08351b47 in _IO_stdin_used () #3 0x in ?? () #4 0x in ?? () #5 0x0851d1a0 in ?? () #6 0x0882e528 in ?? () #7 0x0882e588 in ?? () #8 0x0882e520 in ?? () #9 0x082fe788 in mail_free_body_parameter () #10 0x0882e578 in ?? () #11 0x0851d1a0 in ?? () #12 0x0882e528 in ?? () #13 0x082fe5a2 in mail_free_body_data () #14 0xbfffacc4 in ?? () #15 0x0882e598 in ?? () #16 0xbfffacc0 in ?? () #17 0x082fe548 in mail_free_body () #18 0x0882e520 in ?? () #19 0x0882e694 in ?? () #20 0x0882bcbc in ?? () #21 0x0810cfc0 in zif_imap_mail_compose () #22 0x in ?? () (gdb) frame 21 #21 0x0810cfc0 in zif_imap_mail_compose () (gdb) frame 22 #22 0x in ?? () [2005-02-07 01:00:04] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2005-01-21 21:30:12] [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. Also, I should note that I can't reproduce it with both 5.x snapshots. [2005-01-21 20:58:43] webmaster at alikuvkoutek dot cz ? $envelope[from]= '[EMAIL PROTECTED]'; $envelope[return_path]= '[EMAIL PROTECTED]'; $envelope[custom_headers][] = X-Priority: 3; $body[1][type]=TYPETEXT; $body[1][subtype]=plain; $body[1][encoding]=ENCQUOTEDPRINTABLE ; $body[1][charset]='windows-1250'; // when removed, all is ok $body[1][contents.data]='text'; $envelope = unserialize(serialize($envelope)); $body = unserialize(serialize($body)); echo nl2br( imap_mail_compose($envelope, $body) ); ? hr / [2005-01-21 20:47:20] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. 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/31646 -- Edit this bug report at http://bugs.php.net/?id=31646edit=1
#32957 [Fbk-Csd]: putenv(A=A);putenv(A=); CRASH
ID: 32957
Updated by: [EMAIL PROTECTED]
Reported By: ukm at servplus dot ru
-Status: Feedback
+Status: Closed
Bug Type: Reproducible crash
Operating System: win xp sp2
PHP Version: 4.3.11
Assigned To: wez
New Comment:
Yes, that fixed it. Committed.
Previous Comments:
[2005-05-08 04:07:48] [EMAIL PROTECTED]
Not such a useful trace :-/
You should be able to link against the debug version of the libc or
download the .pdb files for the release version to get more info.
I've just glanced at the putenv code in the 4.3 branch, and it doesn't
have my workaround that's in the 5.x branches.
Can you try merging the two places where we have:
#if _MSC_VER = 1300
/* VS.Net has a bug in putenv() when setting a variable that
* is already set; if the SetEnvironmentVariable() API call
* fails, the Crt will double free() a string.
* We try to avoid this by setting our own value first */
SetEnvironmentVariable(pe.key, bugbug);
#endif
from basic_functions.c back into the 4.3 branch, but change the #if
_MSC_VER = 1300 into just #if _MSC_VER, so that it is used
regardless of which version of the MS compiler is being used?
[2005-05-08 03:45:34] [EMAIL PROTECTED]
Wez, here's the callstack:
NTDLL! 77f57ec4()
MSVCRT! 77c1ac14()
MSVCRT! 77c1ac2a()
MSVCRT! 77c241a7()
zif_putenv(int 1, _zval_struct * 0x01299878, _zval_struct * 0x,
int 0, void * * * 0x01172948) line 1433 + 12 bytes
execute(_zend_op_array * 0x01298f88, void * * * 0x01172948) line 1654 +
47 bytes
zend_execute_scripts(int 8, void * * * 0x01172948, _zval_struct * *
0x, int 3) line 926 + 34 bytes
php_execute_script(_zend_file_handle * 0x0012ff54, void * * *
0x01172948) line 1747 + 27 bytes
main(int 2, char * * 0x01172580) line 828 + 14 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e8141a()
Let me know if you need something else..I'm not very good with
debugging under win32. :)
[2005-05-05 22:09:03] [EMAIL PROTECTED]
tony2001: ms libc putenv function does have at least one segfault bug
that we have a workaround for. Someone needs to check a debug build of
4.3 on windows; preferably someone with MS VC 6 installed, as the libc
has changed between releases. I'd check it myself, but I only have
vs.net installed, so it would be a bogus check.
[2005-05-05 16:22:00] ukm at servplus dot ru
Description:
During the execution on this fragment with php.exe this application
error occures:
The instruction at 0x... referenced memory at 0x.
The memory could not be written.
Reproduce code:
---
?php
for($i = 0; $i 100; ++$i)
{
putenv(VAR=VALUE);
putenv(VAR=);
}
?
--
Edit this bug report at http://bugs.php.net/?id=32957edit=1
#32800 [Opn-Fbk]: 64 bit linux + php + IBM DB2
ID: 32800 Updated by: [EMAIL PROTECTED] Reported By: tinko at siol dot com -Status: Open +Status: Feedback Bug Type: ODBC related Operating System: SLES9 64 bit PHP Version: 4.3.11 New Comment: Exactly what did you do? (there was no feedback on the other report..) Previous Comments: [2005-05-03 10:26:18] tinko at siol dot com Problem solved with Your answer. Thank You very much. Tinko [2005-04-27 16:13:40] [EMAIL PROTECTED] Might be related to bug #32830 [2005-04-22 11:38:50] tinko at siol dot com Description: Hello! Kinda desperate here, since I've read all about php + db2 + apache, so is there a soul to help me? I'm running SLES 9 (also SLES8 - the problem is the same) under z/VM on z900 (1IFL) in 64 bit mode/version. I successfuly installed IBM DB2 8.1 ESE (64 bit) with latest FixPacks. DB2 runs fine, I can connect to DB2 on z/OS... I've compiled (many versions) of php (with -m64) with IBM-DB2 included ... everything by the manual, and everything works fine - apache+php connect, insert, odbc_result_all, but when trying to do odbc_result with fetching i get the number of rows with no values... After running query for several times I get emalloc errors in apache log... (I've tried many different shapes of queries...allways the same result) I've also tried to do the same configuration on 32 bit linux on intel ...same php, db2, queries etc - everything works perfect and fast. So, i think there must be a 64 bit issue... Any1 has any ideas? Please, please help Thank You very much in advance, Tinko Reproduce code: --- I found this... In file included from /home/db2inst1/sqllib/include/sqlcli1.h:42, from /ins/php-4.3.11/ext/odbc/php_odbc_includes.h:176, from /ins/php-4.3.11/ext/odbc/php_odbc.c:37: /home/db2inst1/sqllib/include/sqlcli.h:772:1: warning: ODBCVER redefined In file included from /ins/php-4.3.11/ext/odbc/php_odbc.c:37: /ins/php-4.3.11/ext/odbc/php_odbc_includes.h:28:1: warning: this is the location of the previous definition /ins/php-4.3.11/ext/odbc/php_odbc.c: In function `safe_odbc_disconnect': /ins/php-4.3.11/ext/odbc/php_odbc.c:201: warning: passing arg 1 of `SQLDisconnect' makes integer from pointer without a cast /ins/php-4.3.11/ext/odbc/php_odbc.c:204: warning: passing arg 1 of `SQLTransact' makes integer from pointer without a cast /ins/php-4.3.11/ext/odbc/php_odbc.c:204: warning: passing arg 2 of `SQLTransact' makes integer from pointer without a cast /ins/php-4.3.11/ext/odbc/php_odbc.c:205: warning: passing arg 1 of `SQLDisconnect' makes integer from pointer without a cast /ins/php-4.3.11/ext/odbc/php_odbc.c: In function `_close_odbc_conn': /ins/php-4.3.11/ext/odbc/php_odbc.c:231: warning: passing arg 1 of `safe_odbc_disconnect' makes pointer from integer without a cast /ins/php-4.3.11/ext/odbc/php_odbc.c: In function `_close_odbc_pconn': /ins/php-4.3.11/ext/odbc/php_odbc.c:259: warning: passing arg 1 of `safe_odbc_disconnect' makes pointer from integer without a cast /ins/php-4.3.11/ext/odbc/php_odbc.c: In function `odbc_bindcols': /ins/php-4.3.11/ext/odbc/php_odbc.c:676: warning: passing arg 6 of `SQLBindCol' from incompatible pointer type /ins/php-4.3.11/ext/odbc/php_odbc.c: In function `zif_odbc_execute': /ins/php-4.3.11/ext/odbc/php_odbc.c:1042: warning: cast to pointer from integer of different size /ins/php-4.3.11/ext/odbc/php_odbc.c: In function `zif_odbc_data_source': /ins/php-4.3.11/ext/odbc/php_odbc.c:1223: warning: passing arg 2 of `odbc_sql_error' makes integer from pointer without a cast /ins/php-4.3.11/ext/odbc/php_odbc.c: In function `php_odbc_fetch_hash': /ins/php-4.3.11/ext/odbc/php_odbc.c:1434: warning: passing arg 6 of `SQLGetData' from incompatible pointer type /ins/php-4.3.11/ext/odbc/php_odbc.c: In function `zif_odbc_fetch_into': /ins/php-4.3.11/ext/odbc/php_odbc.c:1594: warning: passing arg 6 of `SQLGetData' from incompatible pointer type /ins/php-4.3.11/ext/odbc/php_odbc.c: In function `zif_odbc_result': /ins/php-4.3.11/ext/odbc/php_odbc.c:1825: warning: passing arg 6 of `SQLGetData' from incompatible pointer type /ins/php-4.3.11/ext/odbc/php_odbc.c:1868: warning: passing arg 6 of `SQLGetData' from incompatible pointer type /ins/php-4.3.11/ext/odbc/php_odbc.c: In function `zif_odbc_result_all': /ins/php-4.3.11/ext/odbc/php_odbc.c:1972: warning: passing arg 6 of `SQLGetData' from incompatible pointer type /ins/php-4.3.11/ext/odbc/php_odbc.c: In function `odbc_do_connect': /ins/php-4.3.11/ext/odbc/php_odbc.c:2302: warning: cast from pointer to integer of different size -- Edit this bug report at
#32979 [NEW]: socket stream opened with stream_socket_client doesnt work with stream_select
From: mjpph at stardust dot fi
Operating system: Linux (Fedora Core 3)
PHP version: 5CVS-2005-05-08 (dev)
PHP Bug Type: CGI related
Bug description: socket stream opened with stream_socket_client doesnt work
with stream_select
Description:
Using stream_socket_client or stream_socket_server to open a connection
fails to report correct values with stream_select. Using fread to get one
byte before stream_select suddenly makes stream_select work as expected.
Without it stream_select returns 0 changed streams even though there is
data waiting. Service used as an endpoint is persistent and doesn't close
the connection after it's output. PHP is CLI-version.
Reproduce code:
---
$c = stream_socket_client(tcp://127.0.0.1:80);
while (1)
{
$streams = array($c);
if (stream_select($streams, $write=NULL, $except=NULL, 0, 5000)) {
print Data received\n;
}
}
// IP:Port can be anything which outputs something after connection.
Expected result:
Text Data received after connection and output from the service. The
service can be anything which just outputs something right after connect.
Actual result:
--
Nothing. stream_select returns 0 even though there is data waiting.
--
Edit bug report at http://bugs.php.net/?id=32979edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32979r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32979r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32979r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32979r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32979r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32979r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32979r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32979r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32979r=support
Expected behavior: http://bugs.php.net/fix.php?id=32979r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32979r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32979r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32979r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32979r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32979r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32979r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32979r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32979r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32979r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32979r=mysqlcfg
#32979 [Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979
User updated by: mjpph at stardust dot fi
Reported By: mjpph at stardust dot fi
Status: Open
Bug Type: CGI related
Operating System: Linux (Fedora Core 3)
PHP Version: 5CVS-2005-05-08 (dev)
New Comment:
Also, adding fread($c,1); after stream_socket_client and before the
while loop enables correct functionality of the stream_select function
from that pont on.
Previous Comments:
[2005-05-08 22:18:29] mjpph at stardust dot fi
Description:
Using stream_socket_client or stream_socket_server to open a connection
fails to report correct values with stream_select. Using fread to get
one byte before stream_select suddenly makes stream_select work as
expected.
Without it stream_select returns 0 changed streams even though there is
data waiting. Service used as an endpoint is persistent and doesn't
close the connection after it's output. PHP is CLI-version.
Reproduce code:
---
$c = stream_socket_client(tcp://127.0.0.1:80);
while (1)
{
$streams = array($c);
if (stream_select($streams, $write=NULL, $except=NULL, 0, 5000)) {
print Data received\n;
}
}
// IP:Port can be anything which outputs something after connection.
Expected result:
Text Data received after connection and output from the service. The
service can be anything which just outputs something right after
connect.
Actual result:
--
Nothing. stream_select returns 0 even though there is data waiting.
--
Edit this bug report at http://bugs.php.net/?id=32979edit=1
#32979 [Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979
User updated by: mjpph at stardust dot fi
Reported By: mjpph at stardust dot fi
Status: Open
Bug Type: CGI related
Operating System: Linux (Fedora Core 3)
PHP Version: 5CVS-2005-05-08 (dev)
New Comment:
Correction to the previous comment. The fread has to be done before
every stream_select to obtain any other value from stream_select other
than 0. stream_get_meta_data also reports pending data as 0 before the
fread and non-zero value right after the 1 byte fread.
Previous Comments:
[2005-05-08 22:46:55] mjpph at stardust dot fi
Also, adding fread($c,1); after stream_socket_client and before the
while loop enables correct functionality of the stream_select function
from that pont on.
[2005-05-08 22:18:29] mjpph at stardust dot fi
Description:
Using stream_socket_client or stream_socket_server to open a connection
fails to report correct values with stream_select. Using fread to get
one byte before stream_select suddenly makes stream_select work as
expected.
Without it stream_select returns 0 changed streams even though there is
data waiting. Service used as an endpoint is persistent and doesn't
close the connection after it's output. PHP is CLI-version.
Reproduce code:
---
$c = stream_socket_client(tcp://127.0.0.1:80);
while (1)
{
$streams = array($c);
if (stream_select($streams, $write=NULL, $except=NULL, 0, 5000)) {
print Data received\n;
}
}
// IP:Port can be anything which outputs something after connection.
Expected result:
Text Data received after connection and output from the service. The
service can be anything which just outputs something right after
connect.
Actual result:
--
Nothing. stream_select returns 0 even though there is data waiting.
--
Edit this bug report at http://bugs.php.net/?id=32979edit=1
#32979 [Opn]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979
User updated by: mjpph at stardust dot fi
Reported By: mjpph at stardust dot fi
Status: Open
Bug Type: CGI related
Operating System: Linux (Fedora Core 3)
PHP Version: 5CVS-2005-05-08 (dev)
New Comment:
The issue is the same when using stream_socket_server.
stream_socket_accept works as expected, but if you select the socket it
always returns 0, even if there is a pending connection which would be
returned with stream_socket_accept.
Previous Comments:
[2005-05-08 22:50:58] mjpph at stardust dot fi
Correction to the previous comment. The fread has to be done before
every stream_select to obtain any other value from stream_select other
than 0. stream_get_meta_data also reports pending data as 0 before the
fread and non-zero value right after the 1 byte fread.
[2005-05-08 22:46:55] mjpph at stardust dot fi
Also, adding fread($c,1); after stream_socket_client and before the
while loop enables correct functionality of the stream_select function
from that pont on.
[2005-05-08 22:18:29] mjpph at stardust dot fi
Description:
Using stream_socket_client or stream_socket_server to open a connection
fails to report correct values with stream_select. Using fread to get
one byte before stream_select suddenly makes stream_select work as
expected.
Without it stream_select returns 0 changed streams even though there is
data waiting. Service used as an endpoint is persistent and doesn't
close the connection after it's output. PHP is CLI-version.
Reproduce code:
---
$c = stream_socket_client(tcp://127.0.0.1:80);
while (1)
{
$streams = array($c);
if (stream_select($streams, $write=NULL, $except=NULL, 0, 5000)) {
print Data received\n;
}
}
// IP:Port can be anything which outputs something after connection.
Expected result:
Text Data received after connection and output from the service. The
service can be anything which just outputs something right after
connect.
Actual result:
--
Nothing. stream_select returns 0 even though there is data waiting.
--
Edit this bug report at http://bugs.php.net/?id=32979edit=1
#32850 [NoF-Csd]: PHP crashes on startup because zend_do_implement_interface is called with NULL
ID: 32850 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Closed Bug Type: SQLite related Operating System: Debian Sarge Unstable PHP Version: 5CVS-2005-04-27 (dev) New Comment: using gawk fixes the extension load order problem Previous Comments: [2005-05-07 01:00:04] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2005-04-29 16:36:20] [EMAIL PROTECTED] Well yeah it does not crash for me on other systems, too... But it crashes on a more or less fresh install of Debian Sarge Unstable. And the configure line does not matter... Same behaviour with ./configure --with-apxs=... ./configure ./configure bunch of options I have really no clue why it dies on that one system, because I have nothing unusual on it... (But I will look into it again tonight...) [2005-04-29 02:25:58] [EMAIL PROTECTED] It doesn't crash for me (either, as I guess it didn't for Antony?). So..start with the configure line you used? :) [2005-04-28 22:46:11] [EMAIL PROTECTED] PHP crashes in the second I invoke ./php Like the backtrace shows it dies when loading sqlite extension because it ends up calling zend_do_implement_interface (ce=0x82f2ca0, iface=0x0) --- with a 0x0 NULL pointer [2005-04-28 22:00:13] [EMAIL PROTECTED] Any info on how to reproduce it? 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/32850 -- Edit this bug report at http://bugs.php.net/?id=32850edit=1
#32979 [Opn-Fbk]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979
Updated by: [EMAIL PROTECTED]
Reported By: mjpph at stardust dot fi
-Status: Open
+Status: Feedback
Bug Type: CGI related
Operating System: Linux (Fedora Core 3)
PHP Version: 5CVS-2005-05-08 (dev)
New Comment:
Is the server end of the socket talking http?
If not, does it send data to the client immediately upon client
connection (without expecting data from the client first)?
If not, stream_select() is working precisely as it should.
Also note that stream_select() tells you only if a read or write would
not block, not whether there actually is data pending.
Previous Comments:
[2005-05-08 23:06:40] mjpph at stardust dot fi
The issue is the same when using stream_socket_server.
stream_socket_accept works as expected, but if you select the socket it
always returns 0, even if there is a pending connection which would be
returned with stream_socket_accept.
[2005-05-08 22:50:58] mjpph at stardust dot fi
Correction to the previous comment. The fread has to be done before
every stream_select to obtain any other value from stream_select other
than 0. stream_get_meta_data also reports pending data as 0 before the
fread and non-zero value right after the 1 byte fread.
[2005-05-08 22:46:55] mjpph at stardust dot fi
Also, adding fread($c,1); after stream_socket_client and before the
while loop enables correct functionality of the stream_select function
from that pont on.
[2005-05-08 22:18:29] mjpph at stardust dot fi
Description:
Using stream_socket_client or stream_socket_server to open a connection
fails to report correct values with stream_select. Using fread to get
one byte before stream_select suddenly makes stream_select work as
expected.
Without it stream_select returns 0 changed streams even though there is
data waiting. Service used as an endpoint is persistent and doesn't
close the connection after it's output. PHP is CLI-version.
Reproduce code:
---
$c = stream_socket_client(tcp://127.0.0.1:80);
while (1)
{
$streams = array($c);
if (stream_select($streams, $write=NULL, $except=NULL, 0, 5000)) {
print Data received\n;
}
}
// IP:Port can be anything which outputs something after connection.
Expected result:
Text Data received after connection and output from the service. The
service can be anything which just outputs something right after
connect.
Actual result:
--
Nothing. stream_select returns 0 even though there is data waiting.
--
Edit this bug report at http://bugs.php.net/?id=32979edit=1
#32971 [Fbk-Opn]: SIGPIPE Broken Pipe, occurs on one of two machines
ID: 32971 User updated by: saeven at saeven dot net Reported By: saeven at saeven dot net -Status: Feedback +Status: Open Bug Type: Zend Engine 2 problem Operating System: Fedora Core 2 PHP Version: 5.0.4 New Comment: Hi, Having compiled with --enable-debug, being forced then to use the unencoded version, the problem no longer occurs. The bug then safely can be assumed to be with Zend Optimizer? Where should I direct a Zend Optimizer bug report? Thanks! Alex Previous Comments: [2005-05-07 03:29:56] [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. your stack trace is not useful for two reasons: - you need to build a debug build of PHP (which means running without the zend optimizer) - gdb will catch signals like SIGPIPE that are otherwise handled by the program being debugged. You can either tell gdb to cont when you see that message, or create a .gdbinit file that has handle SIGPIPE nostop in it. [2005-05-06 22:16:54] saeven at saeven dot net Description: Inclusion of a custom user session object at a particular point causes segmentation faults. Occurs in both Zend optimized and un-optimized code. Works on several machines, but fails on a distinct few as well. Apache as well as PHP have been recompiled. Help interpreting the stack trace would be appreciated. Actual result: -- Program received signal SIGPIPE, Broken pipe. [Switching to Thread -1208590208 (LWP 15537)] 0x0060d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (gdb) bt #0 0x0060d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x006d9eac in writev () from /lib/tls/libc.so.6 #2 0x08073fb9 in ssl_io_hook_writev () #3 0x080ac402 in ap_hook_call_func () #4 0x080abbea in ap_hook_call () #5 0x080884c4 in writev_it_all () #6 0x08088859 in large_write () #7 0x0808891c in ap_bwrite () #8 0x0809beee in ap_rwrite () #9 0x0030b9a3 in ?? () from /usr/local/apache/libexec/libphp5.so #10 0x002c6b8b in ?? () from /usr/local/apache/libexec/libphp5.so #11 0x002c6bf9 in ?? () from /usr/local/apache/libexec/libphp5.so #12 0x002c5dfe in ?? () from /usr/local/apache/libexec/libphp5.so #13 0x002e8639 in ?? () from /usr/local/apache/libexec/libphp5.so #14 0x002e85df in ?? () from /usr/local/apache/libexec/libphp5.so #15 0x002e8130 in ?? () from /usr/local/apache/libexec/libphp5.so #16 0x00b13849 in get_module () from /usr/local/Zend/lib/Optimizer-2.5.7/php-5.0.x/ZendOptimizer.so #17 0x00b79738 in ?? () from /usr/local/Zend/lib/Optimizer-2.5.7/php-5.0.x/ZendOptimizer.so #18 0x003956f4 in ?? () from /usr/local/apache/libexec/libphp5.so #19 0x00b134a0 in get_module () from /usr/local/Zend/lib/Optimizer-2.5.7/php-5.0.x/ZendOptimizer.so #20 0x00b7c6e0 in ?? () from /usr/local/Zend/lib/Optimizer-2.5.7/php-5.0.x/ZendOptimizer.so #21 0xbfe1caf8 in ?? () #22 0xbfe1cb38 in ?? () #23 0x00b79738 in ?? () from /usr/local/Zend/lib/Optimizer-2.5.7/php-5.0.x/ZendOptimizer.so #24 0x00b7c6e0 in ?? () from /usr/local/Zend/lib/Optimizer-2.5.7/php-5.0.x/ZendOptimizer.so #25 0xbfe1caf8 in ?? () #26 0x in ?? () -- Edit this bug report at http://bugs.php.net/?id=32971edit=1
#32312 [Bgs]: Error in PCRE
ID: 32312
User updated by: xanthor at xanthor dot tk
Reported By: xanthor at xanthor dot tk
Status: Bogus
Bug Type: PCRE related
Operating System: *
PHP Version: 4CVS, 5CVS (2005-03-19)
New Comment:
And were are submited PCRElib bugs ?
Previous Comments:
[2005-04-20 09:04:40] [EMAIL PROTECTED]
It's the PCRElib limitation again..
[2005-03-19 00:07:33] [EMAIL PROTECTED]
No, it doesn't return 'bool(true)' as preg_match() returns an integer.
Try with something like 'var_dump(preg_match...'
Also RTFM.
[2005-03-16 21:31:52] xanthor at xanthor dot tk
It works with 4.3.2
[2005-03-15 10:32:34] xanthor at xanthor dot tk
Description:
The following code returns a wrong result with some strings, but when
we reduce them, it swich back to expected behaviour.
Tested on PHP 4.3.10, 4.3.9, 5.0.2, and 5.0.3RC2
PCRE Library Version = 4.5 01-December-2003
Reproduce code:
---
preg_match(/((.*.*.*)*.(.*.+.+..+)*b)?/,''.str_repeat('a',14).''.str_repeat('a',33).'a'.str_repeat('a',92).'a'.str_repeat('a',8).'aa')
Expected result:
This code should return true
Actual result:
--
The code returns false.
Reduce one of the str_repeat, and it'll return true.
--
Edit this bug report at http://bugs.php.net/?id=32312edit=1
