Bug #15980 Updated: can't install php4
ID: 15980
Updated by: [EMAIL PROTECTED]
-Summary: can't install php4
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Documentation problem
Operating System: Linux mandrake 7.2
PHP Version: 4.1.2
New Comment:
dear sir/madam,
i have installed flex and bison again. however the same problems still
occurred. (my procedure is : download the flex-2.5.4a.tar.gz and
bison-1.33.tar.gz ) then copy to /usr/local/ and go to their directory
and ./configure and make and make install.
Finally, i go to /usr/local/php-4.1.2/
and cd /usr/local/php-4.1.2
./configure --with-apxs=/usr/local/apache/bin/apxs \
--with-mysql \
--enable-track-vars
:(
but the same problem is still here
thanks
Rgds,
arthur
Previous Comments:
[2002-03-10 22:42:20] [EMAIL PROTECTED]
You need to install flex.. ask further support questions
on the mailing lists. http://www.php.net/support.php
(Reclassified as documentation problem, FAQ's build section should have
entry for this :)
[2002-03-10 21:11:09] [EMAIL PROTECTED]
Dear sir/madam,
my OS is Linux Mandrake 7.2 and i install apache as my web server and
mysql as my database. (Perl is also pre loaded)
However, i tried to install PHP by use php*.tar.gz or *.rpm are both
failed. i don't know why. Isn't the computer missed some gcc (compilers
such as C compiler or others). Please give me a hand . thanks.
when i tried to install by using un-tar *.tar.gz. the error is as
below:
firstly, i saved the un-tar directory in /tmp/php-4.1.2/**
it is a root user too.
The error as below:
**
[root@i-arthur php-4.1.2]# ./configure
loading cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... missing
checking for working autoconf... missing
checking for working automake... missing
checking for working autoheader... missing
checking for working makeinfo... missing
checking whether to enable maintainer-specific portions of Makefiles...
no
checking host system type... i686-pc-linux-gnu
checking for gawk... gawk
checking for bison... bison -y
checking bison version... 1.28 (ok)
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for AIX... no
checking for gcc option to accept ANSI C... none needed
checking for ranlib... ranlib
checking whether gcc and cc understand -c and -o together... yes
checking whether ln -s works... yes
checking for flex... lex
checking for yywrap in -ll... no
checking lex output file root... ./configure: lex: command not found
configure: error: cannot find output from lex; giving up
**
What can i do?
thanks
Rgds,
arthur
[EMAIL PROTECTED]
[2002-03-10 21:09:34] [EMAIL PROTECTED]
Dear sir/madam,
my OS is Linux Mandrake 7.2 and i install apache as my web server and
mysql as my database. (Perl is also pre loaded)
However, i tried to install PHP by use php*.tar.gz or *.rpm are both
failed. i don't know why. Isn't the computer missed some gcc (compilers
such as C compiler or others). Please give me a hand . thanks.
when i tried to install by using un-tar *.tar.gz. the error is as
below:
firstly, i saved the un-tar directory in /tmp/php-4.1.2/**
it is a root user too.
The error as below:
**
[root@i-arthur php-4.1.2]# ./configure
loading cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... missing
checking for working autoconf... missing
checking for working automake... missing
checking for working autoheader... missing
checking for working makeinfo... missing
checking whether to enable maintainer-specific portions of Makefiles...
no
checking host system type... i686-pc-linux-gnu
checking for gawk... gawk
checking for bison... bison -y
checking bison version... 1.28 (ok)
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for AIX... no
checking for gcc option to accept ANSI C... none needed
checking for ranlib... ranlib
checking
Bug #15595 Updated: imap routines hang when To header is too large
ID: 15595
Updated by: [EMAIL PROTECTED]
-Summary: imap routines hang when To header is too large
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: IMAP related
Operating System: Solaris-i86
PHP Version: 4.1.1
New Comment:
Is there anything I can do to help this along? We've been bitten twice
by this in the last few days.
Previous Comments:
[2002-02-18 18:09:33] [EMAIL PROTECTED]
An exact script is difficult. (I've spent a day or two trying to pin it
down to a simple routine, not with any great success).
However, it looks like
$h = @imap_header($imp-stream, imap_msgno($imp-stream, $msgnum));
is hanging with a message that has to header of about 4K (again, this
probably violates rfc822, but it shouldn't hang like it does).
$imp-stream is constructed like this (as you'd expect):
$connstr = '{' . $this-server . ':' . $this-port . '}' .
$this-mailbox;
$this-stream = @imap_open($connstr, $this-user, $this-pass);
Thanks.
[2002-02-18 08:29:31] [EMAIL PROTECTED]
Can you provide a simple sample script?
[2002-02-18 04:23:34] [EMAIL PROTECTED]
The starting point for this was that our webmail (customised IMP)would
crash if the To header was too large. Probably the header violates
rfc822, but php should be able to cope, or at least fail gracefully and
not hang.
We are running php built with the imap4.5 uwash c-client, with ldap,
with mysql. Apache is built with mods rewrite, mime_magic, the lastest
fastcgi, the latest modssl. The fastcgi connection is used for most
pages rendered from our site.
Playing around with truss led us to suspect mime_header_decode was at
fault, ie:
php_if_imap_mime_header_decode+0x6d3: movl (%ebx),%edx
Now, in getting a gdb backtrace, things got very wierd. Below is the
output - but it occurs not only when we try to read the email with the
oversized to header, but when I try to do something mundane like parse
the whole mailbox.
So maybe there are two problems, needless to say - I hope the truss
line is useful, because I wouldn't rely on the gdb backtrace.
Thanks.
Program received signal SIGPIPE, Broken pipe.
0xdfee1f3b in _writev ()
(gdb) bt
#0 0xdfee1f3b in _writev ()
#1 0x80b2254 in ssl_io_unregister ()
#2 0x81ba5f4 in ap_hook_call ()
#3 0x81b9d41 in ap_hook_call ()
#4 0x8196641 in ap_bfilbuf ()
#5 0x8196a6c in ap_bfilbuf ()
#6 0x8196b38 in ap_bwrite ()
#7 0x816537e in php_mergesort ()
#8 0x8166ec5 in php_mergesort ()
#9 0x816749d in php_mergesort ()
#10 0x8197ddb in ap_invoke_handler ()
#11 0x81ac451 in ap_some_auth_required ()
#12 0x81ac4b0 in ap_process_request ()
#13 0x81a3ad1 in ap_child_terminate ()
#14 0x81a3c80 in ap_child_terminate ()
#15 0x81a3ddb in ap_child_terminate ()
#16 0x81a43d8 in ap_child_terminate ()
#17 0x81a4b9b in main ()
#18 0x809b947 in _start ()
--
Edit this bug report at http://bugs.php.net/?id=15595edit=1
Bug #15799 Updated: Another segfault on iconv
ID: 15799
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type: ICONV related
Operating System: Linux
PHP Version: 4.0CVS-2002-02-2
New Comment:
I see you already committed the patch to cvs and, yes, php doesn't
segfault anymore, thanks.
But unfortunately the conversion doesn't happen at all. You can try the
same script I posted earlier to reproduce it. Method 1 converts
correctly, method 2 just send the Big5 data asis.
Previous Comments:
[2002-03-10 18:01:25] [EMAIL PROTECTED]
Fixed in CVS and 4.2.0 branch.
[2002-03-09 15:34:13] [EMAIL PROTECTED]
I've sent a patch to jan (wouldn't make sense to paste here as long
lines get broken) and I'm pretty sure it's the right fix. I bet the
current code never really worked the way it was written.
Anyway I'm for deprecating iconv_(set|get)_encoding. All it does is
changing INI settigns which can be easily read and set with
ini_get(iconv.input_encoding) or ini_set(). However I don't know what
the general consesus in in such situations. The two functions just seem
redundant to me.
[2002-03-09 11:19:45] [EMAIL PROTECTED]
The segfaults still happen even after the recent changes in the iconv
extension and the output buffering code.
Here is a small script to reproduce it. Method 1 (commented out) works
fine, method 2 segfaults.
?
error_reporting(E_ALL);
$text = END
Thanks !!
David Chang
-
¨C¤Ñ³£ Yahoo!©_¼¯ www.yahoo.com.tw
END;
// Method 1: Works!
/*
$src = 'BIG5';
$dst = 'UTF-8';
$rc = iconv($src, $dst, $text);
header('Content-Type: text/plain; charset=UTF-8');
echo $rc;
*/
// Method 2: Segfaults!
iconv_set_encoding('input_encoding', 'BIG5');
iconv_set_encoding('internal_encoding', 'UTF-8');
iconv_set_encoding('output_encoding', 'UTF-8');
ob_start('ob_iconv_handler');
echo $text;
$rc = ob_get_contents();
ob_end_clean();
header('Content-Type: text/plain; charset=UTF-8');
echo $rc;
?
Since the line numbers changed since my initial report and I use a
different script (above), here's also an updated bt:
Program received signal SIGSEGV, Segmentation fault.
0x4010621a in chunk_free (ar_ptr=0x7a62e850, p=0x404ea168) at
malloc.c:3049
3049malloc.c: No such file or directory.
(gdb) bt
#0 0x4010621a in chunk_free (ar_ptr=0x7a62e850, p=0x404ea168) at
malloc.c:3049
#1 0x401061bf in free () at malloc.c:2952
#2 0x403744ec in zif_iconv_set_encoding () at iconv.c:267
#3 0x40317077 in execute () at ./zend_execute.c:959
#4 0x40328fb4 in zend_execute_scripts () at zend.c:373
#5 0x4033cea7 in php_execute_script () at main.c:1309
#6 0x40337240 in apache_php_module_main () at sapi_apache.c:100
#7 0x403381d8 in send_php (r=0x81825a0, display_source_mode=0,
filename=0x81841a8 /usr/local/httpd/htdocs/headhorde/iconv.php)
at mod_php4.c:575
#8 0x40338263 in send_parsed_php (r=0x81825a0) at mod_php4.c:590
#9 0x8055250 in ap_invoke_handler ()
#10 0x80677bc in ap_some_auth_required ()
#11 0x8067833 in ap_process_request ()
#12 0x805fd27 in ap_child_terminate ()
#13 0x805fed5 in ap_child_terminate ()
#14 0x8060016 in ap_child_terminate ()
#15 0x8060628 in ap_child_terminate ()
#16 0x8060e95 in main ()
#17 0x400cca8e in __libc_start_main () at
../sysdeps/generic/libc-start.c:93
[2002-02-28 20:26:43] [EMAIL PROTECTED]
Better yet.
Could you make a script that included base64/uuencoded BIG5 data end
decode it and feed it to iconv?
[2002-02-28 19:32:59] [EMAIL PROTECTED]
BIG5
I guess it's supported by libiconv and your glibc is ok..
If text is small enough, could you pate uuencoded text there?
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/15799
--
Edit this bug report at http://bugs.php.net/?id=15799edit=1
Bug #15989 Updated: php is segfaulting when trying to read http header of a ftp.domaine.com site
ID: 15989 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: cURL related Operating System: windows 2000, macosx PHP Version: 4.1.2 New Comment: To properly diagnose this bug, 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. Previous Comments: [2002-03-10 21:06:57] [EMAIL PROTECTED] Here is a simple code for this : ?php curl_setopt($ch, CURLOPT_URL, ftp.dds.be); // this is an example curl_setopt($ch, CURLOPT_RETURNTRANSFER,1); curl_setopt ($ch, CURLOPT_HEADER, 1); curl_setopt ($ch, CURLOPT_NOBODY, 1); curl_setopt ($ch, CURLOPT_TIMEOUT, 5); print OK until now\n; var_dump( $retour = curl_exec ($ch)); ? When the protocol is not specified, and the host name starts with ftp., there is a conflict segfault. It seems to have a conflict where curl choose automatically ftp protocole for ftp.*.* sites, but the script ask for http header. Then php crashes. This has been found with PHP 4.1.0/4.1.1 for windows, and PHP 4.1.2/ curl 7.9.4 PHP should return an error, but not crash. Note that when specifying the protocol, (eg, http://ftp.site.com;), it works fine. -- Edit this bug report at http://bugs.php.net/?id=15989edit=1
Bug #15955 Updated: header(Location: ...) doesn't work
ID: 15955 Updated by: [EMAIL PROTECTED] -Summary: header(Location: ...) doesn't work Reported By: [EMAIL PROTECTED] Status: Open Bug Type: HTTP related Operating System: Win 98 SE PHP Version: 4.1.2 New Comment: Even worse, the protocol and full hostname are required too by the RFCs. Derick Previous Comments: [2002-03-11 06:03:35] [EMAIL PROTECTED] arg php.net was just an exapmle :) i'm calling header(Location: artikel.php?.$QUERY_STRING); ;) [2002-03-11 05:59:36] [EMAIL PROTECTED] well, for a start: http://www.php.net; is *not* a valid URL, http://www.php.net/; is the trailing slash behind the Hostname is required by the RFCs [2002-03-08 07:59:14] [EMAIL PROTECTED] what's wrong with following file: ?php header(Location: http://www.php.net;); ? When it works on other servers, but not on 98SE with 4.1.2 with 98SE and 4.1.1 it's also working [2002-03-08 07:52:47] [EMAIL PROTECTED] Without complete, short script that fails I'm pretty sure you're doing something wrong. --Jani [2002-03-08 07:38:51] [EMAIL PROTECTED] lol? i'm not a noob, that's not a support question it's a bug i wrote enough projects to decide whats a bug and when i'm to silly to code something 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/15955 -- Edit this bug report at http://bugs.php.net/?id=15955edit=1
Bug #15992 Updated: Segmentation fault (11)
ID: 15992 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: InterBase related Operating System: RH 7.2 PHP Version: 4.1.2 New Comment: Can you provide more context of the backtrace (e.g. a few more lines from 'bt full') ? Previous Comments: [2002-03-11 05:07:08] [EMAIL PROTECTED] ibase_close function causes Segmentation fault (11) in Apache 1.3.23 web server. Program received signal SIGSEGV, Segmentation fault. 0x40430c7c in memcpy () from /lib/i686/libc.so.6 (gdb) bt #0 0x40430c7c in memcpy () from /lib/i686/libc.so.6 #1 0x in __strtol_internal (nptr=0x0, endptr=0x0, base=165, group=128) If I comment out the ibase_close() from my PHP scripst all works well. -- Edit this bug report at http://bugs.php.net/?id=15992edit=1
Bug #15992 Updated: Segmentation fault (11)
ID: 15992 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: InterBase related Operating System: RH 7.2 PHP Version: 4.1.2 New Comment: As before i did: ./configure --without-mysql --with-imap --with-imap-ssl --with-interbase --with-pgsql --with-kerberos --with-gettext --with-xml --with-apache=../apache_1.3.23/ --enable-track-vars --enable-debug .log Backtrace only outputs the same 2 lines after httpd crashes Previous Comments: [2002-03-11 06:33:13] [EMAIL PROTECTED] Recompile php and the module (if not static already) with the configure line '--enable-debug'. [2002-03-11 06:25:10] [EMAIL PROTECTED] No symbol table info available. What else can I do to help? [2002-03-11 06:07:56] [EMAIL PROTECTED] Can you provide more context of the backtrace (e.g. a few more lines from 'bt full') ? [2002-03-11 05:07:08] [EMAIL PROTECTED] ibase_close function causes Segmentation fault (11) in Apache 1.3.23 web server. Program received signal SIGSEGV, Segmentation fault. 0x40430c7c in memcpy () from /lib/i686/libc.so.6 (gdb) bt #0 0x40430c7c in memcpy () from /lib/i686/libc.so.6 #1 0x in __strtol_internal (nptr=0x0, endptr=0x0, base=165, group=128) If I comment out the ibase_close() from my PHP scripst all works well. -- Edit this bug report at http://bugs.php.net/?id=15992edit=1
Bug #14370 Updated: PHP_AUTH_PW being improperly set
ID: 14370
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache related
Operating System: FreeBSD
PHP Version: 4.0.6
New Comment:
The following patch solves this bug by not exporting the PHP_AUTH_*
variables when safe_mode is set.
===8
--- php-4.1.2/main/main.c.orig-securevars Mon Dec 17 22:19:51
2001
+++ php-4.1.2/main/main.c Mon Mar 11 07:34:40 2002
@@ -1031,10 +1031,10 @@
}
/* PHP Authentication support */
- if (SG(request_info).auth_user) {
+ if (!PG(safe_mode) SG(request_info).auth_user) {
php_register_variable(PHP_AUTH_USER,
SG(request_info).auth_user, array_ptr TSRMLS_CC);
}
- if (SG(request_info).auth_password) {
+ if (!PG(safe_mode) SG(request_info).auth_password) {
php_register_variable(PHP_AUTH_PW,
SG(request_info).auth_password, array_ptr TSRMLS_CC);
}
}
Previous Comments:
[2001-12-06 19:34:29] [EMAIL PROTECTED]
PHP_AUTH_PW is being improperly set when external authentication is
active
on Apache.
I have a directory structure that is protected via Apache
authentication, according
to the PHP documentation the PHP_AUTH_PW should not be available when
external authentication is in use. This is necessary for security
concerns when you
cannot trust the php applications. In any case, w/ php the AUTH_PW is
being
set at all times. Please fix, thanks!
--
Edit this bug report at http://bugs.php.net/?id=14370edit=1
Bug #15995: Syntax error in debugger documentation (debugger-using.html, 10-03-2002)
From: [EMAIL PROTECTED] Operating system: PHP version: 4.1.1 PHP Bug Type: Documentation problem Bug description: Syntax error in debugger documentation (debugger-using.html, 10-03-2002) In the debugger documentation (debugger-using.html) is a syntax error in last sentence: even if you them turned off with - even if you turned them off with I have found this error both in the online version as well as in the downloadable version (english, many HTML files, http://www.php.net/distributions/manual/php_manual_en.tar.bz2) Kind regards Markus Wolf -- Edit bug report at http://bugs.php.net/?id=15995edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15995r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15995r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15995r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15995r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15995r=support Expected behavior: http://bugs.php.net/fix.php?id=15995r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15995r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15995r=submittedtwice
Bug #15993 Updated: Download problem
ID: 15993 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: *General Issues Operating System: Windows PHP Version: 4.1.2 New Comment: Works fine for me. This is likely to be a problem with your browser or your internet connection. Previous Comments: [2002-03-11 05:59:21] [EMAIL PROTECTED] Hi, I tried to download the php patch from 4.06 to 4.1.1. The problem is that the download does not stop. The file gets bigger and bigger. I am downloading the file in an windows environment, but for the linux distribution. I push right mouse button and chose save link location (Ziel speichern unter - german). Benjamin Elixmann -- Edit this bug report at http://bugs.php.net/?id=15993edit=1
Bug #15992 Updated: Segmentation fault (11)
ID: 15992 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: InterBase related Operating System: RH 7.2 PHP Version: 4.1.2 New Comment: Try compiling Apache with --enable-debug too. Previous Comments: [2002-03-11 06:51:55] [EMAIL PROTECTED] As before i did: ./configure --without-mysql --with-imap --with-imap-ssl --with-interbase --with-pgsql --with-kerberos --with-gettext --with-xml --with-apache=../apache_1.3.23/ --enable-track-vars --enable-debug .log Backtrace only outputs the same 2 lines after httpd crashes [2002-03-11 06:33:13] [EMAIL PROTECTED] Recompile php and the module (if not static already) with the configure line '--enable-debug'. [2002-03-11 06:25:10] [EMAIL PROTECTED] No symbol table info available. What else can I do to help? [2002-03-11 06:07:56] [EMAIL PROTECTED] Can you provide more context of the backtrace (e.g. a few more lines from 'bt full') ? [2002-03-11 05:07:08] [EMAIL PROTECTED] ibase_close function causes Segmentation fault (11) in Apache 1.3.23 web server. Program received signal SIGSEGV, Segmentation fault. 0x40430c7c in memcpy () from /lib/i686/libc.so.6 (gdb) bt #0 0x40430c7c in memcpy () from /lib/i686/libc.so.6 #1 0x in __strtol_internal (nptr=0x0, endptr=0x0, base=165, group=128) If I comment out the ibase_close() from my PHP scripst all works well. -- Edit this bug report at http://bugs.php.net/?id=15992edit=1
Bug #14906 Updated: The function mysql_select_db set the db for other link ids than specified.
ID: 14906
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: MySQL related
Operating System: RedHat 7.1
PHP Version: 4.1.0
New Comment:
This is a known limitation and a workaround exists in current CVS and
upcomming 4.2.0 version which has a new, additional/optional parameter
to mysql_connect() [NOT! pconnect!] which forces the creation of a
truly new link and not re-use an existing one.
Previous Comments:
[2002-03-11 07:24:13] [EMAIL PROTECTED]
On my Slackware 3.6 box (not that it matters, since everything has been
built from source [php 4.0.6, 4.1.1 and 4.1.2, mysql 3.22.30]), I get
essentially the same results. I don't remember if the resource IDs
were the same, but I rewrote a few of my database libraries because of
this.
Basically, I had to write my database wrappers to never select a
database and always user mysql_db_query() because if someone using the
library connected with the same host/user/pass and selected a database,
the most current one would be used by both/all connections.
Please don't take mysql_db_query() away until this is sorted out. (and
maybe not even then) :)
[2002-01-07 07:27:54] [EMAIL PROTECTED]
PHP 4.1.0 and MySQL 3.23.41-log
The function mysql_select_db set the db for other link
identifiers than specified.
Doc:
bool mysql_select_db (string database_name, resource
[link_identifier])
mysql_select_db() sets the current active database on the server that's
associated with the specified link identifier. If no link identifier is
specified, the last opened link is assumed. If no link is open, the
function will try to establish a link as if mysql_connect() was called
without arguments, and use it.
The table my_table is in db1 but the active database
seems to be test on link #8.
Here the result:
mysql_pconnect() id1=Resource id #8
mysql_select_db(db1,Resource id #8)
mysql_pconnect() id2=Resource id #9
mysql_select_db(test,Resource id #9)
mysql_query(select * from my_table,Resource id #8)
failed: Table 'test.my_table' doesn't exist
Here the source:
$id1=mysql_pconnect($host,$user,$pass);
if($id1==false){
die(brmysql_pconnect() failed: .mysql_error());
}
echo brmysql_pconnect() id1=$id1;
$b=mysql_select_db($db1,$id1);
if($b==false){
die(brmysql_select_db($db1,$id1)
failed:.mysql_error());
}
echo brmysql_select_db($db1,$id1);
$id2=mysql_pconnect($host,$user,$pass);
if($id2==false){
echo brmysql_pconnect() failed: .mysql_error();
}
echo brmysql_pconnect() id2=$id2;
$b=mysql_select_db($db2,$id2);
if($b==false){
die(brmysql_select_db($db2,$id2)
failed:.mysql_error());
}
echo brmysql_select_db($db2,$id2);
$sql='select * from my_table';
$result=mysql_query($sql,$id1);
if($result==false){
die(brmysql_query($sql,$id1)
failed:.mysql_error());
}
--
Edit this bug report at http://bugs.php.net/?id=14906edit=1
Bug #15996: ereg doesn't match on Alpha but does on i586
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.2 PHP Bug Type: *Regular Expressions Bug description: ereg doesn't match on Alpha but does on i586 I was trying a set of scripts on my alpha intead of the i586 I used before (same php version same configure options). I had some problems and found it had something to do with weird behaviour of ereg. It doesn't match in some cases where it should (and does on i586), the matches array is left empty. Some examples: $p=blah link website bluh; ereg((.*)bla(.*)lin(.*)uh,$p,$regs1); //OK isset($regs1) and print(implode(br,$regs1)); ereg((.*)bla(.*)lin(.*)web(.*)uh,$p,$regs2); //NOT OK isset($regs2) and print(implode(br,$regs2)); ereg(bla(.*)lin(.*)web(.*)uh,$p,$regs3); //NOT OK isset($regs3) and print(implode(br,$regs3)); ereg(bla(.*)lin(.*)uh,$p,$regs4); //OK isset($regs4) and print(implode(br,$regs4)); So only examples 1 and 4 have output. I can't find a real patern in it.. I hope you can Tim XXX Compile options (I got from debian): '../configure' '--prefix=/usr' '--with-apxs=/usr/bin/apxs' '--with-regex=system' '--with-config-file-path=/etc/php4/apache' '--disable-rpath' '--disable-debug' '--enable-memory-limit' '--enable-calendar' '--enable-sysvsem' '--enable-sysvshm' '--enable-track-vars' '--enable-trans-sid' '--enable-bcmath' '--with-bz2' '--enable-ctype' '--with-db2' '--with-iconv' '--with-ndbm' '--enable-exif' '--enable-filepro' '--enable-ftp' '--with-gettext' '--enable-mbstring' '--with-pcre-regex=/usr' '--enable-shmop' '--enable-sockets' '--enable-wddx' '--with-xml=/usr' '--with-expat-dir=/usr' '--enable-yp' '--with-zlib' '--without-pgsql' '--disable-static' '--with-layout=GNU' '--with-curl=shared,/usr' '--with-dom=shared,/usr' '--with-zlib-dir=/usr' '--with-gd=shared,/usr' '--with-jpeg-dir=shared,/usr' '--with-xpm-dir=shared,/usr/X11R6' '--with-png-dir=shared,/usr' '--with-freetype-dir=shared,/usr' '--with-imap=shared,/usr' '--with-ldap=shared,/usr' '--with-mcal=shared,/usr' '--with-mhash=shared,/usr' '--with-mm' '--with-mysql=shared,/usr' '--with-recode=shared,/usr' '--enable-xslt' '--with-xslt-sablot=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-sybase-ct=shared,/usr' '--with-ttf=shared,/usr' '--with-t1lib=shared,/usr' -- Edit bug report at http://bugs.php.net/?id=15996edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15996r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15996r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15996r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15996r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15996r=support Expected behavior: http://bugs.php.net/fix.php?id=15996r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15996r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15996r=submittedtwice
Bug #15992 Updated: Segmentation fault (11)
ID: 15992 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: InterBase related Operating System: RH 7.2 PHP Version: 4.1.2 New Comment: Apache does not have en --enable-debug option but I compiled it with -g option in gcc and it still did not work. I only get 2 lines of backtrace info :( Previous Comments: [2002-03-11 08:13:46] [EMAIL PROTECTED] Try compiling Apache with --enable-debug too. [2002-03-11 06:51:55] [EMAIL PROTECTED] As before i did: ./configure --without-mysql --with-imap --with-imap-ssl --with-interbase --with-pgsql --with-kerberos --with-gettext --with-xml --with-apache=../apache_1.3.23/ --enable-track-vars --enable-debug .log Backtrace only outputs the same 2 lines after httpd crashes [2002-03-11 06:33:13] [EMAIL PROTECTED] Recompile php and the module (if not static already) with the configure line '--enable-debug'. [2002-03-11 06:25:10] [EMAIL PROTECTED] No symbol table info available. What else can I do to help? [2002-03-11 06:07:56] [EMAIL PROTECTED] Can you provide more context of the backtrace (e.g. a few more lines from 'bt full') ? 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/15992 -- Edit this bug report at http://bugs.php.net/?id=15992edit=1
Bug #15991 Updated: Undefined symbol mysql_drop_db
ID: 15991 Updated by: [EMAIL PROTECTED] -Summary: Undefined symbol mysql_drop_db Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: MySQL related Operating System: FreeBSD 4.5 PHP Version: 4.0CVS-2002-03-11 New Comment: Do you happen to have some old mysql version in your system? ie. you might have older libs somewhere in the libpath which are found before the new ones. --Jani Previous Comments: [2002-03-11 06:04:13] [EMAIL PROTECTED] mysql-4.0.1-alpha (libmysqlclient.so.11) ./configure --disable-cli --with-exec-dir=/usr/local/php/bin --with-mnogosearch=/usr/local/mnsh --enable-inline-optimization --with-freetype-dir=/usr/local --enable-trans-sid --enable-versioning --enable-ftp --with-xml --with-magic-quotes --enable-track-vars --enable-gd-native-ttf --with-png-dir=/usr/local --with-apxs=/usr/local/apache/bin/apxs --with-gd=/usr/local --with-jpeg-dir=/usr/local --with-gettext=/usr/local --with-bz2=/usr/local --with-zlib=/usr/local --with-mysql=/usr/local/mysql --enable-calendar --enable-safe-mode --enable-sysvsem --enable-sysvshm --with-config-file-path=/usr/local/php/ --with-exec-dir=/usr/local/php/bin --with-mod_charset --enable-bcmath [2002-03-11 05:34:37] [EMAIL PROTECTED] What is your configure line? What is your version of libmysqlclient (if you're using an other client than the built-in)? [2002-03-11 04:09:34] [EMAIL PROTECTED] Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/apache/ libexec/libphp4.so: Undefined symbol mysql_drop_db ./apachectl start: httpd could not be started -- Edit this bug report at http://bugs.php.net/?id=15991edit=1
Bug #15595 Updated: imap routines hang when To header is too large
ID: 15595
Updated by: [EMAIL PROTECTED]
-Summary: imap routines hang when To header is too large
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: IMAP related
Operating System: Solaris-i86
PHP Version: 4.1.1
New Comment:
First of all you should try with the latest c-client.
--Jani
Previous Comments:
[2002-03-11 04:47:56] [EMAIL PROTECTED]
Is there anything I can do to help this along? We've been bitten twice
by this in the last few days.
[2002-02-18 18:09:33] [EMAIL PROTECTED]
An exact script is difficult. (I've spent a day or two trying to pin it
down to a simple routine, not with any great success).
However, it looks like
$h = @imap_header($imp-stream, imap_msgno($imp-stream, $msgnum));
is hanging with a message that has to header of about 4K (again, this
probably violates rfc822, but it shouldn't hang like it does).
$imp-stream is constructed like this (as you'd expect):
$connstr = '{' . $this-server . ':' . $this-port . '}' .
$this-mailbox;
$this-stream = @imap_open($connstr, $this-user, $this-pass);
Thanks.
[2002-02-18 08:29:31] [EMAIL PROTECTED]
Can you provide a simple sample script?
[2002-02-18 04:23:34] [EMAIL PROTECTED]
The starting point for this was that our webmail (customised IMP)would
crash if the To header was too large. Probably the header violates
rfc822, but php should be able to cope, or at least fail gracefully and
not hang.
We are running php built with the imap4.5 uwash c-client, with ldap,
with mysql. Apache is built with mods rewrite, mime_magic, the lastest
fastcgi, the latest modssl. The fastcgi connection is used for most
pages rendered from our site.
Playing around with truss led us to suspect mime_header_decode was at
fault, ie:
php_if_imap_mime_header_decode+0x6d3: movl (%ebx),%edx
Now, in getting a gdb backtrace, things got very wierd. Below is the
output - but it occurs not only when we try to read the email with the
oversized to header, but when I try to do something mundane like parse
the whole mailbox.
So maybe there are two problems, needless to say - I hope the truss
line is useful, because I wouldn't rely on the gdb backtrace.
Thanks.
Program received signal SIGPIPE, Broken pipe.
0xdfee1f3b in _writev ()
(gdb) bt
#0 0xdfee1f3b in _writev ()
#1 0x80b2254 in ssl_io_unregister ()
#2 0x81ba5f4 in ap_hook_call ()
#3 0x81b9d41 in ap_hook_call ()
#4 0x8196641 in ap_bfilbuf ()
#5 0x8196a6c in ap_bfilbuf ()
#6 0x8196b38 in ap_bwrite ()
#7 0x816537e in php_mergesort ()
#8 0x8166ec5 in php_mergesort ()
#9 0x816749d in php_mergesort ()
#10 0x8197ddb in ap_invoke_handler ()
#11 0x81ac451 in ap_some_auth_required ()
#12 0x81ac4b0 in ap_process_request ()
#13 0x81a3ad1 in ap_child_terminate ()
#14 0x81a3c80 in ap_child_terminate ()
#15 0x81a3ddb in ap_child_terminate ()
#16 0x81a43d8 in ap_child_terminate ()
#17 0x81a4b9b in main ()
#18 0x809b947 in _start ()
--
Edit this bug report at http://bugs.php.net/?id=15595edit=1
Bug #15997 Updated: creating blank cookies
ID: 15997 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: HTTP related Operating System: linux rh 7.0 PHP Version: 4.1.2 New Comment: The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Previous Comments: [2002-03-11 09:52:09] [EMAIL PROTECTED] When i try to receive value through SetCookie() it doesn`t return any value, but create new blank cookie in client`s browser. For example: SetCookie(mp3); -- Edit this bug report at http://bugs.php.net/?id=15997edit=1
Bug #15884 Updated: session_unregister does not work when followed by header(Location: ...)
ID: 15884 Updated by: [EMAIL PROTECTED] -Summary: session_unregister does not work when followed by header(Location: ...) Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Linux PHP Version: 4.1.2 New Comment: Yup looks like the two are related. The other bug was submitted an Mar 6th, I submitted mine on Mar 5th so at least the dupe is not my fault ;) Jochen Previous Comments: [2002-03-08 15:08:30] [EMAIL PROTECTED] I believe this bug is related to bug #15909 (http://bugs.php.net/bug.php?id=15909) [2002-03-06 12:25:09] [EMAIL PROTECTED] You must provide short complete script. It sounds like your bug to me. Well this issue is very to reproduce so I thought providing a script wont be necessary. Anyway the following set of scripts will expose the bug. Please note that including the session handler will not be necessary if you are not running user-defined session handlers (php.ini setting) An explanation on how to use the scripts is below - file: include.php ? if (!$pgsql_session_table) include(/path/to/pgsql_session_handler.php); session_start(); ? - file: t1.php ? include(include.php); $myvar = hello; session_register(myvar); ? A HREF=t2.phpt2/A - file: t2.php ? include(include.php); echo myvar: $myvarBR; ? A HREF=t3.phpt3/A - file: t3.php ? include(include.php); session_unregister(myvar); header(Location: t2.php); ? A HREF=t2.phpt2/A - Observed behaviour: t1 registers $myvar and displays link to t2. Follow this link t2 shows value of $myvar and displays link to t3. Follow this link t3 unregisters $myvar and uses header(Location: ) to redirect you to t2 t2 shows value of $myvar - it is still hello The behaviour in the last step is incorrect - since $myvar was unregistred, its value should have been deleted from the session but obiously is not When you comment out the line starting with header in t3.php and do the first two steps above and then click the link t3 shows $myvar will get unregistred properly. This is why the bug has the title session_unregister does not work when followed by header(Location: ...) btw: The reason for this is not the session-handler I use, php simply does not call the pgsql_session_write function if session_unregister is followed by a header(Location: ...) statement. best regards, Jochen [2002-03-06 03:04:01] [EMAIL PROTECTED] 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. You must provide short complete script. It sounds like your bug to me. [2002-03-05 12:32:08] [EMAIL PROTECTED] When followed by a header(Location: ...); statement session_unregister does not get properly executed. Reproduce: Take any script that has a session_unregister in it, put a header(Location: ...) under this statement, and see if unregistered var gets deleted from session-storage (it does not) Now put a session_write_close() in front of the header-statement and watch it work properly. If you have trouble reproducing this please don't hesitate to contact me. My setup: User-Defined Session-Handler: pgsql_session_handler latest version PHP compiled with: ./configure' '--with-mysql=/usr/local/mysql' '--with-pgsql' '--with-ldap' '--enable-trans-sid' '--with-gd' Exact same setup worked with php4.0.6, did not work after upgrade to 4.1.2 -- Edit this bug report at http://bugs.php.net/?id=15884edit=1
Bug #15998: Difference in mail() function in PHP 4.1.2, causes delay in sending mail.
From: [EMAIL PROTECTED] Operating system: Linux/Unix Redhat PHP version: 4.1.2 PHP Bug Type: Mail related Bug description: Difference in mail() function in PHP 4.1.2, causes delay in sending mail. There appears to be a difference between the way mail() works between 4.1.0 and 4.1.2. This can cause scripts which worked perfectly in PHP 4.1.0 to take as much as a minute to excecute in PHP 4.1.2. I upgraded using a pkg file from pkgmaster.com for a Cobalt RAQ4 server, and I have spoken to another PHP user using Redhat 7 who has experienced the same issue. Basically PHP mail() functions were taking as long as a minute to excecute, when prior to the upgrade they took seconds. We found that while we had no problems with PHP 4.1.0, we had to add all our IP's into the /etc/hosts file to cure the problem experienced with 4.1.2. Config is: System Linux rev66.cobalt 2.2.16C28_III #1 Mon Jul 30 22:07:58 PDT 2001 i586 unknown Build Date Feb 27 2002 Configure Command './configure' '--prefix=/usr' '--with-apxs=/usr/sbin/apxs' '--with-gd' '--with-gettext=/usr' '--enable-safe-mode' '--with-config-file-path=/etc/httpd' '--with-exec-dir=/usr/bin' '--with-zlib' '--enable-magic-quotes' '--with-regex=system' '--with-ttf' '--with-db' '--with-gdbm' '--with-mbstring' '--with-mbstr-enc-trans' '--enable-track-vars' '--enable-wddx=shared' '--enable-mm=shared' '--enable-xml' '--disable-debug' '--with-libdir=/usr/lib' '--with-db3' '--with-interbase=shared' '--with-pgsql=shared' '-- Although we have solved this issue by adding the IP's to the /etc/hosts file, it may be worth documenting this somewhere for others reference, it took a great deal of hair-pulling to get it solved! -- Edit bug report at http://bugs.php.net/?id=15998edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15998r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15998r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15998r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15998r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15998r=support Expected behavior: http://bugs.php.net/fix.php?id=15998r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15998r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15998r=submittedtwice
Bug #15999: fread() hangs apache when file pointer obtained from a url parameter PHPSESSID
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.0 PHP Bug Type: Session related Bug description: fread() hangs apache when file pointer obtained from a url parameter PHPSESSID ?php $url = http://test/block.html?PHPSESSID=.session_id(); $fp = fopen($url, 'r'); // the file pointer semms to be valid $file = fread($fp,1048576); //hangs here ! echo $file; ? hangs apache (1.3.x). Same with 4.0.2, 4.0.6 Linux (RH 6.2 and Debian 2.2), never on Win98. Other parameters don't have the same effect. -- Edit bug report at http://bugs.php.net/?id=15999edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15999r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15999r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15999r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15999r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15999r=support Expected behavior: http://bugs.php.net/fix.php?id=15999r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15999r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15999r=submittedtwice
Bug #15998 Updated: Difference in mail() function in PHP 4.1.2, causes delay in sending mail.
ID: 15998 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Mail related Operating System: Linux/Unix Redhat PHP Version: 4.1.2 New Comment: There were no code changes to the mail() function code between 4.1.0 and 4.1.2. And even if there was, all mail() does is open a pipe to your sendmail or equivalent mail delivery program. PHP does not try to do any domain name resolution on the addresses so this DNS delay you are experiencing can not possibly be PHP related as the DNS resolution is done by the external mail delivery program. You probably changed something else on your system. Check your /etc/resolv.conf and make sure the DNS servers listed there are responding quickly. Previous Comments: [2002-03-11 10:36:47] [EMAIL PROTECTED] There appears to be a difference between the way mail() works between 4.1.0 and 4.1.2. This can cause scripts which worked perfectly in PHP 4.1.0 to take as much as a minute to excecute in PHP 4.1.2. I upgraded using a pkg file from pkgmaster.com for a Cobalt RAQ4 server, and I have spoken to another PHP user using Redhat 7 who has experienced the same issue. Basically PHP mail() functions were taking as long as a minute to excecute, when prior to the upgrade they took seconds. We found that while we had no problems with PHP 4.1.0, we had to add all our IP's into the /etc/hosts file to cure the problem experienced with 4.1.2. Config is: System Linux rev66.cobalt 2.2.16C28_III #1 Mon Jul 30 22:07:58 PDT 2001 i586 unknown Build Date Feb 27 2002 Configure Command './configure' '--prefix=/usr' '--with-apxs=/usr/sbin/apxs' '--with-gd' '--with-gettext=/usr' '--enable-safe-mode' '--with-config-file-path=/etc/httpd' '--with-exec-dir=/usr/bin' '--with-zlib' '--enable-magic-quotes' '--with-regex=system' '--with-ttf' '--with-db' '--with-gdbm' '--with-mbstring' '--with-mbstr-enc-trans' '--enable-track-vars' '--enable-wddx=shared' '--enable-mm=shared' '--enable-xml' '--disable-debug' '--with-libdir=/usr/lib' '--with-db3' '--with-interbase=shared' '--with-pgsql=shared' '-- Although we have solved this issue by adding the IP's to the /etc/hosts file, it may be worth documenting this somewhere for others reference, it took a great deal of hair-pulling to get it solved! -- Edit this bug report at http://bugs.php.net/?id=15998edit=1
Bug #15998 Updated: Difference in mail() function in PHP 4.1.2, causes delay in sending mail.
ID: 15998 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Mail related Operating System: Linux/Unix Redhat PHP Version: 4.1.2 New Comment: The servers are responding fine. Sendmail was working fine from the command line, before AND after the PHP upgrade, but the php mail() command was taking a VERY long time until I added all the IP details to /etc/hosts. Now it works fine. Previous Comments: [2002-03-11 11:00:05] [EMAIL PROTECTED] There were no code changes to the mail() function code between 4.1.0 and 4.1.2. And even if there was, all mail() does is open a pipe to your sendmail or equivalent mail delivery program. PHP does not try to do any domain name resolution on the addresses so this DNS delay you are experiencing can not possibly be PHP related as the DNS resolution is done by the external mail delivery program. You probably changed something else on your system. Check your /etc/resolv.conf and make sure the DNS servers listed there are responding quickly. [2002-03-11 10:36:47] [EMAIL PROTECTED] There appears to be a difference between the way mail() works between 4.1.0 and 4.1.2. This can cause scripts which worked perfectly in PHP 4.1.0 to take as much as a minute to excecute in PHP 4.1.2. I upgraded using a pkg file from pkgmaster.com for a Cobalt RAQ4 server, and I have spoken to another PHP user using Redhat 7 who has experienced the same issue. Basically PHP mail() functions were taking as long as a minute to excecute, when prior to the upgrade they took seconds. We found that while we had no problems with PHP 4.1.0, we had to add all our IP's into the /etc/hosts file to cure the problem experienced with 4.1.2. Config is: System Linux rev66.cobalt 2.2.16C28_III #1 Mon Jul 30 22:07:58 PDT 2001 i586 unknown Build Date Feb 27 2002 Configure Command './configure' '--prefix=/usr' '--with-apxs=/usr/sbin/apxs' '--with-gd' '--with-gettext=/usr' '--enable-safe-mode' '--with-config-file-path=/etc/httpd' '--with-exec-dir=/usr/bin' '--with-zlib' '--enable-magic-quotes' '--with-regex=system' '--with-ttf' '--with-db' '--with-gdbm' '--with-mbstring' '--with-mbstr-enc-trans' '--enable-track-vars' '--enable-wddx=shared' '--enable-mm=shared' '--enable-xml' '--disable-debug' '--with-libdir=/usr/lib' '--with-db3' '--with-interbase=shared' '--with-pgsql=shared' '-- Although we have solved this issue by adding the IP's to the /etc/hosts file, it may be worth documenting this somewhere for others reference, it took a great deal of hair-pulling to get it solved! -- Edit this bug report at http://bugs.php.net/?id=15998edit=1
Bug #15999 Updated: fread() hangs apache when file pointer obtained from a url parameter PHPSESSID
ID: 15999 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Session related Operating System: Linux PHP Version: 4.1.0 New Comment: You're calling the same script with that fopen() ? The behaviour is called 'infinite recursion' and yes, it will hang. Not a bug. --Jani Previous Comments: [2002-03-11 10:48:52] [EMAIL PROTECTED] ?php $url = http://test/block.html?PHPSESSID=.session_id(); $fp = fopen($url, 'r'); // the file pointer semms to be valid $file = fread($fp,1048576); //hangs here ! echo $file; ? hangs apache (1.3.x). Same with 4.0.2, 4.0.6 Linux (RH 6.2 and Debian 2.2), never on Win98. Other parameters don't have the same effect. -- Edit this bug report at http://bugs.php.net/?id=15999edit=1
Bug #16000: fpassthru and timeouts
From: [EMAIL PROTECTED] Operating system: 2000 Server PHP version: 4.1.2 PHP Bug Type: Output Control Bug description: fpassthru and timeouts There seems to be a timeout problems with using fpassthru. Code : header( Content-type: application/octet-stream ); header( Content-Length: $c_ByteSize ); header( Content-Disposition: attachment; filename=\$F\ ); $fp = fopen(D:\\CarrierFTP_Files\\.odbc_result($result, FilePath).$F,r) or die(Can't find file.); fpassthru($fp); When the person starts getting the file, after 5 min 2 sec it quits and tells me it has finished. I have increased timeouts everywhere, but it never gets the file. Suggestions on this? -- Edit bug report at http://bugs.php.net/?id=16000edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16000r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16000r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16000r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16000r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16000r=support Expected behavior: http://bugs.php.net/fix.php?id=16000r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16000r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16000r=submittedtwice
Bug #15999 Updated: fread() hangs apache when file pointer obtained from a url parameter PHPSESSID
ID: 15999 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Session related Operating System: Linux PHP Version: 4.1.0 New Comment: Why do you think that block.html is the same script ? Maybe my example is not very clear. But you are right, Apache behavior looks like infinite recursion. Let me explain again and more precisly : the script A (the one in the previous post) tries to open the url B ($url). Script C is auto_prepended (at fread instruction, right ?) and validate the access to the script B, with the session variable. If I don't use the PHPSESSID in the url parameter (and skip the test in the script C), the script is OK. If I use another parameter than PHPSESSID, the script A is OK. Same behavior with fgets, readfile, etc... Note that the script C is auto_prepended only in a subdirectory (containing only docs like B) by apache configuration (Directory ... php_value /Directory) and of course scripts A and C are not on this directory. Previous Comments: [2002-03-11 11:17:55] [EMAIL PROTECTED] You're calling the same script with that fopen() ? The behaviour is called 'infinite recursion' and yes, it will hang. Not a bug. --Jani [2002-03-11 10:48:52] [EMAIL PROTECTED] ?php $url = http://test/block.html?PHPSESSID=.session_id(); $fp = fopen($url, 'r'); // the file pointer semms to be valid $file = fread($fp,1048576); //hangs here ! echo $file; ? hangs apache (1.3.x). Same with 4.0.2, 4.0.6 Linux (RH 6.2 and Debian 2.2), never on Win98. Other parameters don't have the same effect. -- Edit this bug report at http://bugs.php.net/?id=15999edit=1
Bug #15771 Updated: cannot pass value to image field by ado
ID: 15771 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Suspended Bug Type: COM related Operating System: windows PHP Version: 4.0.6 New Comment: hmm, this is a bit difficult because strings become usually translated into unicode which is usually a good thing(tm) but unfortunatelly not in this case. as i'm actually rewriting the whole thing for php5/ZE2 i don't think that i'll address this yet. harald ps: don't use ado, it's slw :) Previous Comments: [2002-02-27 21:29:09] [EMAIL PROTECTED] Since PHP can support COM and I usually use php in windows, I try to use database like mssql through ado. All things work properly but the image datatype of mysql cannot be set correctly. I use it just like this ? $dbconn=new COM(ADODB.Connection) or die (connection create fail); $dbconn-Open(Provider=sqloledb;Data Source=ndht;Initial Catalog=printers;User Id=printers;Password=printers;); $fp=fopen(5.gif,r) or die (file opening error); $content = fread ($fp, filesize (5.gif)); fclose ($fp); echo filesize (5.gif); $rec=new COM(ADODB.recordset); $rec-open(select * from sav,$dbconn); $rec-addnew(); $rec-fields[datas]-AppendChunk($content); $rec-update(); $rec-close(); $rec=null; $dbconn-close(); $dbconn=null; ? I think that windows use two type text for strings and binary for the 8bit chars, but in php string are both of these. So when trans the data to mssql,the variables be string of window first, and the information were lost. -- Edit this bug report at http://bugs.php.net/?id=15771edit=1
Bug #15999 Updated: fread() hangs apache when file pointer obtained from a url parameter PHPSESSID
ID: 15999 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Session related Operating System: Linux PHP Version: 4.1.0 New Comment: Ok..let's reopen this. I have no idea what you're doing but if you're not doing what I thought you were, it might be a bug..although that auto_prepend thing makes me wonder.. Please add some example scripts and what needs to be set in php.ini / httpd.conf to reproduce this. Previous Comments: [2002-03-11 12:38:04] [EMAIL PROTECTED] Why do you think that block.html is the same script ? Maybe my example is not very clear. But you are right, Apache behavior looks like infinite recursion. Let me explain again and more precisly : the script A (the one in the previous post) tries to open the url B ($url). Script C is auto_prepended (at fread instruction, right ?) and validate the access to the script B, with the session variable. If I don't use the PHPSESSID in the url parameter (and skip the test in the script C), the script is OK. If I use another parameter than PHPSESSID, the script A is OK. Same behavior with fgets, readfile, etc... Note that the script C is auto_prepended only in a subdirectory (containing only docs like B) by apache configuration (Directory ... php_value /Directory) and of course scripts A and C are not on this directory. [2002-03-11 11:17:55] [EMAIL PROTECTED] You're calling the same script with that fopen() ? The behaviour is called 'infinite recursion' and yes, it will hang. Not a bug. --Jani [2002-03-11 10:48:52] [EMAIL PROTECTED] ?php $url = http://test/block.html?PHPSESSID=.session_id(); $fp = fopen($url, 'r'); // the file pointer semms to be valid $file = fread($fp,1048576); //hangs here ! echo $file; ? hangs apache (1.3.x). Same with 4.0.2, 4.0.6 Linux (RH 6.2 and Debian 2.2), never on Win98. Other parameters don't have the same effect. -- Edit this bug report at http://bugs.php.net/?id=15999edit=1
Bug #16001: File-Upload's mime-type in Opera
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.2 PHP Bug Type: Feature/Change Request Bug description: File-Upload's mime-type in Opera There seems to be a problem when getting uploaded file's mime-type. The problem occurs only with Opera. The file is uploaded correctly, and then I try to check the uploaded file's mime-type. $userfile_type gives: image/gif; name=\logo3.gif\ It should be of cource only image/gif. And the name should be reported only in $userfile_name, not in $userfile_type. So I'll have to write a correction to every my scripts involved with file-uploads. Correction I have made: list ($userfile_type) = split(;, $userfile_type); I have made an example page for uploading images, which is in the address: http://ihastus.net/phpbug/ -- Edit bug report at http://bugs.php.net/?id=16001edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16001r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16001r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16001r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16001r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16001r=support Expected behavior: http://bugs.php.net/fix.php?id=16001r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16001r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16001r=submittedtwice
Bug #16001 Updated: File-Upload's mime-type in Opera
ID: 16001 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.1.2 New Comment: This bug has been fixed in CVS. Previous Comments: [2002-03-11 13:40:16] [EMAIL PROTECTED] There seems to be a problem when getting uploaded file's mime-type. The problem occurs only with Opera. The file is uploaded correctly, and then I try to check the uploaded file's mime-type. $userfile_type gives: image/gif; name=\logo3.gif\ It should be of cource only image/gif. And the name should be reported only in $userfile_name, not in $userfile_type. So I'll have to write a correction to every my scripts involved with file-uploads. Correction I have made: list ($userfile_type) = split(;, $userfile_type); I have made an example page for uploading images, which is in the address: http://ihastus.net/phpbug/ -- Edit this bug report at http://bugs.php.net/?id=16001edit=1
Bug #15578 Updated: using FreeTDS - Re: Now Undefined symbol: dbhead
ID: 15578 Updated by: [EMAIL PROTECTED] -Summary: PHP Causes Apache segmentation when using FreeTDS Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: MSSQL related -Operating System: Linux Red Hat 7.1 +Operating System: Linux Red Hat 7.2 -PHP Version: 4.1.1 +PHP Version: 4.1.2 New Comment: Okay well now I upgraded to apache 1.3.20, and php 4.1.2 and freetds 0.53, I don't even get as far as the segmentation fault anymore because after compiling PHP with: ./configure --with-apxs --with-sybase=/usr/local/freetds --with-pspell and make and make install, apache doesn't seem to be running anymore, I do /etc/rc.d/init.d/httpd restart and the following message appears: Starting httpd: Syntax error on line 260 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/libphp4.so into server: /etc/httpd/modules/libphp4.so: undefined symbol: dbdead[FAILED] I could not find a way to solve this problem. Previous Comments: [2002-02-25 14:44:25] [EMAIL PROTECTED] Well I tried the same thing with another configuration and it seemed to be working so I think it might be an apache related problem. I will upgrade to the latest version of Apache in the next week or so so I will get a backtrace then if the problem persists. Thank you. [2002-02-15 16:05:45] [EMAIL PROTECTED] To properly diagnose this bug, 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. [2002-02-15 15:16:45] [EMAIL PROTECTED] Hi, I need to access a MS-SQL server 2000 from a linux RH7.1 box running PHP 4.1.1 compiled with the following options: ./configure --with-sybase=/usr/local/freetds --with-apxs And freetds installed from RPM (but I also tried with the source and it didn't work either... tried FreeTDS from CVS as well). and apache 1.3.19. PHP seems to be working fine and phpinfo(); seems fine... Whenever I load a PHP script that uses any mssql_* function, the page cannot load The page cannot be displayed... When I check apache's error log, it reports Segmentation Fault on child process. I tried with different versions of PHP and it always crashes the same way but the Perl applications using FreeTDS to connect to the same server work just fine so it probably is a problem related to PHP. Any input ? -- Edit this bug report at http://bugs.php.net/?id=15578edit=1
Bug #14910 Updated: --with-snmp compile failure
ID: 14910 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: Red Hat Linux 7.1 PHP Version: 4.1.1 New Comment: I am using UCD-SNMP 4.2.3 on a Red Hat 7.2 base isntallation. Can't get PHP 4.1.2 (or 4.1.1) to finish compile when using the --with-apxs option. Works fine without the --with-apxs option though. Previous Comments: [2002-03-10 05:59:03] [EMAIL PROTECTED] Hi I am installing php-4.1.2 with ucd-snmp-4.2.3 on RedHatLinux 7.2 and i am getting same type of errors. it configures correctly but in make it gives same type of errors.Is there any solution for this. Please reply back to me on my mail address if possible. [2002-03-01 05:27:41] [EMAIL PROTECTED] I'm using ucd-snmp 4.2.1 and it compiles fine, at least. [2002-02-28 22:17:14] [EMAIL PROTECTED] I am getting an identical error when compiling PHP 4.1.2 with UCD-SNMP 4.2.3 on FreeBSD. When I compile PHP for CGI/command line duties (no --with-apxs... all other options the same) with UCD snmp it compiles without errors. [2002-02-20 03:35:57] [EMAIL PROTECTED] Unreproducible with Debian GNU/Linux woody and standard Debian (dev-)packages of net-snmp, gd etc. net-snmp 4.2.3 and php 4.1.1 [2002-01-30 20:10:27] [EMAIL PROTECTED] I'm just tossing in a comment to say I'm also able to reproduce this bug report with 4.1.1 on Slack 8. 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/14910 -- Edit this bug report at http://bugs.php.net/?id=14910edit=1
Bug #16002: imagecreatetruecolor not recognizing create version of GD library
From: [EMAIL PROTECTED] Operating system: Red Hat Linux PHP version: 4.1.2 PHP Bug Type: GD related Bug description: imagecreatetruecolor not recognizing create version of GD library I rent my server from a virtual host so I do not have much control over the server. This might not be a bug but a error in them compiling it but it should be reported just in case. I had a script that was working that used imagecreatetruecolor with a older version of PHP, I think it was two versions back. Anyway, my server updated to php 4.1.2 and it 2.01 of GD and after that my script would only return this error. Fatal error: imagecreatetruecolor(): requires GD 2.0 or later in /home/member/public_html/website/admin/imgfunctions.php on line 39 As I said it is a virtual server but phpinfo produced this, './configure' '--with-mysql' '--with-apache=../apache_1.3.23' '--enable-track-vars' '--with-gd=/usr/gd-2.0.1' '--with-jpeg-dir=/usr' '--with-png-dir=/usr/local/lib' '--with-zlib-dir=/usr/local/include' This might not be a bug but an error in my server compiling the latest version of PHP. Please email me at [EMAIL PROTECTED] if an error is obvious that you can see that I can't and I will contact my host and see if that is the problem and then this bug report can be closed. -- Edit bug report at http://bugs.php.net/?id=16002edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16002r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16002r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16002r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16002r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16002r=support Expected behavior: http://bugs.php.net/fix.php?id=16002r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16002r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16002r=submittedtwice
Bug #16003: Access Denied when loading ldap extension
From: [EMAIL PROTECTED] Operating system: Win2K PHP version: 4.1.1 PHP Bug Type: Reproducible crash Bug description: Access Denied when loading ldap extension Win2K server, running IIS with PHP 4.1.1 when I try to load the ldap extension, I get a message that says Unable to load dynamic library 'd:\php\extensions/php_ldap.dll' - Access is denied. I don't think it is talking about windows file permissions, because Internet Guest, Guest and Everyone user accounts have full control on the file, and all folders containg the file. -- Edit bug report at http://bugs.php.net/?id=16003edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16003r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16003r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16003r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16003r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16003r=support Expected behavior: http://bugs.php.net/fix.php?id=16003r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16003r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16003r=submittedtwice
Bug #15112 Updated: failed to compile extension modules as a dso
ID: 15112 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: NetBSD/Alpha-1.5.2 PHP Version: 4.1.1 New Comment: Build php using latest snapshot: php4-200203111200.tar.gz It's now building shared extensions fine. However, httpd refuses to run and exits without any error messages when attempting to run it. Previous Comments: [2002-03-09 13:20:07] [EMAIL PROTECTED] Could you please try latest CVS snapshot from http://snaps.php.net/ ? [2002-02-28 09:57:47] [EMAIL PROTECTED] Seeing the same problems with php-4.1.2 [2002-01-19 04:29:24] [EMAIL PROTECTED] # NetBSD/Alpha 1.5.2 PHP-4.1.1 # # Building the CGI export LDFLAGS=-Wl,-R/usr/lib -L/usr/lib -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -Wl,-R/usr/local/lib -L/usr/local/lib -Wl,--export-dynamic -Wl,--whole-archive -Wl,-lgcc -Wl,--no-whole-archive ./configure \ --prefix=/usr/local_install/php-4.1.1 \ --with-config-file-path=/usr/local/etc \ --with-regex=system \ --with-gettext=shared,/usr/pkg \ --with-pgsql=shared,/usr/local \ --with-mysql=shared,/usr/pkg \ --with-pcre-regex \ --with-gd=shared,/usr/local \ --with-jpeg-dir=shared,/usr/pkg \ --with-png-dir=shared,/usr/pkg \ --with-xpm-dir=shared,/usr/pkg \ --with-ttf=shared,/usr/pkg \ --with-freetype-dir=shared,/usr/pkg \ --with-zlib-dir=/usr \ --enable-gd-native-ttf \ --enable-sysvsem=shared \ --enable-sysvshm=shared \ --enable-sockets=shared \ --enable-xml=shared \ --enable-trans-sid \ --enable-discard-path \ --enable-force-cgi-redirect \ --enable-memory-limit \ --enable-track-vars \ --without-t1lib \ --disable-static \ --enable-shared Compiles fine and all that, but the modules aren't in *.so format, instead: # ls -l /usr/local_install/php-4.1.1/lib/php/20010901 total 1291 -rw-r--r-- 1 root wheel 312754 Jan 19 03:25 gd.a -rw-r--r-- 1 root wheel 42044 Jan 19 03:25 gettext.a -rw-r--r-- 1 root wheel 169096 Jan 19 03:25 mysql.a -rw-r--r-- 1 root wheel 263840 Jan 19 03:25 pcre.a -rw-r--r-- 1 root wheel 181726 Jan 19 03:25 pgsql.a -rw-r--r-- 1 root wheel 174484 Jan 19 03:25 sockets.a -rw-r--r-- 1 root wheel 49260 Jan 19 03:25 sysvsem.a -rw-r--r-- 1 root wheel 57342 Jan 19 03:25 sysvshm.a # Seems like libtool failed somewhere? -- Edit this bug report at http://bugs.php.net/?id=15112edit=1
Bug #16004: @imap_msgno() and @imap_header() display warnings
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.2 PHP Bug Type: IMAP related Bug description: @imap_msgno() and @imap_header() display warnings When processing an email with a header of 'To: ', imap_msgno() and imap_header give errors of Unexpected characters at end of address: (errflg=3) in Unknown on line 0, even when I call the functions with an @ preceding the function name to surpress error output. -- Edit bug report at http://bugs.php.net/?id=16004edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16004r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16004r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16004r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16004r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16004r=support Expected behavior: http://bugs.php.net/fix.php?id=16004r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16004r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16004r=submittedtwice
Bug #16005: Conflict between OpenLDAP and Oracle
From: [EMAIL PROTECTED] Operating system: Solaris 8/Intel PHP version: 4.1.2 PHP Bug Type: LDAP related Bug description: Conflict between OpenLDAP and Oracle PHP dumps core when compiled with both LDAP and OCI8. The reason is the Oracle client libraries include an LDAP library, and PHP is calling the Oracle ldap_modify_s instead of the OpenLDAP ldap_modify_s. We are using OpenLDAP 1.2.11 and Oracle 8.1.6. Short-term workaround: use LD_PRELOAD, e.g. add: LD_PRELOAD=/usr/local/ldap/lib/libldap.so export LD_PRELOAD to your Apache start scripts. Here is the gdb backtrace: (gdb) r -X -f /usr/local/apache/conf/httpd-kefta.conf Starting program: /usr/local/apache/bin/httpd -X -f /usr/local/apache/conf/httpd -kefta.conf [New LWP 1] [New LWP 2] [New LWP 3] warning: Lowest section in /usr/lib/libintl.so.1 is .dynamic at 0074 [New LWP 4] warning: Lowest section in /usr/lib/libintl.so.1 is .dynamic at 0074 Program received signal SIGSEGV, Segmentation fault. 0xde589e0a in gsleenSBerPrintf () from /export/home/oracle/lib/libclntsh.so.8.0 (gdb) bt #0 0xde589e0a in gsleenSBerPrintf () from /export/home/oracle/lib/libclntsh.so.8.0 #1 0xde580234 in gslcmom_Modify () from /export/home/oracle/lib/libclntsh.so.8.0 #2 0xde57d8e7 in ldap_modify_s () from /export/home/oracle/lib/libclntsh.so.8.0 #3 0xdee2f440 in php_ldap_do_modify (ht=3, return_value=0x81f5d0c, this_ptr=0x0, return_value_used=0, oper=2) at ldap.c:1364 #4 0xdee2f5e1 in zif_ldap_modify (ht=3, return_value=0x81f5d0c, this_ptr=0x0, return_value_used=0) at ldap.c:1399 #5 0xdedd51b9 in execute (op_array=0x8195fc0) at ./zend_execute.c:1590 #6 0xdedd540c in execute (op_array=0x819296c) at ./zend_execute.c:1630 #7 0xdede66b0 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:814 #8 0xdedf98c1 in php_execute_script (primary_file=0x8047808) at main.c:1307 #9 0xdedf3d4a in apache_php_module_main (r=0x818a750, display_source_mode=0) at sapi_apache.c:90 #10 0xdedf4f00 in send_php (r=0x818a750, display_source_mode=0, filename=0x818c338 /usr/local/apache/htdocs/mail/mailforward.php) at mod_php4.c:575 #11 0xdedf4f73 in send_parsed_php (r=0x818a750) at mod_php4.c:590 #12 0x8088945 in ap_invoke_handler (r=0x818a750) at http_config.c:517 #13 0x809e794 in process_request_internal (r=0x818a750) at http_request.c:1308 #14 0x809e7fe in ap_process_request (r=0x818a750) at http_request.c:1324 ---Type return to continue, or q return to quit---q Quit (gdb) i sym Here is the final link stage in compiling PHP. Please note -lldap is supplied before -lclntsh, and thus OpenLDAP should resolve first, but apparently this is not the case: /bin/sh /home/majid/src/php-4.1.2/libtool --silent --mode=link gcc -I. -I/home/ majid/src/php-4.1.2/ -I/home/majid/src/php-4.1.2/main -I/home/majid/src/php-4.1. 2 -I/usr/local/ldap/include -I/export/home/oracle/rdbms/demo -I/export/home/orac le/network/public -Iexpat/xmltok -Iexpat/xmlparse -Iimap-4.7c/c-client -I/usr/lo cal/apache/include -I/home/majid/src/php-4.1.2/Zend -I/usr/local/include/freetyp e -I/usr/local/include -I/usr/local/ldap/include -I/usr/local/mysql/include/mysq l -I/export/home/oracle/rdbms/public -I/export/home/oracle/rdbms/demo -I/export/ home/oracle/network/public -I/home/majid/src/php-4.1.2/ext/xml/expat -D_POSIX_P THREAD_SEMANTICS -DSOLARIS2=280 -DMOD_SSL=208106 -DEAPI -DEAPI_MM -DUSE_EXPAT -I /home/majid/src/php-4.1.2/TSRM -g -DEAPI -prefer-pic -o libphp4.la -rpath /hom e/majid/src/php-4.1.2/libs -export-symbols /home/majid/src/php-4.1.2/sapi/apache /php.sym -avoid-version -L/usr/ucblib -L/usr/local/lib/gcc-lib/i386-pc-solaris2. 8/2.95.2 -L/usr/local/lib -L/usr/local/ldap/lib -L/usr/local/mysql/lib/mysql -L/ export/home/oracle/lib -R /usr/ucblib -R /usr/local/lib/gcc-lib/i386-pc-solaris 2.8/2.95.2 -R /usr/local/lib -R /usr/local/ldap/lib -R /usr/local/mysql/lib/mysq l -R /export/home/oracle/lib stub.lo Zend/libZend.la sapi/apache/libsapi.la m ain/libmain.la regex/libregex.la ext/gd/libgd.la ext/imap/libimap.la ext/ldap/ libldap.la ext/mhash/libmhash.la ext/mysql/libmysql.la ext/oci8/liboci8.la ext/p cre/libpcre.la ext/posix/libposix.la ext/session/libsession.la ext/standard/libs tandard.la ext/xml/libxml.la TSRM/libtsrm.la -L/usr/local/ldap/lib -L/usr/local /lib -lgd -lmhash -llber -lldap -L/export/home/oracle/lib -lclient8 -lclntsh -L/ usr/local/mysql/lib/mysql -lmysqlclient -lpam -limap -ldl -lm -lthread -laio -le lf -ldl -lgen -lnsl -lsocket -lmysqlclient -lmhash -lldap -llber -lcrypt -lpam - lgd -lttf -lcrypt -lresolv -lresolv -lresolv -lm -ldl -lnsl -lsocket -lsocket -l gcc -lcrypt -lclntsh -- Edit bug report at http://bugs.php.net/?id=16005edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16005r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16005r=alreadyfixed Need backtrace:
Bug #16006 Updated: ODBC data transfer
ID: 16006 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: ODBC related Operating System: RedHat 7.2 PHP Version: 4.1.2 New Comment: I suggest you try this with iODBC, as a comparison. www.iodbc.org Best regards, Andrew Hill OpenLink Software Previous Comments: [2002-03-11 16:55:28] [EMAIL PROTECTED] Hello there. Is there maximum limit of data ( SQL query ) that can be send via odbc? I've been exerimenting with inserting large text into database and noticed that sent queries larger than 8190 byte are cause to error: SQL error: [unixODBC]Requested value changed., SQL state 01S02 in SQLExecDirect in /path/scriptname while sending queries larger than 8190 byte from DataManager ( unixODBC client ) works just fine. So, problem looks in PHP... Now I wonder if it's a bug or some configuration errors? ( I'm not expert ) Second problem - Recieving binary data via ODBC. Selected binary data corrupted... ( Less in size ) functions odbc_binmode() and odbc_longreadlen() did not help. while selecting the same data via builtin Postgres functions works fine. -- Edit this bug report at http://bugs.php.net/?id=16006edit=1
Bug #16006 Updated: ODBC data transfer
ID: 16006 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: ODBC related Operating System: RedHat 7.2 PHP Version: 4.1.2 New Comment: Marking as feedback. Previous Comments: [2002-03-11 17:04:29] [EMAIL PROTECTED] I suggest you try this with iODBC, as a comparison. www.iodbc.org Best regards, Andrew Hill OpenLink Software [2002-03-11 16:55:28] [EMAIL PROTECTED] Hello there. Is there maximum limit of data ( SQL query ) that can be send via odbc? I've been exerimenting with inserting large text into database and noticed that sent queries larger than 8190 byte are cause to error: SQL error: [unixODBC]Requested value changed., SQL state 01S02 in SQLExecDirect in /path/scriptname while sending queries larger than 8190 byte from DataManager ( unixODBC client ) works just fine. So, problem looks in PHP... Now I wonder if it's a bug or some configuration errors? ( I'm not expert ) Second problem - Recieving binary data via ODBC. Selected binary data corrupted... ( Less in size ) functions odbc_binmode() and odbc_longreadlen() did not help. while selecting the same data via builtin Postgres functions works fine. -- Edit this bug report at http://bugs.php.net/?id=16006edit=1
Bug #15799 Updated: Another segfault on iconv
ID: 15799
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Closed
Bug Type: ICONV related
Operating System: Linux
PHP Version: 4.0CVS-2002-02-2
Assigned To: mfischer
New Comment:
I'm closing this because I think your code is bogus. The manual clearly
says The function (ob_iconv_handler) will be called when
ob_end_flush() is called, or when the output buffer is flushed to the
browser at the end of the request.
So, if you call ob_get_contents() and ob_end_clean() you do not get any
conversion. If you either call ob_end_flush() or just don't call any
further ob*() functions the conversion works as expected for me.
Feel free to re-open if you think I'm wrong.
Previous Comments:
[2002-03-11 05:58:19] [EMAIL PROTECTED]
Yep, saw it. Will fix this later (this day).
[2002-03-11 05:18:13] [EMAIL PROTECTED]
I see you already committed the patch to cvs and, yes, php doesn't
segfault anymore, thanks.
But unfortunately the conversion doesn't happen at all. You can try the
same script I posted earlier to reproduce it. Method 1 converts
correctly, method 2 just send the Big5 data asis.
[2002-03-10 18:01:25] [EMAIL PROTECTED]
Fixed in CVS and 4.2.0 branch.
[2002-03-09 15:34:13] [EMAIL PROTECTED]
I've sent a patch to jan (wouldn't make sense to paste here as long
lines get broken) and I'm pretty sure it's the right fix. I bet the
current code never really worked the way it was written.
Anyway I'm for deprecating iconv_(set|get)_encoding. All it does is
changing INI settigns which can be easily read and set with
ini_get(iconv.input_encoding) or ini_set(). However I don't know what
the general consesus in in such situations. The two functions just seem
redundant to me.
[2002-03-09 11:19:45] [EMAIL PROTECTED]
The segfaults still happen even after the recent changes in the iconv
extension and the output buffering code.
Here is a small script to reproduce it. Method 1 (commented out) works
fine, method 2 segfaults.
?
error_reporting(E_ALL);
$text = END
Thanks !!
David Chang
-
¨C¤Ñ³£ Yahoo!©_¼¯ www.yahoo.com.tw
END;
// Method 1: Works!
/*
$src = 'BIG5';
$dst = 'UTF-8';
$rc = iconv($src, $dst, $text);
header('Content-Type: text/plain; charset=UTF-8');
echo $rc;
*/
// Method 2: Segfaults!
iconv_set_encoding('input_encoding', 'BIG5');
iconv_set_encoding('internal_encoding', 'UTF-8');
iconv_set_encoding('output_encoding', 'UTF-8');
ob_start('ob_iconv_handler');
echo $text;
$rc = ob_get_contents();
ob_end_clean();
header('Content-Type: text/plain; charset=UTF-8');
echo $rc;
?
Since the line numbers changed since my initial report and I use a
different script (above), here's also an updated bt:
Program received signal SIGSEGV, Segmentation fault.
0x4010621a in chunk_free (ar_ptr=0x7a62e850, p=0x404ea168) at
malloc.c:3049
3049malloc.c: No such file or directory.
(gdb) bt
#0 0x4010621a in chunk_free (ar_ptr=0x7a62e850, p=0x404ea168) at
malloc.c:3049
#1 0x401061bf in free () at malloc.c:2952
#2 0x403744ec in zif_iconv_set_encoding () at iconv.c:267
#3 0x40317077 in execute () at ./zend_execute.c:959
#4 0x40328fb4 in zend_execute_scripts () at zend.c:373
#5 0x4033cea7 in php_execute_script () at main.c:1309
#6 0x40337240 in apache_php_module_main () at sapi_apache.c:100
#7 0x403381d8 in send_php (r=0x81825a0, display_source_mode=0,
filename=0x81841a8 /usr/local/httpd/htdocs/headhorde/iconv.php)
at mod_php4.c:575
#8 0x40338263 in send_parsed_php (r=0x81825a0) at mod_php4.c:590
#9 0x8055250 in ap_invoke_handler ()
#10 0x80677bc in ap_some_auth_required ()
#11 0x8067833 in ap_process_request ()
#12 0x805fd27 in ap_child_terminate ()
#13 0x805fed5 in ap_child_terminate ()
#14 0x8060016 in ap_child_terminate ()
#15 0x8060628 in ap_child_terminate ()
#16 0x8060e95 in main ()
#17 0x400cca8e in __libc_start_main () at
../sysdeps/generic/libc-start.c:93
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/15799
--
Edit this bug report at http://bugs.php.net/?id=15799edit=1
Bug #10585 Updated: Php can't connect to MySQL database
ID: 10585 Updated by: [EMAIL PROTECTED] -Summary: Php can't connect to MySQL database Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: MySQL related Operating System: redhat 7 PHP Version: 4.0.5 New Comment: This is fixed. --Jani Previous Comments: [2002-03-11 15:53:02] [EMAIL PROTECTED] The security patch from redhat apparently causes this problem (possibly among other things). Editing the socket entry in the php.ini file fixes the problem. My version is 4.0.6-12. [2002-03-06 22:14:12] [EMAIL PROTECTED] And what is your PHP version? [2002-03-06 15:38:52] [EMAIL PROTECTED] Edit the mysql socket entry in the php.ini file and restart the httpd. Try this: mysql.default_socket = /var/lib/mysql/mysql.sock [2001-05-01 20:24:30] [EMAIL PROTECTED] There was a bug in the configure. Should be fixed in CVS now. --Jani [2001-05-01 14:53:20] [EMAIL PROTECTED] most likely a configuration error ask a support forum like [EMAIL PROTECTED] 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/10585 -- Edit this bug report at http://bugs.php.net/?id=10585edit=1
Bug #16003 Updated: Access Denied when loading ldap extension
ID: 16003 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Win2K PHP Version: 4.1.1 New Comment: The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Previous Comments: [2002-03-11 15:56:16] [EMAIL PROTECTED] Win2K server, running IIS with PHP 4.1.1 when I try to load the ldap extension, I get a message that says Unable to load dynamic library 'd:\php\extensions/php_ldap.dll' - Access is denied. I don't think it is talking about windows file permissions, because Internet Guest, Guest and Everyone user accounts have full control on the file, and all folders containg the file. -- Edit this bug report at http://bugs.php.net/?id=16003edit=1
Bug #15307 Updated: Segmentation fault if cURL tries to get a page and the server returns nothing.
ID: 15307 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: cURL related Operating System: Linux 2.4.x PHP Version: 4.1.1 Assigned To: sterling New Comment: This is fixed in 4.1.2 (I believe) or CVS most definitely... Previous Comments: [2002-03-01 10:38:05] [EMAIL PROTECTED] Same problem here. But: same code on another machine works just fine. Only differences: working one:curl --version curl 7.9.2 (i686-pc-linux-gnu) libcurl 7.9.2 (OpenSSL 0.9.6a) not-working one: curl --version curl 7.9.3 (i686-pc-linux-gnu) libcurl 7.9.3 (OpenSSL 0.9.5) [2002-02-20 02:54:47] [EMAIL PROTECTED] I've experienced the same problem. Additionally info: it works fine with PHP 4.0.6. [2002-01-30 22:22:29] [EMAIL PROTECTED] Oops - that's wrong; the OpenSSL option is installed in libcurl, but this particular segfault happened using plain old http. [2002-01-30 22:17:12] [EMAIL PROTECTED] One more thing - I'm using https protocol for the transfer. [2002-01-30 22:14:25] [EMAIL PROTECTED] I found this behavior while building a client-server system that uses cURL to get data from the server; when my server-side script didn't return anything at all, it caused the client side Apache process to actually die with a signal 11. I have the latest libcurl and the latest PHP, and I've just tried updating Apache to see if that affects the behavior (it doesn't, but it seemed like a good excuse to get my development system up to date). The only option I'm using for cURL is CURLOPT_RETURNTRANSFER. I'm not sure if this means anything, but if I run cURL from the command line, it doesn't segfault when visiting the same totally empty URL. Thanks for PHP! It's good, fast, AND cheap -- Edit this bug report at http://bugs.php.net/?id=15307edit=1
Bug #15943 Updated: Viewing .phps Crashes with php.ini-recommended
ID: 15943 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Unknown/Other Function Operating System: FreeBSD PHP Version: 4.1.2 New Comment: I've found which php.ini directive is the culprit here. output_buffering = 4096 If this is set to Off, there are no problems. Just some added info. Maybe someone could elaborate on why this happens, and if there is a work around? Thanks, Hans Previous Comments: [2002-03-07 21:40:48] [EMAIL PROTECTED] I could some more details? For one, why it should be removed, and two what in the php.ini file breaks the .phps functionality? Using .phps is very useful.. I would think only having show_source() would be clunky, as you'd need another script to just display others. [2002-03-07 21:36:31] [EMAIL PROTECTED] This is known issue but I don't know if this is reported. I think phps feature should be removed. (Thoes who know issues understand why :) Use show_source() instead. [2002-03-07 21:00:26] [EMAIL PROTECTED] I've installed 4.1.2 and everything works fine with the latest Apache release on the latest FreeBSD release. However, when I try to view a .phps page, the connection to the browser closes abruptly. I was using the supplied php.ini-recommended, and after playing around for a while, saw that using php.ini-dist cleared the problem up. I've looked at both php.ini's supplied with the source, but can't see any difference that would effect this. How can using php.ini-recommended (doesn't work) versus php.ini-dist (works) make a difference, and how can this be straightened out? Thank you, Hans -- Edit this bug report at http://bugs.php.net/?id=15943edit=1
Bug #14998 Updated: Can't name a class 'Directory'
ID: 14998
Updated by: [EMAIL PROTECTED]
-Summary: Can't name a class 'Directory'
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: Red Hat Linux 7.0
PHP Version: 4.0.5
New Comment:
This bug has been fixed in CVS.
Previous Comments:
[2002-03-04 11:47:28] [EMAIL PROTECTED]
This one just bit me for 20 minutes as well. A documentation change
would be quite helpful (Also, I think this is something that would
generally be happier in PEAR or similar, but that's a diffrent problem
:).
[2002-01-11 13:54:29] [EMAIL PROTECTED]
See http://www.php.net/manual/en/function.get-declared-classes.php. It
is predefined. Should be pointed out more clearly, - documentation
problem.
[2002-01-11 12:17:37] [EMAIL PROTECTED]
For example, given the code:
?
class Directory
{
// CONSTRUCTOR
function Directory($req_id = FALSE)
{
// nothing
}
}
?
PHP gives the error: Cannot redeclare class directory. Maybe the the
dir() function/class interferes??
Configuration:
'./configure' '--prefix=/usr' '--with-apxs=/usr/sbin/apxs'
'--with-exec-dir=/usr/bin' '--with-config-file-path=/etc/httpd'
'--with-regex=system' '--enable-debugger' '--enable-magic-quotes'
'--enable-sysvshm' '--with-dom' '--enable-force-cgi-redirect'
'--enable-sigchild' '--with-wddx' '--enable-inline-optimization'
'--with-gnu-ld' '--enable-bcmath' '--enable-crypt' '--with-xml'
'--with-sablot' '--enable-dbg=shared' '--with-dbg-profiler'
Thanks.
--
Edit this bug report at http://bugs.php.net/?id=14998edit=1
Bug #15595 Updated: imap routines hang when To header is too large
ID: 15595
Updated by: [EMAIL PROTECTED]
-Summary: imap routines hang when To header is too large
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: IMAP related
Operating System: Solaris-i86
PHP Version: 4.1.1
New Comment:
We upgraded last week to 4.1.2, the problem still occurs.
Previous Comments:
[2002-03-11 09:37:31] [EMAIL PROTECTED]
First of all you should try with the latest c-client.
--Jani
[2002-03-11 04:47:56] [EMAIL PROTECTED]
Is there anything I can do to help this along? We've been bitten twice
by this in the last few days.
[2002-02-18 18:09:33] [EMAIL PROTECTED]
An exact script is difficult. (I've spent a day or two trying to pin it
down to a simple routine, not with any great success).
However, it looks like
$h = @imap_header($imp-stream, imap_msgno($imp-stream, $msgnum));
is hanging with a message that has to header of about 4K (again, this
probably violates rfc822, but it shouldn't hang like it does).
$imp-stream is constructed like this (as you'd expect):
$connstr = '{' . $this-server . ':' . $this-port . '}' .
$this-mailbox;
$this-stream = @imap_open($connstr, $this-user, $this-pass);
Thanks.
[2002-02-18 08:29:31] [EMAIL PROTECTED]
Can you provide a simple sample script?
[2002-02-18 04:23:34] [EMAIL PROTECTED]
The starting point for this was that our webmail (customised IMP)would
crash if the To header was too large. Probably the header violates
rfc822, but php should be able to cope, or at least fail gracefully and
not hang.
We are running php built with the imap4.5 uwash c-client, with ldap,
with mysql. Apache is built with mods rewrite, mime_magic, the lastest
fastcgi, the latest modssl. The fastcgi connection is used for most
pages rendered from our site.
Playing around with truss led us to suspect mime_header_decode was at
fault, ie:
php_if_imap_mime_header_decode+0x6d3: movl (%ebx),%edx
Now, in getting a gdb backtrace, things got very wierd. Below is the
output - but it occurs not only when we try to read the email with the
oversized to header, but when I try to do something mundane like parse
the whole mailbox.
So maybe there are two problems, needless to say - I hope the truss
line is useful, because I wouldn't rely on the gdb backtrace.
Thanks.
Program received signal SIGPIPE, Broken pipe.
0xdfee1f3b in _writev ()
(gdb) bt
#0 0xdfee1f3b in _writev ()
#1 0x80b2254 in ssl_io_unregister ()
#2 0x81ba5f4 in ap_hook_call ()
#3 0x81b9d41 in ap_hook_call ()
#4 0x8196641 in ap_bfilbuf ()
#5 0x8196a6c in ap_bfilbuf ()
#6 0x8196b38 in ap_bwrite ()
#7 0x816537e in php_mergesort ()
#8 0x8166ec5 in php_mergesort ()
#9 0x816749d in php_mergesort ()
#10 0x8197ddb in ap_invoke_handler ()
#11 0x81ac451 in ap_some_auth_required ()
#12 0x81ac4b0 in ap_process_request ()
#13 0x81a3ad1 in ap_child_terminate ()
#14 0x81a3c80 in ap_child_terminate ()
#15 0x81a3ddb in ap_child_terminate ()
#16 0x81a43d8 in ap_child_terminate ()
#17 0x81a4b9b in main ()
#18 0x809b947 in _start ()
--
Edit this bug report at http://bugs.php.net/?id=15595edit=1
Bug #14734 Updated: new superglobals ($_SERVER, etc.) not documented
ID: 14734 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Win XP PHP Version: 4.1.0 New Comment: This has been fixed in CVS. FWIW, I think that if $PHP_SELF is to be documented outside of the $_SERVER list, it should be worded carefully to prevent users wondering why $PHP_SELF isn't available in the global scope. Torben Previous Comments: [2002-01-04 01:16:40] [EMAIL PROTECTED] but $PHP_SELF is also a special variable, so I think also listing it out of any collection is a good thing. [2001-12-28 11:35:45] [EMAIL PROTECTED] Tested again. Yes you are right. It would be good to have it listed only in _SERVER, as the other vars. [2001-12-28 10:29:47] [EMAIL PROTECTED] It's printed in _SERVER too (apache 1.3.22/php 4.1.0). [2001-12-28 10:17:17] [EMAIL PROTECTED] Just a note: in the PHP 4.1.0 phpinfo() output, all the predefined vars are printed as _SERVER and _ENV members, except PHP_SELF, it is printed alone, and not in any array. This must be corrected! [2001-12-28 10:05:28] [EMAIL PROTECTED] Valid point. I'm reopening this as a documentation problem. 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/14734 -- Edit this bug report at http://bugs.php.net/?id=14734edit=1
Bug #15595 Updated: imap routines hang when To header is too large
ID: 15595
Updated by: [EMAIL PROTECTED]
-Summary: imap routines hang when To header is too large
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: IMAP related
Operating System: Solaris-i86
PHP Version: 4.1.1
New Comment:
Try the latest _c-client_ library, not PHP.
As this is most likely not bug in PHP but in the
c-client library itself.
--Jani
Previous Comments:
[2002-03-11 20:52:16] [EMAIL PROTECTED]
We upgraded last week to 4.1.2, the problem still occurs.
[2002-03-11 09:37:31] [EMAIL PROTECTED]
First of all you should try with the latest c-client.
--Jani
[2002-03-11 04:47:56] [EMAIL PROTECTED]
Is there anything I can do to help this along? We've been bitten twice
by this in the last few days.
[2002-02-18 18:09:33] [EMAIL PROTECTED]
An exact script is difficult. (I've spent a day or two trying to pin it
down to a simple routine, not with any great success).
However, it looks like
$h = @imap_header($imp-stream, imap_msgno($imp-stream, $msgnum));
is hanging with a message that has to header of about 4K (again, this
probably violates rfc822, but it shouldn't hang like it does).
$imp-stream is constructed like this (as you'd expect):
$connstr = '{' . $this-server . ':' . $this-port . '}' .
$this-mailbox;
$this-stream = @imap_open($connstr, $this-user, $this-pass);
Thanks.
[2002-02-18 08:29:31] [EMAIL PROTECTED]
Can you provide a simple sample script?
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/15595
--
Edit this bug report at http://bugs.php.net/?id=15595edit=1
Bug #16010: phpinfo manual page bad grammar
From: [EMAIL PROTECTED] Operating system: n/a PHP version: 4.1.2 PHP Bug Type: Documentation problem Bug description: phpinfo manual page bad grammar on http://www.php.net/manual/en/function.phpinfo.php, in the phpinfo() options table: Loaded modules and there respective settings. should be: Loaded modules and their respective settings. (is this the right place to report this sort of error?) S -- Edit bug report at http://bugs.php.net/?id=16010edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16010r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16010r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16010r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16010r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16010r=support Expected behavior: http://bugs.php.net/fix.php?id=16010r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16010r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16010r=submittedtwice
Bug #16011: --with-bcmath link error
From: [EMAIL PROTECTED] Operating system: Mac OS X 10.1.3 PHP version: 4.0CVS-2002-03-11 PHP Bug Type: Compile Failure Bug description: --with-bcmath link error Configure Line: ./configure --with-ldap=/usr/local --with-xml --enable-shared --enable-versioning --enable-trans-id --enable-t rack-vars --enable-ftp --with-mysql --with-pdflib=/usr/local --with-zlib-dir=/usr/local --with-png-dir=/usr/lo cal --with-jpeg-dir=/usr/local --with-gd=/usr/local --with-tiff-dir=/usr/local --with-apxs=/usr/sbin/apxs --en able-openbase_module --with-pgsql=/Library/PostgreSQL --with-curl=/usr/local --with-pspell=/usr/local/pspell - -enable-exif --enable-wddx --enable-mbstring --enable-mbstr-enc-trans --with-iconv=/usr/local/iconv --enable-b cmath Yields the following output during the final link phase: /usr/bin/ld: multiple definitions of symbol __bc_Free_list ext/bcmath/libbcmath/src/add.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/div.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/init.lo definition of __bc_Free_list in section (__DATA,__data) /usr/bin/ld: multiple definitions of symbol __one_ ext/bcmath/bcmath.lo definition of __one_ in section (__DATA,__common) ext/bcmath/libbcmath/src/init.lo definition of __one_ in section (__DATA,__common) /usr/bin/ld: multiple definitions of symbol __two_ ext/bcmath/bcmath.lo definition of __two_ in section (__DATA,__common) ext/bcmath/libbcmath/src/init.lo definition of __two_ in section (__DATA,__common) /usr/bin/ld: multiple definitions of symbol __zero_ ext/bcmath/bcmath.lo definition of __zero_ in section (__DATA,__common) ext/bcmath/libbcmath/src/init.lo definition of __zero_ in section (__DATA,__common) ext/bcmath/libbcmath/src/neg.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/outofmem.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/raisemod.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/rt.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/sub.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/compare.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/divmod.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/int2num.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/num2long.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/output.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/recmul.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/sqrt.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/zero.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/debug.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/doaddsub.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/nearzero.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/num2str.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/raise.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/rmzero.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/str2num.lo definition of __bc_Free_list in section (__DATA,__common) make: *** [libphp4.la] Error 1 This is also the case with 4.1.2 stable. -- Edit bug report at http://bugs.php.net/?id=16011edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16011r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16011r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16011r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16011r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16011r=support Expected behavior: http://bugs.php.net/fix.php?id=16011r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16011r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16011r=submittedtwice
Bug #16011 Updated: --enable-bcmath link error
ID: 16011 Updated by: [EMAIL PROTECTED] -Summary: --with-bcmath link error Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: Mac OS X 10.1.3 PHP Version: 4.0CVS-2002-03-11 New Comment: wrong configure argument in title :\ Previous Comments: [2002-03-11 22:24:33] [EMAIL PROTECTED] Configure Line: ./configure --with-ldap=/usr/local --with-xml --enable-shared --enable-versioning --enable-trans-id --enable-t rack-vars --enable-ftp --with-mysql --with-pdflib=/usr/local --with-zlib-dir=/usr/local --with-png-dir=/usr/lo cal --with-jpeg-dir=/usr/local --with-gd=/usr/local --with-tiff-dir=/usr/local --with-apxs=/usr/sbin/apxs --en able-openbase_module --with-pgsql=/Library/PostgreSQL --with-curl=/usr/local --with-pspell=/usr/local/pspell - -enable-exif --enable-wddx --enable-mbstring --enable-mbstr-enc-trans --with-iconv=/usr/local/iconv --enable-b cmath Yields the following output during the final link phase: /usr/bin/ld: multiple definitions of symbol __bc_Free_list ext/bcmath/libbcmath/src/add.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/div.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/init.lo definition of __bc_Free_list in section (__DATA,__data) /usr/bin/ld: multiple definitions of symbol __one_ ext/bcmath/bcmath.lo definition of __one_ in section (__DATA,__common) ext/bcmath/libbcmath/src/init.lo definition of __one_ in section (__DATA,__common) /usr/bin/ld: multiple definitions of symbol __two_ ext/bcmath/bcmath.lo definition of __two_ in section (__DATA,__common) ext/bcmath/libbcmath/src/init.lo definition of __two_ in section (__DATA,__common) /usr/bin/ld: multiple definitions of symbol __zero_ ext/bcmath/bcmath.lo definition of __zero_ in section (__DATA,__common) ext/bcmath/libbcmath/src/init.lo definition of __zero_ in section (__DATA,__common) ext/bcmath/libbcmath/src/neg.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/outofmem.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/raisemod.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/rt.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/sub.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/compare.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/divmod.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/int2num.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/num2long.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/output.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/recmul.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/sqrt.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/zero.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/debug.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/doaddsub.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/nearzero.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/num2str.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/raise.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/rmzero.lo definition of __bc_Free_list in section (__DATA,__common) ext/bcmath/libbcmath/src/str2num.lo definition of __bc_Free_list in section (__DATA,__common) make: *** [libphp4.la] Error 1 This is also the case with 4.1.2 stable. -- Edit this bug report at http://bugs.php.net/?id=16011edit=1
Bug #15799 Updated: Another segfault on iconv
ID: 15799
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Analyzed
Bug Type: ICONV related
Operating System: Linux
PHP Version: 4.0CVS-2002-02-2
New Comment:
Yes true ... weird. Upon taking a closer look it seems the iconv fails
with 'Invalid or incomplete multibyte or wide character' but the error
code is not properly handled in the code in the first and therefore not
recognized. Will take a closer look later (this day ;).
Maybe you can verify if your input data really without errors?
Previous Comments:
[2002-03-11 17:40:44] [EMAIL PROTECTED]
Ah, you're right, I thought all ob_* functions that return or output
the buffer pass the data through the ob_handler first.
But even if I use it the intended way, the output is not converted.
This is the new script I used:
?
error_reporting(E_ALL);
$text = END
Thanks !!
David Chang
-
¨C¤#1139;£ Yahoo!©_¼¯ www.yahoo.com.tw
END;
iconv_set_encoding('input_encoding', 'BIG5');
iconv_set_encoding('internal_encoding', 'UTF-8');
iconv_set_encoding('output_encoding', 'UTF-8');
ob_start('ob_iconv_handler');
echo $text;
header('Content-Type: text/plain; charset=UTF-8');
ob_end_flush();
?
[2002-03-11 17:10:02] [EMAIL PROTECTED]
I'm closing this because I think your code is bogus. The manual clearly
says The function (ob_iconv_handler) will be called when
ob_end_flush() is called, or when the output buffer is flushed to the
browser at the end of the request.
So, if you call ob_get_contents() and ob_end_clean() you do not get any
conversion. If you either call ob_end_flush() or just don't call any
further ob*() functions the conversion works as expected for me.
Feel free to re-open if you think I'm wrong.
[2002-03-11 05:58:19] [EMAIL PROTECTED]
Yep, saw it. Will fix this later (this day).
[2002-03-11 05:18:13] [EMAIL PROTECTED]
I see you already committed the patch to cvs and, yes, php doesn't
segfault anymore, thanks.
But unfortunately the conversion doesn't happen at all. You can try the
same script I posted earlier to reproduce it. Method 1 converts
correctly, method 2 just send the Big5 data asis.
[2002-03-10 18:01:25] [EMAIL PROTECTED]
Fixed in CVS and 4.2.0 branch.
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/15799
--
Edit this bug report at http://bugs.php.net/?id=15799edit=1
