Bug #15828 Updated: Trim() leaving 1 begining/ending whitespace
ID: 15828 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Output Control Operating System: WindowsXP Pro PHP Version: 4.1.1 New Comment: RTFM! trim() returns the trimmed string. $foo = trim($foo) and not trim($foo) Previous Comments: [2002-03-02 03:09:45] [EMAIL PROTECTED] This is using php4isapi.dll $var = ' content '; trim($var); echo "->".$var."<-"; echo "->$var<-"; Output: -> content <- -> content <- leaves 1 whitespace at the beginning and at the end. -- Edit this bug report at http://bugs.php.net/?id=15828&edit=1
Bug #15825 Updated: isset() raises warning for undefined class property
ID: 15825
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Analyzed
+Status: Closed
Bug Type: Variables related
Operating System: ANY
PHP Version: 4.0CVS-2002-03-0
New Comment:
There is nothing wrong here, it prints "PHP Notice: Uninitialized
string offset: 0 in - on line 5" for me, which it should.
Derick
Previous Comments:
[2002-03-01 22:32:40] [EMAIL PROTECTED]
Should be fixed before 4.2.0, IMO
[2002-03-01 22:32:03] [EMAIL PROTECTED]
4.0..x does not raise error, but 4.1.x does.
dd[0])){
echo "(A) TRUE \n";
}else{
echo "(A) FALSE \n";
}
if (is_array($test->dd) && isset($test->dd[0])){
echo "(B) TRUE \n";
}else{
echo "(B) FALSE \n";
}
?>
--
Edit this bug report at http://bugs.php.net/?id=15825&edit=1
Bug #15827 Updated: posts with enctype=multipart/form-data do not register post vars.
ID: 15827 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Bogus Bug Type: Variables related Operating System: Redhat 7.0 PHP Version: 4.1.2 New Comment: Making this bogus (user error) Derick Previous Comments: [2002-03-02 01:04:34] [EMAIL PROTECTED] My mistake - after my upgrade (due to the security risk) I didn't re-set the ini file to allow file uploads again. I guess this directive is there to prevent unauthorised multipart submissions. For others experiencing this problem, check your ini file and ensure the following line exists: file_uploads = On [2002-03-02 00:54:03] [EMAIL PROTECTED] Forms with an enctype of 'multitype/form-data' do not register the POST variables. Here's how to reproduce: - Short Script Follows - - End Script - Run the script above. It is simple enough - it has a form that submits to itself, and then displays the HTTP_POST_VARS variable. When I remove the enctype='multipart/form-data' attribute from the form tag, the script works fine (i.e. the variable 'foo' appears). The enctype directive appears to surpress the variables. -- Edit this bug report at http://bugs.php.net/?id=15827&edit=1
Bug #15288 Updated: Image*-functions being avail even if they're not implemented by gd
ID: 15288
Updated by: [EMAIL PROTECTED]
-Summary: Image*-functions being avail even if they're not
implemented by gd
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: GD related
Operating System: All
PHP Version: 4.1.1
New Comment:
4.1.2 was only a security fix, and new code only goes to the HEAD
branch. I'll now add your patch to the CVS, the changes will be in PHP
4.2.0.
Derick
Previous Comments:
[2002-03-02 00:28:27] [EMAIL PROTECTED]
I worry about backward compatibility issues here. I agree that
non-implemented functions should be be defined, but the gd extension I
think was the first ever PHP extension I originally wrote years and
years ago now and it hasn't changed all that much over the years.
I guess the BC issues wouldn't be too bad since the error message was
fatal before so people couldn't really write code to check if the
function was there or not.
[2002-03-01 22:09:14] [EMAIL PROTECTED]
Did anything happen in this case? Did it just disappear into the magic
night? 4.1.2 still has the same old code in, a small CVS-change for the
TrueColor-functions .. but this (in my mind) broken approach is still
there.
Any reason why it wasnt included?
[2002-02-02 18:36:19] [EMAIL PROTECTED]
I've also created a patch that remove the functions from the
binary/module (if they're not available);
http://software.e-mats.org/patches/gd.c-diff-2002-02-02
(i also moved this to 'GD related'.)
[2002-01-30 10:41:52] [EMAIL PROTECTED]
I've made a small patch based on the CVS-version that remove functions
that are not available. I'm not sure if i caught them all, but i made a
try :-) I've not removed the original error-messages ("gd was compiled
without support.."), so they're still in there (maybe a define or
./configure-option to select what way error-reporting should be done).
the diff:
http://software.e-mats.org/patches/gd.c-diff-2002-01-30
the source:
http://software.e-mats.org/patches/gd.c-cvs-2002-01-30
[2002-01-30 08:51:11] [EMAIL PROTECTED]
I'm +1 on your patch as well, can you make it against the latest CVS
version?
I'll make sure it gets committed then.
regards,
Derick
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/15288
--
Edit this bug report at http://bugs.php.net/?id=15288&edit=1
Bug #15825 Updated: isset() raises warning for undefined class property
ID: 15825
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Variables related
Operating System: ANY
PHP Version: 4.0CVS-2002-03-0
New Comment:
I confirmed it also. It seems andrei's patch fixed this somehow.
Previous Comments:
[2002-03-02 06:04:36] [EMAIL PROTECTED]
There is nothing wrong here, it prints "PHP Notice: Uninitialized
string offset: 0 in - on line 5" for me, which it should.
Derick
[2002-03-01 22:32:40] [EMAIL PROTECTED]
Should be fixed before 4.2.0, IMO
[2002-03-01 22:32:03] [EMAIL PROTECTED]
4.0..x does not raise error, but 4.1.x does.
dd[0])){
echo "(A) TRUE \n";
}else{
echo "(A) FALSE \n";
}
if (is_array($test->dd) && isset($test->dd[0])){
echo "(B) TRUE \n";
}else{
echo "(B) FALSE \n";
}
?>
--
Edit this bug report at http://bugs.php.net/?id=15825&edit=1
Bug #15829: using nonexistingn back reference in regex crashes PHP
From: [EMAIL PROTECTED]
Operating system: Debian (Sid) Linux
PHP version: 4.0CVS-2002-03-02
PHP Bug Type: Reproducible crash
Bug description: using nonexistingn back reference in regex crashes PHP
The testscript ext/standard/tests/reg/012.phpt (" nonexisting back
reference") causes PHP to segfault:
#0 0x4017e197 in memcpy () from /lib/libc.so.6
#1 0x08133fd5 in php_reg_replace (pattern=0x82daf4c "123",
replace=0x82daf64 "def\\1ghi", string=0x82daf84 "abc123", icase=0,
extended=1) at reg.c:377
#2 0x081343ca in php_ereg_replace (ht=3, return_value=0x82daf2c,
this_ptr=0x0, return_value_used=1, icase=0) at reg.c:475
#3 0x081344b5 in zif_ereg_replace (ht=3,nonexisting back reference
return_value=0x82daf2c,
this_ptr=0x0, return_value_used=1) at reg.c:493
#4 0x08175b9e in execute (op_array=0x82dafcc) at ./zend_execute.c:1598
#5 0x080895ee in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at zend.c:810
#6 0x080946e6 in php_execute_script (primary_file=0xba48) at
main.c:1337
#7 0x08076493 in main (argc=2, argv=0xbac4) at php_cli.c:555
#8 0x4012265f in __libc_start_main () from /lib/libc.so.6
Configure line:
'./configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-mysql'
'--enable-ftp' '--enable-sockets' '--enable-calendar' '--enable-bcmath'
'--with-pcntl' '--enable-ctype' '--with-mhash' '--with-openssl'
'--enable-dbase' '--with-curl' '--enable-dbx' '--enable-dio'
'--enable-exif' '--with-pgsql' '--with-pspell' '--enable-filepro'
'--enable-gd' '--enable-gd-native-ttf' '--with-jpeg-dir=/usr'
'--with-png-dir=/usr' '--with-gettext' '--with-gmp'
'--enable-mailparse' '--enable-mbstring' '--enable-mbstr-enc-trans'
'--enable-mgrexeg' '--with-zlib' '--with-bzip2' '--with-imap'
'--enable-inline-optimization' '--with-readline'
--
Edit bug report at http://bugs.php.net/?id=15829&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15829&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15829&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15829&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15829&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15829&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15829&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15829&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15829&r=submittedtwice
Bug #15829 Updated: using nonexistingn back reference in regex crashes PHP
ID: 15829
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: Debian (Sid) Linux
-PHP Version: 4.0CVS-2002-03-02
+PHP Version: 4.0CVS-2002-03-0
New Comment:
With my configuration it passes.
Running tests in /home/yohgaki/cvs/php/DEV/ext/standard/tests/reg
=
\0 back reference
... passed
However, there is something wrong in current PHP. I got exit status 255
when run-tests.php finished. (It doesn't now)
The real problem may be in broken heap memory area by some other
place.
Previous Comments:
[2002-03-02 06:47:48] [EMAIL PROTECTED]
The testscript ext/standard/tests/reg/012.phpt (" nonexisting back
reference") causes PHP to segfault:
#0 0x4017e197 in memcpy () from /lib/libc.so.6
#1 0x08133fd5 in php_reg_replace (pattern=0x82daf4c "123",
replace=0x82daf64 "def\\1ghi", string=0x82daf84 "abc123", icase=0,
extended=1) at reg.c:377
#2 0x081343ca in php_ereg_replace (ht=3, return_value=0x82daf2c,
this_ptr=0x0, return_value_used=1, icase=0) at reg.c:475
#3 0x081344b5 in zif_ereg_replace (ht=3,nonexisting back reference
return_value=0x82daf2c,
this_ptr=0x0, return_value_used=1) at reg.c:493
#4 0x08175b9e in execute (op_array=0x82dafcc) at
./zend_execute.c:1598
#5 0x080895ee in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at zend.c:810
#6 0x080946e6 in php_execute_script (primary_file=0xba48) at
main.c:1337
#7 0x08076493 in main (argc=2, argv=0xbac4) at php_cli.c:555
#8 0x4012265f in __libc_start_main () from /lib/libc.so.6
Configure line:
'./configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-mysql'
'--enable-ftp' '--enable-sockets' '--enable-calendar'
'--enable-bcmath' '--with-pcntl' '--enable-ctype' '--with-mhash'
'--with-openssl' '--enable-dbase' '--with-curl' '--enable-dbx'
'--enable-dio' '--enable-exif' '--with-pgsql' '--with-pspell'
'--enable-filepro' '--enable-gd' '--enable-gd-native-ttf'
'--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-gettext'
'--with-gmp' '--enable-mailparse' '--enable-mbstring'
'--enable-mbstr-enc-trans' '--enable-mgrexeg' '--with-zlib'
'--with-bzip2' '--with-imap' '--enable-inline-optimization'
'--with-readline'
--
Edit this bug report at http://bugs.php.net/?id=15829&edit=1
Bug #15829 Updated: using nonexistingn back reference in regex crashes PHP
ID: 15829
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: Debian (Sid) Linux
PHP Version: 4.0CVS-2002-03-0
New Comment:
Errm...
That test passes here too:
\0 back reference
... passed
But this one doesn't:
nonexisting back reference (012.phpt)
... failed
(it crashes)
Previous Comments:
[2002-03-02 07:15:12] [EMAIL PROTECTED]
With my configuration it passes.
Running tests in /home/yohgaki/cvs/php/DEV/ext/standard/tests/reg
=
\0 back reference
... passed
However, there is something wrong in current PHP. I got exit status 255
when run-tests.php finished. (It doesn't now)
The real problem may be in broken heap memory area by some other
place.
[2002-03-02 06:47:48] [EMAIL PROTECTED]
The testscript ext/standard/tests/reg/012.phpt (" nonexisting back
reference") causes PHP to segfault:
#0 0x4017e197 in memcpy () from /lib/libc.so.6
#1 0x08133fd5 in php_reg_replace (pattern=0x82daf4c "123",
replace=0x82daf64 "def\\1ghi", string=0x82daf84 "abc123", icase=0,
extended=1) at reg.c:377
#2 0x081343ca in php_ereg_replace (ht=3, return_value=0x82daf2c,
this_ptr=0x0, return_value_used=1, icase=0) at reg.c:475
#3 0x081344b5 in zif_ereg_replace (ht=3,nonexisting back reference
return_value=0x82daf2c,
this_ptr=0x0, return_value_used=1) at reg.c:493
#4 0x08175b9e in execute (op_array=0x82dafcc) at
./zend_execute.c:1598
#5 0x080895ee in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at zend.c:810
#6 0x080946e6 in php_execute_script (primary_file=0xba48) at
main.c:1337
#7 0x08076493 in main (argc=2, argv=0xbac4) at php_cli.c:555
#8 0x4012265f in __libc_start_main () from /lib/libc.so.6
Configure line:
'./configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-mysql'
'--enable-ftp' '--enable-sockets' '--enable-calendar'
'--enable-bcmath' '--with-pcntl' '--enable-ctype' '--with-mhash'
'--with-openssl' '--enable-dbase' '--with-curl' '--enable-dbx'
'--enable-dio' '--enable-exif' '--with-pgsql' '--with-pspell'
'--enable-filepro' '--enable-gd' '--enable-gd-native-ttf'
'--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-gettext'
'--with-gmp' '--enable-mailparse' '--enable-mbstring'
'--enable-mbstr-enc-trans' '--enable-mgrexeg' '--with-zlib'
'--with-bzip2' '--with-imap' '--enable-inline-optimization'
'--with-readline'
--
Edit this bug report at http://bugs.php.net/?id=15829&edit=1
Bug #15829 Updated: using nonexistingn back reference in regex crashes PHP
ID: 15829
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: Debian (Sid) Linux
PHP Version: 4.0CVS-2002-03-0
New Comment:
Doesn't crash for me:
php -q
abcdef\1ghi
Derick
Previous Comments:
[2002-03-02 07:24:07] [EMAIL PROTECTED]
Errm...
That test passes here too:
\0 back reference
... passed
But this one doesn't:
nonexisting back reference (012.phpt)
... failed
(it crashes)
[2002-03-02 07:15:12] [EMAIL PROTECTED]
With my configuration it passes.
Running tests in /home/yohgaki/cvs/php/DEV/ext/standard/tests/reg
=
\0 back reference
... passed
However, there is something wrong in current PHP. I got exit status 255
when run-tests.php finished. (It doesn't now)
The real problem may be in broken heap memory area by some other
place.
[2002-03-02 06:47:48] [EMAIL PROTECTED]
The testscript ext/standard/tests/reg/012.phpt (" nonexisting back
reference") causes PHP to segfault:
#0 0x4017e197 in memcpy () from /lib/libc.so.6
#1 0x08133fd5 in php_reg_replace (pattern=0x82daf4c "123",
replace=0x82daf64 "def\\1ghi", string=0x82daf84 "abc123", icase=0,
extended=1) at reg.c:377
#2 0x081343ca in php_ereg_replace (ht=3, return_value=0x82daf2c,
this_ptr=0x0, return_value_used=1, icase=0) at reg.c:475
#3 0x081344b5 in zif_ereg_replace (ht=3,nonexisting back reference
return_value=0x82daf2c,
this_ptr=0x0, return_value_used=1) at reg.c:493
#4 0x08175b9e in execute (op_array=0x82dafcc) at
./zend_execute.c:1598
#5 0x080895ee in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at zend.c:810
#6 0x080946e6 in php_execute_script (primary_file=0xba48) at
main.c:1337
#7 0x08076493 in main (argc=2, argv=0xbac4) at php_cli.c:555
#8 0x4012265f in __libc_start_main () from /lib/libc.so.6
Configure line:
'./configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-mysql'
'--enable-ftp' '--enable-sockets' '--enable-calendar'
'--enable-bcmath' '--with-pcntl' '--enable-ctype' '--with-mhash'
'--with-openssl' '--enable-dbase' '--with-curl' '--enable-dbx'
'--enable-dio' '--enable-exif' '--with-pgsql' '--with-pspell'
'--enable-filepro' '--enable-gd' '--enable-gd-native-ttf'
'--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-gettext'
'--with-gmp' '--enable-mailparse' '--enable-mbstring'
'--enable-mbstr-enc-trans' '--enable-mgrexeg' '--with-zlib'
'--with-bzip2' '--with-imap' '--enable-inline-optimization'
'--with-readline'
--
Edit this bug report at http://bugs.php.net/?id=15829&edit=1
Bug #15288 Updated: Image*-functions being avail even if they're not implemented by gd
ID: 15288
Updated by: [EMAIL PROTECTED]
-Summary: Image*-functions being avail even if they're not
implemented by gd
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: GD related
Operating System: All
PHP Version: 4.1.1
New Comment:
Applied to CVS. Thx!
Derick
Previous Comments:
[2002-03-02 06:20:33] [EMAIL PROTECTED]
4.1.2 was only a security fix, and new code only goes to the HEAD
branch. I'll now add your patch to the CVS, the changes will be in PHP
4.2.0.
Derick
[2002-03-02 00:28:27] [EMAIL PROTECTED]
I worry about backward compatibility issues here. I agree that
non-implemented functions should be be defined, but the gd extension I
think was the first ever PHP extension I originally wrote years and
years ago now and it hasn't changed all that much over the years.
I guess the BC issues wouldn't be too bad since the error message was
fatal before so people couldn't really write code to check if the
function was there or not.
[2002-03-01 22:09:14] [EMAIL PROTECTED]
Did anything happen in this case? Did it just disappear into the magic
night? 4.1.2 still has the same old code in, a small CVS-change for the
TrueColor-functions .. but this (in my mind) broken approach is still
there.
Any reason why it wasnt included?
[2002-02-02 18:36:19] [EMAIL PROTECTED]
I've also created a patch that remove the functions from the
binary/module (if they're not available);
http://software.e-mats.org/patches/gd.c-diff-2002-02-02
(i also moved this to 'GD related'.)
[2002-01-30 10:41:52] [EMAIL PROTECTED]
I've made a small patch based on the CVS-version that remove functions
that are not available. I'm not sure if i caught them all, but i made a
try :-) I've not removed the original error-messages ("gd was compiled
without support.."), so they're still in there (maybe a define or
./configure-option to select what way error-reporting should be done).
the diff:
http://software.e-mats.org/patches/gd.c-diff-2002-01-30
the source:
http://software.e-mats.org/patches/gd.c-cvs-2002-01-30
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/15288
--
Edit this bug report at http://bugs.php.net/?id=15288&edit=1
Bug #15829 Updated: using nonexistingn back reference in regex crashes PHP
ID: 15829
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: Debian (Sid) Linux
PHP Version: 4.0CVS-2002-03-0
New Comment:
It crashes with a plain ./configure too btw...
Previous Comments:
[2002-03-02 07:25:30] [EMAIL PROTECTED]
Doesn't crash for me:
php -q
abcdef\1ghi
Derick
[2002-03-02 07:24:07] [EMAIL PROTECTED]
Errm...
That test passes here too:
\0 back reference
... passed
But this one doesn't:
nonexisting back reference (012.phpt)
... failed
(it crashes)
[2002-03-02 07:15:12] [EMAIL PROTECTED]
With my configuration it passes.
Running tests in /home/yohgaki/cvs/php/DEV/ext/standard/tests/reg
=
\0 back reference
... passed
However, there is something wrong in current PHP. I got exit status 255
when run-tests.php finished. (It doesn't now)
The real problem may be in broken heap memory area by some other
place.
[2002-03-02 06:47:48] [EMAIL PROTECTED]
The testscript ext/standard/tests/reg/012.phpt (" nonexisting back
reference") causes PHP to segfault:
#0 0x4017e197 in memcpy () from /lib/libc.so.6
#1 0x08133fd5 in php_reg_replace (pattern=0x82daf4c "123",
replace=0x82daf64 "def\\1ghi", string=0x82daf84 "abc123", icase=0,
extended=1) at reg.c:377
#2 0x081343ca in php_ereg_replace (ht=3, return_value=0x82daf2c,
this_ptr=0x0, return_value_used=1, icase=0) at reg.c:475
#3 0x081344b5 in zif_ereg_replace (ht=3,nonexisting back reference
return_value=0x82daf2c,
this_ptr=0x0, return_value_used=1) at reg.c:493
#4 0x08175b9e in execute (op_array=0x82dafcc) at
./zend_execute.c:1598
#5 0x080895ee in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at zend.c:810
#6 0x080946e6 in php_execute_script (primary_file=0xba48) at
main.c:1337
#7 0x08076493 in main (argc=2, argv=0xbac4) at php_cli.c:555
#8 0x4012265f in __libc_start_main () from /lib/libc.so.6
Configure line:
'./configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-mysql'
'--enable-ftp' '--enable-sockets' '--enable-calendar'
'--enable-bcmath' '--with-pcntl' '--enable-ctype' '--with-mhash'
'--with-openssl' '--enable-dbase' '--with-curl' '--enable-dbx'
'--enable-dio' '--enable-exif' '--with-pgsql' '--with-pspell'
'--enable-filepro' '--enable-gd' '--enable-gd-native-ttf'
'--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-gettext'
'--with-gmp' '--enable-mailparse' '--enable-mbstring'
'--enable-mbstr-enc-trans' '--enable-mgrexeg' '--with-zlib'
'--with-bzip2' '--with-imap' '--enable-inline-optimization'
'--with-readline'
--
Edit this bug report at http://bugs.php.net/?id=15829&edit=1
Bug #15688 Updated: undefined symbol:stat
ID: 15688 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Informix related Operating System: SuSe Linux 7.3 PHP Version: 4.1.1 New Comment: The problem is CSDK 2.70. Try getting the older version 2.60. Unfortunately it is no more available on the website "www.informix.com/evaluate". There has somethings changed between the two versions which produces this error. There was a discussion about this in comp.databases.informix about the end of the year 2001. Take a look at: http://dbforums.com/archive/40/2001/12/1/218803 Previous Comments: [2002-02-23 09:36:00] [EMAIL PROTECTED] i can configure PHP4 with Informix as dynamic module without getting errors. But when i try to start th Apache server i get the error message Cannot load /usr/lib/apache/libphp4.so into server: opt/informix/lib/esql/libifgen.so: undefined symbol /usr/sbin/apachectl start: httpd could not be started configure: ./configure --with-config-file-path=/etc --with-apxs --with-informix Linux version: Suse 7.3 Informix cdsk version: 9.51UC1 Make: version 3.79.1 gcc version: 2.95.3 flexversion: 2.5.4 bison version: 1.28 httpd version: 1.3.20 I trying since several days to get it running, i have serched a lot of sites for a solutiion, and tried out several changes in generating and setting Variables but it's always the same. Can the problem solved by PHP or is it a problem of the Informix cdsk? Thanks for any help. Winfried -- Edit this bug report at http://bugs.php.net/?id=15688&edit=1
Bug #15830: configure recognize lib mcrypt 2.4 as 2.2
From: [EMAIL PROTECTED] Operating system: RedHat Linux 7.2 PHP version: 4.1.2 PHP Bug Type: mcrypt related Bug description: configure recognize lib mcrypt 2.4 as 2.2 configure in php 4.1.2 will recognize libmcrypt 2.4.x (tested with libmcrypt 2.4.15/16 and 22) as libmcrypt 2.2.x. This will cause compile to fail due to some missing #define php 4.1.1 perfectly works instead (tested with the same libmcrypt versions). -- Edit bug report at http://bugs.php.net/?id=15830&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15830&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15830&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15830&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15830&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15830&r=support Expected behavior: http://bugs.php.net/fix.php?id=15830&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15830&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15830&r=submittedtwice
Bug #15830 Updated: configure recognize lib mcrypt 2.4 as 2.2
ID: 15830 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: mcrypt related Operating System: RedHat Linux 7.2 PHP Version: 4.1.2 New Comment: That is really weird, because mcrypt didn't change one single bit. Can you send me your configure.log (or config.log) (privately please)? Derick Previous Comments: [2002-03-02 10:34:56] [EMAIL PROTECTED] configure in php 4.1.2 will recognize libmcrypt 2.4.x (tested with libmcrypt 2.4.15/16 and 22) as libmcrypt 2.2.x. This will cause compile to fail due to some missing #define php 4.1.1 perfectly works instead (tested with the same libmcrypt versions). -- Edit this bug report at http://bugs.php.net/?id=15830&edit=1
Bug #15831: function ftp_nlist() returns anything
From: [EMAIL PROTECTED] Operating system: Windows 2000 Server PHP version: 4.1.1 PHP Bug Type: IIS related Bug description: function ftp_nlist() returns anything When i am using the ftp_nlist() or ftp_rawlist() functions returns anything i can already tryed with pasv mode and the result is the same, i have tryed with a lot of examples sources and nothing, so i can not do my project in PHP. -- Edit bug report at http://bugs.php.net/?id=15831&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15831&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15831&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15831&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15831&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15831&r=support Expected behavior: http://bugs.php.net/fix.php?id=15831&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15831&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15831&r=submittedtwice
Bug #13094 Updated: Upload very slow
ID: 13094 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Performance problem Operating System: Windows 2000 PHP Version: 4.0.6 Assigned To: sniper New Comment: Has this problem been solved in the update for 4.1.2? Previous Comments: [2001-10-28 12:34:17] [EMAIL PROTECTED] This should be fixed in CVS now. You can try the latest development build from http://www.php4win.com/ but make sure it's dated after 27th of October 2001. Also, there are some minor leaks still in the new code. If you encounter such leaks, please send the shortest possible code + html with which you can reproduce the leak to [EMAIL PROTECTED] (or me) so we can get rid of these leaks. The fix will be in PHP 4.2.0. --Jani [2001-10-28 12:10:12] [EMAIL PROTECTED] Fixed in CVS by Jani, will be fixed in 4.2.0 [2001-09-02 16:52:23] [EMAIL PROTECTED] Work in progress... [2001-09-02 11:57:36] [EMAIL PROTECTED] This has nothing to do with 2291. The problem probably is that PHP takes all HTTP-post data into it's memory, and only after the complete header (WITH all files) are in-memory, php_mime_split is called to get the files out of the request and save them to disk. So if you need to recieve file-uploads of 100MB or something, PHP needs 100MB of RAM... otherwise it will swap and thus be terribly slow (especially on Windows) A real solution would be to rewrite php_mime_split to run on-the-fly... which at first glance isn't terribly hard. [2001-09-02 11:17:11] [EMAIL PROTECTED] Seems duplicate of 2291, but that one should be fixed in 4.0.6 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/13094 -- Edit this bug report at http://bugs.php.net/?id=13094&edit=1
Bug #13094 Updated: Upload very slow
ID: 13094 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Performance problem Operating System: Windows 2000 PHP Version: 4.0.6 Assigned To: sniper New Comment: No, only for 4.2.x Derick Previous Comments: [2002-03-02 10:47:11] [EMAIL PROTECTED] Has this problem been solved in the update for 4.1.2? [2001-10-28 12:34:17] [EMAIL PROTECTED] This should be fixed in CVS now. You can try the latest development build from http://www.php4win.com/ but make sure it's dated after 27th of October 2001. Also, there are some minor leaks still in the new code. If you encounter such leaks, please send the shortest possible code + html with which you can reproduce the leak to [EMAIL PROTECTED] (or me) so we can get rid of these leaks. The fix will be in PHP 4.2.0. --Jani [2001-10-28 12:10:12] [EMAIL PROTECTED] Fixed in CVS by Jani, will be fixed in 4.2.0 [2001-09-02 16:52:23] [EMAIL PROTECTED] Work in progress... [2001-09-02 11:57:36] [EMAIL PROTECTED] This has nothing to do with 2291. The problem probably is that PHP takes all HTTP-post data into it's memory, and only after the complete header (WITH all files) are in-memory, php_mime_split is called to get the files out of the request and save them to disk. So if you need to recieve file-uploads of 100MB or something, PHP needs 100MB of RAM... otherwise it will swap and thus be terribly slow (especially on Windows) A real solution would be to rewrite php_mime_split to run on-the-fly... which at first glance isn't terribly hard. 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/13094 -- Edit this bug report at http://bugs.php.net/?id=13094&edit=1
Bug #15832: error when using the copy function
From: [EMAIL PROTECTED] Operating system: Windows PHP version: 4.1.1 PHP Bug Type: Unknown/Other Function Bug description: error when using the copy function When I use the "copy ( string source, string dest)" function in PHP 4.1.1 and Apache 2.0.28 for uploading files to a dir and forget to set the "string dest" the file will bo copied to the root dir of my harddrive. I have set the php.ini to have this lines. doc_root = "C:\Program Files\Apache Group\Apache2\htdocs" user_dir = "C:\Program Files\Apache Group\Apache2\htdocs" -- Edit bug report at http://bugs.php.net/?id=15832&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15832&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15832&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15832&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15832&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15832&r=support Expected behavior: http://bugs.php.net/fix.php?id=15832&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15832&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15832&r=submittedtwice
Bug #15833: PHP 4.1.x results in huge memory usage during runtime under Solaris 8
From: [EMAIL PROTECTED] Operating system: Solaris 8 PHP version: 4.1.2 PHP Bug Type: Performance problem Bug description: PHP 4.1.x results in huge memory usage during runtime under Solaris 8 Compiling PHP 4.1.1 (patched) or PHP 4.1.2 under Solaris 8 on a Sun NetraX1 as external CGI results in a huge memory usage, even if only the phpinfo function wa called. The executable used around 73 MB memory. Compiling it the same way under Solaris 2.6/7 works perfectly ... Compiling it under Linux the same way works perfectly too. Here the configure line: ./configure --prefix=/usr/local/php-4.1.2 --enable-force-cgi-redirect --with-gdb m --with-gd=/usr/local/gd-2.0.1 --with-mysql=/usr/local/mysql-3.23.37 --with-ttf =/usr/local/freetype-2.0.6 --enable-gd-native-ttf --with-jpeg-dir=/usr/local/con verter --with-xpm-dir --with-freetype-dir=/usr/local/freetype-2.0.6 --with-png-d ir=/usr/local/libpng-1.2.1 --with-gettext=/usr/local/gnu --with-zlib-dir=/lib -- enable-ftp --enable-shared --with-dom=/usr/local/libxml2-2.4.9 --enable-trans-si d --with-config-file-path=/usr/local/php-4.1.2 --with-tiff-dir=/usr/local/tiff-v 3.5.6-beta --with-pdflib=/usr/local/pdflib-4.0.1 --with-imap=/usr/local --with-m crypt=/usr/local/libmcrypt-2.4.10 --with-expat-dir=/usr/local/expat-1.95.2 --wit h-sablot=/usr/local/Sablot-0.65 --with-openssl=/usr/local/openssl-0.9.6a --with- bz2 --with-t1lib=/usr/local/T1-1.1.1 --with-mm --with-zip=/usr/local/zziplib-0.1 0.27 --enable-inline-optimization --enable-sysvsem --enable-sysvshm --with-ndbm Kind regards, Frank PowerWeb -- Edit bug report at http://bugs.php.net/?id=15833&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15833&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15833&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15833&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15833&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15833&r=support Expected behavior: http://bugs.php.net/fix.php?id=15833&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15833&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15833&r=submittedtwice
Bug #15834: segmentation fault starting apache with pfpro
From: [EMAIL PROTECTED] Operating system: linux RH7.1 PHP version: 4.1.2 PHP Bug Type: Reproducible crash Bug description: segmentation fault starting apache with pfpro I get a segmentation fault when start apache when php4.1.2 is compiled with verisign payflowpro. If a recompile with this option everything is OK. I have encountered this problem with all previous versions also. -- Edit bug report at http://bugs.php.net/?id=15834&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15834&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15834&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15834&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15834&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15834&r=support Expected behavior: http://bugs.php.net/fix.php?id=15834&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15834&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15834&r=submittedtwice
Bug #15834 Updated: segmentation fault starting apache with pfpro
ID: 15834 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: linux RH7.1 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-02 11:18:41] [EMAIL PROTECTED] I get a segmentation fault when start apache when php4.1.2 is compiled with verisign payflowpro. If a recompile with this option everything is OK. I have encountered this problem with all previous versions also. -- Edit this bug report at http://bugs.php.net/?id=15834&edit=1
Bug #15834 Updated: segmentation fault starting apache with pfpro
ID: 15834 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: linux RH7.1 PHP Version: 4.1.2 New Comment: Not sure how this could be generated since apache will not start. Follwing is the message that I received when trying to start apache. line 184: 3736 Segmentation fault $HTTPD /usr/local/apache/bin/apachectl start: httpd could not be started Previous Comments: [2002-03-02 11:19:15] [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-03-02 11:18:41] [EMAIL PROTECTED] I get a segmentation fault when start apache when php4.1.2 is compiled with verisign payflowpro. If a recompile with this option everything is OK. I have encountered this problem with all previous versions also. -- Edit this bug report at http://bugs.php.net/?id=15834&edit=1
Bug #15834 Updated: segmentation fault starting apache with pfpro
ID: 15834 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: linux RH7.1 PHP Version: 4.1.2 New Comment: gdb /path/to/httpd and enter on the prompt: run -X Previous Comments: [2002-03-02 11:25:26] [EMAIL PROTECTED] Not sure how this could be generated since apache will not start. Follwing is the message that I received when trying to start apache. line 184: 3736 Segmentation fault $HTTPD /usr/local/apache/bin/apachectl start: httpd could not be started [2002-03-02 11:19:15] [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-03-02 11:18:41] [EMAIL PROTECTED] I get a segmentation fault when start apache when php4.1.2 is compiled with verisign payflowpro. If a recompile with this option everything is OK. I have encountered this problem with all previous versions also. -- Edit this bug report at http://bugs.php.net/?id=15834&edit=1
Bug #15834 Updated: segmentation fault starting apache with pfpro
ID: 15834 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: linux RH7.1 PHP Version: 4.1.2 New Comment: Following is the message. Thanks. Program received signal SIGSEGV, Segmentation fault. 0x400d528c in __umoddi3 () from /usr/local/verisign/payflowpro/linux/lib/libpfpro.so Previous Comments: [2002-03-02 11:27:02] [EMAIL PROTECTED] gdb /path/to/httpd and enter on the prompt: run -X [2002-03-02 11:25:26] [EMAIL PROTECTED] Not sure how this could be generated since apache will not start. Follwing is the message that I received when trying to start apache. line 184: 3736 Segmentation fault $HTTPD /usr/local/apache/bin/apachectl start: httpd could not be started [2002-03-02 11:19:15] [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-03-02 11:18:41] [EMAIL PROTECTED] I get a segmentation fault when start apache when php4.1.2 is compiled with verisign payflowpro. If a recompile with this option everything is OK. I have encountered this problem with all previous versions also. -- Edit this bug report at http://bugs.php.net/?id=15834&edit=1
Bug #15834 Updated: segmentation fault starting apache with pfpro
ID: 15834 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: linux RH7.1 PHP Version: 4.1.2 New Comment: Oops :) Can you hit 'bt full' on the prompt after the crash and post the results again? regards, derick Previous Comments: [2002-03-02 11:36:56] [EMAIL PROTECTED] Following is the message. Thanks. Program received signal SIGSEGV, Segmentation fault. 0x400d528c in __umoddi3 () from /usr/local/verisign/payflowpro/linux/lib/libpfpro.so [2002-03-02 11:27:02] [EMAIL PROTECTED] gdb /path/to/httpd and enter on the prompt: run -X [2002-03-02 11:25:26] [EMAIL PROTECTED] Not sure how this could be generated since apache will not start. Follwing is the message that I received when trying to start apache. line 184: 3736 Segmentation fault $HTTPD /usr/local/apache/bin/apachectl start: httpd could not be started [2002-03-02 11:19:15] [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-03-02 11:18:41] [EMAIL PROTECTED] I get a segmentation fault when start apache when php4.1.2 is compiled with verisign payflowpro. If a recompile with this option everything is OK. I have encountered this problem with all previous versions also. -- Edit this bug report at http://bugs.php.net/?id=15834&edit=1
Bug #15834 Updated: segmentation fault starting apache with pfpro
ID: 15834 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: linux RH7.1 PHP Version: 4.1.2 New Comment: Here it is. #0 0x400d528c in __umoddi3 () from /usr/local/verisign/payflowpro/linux/lib/libpfpro.so No symbol table info available. #1 0x400b7678 in PNVersion () from /usr/local/verisign/payflowpro/linux/lib/libpfpro.so No symbol table info available. Cannot access memory at address 0x3 Previous Comments: [2002-03-02 11:38:26] [EMAIL PROTECTED] Oops :) Can you hit 'bt full' on the prompt after the crash and post the results again? regards, derick [2002-03-02 11:36:56] [EMAIL PROTECTED] Following is the message. Thanks. Program received signal SIGSEGV, Segmentation fault. 0x400d528c in __umoddi3 () from /usr/local/verisign/payflowpro/linux/lib/libpfpro.so [2002-03-02 11:27:02] [EMAIL PROTECTED] gdb /path/to/httpd and enter on the prompt: run -X [2002-03-02 11:25:26] [EMAIL PROTECTED] Not sure how this could be generated since apache will not start. Follwing is the message that I received when trying to start apache. line 184: 3736 Segmentation fault $HTTPD /usr/local/apache/bin/apachectl start: httpd could not be started [2002-03-02 11:19:15] [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". 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/15834 -- Edit this bug report at http://bugs.php.net/?id=15834&edit=1
Bug #15835: Problem on function gmp_invert ()
From: [EMAIL PROTECTED] Operating system: Linux - Red Hat 7.2 PHP version: 4.1.2 PHP Bug Type: *Math Functions Bug description: Problem on function gmp_invert () The function resource gmp_invert() doesn't work right. It always return zero. I implemented the extended Euclides algoritm that do exactly the same that this function and, it returned me the right value. -- Edit bug report at http://bugs.php.net/?id=15835&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15835&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15835&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15835&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15835&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15835&r=support Expected behavior: http://bugs.php.net/fix.php?id=15835&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15835&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15835&r=submittedtwice
Bug #14731 Updated: read_exif_data crash reading specific images
ID: 14731 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: *Graphics related Operating System: FreeBSD 4.4 PHP Version: 4.1.0 -Assigned To: +Assigned To: helly New Comment: This bug has been fixed in CVS. Original version was not really standard complient... Hope i fixed all. But i implemented a test mechanism and it works with all files from exif.org now. Previous Comments: [2002-02-21 04:41:23] [EMAIL PROTECTED] ... camera is Pentax Optio 330 [2002-02-21 04:40:33] [EMAIL PROTECTED] I get the same problem reported here. It doesn't break on all my images. Just certain ones (all taken with the same camera.) Apache logs: FATAL: emalloc(): Unable to allocate -2147483648 bytes System Info: Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_ssl/2.8.5 OpenSSL/0.9.6b DAV/1.0.2 PHP/4.1.1 mod_perl/1.24_01 [2002-02-11 23:01:37] [EMAIL PROTECTED] I had it working ok when reading one file from a DC4800. Tried to open 10 in a row and I got the following error in the apache log file for each file: FATAL: emalloc(): Unable to allocate -2147483648 bytes FreeBSD 4.5, PHP 4.1.1 [2002-01-11 17:43:35] [EMAIL PROTECTED] I've been strugling with this issue for some time, also on FreeBSD 4.4-stable. The bug still exists in CVS as of today. I can also conform that removing TAG_JPEGQUAL and TAG_MACRO fixes the problem. [2001-12-28 07:26:12] [EMAIL PROTECTED] When calling read_exif_data with a picture taken with a Kodak DC240 it causes PHP to crash. (This error is probably related to bug #14026) It seems to be caused to the (mis-)reading of the thumbnail-info from the exif-tag. After changing the ext/exif.c and removing the cases TAG_JPEGQUAL and TAG_MACRO at line 760-779, the read_exif_data runs without any problems - But then (of course) it only read the data about the picture and not the thumbnail. To reproduce call read_exif_data with any photo taken with a Kodak DC240 Examplephoto http://thoestesen.dk/DCP_4030.JPG -- Edit this bug report at http://bugs.php.net/?id=14731&edit=1
Bug #14026 Updated: Apache Crash
ID: 14026 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: *Graphics related Operating System: Linux 2.4.5 PHP Version: 4.1.1 -Assigned To: +Assigned To: helly New Comment: This bug has been fixed in CVS. This bug has been fixed in CVS. Original version was not really standard complient... Hope i fixed all. But i implemented a test mechanism and it works with all files from exif.org now. Previous Comments: [2002-02-22 13:02:13] [EMAIL PROTECTED] Could you send me an image that has this problem? Or point me at a URL where I can grab one? It should be a simple fix if I can reproduce it locally here. [2002-02-20 21:03:29] [EMAIL PROTECTED] I have a Minolta DiMage7 DC I am getting intermittent problems with FATAL: emalloc(): Unable to allocate -2147483648 bytes read_exif_data will work with most pictures, but sometimes will produce the error. [2001-11-12 05:42:16] [EMAIL PROTECTED] Thx much prompt reply. Tried PHP Version 4.2.0-dev at http://www.aimaker.com/info.php Still got the same error with ricoh.jpg but ok with canon jpg. [2001-11-12 04:59:29] [EMAIL PROTECTED] You might want to try a snapshot from snaps.php.net. AFAIK, this should be fixed. Derick [2001-11-12 04:55:20] [EMAIL PROTECTED] :) php-read_exif-data can read exif from Canon DC jpg file :( php-read_exif-data cannot read exif from Ricoh DC jpg file A server error got is - FATAL: emalloc(): Unable to allocate -2147483648 bytes A example of Ricoh DC jpg at http://www.aimaker.com/ricoh.jpg -- Edit this bug report at http://bugs.php.net/?id=14026&edit=1
Bug #14994 Updated: Adding TIFF support to GetImageSize
ID: 14994 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed Bug Type:Feature/Change Request PHP Version: 4.1.1 New Comment: Next version of read_exif_data will provide the information needed. So i think we can add a constant for TIFF and add support... Previous Comments: [2002-01-11 06:07:43] [EMAIL PROTECTED] I know, that Rasmus made the implementation for this function and that he used the header readouts from an imageinfo.c, but I'm missing the ability to identify TIFF images. As i'm not firm with imageheaders, I'd like to ask someone to implement this feature. -- Edit this bug report at http://bugs.php.net/?id=14994&edit=1
Bug #15828 Updated: Trim() leaving 1 begining/ending whitespace
ID: 15828 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Output Control Operating System: WindowsXP Pro PHP Version: 4.1.1 New Comment: This is using php4isapi.dll $var = ' content '; $var = trim($var); // fixed TYPO.. echo "->".$var."<-"; echo "->$var<-"; Output: -> content <- -> content <- leaves 1 whitespace at the beginning and at the end. and I have RTFM!!! Previous Comments: [2002-03-02 05:27:59] [EMAIL PROTECTED] RTFM! trim() returns the trimmed string. $foo = trim($foo) and not trim($foo) [2002-03-02 03:09:45] [EMAIL PROTECTED] This is using php4isapi.dll $var = ' content '; trim($var); echo "->".$var."<-"; echo "->$var<-"; Output: -> content <- -> content <- leaves 1 whitespace at the beginning and at the end. -- Edit this bug report at http://bugs.php.net/?id=15828&edit=1
Bug #15835 Updated: Problem on function gmp_invert ()
ID: 15835 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Math Functions Operating System: Linux - Red Hat 7.2 PHP Version: 4.1.2 New Comment: Please provide a short reproducing script with values that you are using and expected output. Sean Previous Comments: [2002-03-02 11:44:47] [EMAIL PROTECTED] The function resource gmp_invert() doesn't work right. It always return zero. I implemented the extended Euclides algoritm that do exactly the same that this function and, it returned me the right value. -- Edit this bug report at http://bugs.php.net/?id=15835&edit=1
Bug #15835 Updated: Problem on function gmp_invert ()
ID: 15835 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *Math Functions Operating System: Linux - Red Hat 7.2 PHP Version: 4.1.2 Previous Comments: [2002-03-02 13:29:43] [EMAIL PROTECTED] Please provide a short reproducing script with values that you are using and expected output. Sean [2002-03-02 11:44:47] [EMAIL PROTECTED] The function resource gmp_invert() doesn't work right. It always return zero. I implemented the extended Euclides algoritm that do exactly the same that this function and, it returned me the right value. -- Edit this bug report at http://bugs.php.net/?id=15835&edit=1
Bug #15828 Updated: Trim() leaving 1 begining/ending whitespace
ID: 15828 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Output Control Operating System: WindowsXP Pro PHP Version: 4.1.1 New Comment: Not sure what it was, but I restarted IIS 5.1 and now it works. Previous Comments: [2002-03-02 12:52:51] [EMAIL PROTECTED] This is using php4isapi.dll $var = ' content '; $var = trim($var); // fixed TYPO.. echo "->".$var."<-"; echo "->$var<-"; Output: -> content <- -> content <- leaves 1 whitespace at the beginning and at the end. and I have RTFM!!! [2002-03-02 05:27:59] [EMAIL PROTECTED] RTFM! trim() returns the trimmed string. $foo = trim($foo) and not trim($foo) [2002-03-02 03:09:45] [EMAIL PROTECTED] This is using php4isapi.dll $var = ' content '; trim($var); echo "->".$var."<-"; echo "->$var<-"; Output: -> content <- -> content <- leaves 1 whitespace at the beginning and at the end. -- Edit this bug report at http://bugs.php.net/?id=15828&edit=1
Bug #15836: Bug #11162 pfsockopen closes connection after script finishes !
From: [EMAIL PROTECTED] Operating system: FreeBSD PHP version: 4.1.1 PHP Bug Type: Sockets related Bug description: Bug #11162 pfsockopen closes connection after script finishes ! The problem still exists! Connection, opened by pfsockopen(), is closing when the script is finishes. (tested by just simple netcat -l and by multithreaded java chat server) PHP Version 4.1.1 Apache/1.3.20 FreeBSD 4.5-STABLE -- Edit bug report at http://bugs.php.net/?id=15836&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15836&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15836&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15836&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15836&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15836&r=support Expected behavior: http://bugs.php.net/fix.php?id=15836&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15836&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15836&r=submittedtwice
Bug #11162 Updated: pfsockopen closes connection after script finishes
ID: 11162 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: Sockets related Operating System: FreeBSD PHP Version: 4.0.4 New Comment: OK. Reopening. Previous Comments: [2002-02-14 12:15:22] [EMAIL PROTECTED] The problem still exists! Connection, opened by pfsockopen(), is closing when the script is finishes. (tested by just simple netcat -l and by multithreaded java chat server) PHP Version 4.1.1 Apache/1.3.20 FreeBSD 4.5-STABLE [2001-12-13 06:25:08] [EMAIL PROTECTED] No feedback. Closing. [2001-11-21 12:03:03] [EMAIL PROTECTED] Can try with latest RC and see if the problem still exists http://www.php.net/~zeev/php-4.1.0RC3.tar.gz Feedback. [2001-05-29 01:18:39] [EMAIL PROTECTED] When using pfsockopen() it closes the connection as soon as the script finishes. According to the manual, the connection should remain open. I have had a few people write their own script to test this on their machine to make sure it wasn't my machine, or my code, and both of them also produced the same result. So I beleive this is either a bug with pfsockopen() or with the online documents. -- Edit this bug report at http://bugs.php.net/?id=11162&edit=1
Bug #11162 Updated: pfsockopen closes connection after script finishes
ID: 11162 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Duplicate Bug Type: Sockets related Operating System: FreeBSD PHP Version: 4.0.4 New Comment: Making this duplicate of #15836 which I just marked a doc problem. Derick Previous Comments: [2002-03-02 13:48:08] [EMAIL PROTECTED] OK. Reopening. [2002-02-14 12:15:22] [EMAIL PROTECTED] The problem still exists! Connection, opened by pfsockopen(), is closing when the script is finishes. (tested by just simple netcat -l and by multithreaded java chat server) PHP Version 4.1.1 Apache/1.3.20 FreeBSD 4.5-STABLE [2001-12-13 06:25:08] [EMAIL PROTECTED] No feedback. Closing. [2001-11-21 12:03:03] [EMAIL PROTECTED] Can try with latest RC and see if the problem still exists http://www.php.net/~zeev/php-4.1.0RC3.tar.gz Feedback. [2001-05-29 01:18:39] [EMAIL PROTECTED] When using pfsockopen() it closes the connection as soon as the script finishes. According to the manual, the connection should remain open. I have had a few people write their own script to test this on their machine to make sure it wasn't my machine, or my code, and both of them also produced the same result. So I beleive this is either a bug with pfsockopen() or with the online documents. -- Edit this bug report at http://bugs.php.net/?id=11162&edit=1
Bug #11162 Updated: pfsockopen closes connection after script finishes
ID: 11162 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Duplicate Bug Type: Sockets related Operating System: FreeBSD PHP Version: 4.0.4 New Comment: Do NOT open a new report for the same bug. I'm closing this one, see #15836 for more... Previous Comments: [2002-03-02 13:49:40] [EMAIL PROTECTED] Making this duplicate of #15836 which I just marked a doc problem. Derick [2002-03-02 13:48:08] [EMAIL PROTECTED] OK. Reopening. [2002-02-14 12:15:22] [EMAIL PROTECTED] The problem still exists! Connection, opened by pfsockopen(), is closing when the script is finishes. (tested by just simple netcat -l and by multithreaded java chat server) PHP Version 4.1.1 Apache/1.3.20 FreeBSD 4.5-STABLE [2001-12-13 06:25:08] [EMAIL PROTECTED] No feedback. Closing. [2001-11-21 12:03:03] [EMAIL PROTECTED] Can try with latest RC and see if the problem still exists http://www.php.net/~zeev/php-4.1.0RC3.tar.gz Feedback. 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/11162 -- Edit this bug report at http://bugs.php.net/?id=11162&edit=1
Bug #15832 Updated: error when using the copy function
ID: 15832
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Unknown/Other Function
Operating System: Windows
PHP Version: 4.1.1
New Comment:
What do you mean, forget the dest? If you call copy("file"); it will
complain.
Previous Comments:
[2002-03-02 10:53:57] [EMAIL PROTECTED]
When I use the "copy ( string source, string dest)" function in PHP
4.1.1 and Apache 2.0.28 for uploading files to a dir and forget to set
the "string dest" the file will bo copied to the root dir of my
harddrive. I have set the php.ini to have this lines.
doc_root = "C:\Program Files\Apache Group\Apache2\htdocs"
user_dir = "C:\Program Files\Apache Group\Apache2\htdocs"
--
Edit this bug report at http://bugs.php.net/?id=15832&edit=1
Bug #15831 Updated: function ftp_nlist() returns anything
ID: 15831 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: IIS related Operating System: Windows 2000 Server 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-02 10:38:30] [EMAIL PROTECTED] When i am using the ftp_nlist() or ftp_rawlist() functions returns anything i can already tryed with pasv mode and the result is the same, i have tryed with a lot of examples sources and nothing, so i can not do my project in PHP. -- Edit this bug report at http://bugs.php.net/?id=15831&edit=1
Bug #15836 Updated: Bug #11162 pfsockopen closes connection after script finishes !
ID: 15836 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Sockets related +Bug Type: Documentation problem Operating System: FreeBSD PHP Version: 4.1.1 New Comment: [EMAIL PROTECTED] 29-Jan-2001 03:26 OK, WRT to the p* functions opening a new connection when one already exists. It is my understanting that (under Apache anyways) this is on a per-process basis. If you do a 'ps auxw|grep httpd' on your server you will see more than one process. What p* does is make a p-connection on one of those processes only, the one that actually handles your request. Chances are that when you hit the page again it will be answered by a different process. I'm guessing if you keep hitting reload you'll get around to the original process again and there will be no error message or second connection open. Anyhow, this is true of all p* functions; they open not one connection per server, but one connection per server _process_. Hope this explains something (it's from the manual at http://www.php.net/manual/en/function.pfsockopen.php) I'm keeping this open as a doc problem though, cause the documentation is very skimmy. Derick Previous Comments: [2002-03-02 13:39:56] [EMAIL PROTECTED] The problem still exists! Connection, opened by pfsockopen(), is closing when the script is finishes. (tested by just simple netcat -l and by multithreaded java chat server) PHP Version 4.1.1 Apache/1.3.20 FreeBSD 4.5-STABLE -- Edit this bug report at http://bugs.php.net/?id=15836&edit=1
Bug #15837: gpm_powm()
From: [EMAIL PROTECTED] Operating system: Linux - Red Hat 7.2 PHP version: 4.1.2 PHP Bug Type: *Math Functions Bug description: gpm_powm() The gpm function gpm_powm() doesn't work right. If you try to use it, it doesn't return the value. -- Edit bug report at http://bugs.php.net/?id=15837&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15837&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15837&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15837&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15837&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15837&r=support Expected behavior: http://bugs.php.net/fix.php?id=15837&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15837&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15837&r=submittedtwice
Bug #15835 Updated: Problem on function gmp_invert ()
ID: 15835
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: *Math Functions
Operating System: Linux - Red Hat 7.2
PHP Version: 4.1.2
New Comment:
Example:
$x =
gmp_init("0x00d2d025ec7e1dbb6d778a52394c988594c57b47d7327a3e676d3a5ca7a5af87c4153c80994cf781f6a9d4a2f0e66d04baffb0059853a8937a895f6d17e76950e1");
// mod
$y = gmp_init("6211846575289879599"); // value
$w = gmp_invert($y,$x);
The $w value should be :
667351618289984699831448814604762419850017638123963706466136275029334435034698239463153441869117173460635003602664197747901516108936488872273669129832
Previous Comments:
[2002-03-02 13:29:43] [EMAIL PROTECTED]
Please provide a short reproducing script with values that you are
using and expected output.
Sean
[2002-03-02 11:44:47] [EMAIL PROTECTED]
The function resource gmp_invert() doesn't work right. It always return
zero.
I implemented the extended Euclides algoritm that do exactly the same
that this function and, it returned me the right value.
--
Edit this bug report at http://bugs.php.net/?id=15835&edit=1
Bug #15837 Updated: gpm_powm()
ID: 15837 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *Math Functions Operating System: Linux - Red Hat 7.2 PHP Version: 4.1.2 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Previous Comments: [2002-03-02 14:14:13] [EMAIL PROTECTED] The gpm function gpm_powm() doesn't work right. If you try to use it, it doesn't return the value. -- Edit this bug report at http://bugs.php.net/?id=15837&edit=1
Bug #15837 Updated: gpm_powm()
ID: 15837 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *Math Functions Operating System: Linux - Red Hat 7.2 PHP Version: 4.1.2 New Comment: The gpm function gpm_powm() doesn't work !! For example: $x = gmp_init(10); $y = gmp_init(15); $m = gmp_init(20); $assoc = gmp_powm($x,$y,$m); gmp_powm($x,$y,$m)) doesn't return anything. Previous Comments: [2002-03-02 14:39:53] [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". [2002-03-02 14:14:13] [EMAIL PROTECTED] The gpm function gpm_powm() doesn't work right. If you try to use it, it doesn't return the value. -- Edit this bug report at http://bugs.php.net/?id=15837&edit=1
Bug #15837 Updated: gpm_powm()
ID: 15837 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Feedback Bug Type: *Math Functions Operating System: Linux - Red Hat 7.2 PHP Version: 4.1.2 New Comment: What do you mean with 'doesn't return anything'? Does it not return a 'Resource id'? Anyway, your calculation returns 0 (10^15=1000, 1000%20=0). Is that what you mean? What does the following sample script print for you: Also, what's your configure line and your version of gmp? Previous Comments: [2002-03-02 14:57:51] [EMAIL PROTECTED] The gpm function gpm_powm() doesn't work !! For example: $x = gmp_init(10); $y = gmp_init(15); $m = gmp_init(20); $assoc = gmp_powm($x,$y,$m); gmp_powm($x,$y,$m)) doesn't return anything. [2002-03-02 14:39:53] [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". [2002-03-02 14:14:13] [EMAIL PROTECTED] The gpm function gpm_powm() doesn't work right. If you try to use it, it doesn't return the value. -- Edit this bug report at http://bugs.php.net/?id=15837&edit=1
Bug #15837 Updated: gpm_powm()
ID: 15837 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: *Math Functions Operating System: Linux - Red Hat 7.2 PHP Version: 4.1.2 New Comment: I'm using PHP 4.1.2. No, it doesn't return a 'Resource id'. The script doesn't work. It's sounds like an erro on this function because, if I comment it, the script work friendly. On my configure line I added --with-gmp. Previous Comments: [2002-03-02 15:15:23] [EMAIL PROTECTED] What do you mean with 'doesn't return anything'? Does it not return a 'Resource id'? Anyway, your calculation returns 0 (10^15=1000, 1000%20=0). Is that what you mean? What does the following sample script print for you: Also, what's your configure line and your version of gmp? [2002-03-02 14:57:51] [EMAIL PROTECTED] The gpm function gpm_powm() doesn't work !! For example: $x = gmp_init(10); $y = gmp_init(15); $m = gmp_init(20); $assoc = gmp_powm($x,$y,$m); gmp_powm($x,$y,$m)) doesn't return anything. [2002-03-02 14:39:53] [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". [2002-03-02 14:14:13] [EMAIL PROTECTED] The gpm function gpm_powm() doesn't work right. If you try to use it, it doesn't return the value. -- Edit this bug report at http://bugs.php.net/?id=15837&edit=1
Bug #15772 Updated: PHP is developed and maintained by morons
ID: 15772
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: *General Issues
Operating System: all
PHP Version: 4.0.6
New Comment:
Fuck you ...php
Previous Comments:
[2002-03-01 07:03:10] [EMAIL PROTECTED]
I have had a long look at rfc1867.c v 1.71.2.2 2002/02/21
from a download of php4.1.2 today (1 Mar 10:00 CET). There are a large
number of dubious cases of handling of the buffer being processed. The
following diffs address most of these (I believe). I am posting the
patches to the php-dev list, since it's difficult if not impossible to
create a properfly formatted diff in this edit window.
[2002-02-28 17:50:58] [EMAIL PROTECTED]
How about this patch:
--- main/rfc1867.c.orig Thu Feb 28 14:08:25 2002
+++ main/rfc1867.c Thu Feb 28 14:33:03 2002
@@ -163,20 +163,28 @@
SAFE_RETURN;
}
/* some other headerfield
found, skip it */
- loc = (char *) memchr(ptr,
'\n', rem)+1;
+ loc = (char *) memchr(ptr,
'\n', rem);
if (!loc) {
/* broken */
php_error(E_WARNING,
"File Upload Mime headers garbled ptr: [%c%c%c%c%c]", *ptr, *(ptr + 1),
*(ptr + 2), *(ptr
+ 3), *(ptr + 4));
SAFE_RETURN;
}
+ else
+ {
+ loc++;
+ }
while (*loc == ' ' || *loc ==
'\t') {
/* other field is
folded, skip it */
- loc = (char *)
memchr(loc, '\n', rem-(loc-ptr))+1;
+ loc = (char *)
memchr(loc, '\n', rem-(loc-ptr));
if (!loc) {
/* broken */
php_error(E_WARNING, "File Upload Mime headers garbled ptr:
[%c%c%c%c%c]", *ptr, *(ptr + 1), *(ptr +
2), *(ptr + 3), *(ptr + 4));
SAFE_RETURN;
}
+ else
+ {
+ loc++;
+ }
}
rem -= (loc - ptr);
ptr = loc;
@@ -232,6 +240,10 @@
* pre 4.0.6 code here
*/
loc2 = memchr(loc + 1, '\n',
rem);
+ if (!loc2) {
+ php_error(E_WARNING,
"File Upload Mime headers - no newline");
+ SAFE_RETURN;
+ }
rem -= (loc2 - ptr) + 1;
ptr = loc2 + 1;
/* is_arr_upload is true when
name of file upload field
[2002-02-28 05:06:42] [EMAIL PROTECTED]
You are again wrong, cnt must be supplied.
I advise you to think before you speak.
A POST fileupload block can have lots of '\0's in it.
Without the number of bytes it would be impossibe to
handle such a block.
[2002-02-28 04:59:29] [EMAIL PROTECTED]
I'll admit that I did not examine the rest of the program to see if the
buffer was '\0'-terminated, however if it is, it's not just me that
thought it wasn't - whoever wrote the routine thought it wasn't either.
Otherwise there wouldn't even be any point in passing the buffer length
to the function, or the main loop's "while (ptr - buf < cnt)" or indeed
half the function.
As to providing patches, I know from experience that what you tend to
do with them is ignore them, insult them, re-write them badly and apply
them six months later, and then fail to credit. Plus I see no point in
providing band-aids in a futile attempt to cover the gaping wounds in
PHP. I *can* give you the fix I recommend to
Bug #15837 Updated: gpm_powm()
ID: 15837 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *Math Functions Operating System: Linux - Red Hat 7.2 PHP Version: 4.1.2 New Comment: You still failed to mention which version of gmp you are using. Previous Comments: [2002-03-02 15:43:54] [EMAIL PROTECTED] I'm using PHP 4.1.2. No, it doesn't return a 'Resource id'. The script doesn't work. It's sounds like an erro on this function because, if I comment it, the script work friendly. On my configure line I added --with-gmp. [2002-03-02 15:15:23] [EMAIL PROTECTED] What do you mean with 'doesn't return anything'? Does it not return a 'Resource id'? Anyway, your calculation returns 0 (10^15=1000, 1000%20=0). Is that what you mean? What does the following sample script print for you: Also, what's your configure line and your version of gmp? [2002-03-02 14:57:51] [EMAIL PROTECTED] The gpm function gpm_powm() doesn't work !! For example: $x = gmp_init(10); $y = gmp_init(15); $m = gmp_init(20); $assoc = gmp_powm($x,$y,$m); gmp_powm($x,$y,$m)) doesn't return anything. [2002-03-02 14:39:53] [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". [2002-03-02 14:14:13] [EMAIL PROTECTED] The gpm function gpm_powm() doesn't work right. If you try to use it, it doesn't return the value. -- Edit this bug report at http://bugs.php.net/?id=15837&edit=1
Bug #15837 Updated: gpm_powm()
ID: 15837 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: *Math Functions Operating System: Linux - Red Hat 7.2 PHP Version: 4.1.2 New Comment: Lets try this again: What is your ENTIRE configure line. What version of GMP are you using? What does that script print for you? Does it print an error message? Previous Comments: [2002-03-02 15:56:21] [EMAIL PROTECTED] You still failed to mention which version of gmp you are using. [2002-03-02 15:43:54] [EMAIL PROTECTED] I'm using PHP 4.1.2. No, it doesn't return a 'Resource id'. The script doesn't work. It's sounds like an erro on this function because, if I comment it, the script work friendly. On my configure line I added --with-gmp. [2002-03-02 15:15:23] [EMAIL PROTECTED] What do you mean with 'doesn't return anything'? Does it not return a 'Resource id'? Anyway, your calculation returns 0 (10^15=1000, 1000%20=0). Is that what you mean? What does the following sample script print for you: Also, what's your configure line and your version of gmp? [2002-03-02 14:57:51] [EMAIL PROTECTED] The gpm function gpm_powm() doesn't work !! For example: $x = gmp_init(10); $y = gmp_init(15); $m = gmp_init(20); $assoc = gmp_powm($x,$y,$m); gmp_powm($x,$y,$m)) doesn't return anything. [2002-03-02 14:39:53] [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". 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/15837 -- Edit this bug report at http://bugs.php.net/?id=15837&edit=1
Bug #15838: Gettext library not linked in correctly?
From: [EMAIL PROTECTED] Operating system: OpenBSD 2.8 PHP version: 4.1.2 PHP Bug Type: Dynamic loading Bug description: Gettext library not linked in correctly? Hi there, I'm trying to get PHP working with Horde, and running into problems. Basically, Horde says it requires "gettext". So, I downloaded the latest "gettext" from GNU, compiled and installed it in /opt/gettext. Then I compiled PHP with --with-gettext, e.g. ./configure --with-mysql=/usr/local \ --with-apxs=/opt/apache/sbin/apxs \ --prefix=/opt/php --with-openssl=/usr/local/ssl \ --with-imap=/usr/local --with-gdbm --with-xml \ --with-mcrypt=/usr/local --with-gettext=/opt/gettext Compile seems to go fine, with a couple warnings of the form: *** Warning: This library needs some functionality provided by /usr/local/lib/libintl.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. (also a similar warning for -lresolv; is this a problem?) OK, so, then I install PHP, install Horde, and start testing it. The test.php script provided by Horde seems to work fine and report everything working. I did some additional configuration, and everything stopped working; pages wouldn't load, etc etc. After a bit of digging, I finally found this error message in one of my server's error logs: /usr/libexec/ld.so: Undefined symbol "_gettext" called from httpd:/opt/apache/libexec/libphp4.so at 0x4030 44f0 References to "gettext" appear in "libgettext.a" and "libintl.a", but pretty much nowhere else. So here's my guess: PHP is expecting gettext to be in a shared library. GNU gettext doesn't compile a shared library (I even added --enable-shared to the configure line for gettext, and still didn't get a ".so" style library, which I believe is what's needed). Thus, PHP can't find the gettext reference, and when Horde tries to use it, it craps out. About right? So the question is, how do I either a) get a shared gettext library b) compile gettext into PHP statically, or c) fix it some other way? Is this a problem with GNU gettext, PHP, or both, or some problem with the way I configured everything? I'd really appreciate some tips and advice; I can't believe this is really all that hard, so I must have done something wrong. What was supposed to be an afternoon project is turning into a week! Thanks in advance... -- Edit bug report at http://bugs.php.net/?id=15838&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15838&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15838&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15838&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15838&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15838&r=support Expected behavior: http://bugs.php.net/fix.php?id=15838&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15838&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15838&r=submittedtwice
Bug #15837 Updated: gpm_powm()
ID: 15837 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: *Math Functions Operating System: Linux - Red Hat 7.2 PHP Version: 4.1.2 New Comment: I don't know ... Is gmp comming with php ? Previous Comments: [2002-03-02 15:57:55] [EMAIL PROTECTED] Lets try this again: What is your ENTIRE configure line. What version of GMP are you using? What does that script print for you? Does it print an error message? [2002-03-02 15:56:21] [EMAIL PROTECTED] You still failed to mention which version of gmp you are using. [2002-03-02 15:43:54] [EMAIL PROTECTED] I'm using PHP 4.1.2. No, it doesn't return a 'Resource id'. The script doesn't work. It's sounds like an erro on this function because, if I comment it, the script work friendly. On my configure line I added --with-gmp. [2002-03-02 15:15:23] [EMAIL PROTECTED] What do you mean with 'doesn't return anything'? Does it not return a 'Resource id'? Anyway, your calculation returns 0 (10^15=1000, 1000%20=0). Is that what you mean? What does the following sample script print for you: Also, what's your configure line and your version of gmp? [2002-03-02 14:57:51] [EMAIL PROTECTED] The gpm function gpm_powm() doesn't work !! For example: $x = gmp_init(10); $y = gmp_init(15); $m = gmp_init(20); $assoc = gmp_powm($x,$y,$m); gmp_powm($x,$y,$m)) doesn't return anything. 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/15837 -- Edit this bug report at http://bugs.php.net/?id=15837&edit=1
Bug #15839: random error related to stripslashes
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.2 PHP Bug Type: MySQL related Bug description: random error related to stripslashes I'm webmaster/developer of the support / news site www.mactalk.dk The company which host this site, have recently upgraded php from 4.0.6 to 4.1.2 due to the upload security bug. After they have upgraded php to 4.1.2, I'm having problems with stripslashes randomly not working. The result is that data from the MySQL database will be displayed with backslashes i.e.: http://www.mactalk.dk\";> Please visit the forums www.mactalk.dk/foraindex.php to reproduce the error. Please note that this error is a random error and that you there fore might have to reload the page a couple of times to see it. -- Edit bug report at http://bugs.php.net/?id=15839&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15839&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15839&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15839&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15839&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15839&r=support Expected behavior: http://bugs.php.net/fix.php?id=15839&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15839&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15839&r=submittedtwice
Bug #15839 Updated: random error related to stripslashes
ID: 15839 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: MySQL related Operating System: Linux PHP Version: 4.1.2 New Comment: I'm webmaster/developer of the support / news site www.mactalk.dk The company which host this site, have recently upgraded php from 4.0.6 to 4.1.2 due to the upload security bug. After they have upgraded php to 4.1.2, I'm having problems with stripslashes randomly not working. The result is that data from the MySQL database will be displayed with backslashes i.e.: http://www.mactalk.dk\";> Please visit the forums www.mactalk.dk/fora_index.php to reproduce the error. Please note that this error is a random error and that you there fore might have to reload the page a couple of times to see it. Previous Comments: [2002-03-02 16:43:09] [EMAIL PROTECTED] I'm webmaster/developer of the support / news site www.mactalk.dk The company which host this site, have recently upgraded php from 4.0.6 to 4.1.2 due to the upload security bug. After they have upgraded php to 4.1.2, I'm having problems with stripslashes randomly not working. The result is that data from the MySQL database will be displayed with backslashes i.e.: http://www.mactalk.dk\";> Please visit the forums www.mactalk.dk/foraindex.php to reproduce the error. Please note that this error is a random error and that you there fore might have to reload the page a couple of times to see it. -- Edit this bug report at http://bugs.php.net/?id=15839&edit=1
Bug #15840: Sample code bug on in your documentation
From: [EMAIL PROTECTED] Operating system: all PHP version: 4.1.2 PHP Bug Type: Documentation problem Bug description: Sample code bug on in your documentation On this page http://www.php.net/manual/en/ref.session.php there is a bug in this sample code provided. Missing "}" at the end of the code sample. Example 2. Registering a variable with $_SESSION. -- Edit bug report at http://bugs.php.net/?id=15840&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15840&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15840&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15840&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15840&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15840&r=support Expected behavior: http://bugs.php.net/fix.php?id=15840&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15840&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15840&r=submittedtwice
Bug #15840 Updated: Sample code bug on in your documentation
ID: 15840 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: all PHP Version: 4.1.2 New Comment: Fixed in CVS. IT will show up online in a few days. Derick Previous Comments: [2002-03-02 17:43:11] [EMAIL PROTECTED] On this page http://www.php.net/manual/en/ref.session.php there is a bug in this sample code provided. Missing "}" at the end of the code sample. Example 2. Registering a variable with $_SESSION. -- Edit this bug report at http://bugs.php.net/?id=15840&edit=1
Bug #15837 Updated: gpm_powm()
ID: 15837 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *Math Functions Operating System: Linux - Red Hat 7.2 PHP Version: 4.1.2 New Comment: No. I'm bogusifying until you can answer the questions we asked you. Without those answers we cannot help you any further. Feel free to re-open if you have the necessary information. Previous Comments: [2002-03-02 16:02:02] [EMAIL PROTECTED] I don't know ... Is gmp comming with php ? [2002-03-02 15:57:55] [EMAIL PROTECTED] Lets try this again: What is your ENTIRE configure line. What version of GMP are you using? What does that script print for you? Does it print an error message? [2002-03-02 15:56:21] [EMAIL PROTECTED] You still failed to mention which version of gmp you are using. [2002-03-02 15:43:54] [EMAIL PROTECTED] I'm using PHP 4.1.2. No, it doesn't return a 'Resource id'. The script doesn't work. It's sounds like an erro on this function because, if I comment it, the script work friendly. On my configure line I added --with-gmp. [2002-03-02 15:15:23] [EMAIL PROTECTED] What do you mean with 'doesn't return anything'? Does it not return a 'Resource id'? Anyway, your calculation returns 0 (10^15=1000, 1000%20=0). Is that what you mean? What does the following sample script print for you: Also, what's your configure line and your version of gmp? 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/15837 -- Edit this bug report at http://bugs.php.net/?id=15837&edit=1
Bug #15839 Updated: random error related to stripslashes
ID: 15839 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: MySQL related Operating System: Linux PHP Version: 4.1.2 New Comment: Until you provide more information (== reproducable script, related php.ini settings) there's little we can do for you. Previous Comments: [2002-03-02 16:44:55] [EMAIL PROTECTED] I'm webmaster/developer of the support / news site www.mactalk.dk The company which host this site, have recently upgraded php from 4.0.6 to 4.1.2 due to the upload security bug. After they have upgraded php to 4.1.2, I'm having problems with stripslashes randomly not working. The result is that data from the MySQL database will be displayed with backslashes i.e.: http://www.mactalk.dk\";> Please visit the forums www.mactalk.dk/fora_index.php to reproduce the error. Please note that this error is a random error and that you there fore might have to reload the page a couple of times to see it. [2002-03-02 16:43:09] [EMAIL PROTECTED] I'm webmaster/developer of the support / news site www.mactalk.dk The company which host this site, have recently upgraded php from 4.0.6 to 4.1.2 due to the upload security bug. After they have upgraded php to 4.1.2, I'm having problems with stripslashes randomly not working. The result is that data from the MySQL database will be displayed with backslashes i.e.: http://www.mactalk.dk\";> Please visit the forums www.mactalk.dk/foraindex.php to reproduce the error. Please note that this error is a random error and that you there fore might have to reload the page a couple of times to see it. -- Edit this bug report at http://bugs.php.net/?id=15839&edit=1
Bug #15841: CRLF to separate mail headers is incorrect
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.2 PHP Bug Type: *Mail Related Bug description: CRLF to separate mail headers is incorrect Last November the mail documentation was changed from saying: "Multiple extra headers are separated with a newline." to: "Multiple extra headers are separated with a carriage return and newline. Note: You must use \r\n to seperate headers, although some Unix mail transfer agents may work with just a single newline (\n)." This change is inaccurate. Line breaks in headers should be the native line endings for the system on which PHP is running. The mail() function is not talking to an SMTP server, so RFC2822 does not apply here. mail() is talking to a command line program on the local system, and it is reasonable to expect that program to require system-native line breaks. Use of CRLF is known to break qmail systems where no conversion of line breaks occurs on the input data. In this case using CRLF causes all but the first extra header to appear in the message body (CRLF is interpreted as two line breaks). Possibly the best resolution to this problem would be for the mail() function to convert any line breaks in arg 4 into the system's native line breaks. -- Edit bug report at http://bugs.php.net/?id=15841&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15841&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15841&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15841&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15841&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15841&r=support Expected behavior: http://bugs.php.net/fix.php?id=15841&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15841&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15841&r=submittedtwice
Bug #9836 Updated: php unexpectedly ends on too long scripts
ID: 9836 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Scripting Engine problem Operating System: linux PHP Version: 4.1.0 New Comment: Will you please provide a link to a website containing this sample script? Also will you share your php.ini file with us so we might debug this further? What about your config line? Previous Comments: [2001-12-14 15:05:22] [EMAIL PROTECTED] I've verified this problem when I was taking care of other bug report. This is critical I think. I'll look for duplicate later. [2001-08-07 08:47:19] [EMAIL PROTECTED] User feedback: -- After further testing I found out it depends on memory limit. But usually if you violate memory limit, you get a warning. The warning is probably not issued when parsing the script. (I am not sure about it as I didn't look at the sources). --- User used the latest CVS snapshot. --Jani [2001-08-07 05:48:20] [EMAIL PROTECTED] And now we have already released PHP 4.0.6. But could you PLEASE try the latest CVS snapshot: http://snaps.php.net/ After you have tested your script with these and if it still fails, provide the GDB backtrace I asked a long ago. --Jani [2001-08-07 05:28:09] [EMAIL PROTECTED] so it has happened again. I again offer to provide the script so that you can see where the problem is. I won't paste it here because it has 730K. The script cannot really run because it is supposed to have many includes and it itself should be included by other script -- but it should fail with some reason (like unknown function). Instead it just dies with return code 1. [2001-05-10 05:57:58] [EMAIL PROTECTED] No feedback. If problem exists with PHP 4.0.5, reopen. 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/9836 -- Edit this bug report at http://bugs.php.net/?id=9836&edit=1
Bug #15834 Updated: segmentation fault starting apache with pfpro
ID: 15834 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: linux RH7.1 PHP Version: 4.1.2 New Comment: This can happen when you link a library not compiled/linked with gcc into an app that is, or vice versa. Try adding this switch to your PHP ./configure line: --enable-libgcc Previous Comments: [2002-03-02 11:43:02] [EMAIL PROTECTED] Here it is. #0 0x400d528c in __umoddi3 () from /usr/local/verisign/payflowpro/linux/lib/libpfpro.so No symbol table info available. #1 0x400b7678 in PNVersion () from /usr/local/verisign/payflowpro/linux/lib/libpfpro.so No symbol table info available. Cannot access memory at address 0x3 [2002-03-02 11:38:26] [EMAIL PROTECTED] Oops :) Can you hit 'bt full' on the prompt after the crash and post the results again? regards, derick [2002-03-02 11:36:56] [EMAIL PROTECTED] Following is the message. Thanks. Program received signal SIGSEGV, Segmentation fault. 0x400d528c in __umoddi3 () from /usr/local/verisign/payflowpro/linux/lib/libpfpro.so [2002-03-02 11:27:02] [EMAIL PROTECTED] gdb /path/to/httpd and enter on the prompt: run -X [2002-03-02 11:25:26] [EMAIL PROTECTED] Not sure how this could be generated since apache will not start. Follwing is the message that I received when trying to start apache. line 184: 3736 Segmentation fault $HTTPD /usr/local/apache/bin/apachectl start: httpd could not be started 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/15834 -- Edit this bug report at http://bugs.php.net/?id=15834&edit=1
Bug #15131 Updated: XSLT Causing Core Dumps
ID: 15131 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Reproducible crash Operating System: RedHat 7.2 PHP Version: 4.1.1 -Assigned To: +Assigned To: sterling New Comment: assigning to Sterling as he seems to know this best (might be because he wrote it). Any chance we can get this fixed for the next RC process? Previous Comments: [2002-03-01 03:36:07] [EMAIL PROTECTED] Making this critical because: 1. It's an easy fix 2. Documentation should be made better 3. I got bitten by it too :) Derick [2002-03-01 03:33:48] [EMAIL PROTECTED] actually, i was using the function incorrectly. i was providing it strings when it was wanting filenames. i wound up using the variable substitution (from php.net examples) and it worked, feeding it strings. still this is a nasty bug that should be more graceful. [2002-02-16 05:19:22] [EMAIL PROTECTED] I am getting this as well, driving me nuts. Copy of email sent to Sablotron list as well. Also: could this be due to PHP's bundled expat possibly at all? Something to look at I guess, but then again, I'm not that technical on the PHP internals. The machine is Redhat Linux 7.1, PHP 4.1.1, Sablotron 0.82, Apache 1.3.23. I have followed the directions every match of a segfault+php+sablotron+apache on google matched - recompile apache WITHOUT it's expat_lite. Well, I've done that. I renamed the expat_lite dir AND used the --disable-rule=EXPAT, and did a "strings httpd | grep -i expat" and grepped for xml as well, and did an "nm" on the binary as well - no trace of any of that. I also removed the whole apache hierarchy to install it fresh. However, my calls to xslt_process() still give me: [Sat Feb 16 01:46:55 2002] [notice] child pid 6871 exit signal Segmentation fault (11) [Sat Feb 16 01:46:56 2002] [notice] child pid 6894 exit signal Segmentation fault (11) [Sat Feb 16 01:46:58 2002] [notice] child pid 6867 exit signal Segmentation fault (11) [Sat Feb 16 01:47:01 2002] [notice] child pid 6868 exit signal Segmentation fault (11) in fact, now each page load reports TWO errors. the "sabcmd" command works fine, and is able to understand these. technically this shouldn't be a Sablotron bug, but I was hoping someone there would have more pointers to fix this, or find more information about it on their side... but I think the fix will be from the PHP team. php configure: ./configure --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --enable-track-vars --with-curl --with-openssl --enable-sockets --enable-shmop --enable-sysvsem --enable-sysvshm --with-jpeg-dir=/usr/local --with-png-dir=/usr/local --with-gd --with-zlib-dir=/usr --enable-xslt --with-expat-dir=/usr/local --with-xslt-sablot checking for XML support... yes checking external libexpat install dir... yes checking for XMLRPC-EPI support... no checking libexpat dir for XMLRPC-EPI... yes checking whether to enable xslt support... yes checking whether to enable the XSLT Sablotron backend... yes checking libexpat dir for Sablotron XSL support... yes checking for Sablotron libraries in the default path... found Sablotron in /usr/local checking for iconv_open in -lc... yes checking for SablotSetEncoding in -lsablot... yes checking for YAZ support... no ^^ i believe that's as good as it can look. it found my system expat, and sablotron. apache doesnt even care about expat. everything seems to be reading from this central expat, so why doesn't it work? [2002-01-20 22:29:03] [EMAIL PROTECTED] Bug Trace, as best as I can get... root@dev:/usr/local/apache/bin# gdb /usr/local/apache/bin/httpd GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"...(no debugging symbols found)... (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X [New Thread 1024 (LWP 12186)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 12186)] 0x400a3f62 in Situation::generateMessage (this=0x6e617473, type=578643299, code=1667846974, arg1=@0x662f3c6b, arg2=@0x3e746e6f, theMessage=@0x68742f3c) at situa.cpp:279 279 if (messenger && !(flags & SAB_NO_ERROR_REPORTING)) Current language: auto; currently c++ (gdb) bt #0 0x400a3f62 in Situation::generateM
Bug #15842: Fopen function
From: [EMAIL PROTECTED] Operating system: windows XP PHP version: 4.1.2 PHP Bug Type: Apache related Bug description: Fopen function Hi... i want to build a php file that opens one of a number of pages randomly... this is what i've coem up with. the rand function works...but i don't think the fopen function does. i don't know if it has to do with apache or what? thanks: -- Edit bug report at http://bugs.php.net/?id=15842&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15842&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15842&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15842&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15842&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15842&r=support Expected behavior: http://bugs.php.net/fix.php?id=15842&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15842&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15842&r=submittedtwice
Bug #14929 Updated: Segmentation fault when using none-deep recursive scripts
ID: 14929 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Reproducible crash Operating System: RedHat Linux 7.0 PHP Version: 4.1.0 New Comment: No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-01-13 15:09:35] [EMAIL PROTECTED] I think you are using dev/test system, right? Try it under test system. Unless you provide more details, it just can't be fixed :) [2002-01-13 12:42:39] [EMAIL PROTECTED] Hello! Unfortunatelly we could not get the core file as we don't have the root access to the server. Also script crashes after it works for about 5 or even more hours. We run script in the new process, then, after several hours, we can see this process running, then, suddenly, it disappears. Pls. let us know if you have implemented the switch we were asking about, as we really hope it will help us - we will contact server admins and will ask them to recompile the php with your switch. [2002-01-09 22:04:04] [EMAIL PROTECTED] Please read instruction for submitting bugs. You should attach backtrace ;) [2002-01-08 07:36:16] [EMAIL PROTECTED] When running a large multi-file script (it should run for several hours, or maybe even more) using PHP standalone CGI executable from the shell, it crashes with Segmentation Fault after running a wide and none-deep (max 5-10 level depth) recursive script. I'm thinking it's a stack limitation problem. I found this problem (which is very similar to the "recursive call limitation" (#1901) PHP Bug Report) with two my own Linux servers (PHP 4.0.4 and 4.1.0). In the answer to those bug report you mentioned that you may add some compile-time switch, which will make PHP use heap, but not stack for intensive data. Please let me know if such switch has been added and how I can use it with my servers or if you know some other way, which will help me to solve this problem. Thanks in advance! -- Edit this bug report at http://bugs.php.net/?id=14929&edit=1
Bug #14394 Updated: Problem with line 1457 "archive_cmds"
ID: 14394 Updated by: [EMAIL PROTECTED] -Summary: Problem with line 1457 "archive_cmds" Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed Bug Type: Compile Failure Operating System: Mac OSX 10.1 PHP Version: 4.1.0 New Comment: this is actually a known bug. It's more a bug with libtool and not really a bug of PHP. This is supposedly fixed in libtool 1.4.2 but it doesn't seem to be really (at least not for me locally). There is a libtool 1.3.5 patch that supposedly fixes this for v1.3 libtools. If you're feeling bold, try applying that patch and seeing how things go. Previous Comments: [2001-12-11 22:02:11] [EMAIL PROTECTED] Problem also exists in 4.1 [2001-12-09 11:33:47] [EMAIL PROTECTED] When compiling PHP on MacOSX 10.1 you must update line 1457 of the ltconfig file. Trying to compile the source code from php.net as is results in this error: /usr/bin/ld: -undefined error must be used when - twolevel_namespace is in effect make[1]: *** [libphp4.la] Error 1 make: *** [all-recursive] Error 1 Original source line# 1457 of ltconfig downloaded from php.net: archive_cmds='$CC -bundle -undefined suppress -o $lib $libobjs $deplibs $linkopts' What must be used on line 1457 of ltconfig to successfully compile: archive_cmds='$CC -force_flat_namespace -bundle -undefined suppress -o $lib $libobjs $deplibs $linkopts' It took me a long time to find the answer for this problem. There is an article on the Apple developer pages that gave me the change, but they have the wrong line number listed [maybe the source has been updated] Article that told me how to fix it: http://developer.apple.com/internet/macosx/php.html -- Edit this bug report at http://bugs.php.net/?id=14394&edit=1
Bug #15842 Updated: Fopen function
ID: 15842 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache related Operating System: windows XP 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-02 23:48:47] [EMAIL PROTECTED] Hi... i want to build a php file that opens one of a number of pages randomly... this is what i've coem up with. the rand function works...but i don't think the fopen function does. i don't know if it has to do with apache or what? thanks: -- Edit this bug report at http://bugs.php.net/?id=15842&edit=1
Bug #14423 Updated: PHP won't compile with --with-iconv turned on
ID: 14423
Updated by: [EMAIL PROTECTED]
-Summary: PHP won't compile with --with-iconv turned on
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Compile Failure
Operating System: FreeBSD 4.4-STABLE
PHP Version: 4.1.0
New Comment:
any chance you can test this patch out on your machine against a
current CVS checkout?
Index: config.m4
===
RCS file: /repository/php4/ext/iconv/config.m4,v
retrieving revision 1.7
diff -u -r1.7 config.m4
--- config.m4 30 Nov 2001 18:59:38 - 1.7
+++ config.m4 3 Mar 2002 06:24:44 -
@@ -7,15 +7,27 @@
if test "$PHP_ICONV" != "no"; then
+dnl This is a fix for why FreeBSD does not work with ICONV
+dnl It seems libtool checks for libiconv_open which only exists in
+dnl the giconv series of files under FreeBSD
+
+ ac_os_uname = `uname -s 2>/dev/null`
+
+ if test "$ac_os_uname" = "FreeBSD"; then
+ lib_name=giconv
+ else
+ lib_name=iconv
+ fi
+
for i in /usr /usr/local $PHP_ICONV; do
-test -r $i/include/iconv.h && ICONV_DIR=$i
+test -r $i/include/${lib_name}.h && ICONV_DIR=$i
done
if test -z "$ICONV_DIR"; then
AC_MSG_ERROR(Please reinstall the iconv library.)
fi
- if test -f $ICONV_DIR/lib/libconv.a -o -f
$ICONV_DIR/lib/libiconv.$SHLIB_SUFFIX_NAME ; then
+ if test -f $ICONV_DIR/lib/libconv.a -o -f
$ICONV_DIR/lib/lib${lib_name}.$SHLIB_SUFFIX_NAME ;
then
PHP_ADD_LIBRARY_WITH_PATH(iconv, $ICONV_DIR/lib,
ICONV_SHARED_LIBADD)
AC_CHECK_LIB(iconv, libiconv_open, [
AC_DEFINE(HAVE_ICONV, 1, [ ])
Index: php_iconv.h
===
RCS file: /repository/php4/ext/iconv/php_iconv.h,v
retrieving revision 1.9
diff -u -r1.9 php_iconv.h
--- php_iconv.h 13 Dec 2001 14:31:16 - 1.9
+++ php_iconv.h 3 Mar 2002 06:24:44 -
@@ -26,8 +26,9 @@
#define PHP_ICONV_API
#endif
+#if HAVE_ICONV
extern zend_module_entry iconv_module_entry;
-#define phpext_iconv_ptr &iconv_module_entry
+#define iconv_module_ptr &iconv_module_entry;
PHP_MINIT_FUNCTION(miconv);
PHP_MSHUTDOWN_FUNCTION(miconv);
@@ -53,6 +54,14 @@
#define ICONV_INPUT_ENCODING "ISO-8859-1"
#define ICONV_OUTPUT_ENCODING "ISO-8859-1"
#define ICONV_INTERNAL_ENCODING "ISO-8859-1"
+
+#else
+
+#define iconv_module_ptr NULL
+
+#endif /* HAVE_ICONV */
+
+#define phpext_iconv_ptr iconv_module_entry
#endif /* PHP_ICONV_H */
Previous Comments:
[2002-02-23 06:40:15] [EMAIL PROTECTED]
I'm experiencing the same Problem with PHP4.1.1 and FreeBSD 4.5
[2002-01-24 09:06:32] [EMAIL PROTECTED]
Yes, just tried on 4.5-PRERELEASE.
[2002-01-23 16:29:09] [EMAIL PROTECTED]
Does it *always* fail with the former configure line?
[2001-12-24 10:48:32] [EMAIL PROTECTED]
Here is configure, which works fine. But I cannot find out what caused
it to fail in previous case...
'./configure' '--with-config-file-path=/usr/local/etc/php.standalone'
'--disable-pear'
'--enable-discard-path' '--with-readline=/usr'
'--enable-versioning' '--with-system-regex'
'--disable-debug'
'--enable-track-vars' '--with-gd=/usr/local'
'--with-freetype-dir=/usr/local'
'--with-jpeg-dir=/usr/local'
'--with-png-dir=/usr/local' '--with-zlib' '--with-mysql=/usr/local'
'--with-pgsql=/usr/local'
'--with-openssl=/usr' '--with-xml'
'--with-xmlrpc=/usr/local' '--with-ttf' '--with-freetype'
'--enable-xslt'
'--with-xslt-sablot' '--with-expat-dir=/usr/local'
'--with-dom=/usr/local' '--enable-ftp'
'--with-ico
Bug #14250 Updated: From cvs, ./buildconf reports errors
ID: 14250 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: Cobalt RAQ 3-Red Hat 5 PHP Version: 4.2.0 dev (CVS) New Comment: closed as per user statement Previous Comments: [2001-11-27 11:29:46] [EMAIL PROTECTED] dont know, will take 30mins to get to my pc, another 30mins to get to server and five minutes to test. I am happy to close this as I thought I was using 4.1 from cvs as the 'documentation leads you to believe'. [2001-11-27 11:25:05] [EMAIL PROTECTED] Is it now fixed or not? [2001-11-27 11:21:50] [EMAIL PROTECTED] Thanks for that. wget didnt get it, so its a long haul to download to my pc then back to the server. Thanks for your prompt and useful help. Kevin [2001-11-27 11:14:09] [EMAIL PROTECTED] Sorry... I didn't see that ;) [2001-11-27 11:12:31] [EMAIL PROTECTED] No, by default you get 4.2.0 You can find 4.1.0RC3 at http://www.php.net/~zeev/php-4.1.0RC3.tar.gz But please copy&paste the output of buildconf here. 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/14250 -- Edit this bug report at http://bugs.php.net/?id=14250&edit=1
Bug #14557 Updated: Compile Failure (and potential fix)
ID: 14557 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: MacOS X (10.1.1) PHP Version: 4.1.0 -Assigned To: +Assigned To: kalowsky New Comment: Thank you for the submission of this. have you sent an email to the libtool group yet informing them of your findings as well? It might be useful :) Assigning to myself to keep me working on a proper fix. Previous Comments: [2001-12-17 01:07:07] [EMAIL PROTECTED] Oops! One more thing! The full text of the tcsh script I'm using is available at http://leraz.dhs.org:8080/~squasar/ manual_php_compile.txt and a script which outputs a phpinfo() is available at http://leraz.dhs.org:8080/ ~squasar/info.php [2001-12-17 01:04:07] [EMAIL PROTECTED] (Incidently, I want to note that most of the problems with the compile seem to stem from libtool, which evidently has no clue what the heck it's doing.) [2001-12-17 01:01:26] [EMAIL PROTECTED] The compile of PHP 4.1.0 (source tarball) fails miserably out-of-the-box on MacOS X 10.1.1. The CGI version seems mostly alright, but the Apache DSO is a dismal mess. I'm running the latest released Apache (1.3.22). Also, I'm working with the CC shipped by Apple for OS X (this failed even MORE miserably with my compiled version of GCC, which is expected since OS X isn't supported by GCC yet) After some 5 days of wrestling, writing manual compiles, and running make -n and libtool --dry-run to get some idea of what the compilation is doing, I finally got it to work properly via writing a tcsh script that manually compiles the files involved (My configure is "./configure --with- apxs=/usr/sbin/apxs --enable-ftp --enable-mbstring -- enable-mbstr-enc-trans --with-mysql=/usr/local --enable- sockets --with-tsrm-pthreads --enable-ctype --with-zlib -- prefix=/usr --sysconfdir=/etc --localstatedir=/var -- mandir=/usr/share/man"). Instead of filling this text box beyond its buffer with the entire script (which gets a bit long in the tooth, obviously), here's a summary of what options it uses: cc command when compiling normal source files: /usr/bin/cc -dynamic -fPIC -fno-common -traditional-cpp -O2 -I(all the various include dirs) -D(all the various defines) -c (source file).c -o (source file).lo ld command when combining the .lo files in a dir into a .a: /usr/bin/ld -r -o lib(dir name).a (all the objects from the dir) cc command for creating the final libphp4.so: /usr/bin/cc - bundle -bundle_loader /usr/sbin/httpd -flat_namespace - undefined warning -lm -lz -L/usr/local/lib/mysql - lmysqlclient -o libphp4.so (all the .a's compiled above) # for this one, note that the -L and -l for mysql only apply for compiling with a non-bundled libmysql Putting all this together into a tcsh script gave me a successful PHP compile, and adding the appropriate install command (/usr/sbin/apxs -S LIBEXECDIR="/usr/libexec/httpd" -i -a -n php4 libphp4.so) gave me a working Apache + PHP 4.1.0 + MySQL. My humble suggestion is that whoever maintains the autoconf script for PHP use this information to make a normal ./configure work under Darwin. (incidently, `uname -a` == Darwin hostname 5.1 Darwin Kernel Version 5.1: Tue Oct 30 00:06:34 PST 2001; root:xnu/ xnu-201.5.obj~1/RELEASE_PPC Power Macintosh powerpc). Thanks :) -- Edit this bug report at http://bugs.php.net/?id=14557&edit=1
Bug #14765 Updated: Compile Failure
ID: 14765 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: FreeBSD 4.4 PHP Version: 4.1.0 New Comment: build works fine on PHP 4.1.2 release on FreeBSD 4.5 It sounds like your Apache install isn't all there. Previous Comments: [2002-02-27 11:13:10] [EMAIL PROTECTED] I'm experiencing the same problem on a Cobalt raQ (Linux Redhat) with 4.1.1 I can install php as a static module without any problem. I use Apache 1.3.19. It even happens with ./configure --with-apxs Jef [2001-12-30 05:50:48] [EMAIL PROTECTED] I can not compile apache 1.3.19 with PHP(DSO) . éHelp me ! I use command "./configure --with-apxs=/home/httpd/bin/apxs --enable-versioning --with-mysql --enable-track-vars" . and "make" result is " /bin/sh /usr/home/httpd/src/php-4.1.0/libtool --silent --mode=compile gcc -I. -I/usr/home/httpd/src/php-4.1.0/sapi/apache -I/usr/home/httpd/src/php-4.1.0/main -I/usr/home/httpd/src/php-4.1.0 -I/usr/home/httpd/include -I/usr/home/httpd/src/php-4.1.0/Zend -I/usr/home/httpd/src/php-4.1.0/ext/mysql/libmysql -I/usr/home/httpd/src/php-4.1.0/ext/xml/expat -DLINUX=22 -DMOD_SSL=208103 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT -I/usr/home/httpd/src/php-4.1.0/TSRM -g -O2 -prefer-pic -c sapi_apache.c In file included from /usr/home/httpd/include/httpd.h:72, from sapi_apache.c:32: /usr/home/httpd/include/ap_config.h:490: features.h: No such file or directory In file included from /usr/home/httpd/include/httpd.h:72, from sapi_apache.c:32: /usr/home/httpd/include/ap_config.h:1338: warning: `XtOffsetOf' redefined /usr/home/httpd/src/php-4.1.0/main/php.h:342: warning: this is the location of the previous definition *** Error code 1 Stop in /usr/home/httpd/src/php-4.1.0/sapi/apache. *** Error code 1 Stop in /usr/home/httpd/src/php-4.1.0/sapi/apache. *** Error code 1 Stop in /usr/home/httpd/src/php-4.1.0/sapi. *** Error code 1 Stop in /usr/home/httpd/src/php-4.1.0. " çHelp me ! Thank you. -- Edit this bug report at http://bugs.php.net/?id=14765&edit=1
Bug #14394 Updated: Problem with line 1457 "archive_cmds"
ID: 14394 Updated by: [EMAIL PROTECTED] -Summary: Problem with line 1457 "archive_cmds" Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Compile Failure Operating System: Mac OSX 10.1 PHP Version: 4.1.0 -Assigned To: +Assigned To: kalowsky New Comment: assigning to myself Previous Comments: [2002-03-03 00:01:51] [EMAIL PROTECTED] this is actually a known bug. It's more a bug with libtool and not really a bug of PHP. This is supposedly fixed in libtool 1.4.2 but it doesn't seem to be really (at least not for me locally). There is a libtool 1.3.5 patch that supposedly fixes this for v1.3 libtools. If you're feeling bold, try applying that patch and seeing how things go. [2001-12-11 22:02:11] [EMAIL PROTECTED] Problem also exists in 4.1 [2001-12-09 11:33:47] [EMAIL PROTECTED] When compiling PHP on MacOSX 10.1 you must update line 1457 of the ltconfig file. Trying to compile the source code from php.net as is results in this error: /usr/bin/ld: -undefined error must be used when - twolevel_namespace is in effect make[1]: *** [libphp4.la] Error 1 make: *** [all-recursive] Error 1 Original source line# 1457 of ltconfig downloaded from php.net: archive_cmds='$CC -bundle -undefined suppress -o $lib $libobjs $deplibs $linkopts' What must be used on line 1457 of ltconfig to successfully compile: archive_cmds='$CC -force_flat_namespace -bundle -undefined suppress -o $lib $libobjs $deplibs $linkopts' It took me a long time to find the answer for this problem. There is an article on the Apple developer pages that gave me the change, but they have the wrong line number listed [maybe the source has been updated] Article that told me how to fix it: http://developer.apple.com/internet/macosx/php.html -- Edit this bug report at http://bugs.php.net/?id=14394&edit=1
Bug #14919 Updated: PHP errors all over the place!
ID: 14919
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Compile Failure
Operating System: freebsd 4.4
PHP Version: 4.1.1
New Comment:
please 'make distclean' and then rebuild.
Previous Comments:
[2002-01-07 16:43:59] [EMAIL PROTECTED]
with php 4.1.1, i installed with the following options ->
mysql - postgres - xml - domxml - ftp - curl - openssl - gettext -
sockets
installed great. then i try to use curl over https and it tells me:
SSL: Couldn't create a context!
so i look in the bug database and find a few things telling me that in
older versions, configuring php without openssl would fix things up for
me. so i tried that, with all the same options as above but without
openssl, but php will not install without the openssl option. here's
the error plus the bunch of lines before it:
configure:22804: checking for bindtextdomain in -lintl
configure:22823: cc -o conftest -O -pipe -I/usr/local/include
-DHARD_SERVER_LIMIT=512 -DDOCUMENT_LOCATION="/usr/local/www/data/"
-DDEFAULT_PATH="/bin:/usr/bin:/usr/local/bin"
-DACCEPT_FILTER_NAME="httpready" -DUSE_EXPAT -R/usr/local/lib
-L/usr/local/lib -L/usr/local/lib conftest.c -lintl -lz -lxml2 -lcurl
-lcrypto -lssl -lcurl -lz -lcrypt -lm -lcrypt 1>&5
/usr/local/lib/libssl.a(ssl_algs.o): In function `SSL_library_init':
ssl_algs.o(.text+0x34): undefined reference to `EVP_idea_cbc'
configure: failed program was:
#line 22812 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char bindtextdomain();
int main() {
bindtextdomain()
; return 0; }
configure:22843: checking for bindtextdomain in -lc
configure:22862: cc -o conftest -O -pipe -I/usr/local/include
-DHARD_SERVER_LIMIT=512 -DDOCUMENT_LOCATION="/usr/local/www/data/"
-DDEFAULT_PATH="/bin:/usr/bin:/usr/local/bin"
-DACCEPT_FILTER_NAME="httpready" -DUSE_EXPAT -R/usr/local/lib
-L/usr/local/lib -L/usr/local/lib conftest.c -lc -lz -lxml2 -lcurl
-lcrypto -lssl -lcurl -lz -lcrypt -lm -lcrypt 1>&5
/tmp/ccZh5V5u.o: In function `main':
/tmp/ccZh5V5u.o(.text+0x7): undefined reference to `bindtextdomain'
/usr/local/lib/libssl.a(ssl_algs.o): In function `SSL_library_init':
ssl_algs.o(.text+0x34): undefined reference to `EVP_idea_cbc'
configure: failed program was:
#line 22851 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
> builtin and then its argument prototype would still apply. */
char bindtextdomain();
int main() {
bindtextdomain()
; return 0; }
(end of "config.log")
*** Error code 1
Stop in /usr/ports/www/mod_php4.
*** Error code 1
Stop in /usr/ports/www/mod_php4.
--
summary: when i install with openssl i get error:
SSL: couldn't create a context
and i cannot install without openssl. please help me!
--
Edit this bug report at http://bugs.php.net/?id=14919&edit=1
Bug #15217 Updated: syntax error before `va_list'
ID: 15217 Updated by: [EMAIL PROTECTED] -Summary: syntax error before `va_list' Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: FreeBSD PHP Version: 4.1.1 New Comment: works fine in FreeBSD 4.5 Previous Comments: [2002-01-25 01:16:07] [EMAIL PROTECTED] I run ./configure and whether or not I pass arguments I receive this error on 'make'. This is the very first step in the build: Making all in Zend /bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../main -I../TSRM -g -O2 -prefer-non-pic -static -c zend_language_parser.c In file included from zend.h:164, from zend_compile.h:24, from zend_language_parser.c:148: zend_hash.h:119: syntax error before `va_list' In file included from zend.h:165, from zend_compile.h:24, from zend_language_parser.c:148: zend_llist.h:34: syntax error before `va_list' In file included from zend_compile.h:24, from zend_language_parser.c:148: zend.h:247: syntax error before `va_list' zend.h:378: syntax error before `va_list' *** Error code 1 Stop in /usr/sources/php-4.1.1/Zend. *** Error code 1 Stop in /usr/sources/php-4.1.1. Some previous bug reports I've seen were similar, but for previous versions. I tried some code edits anyway, with their ideas in mind, but to no avail. I'm starting to think my FreeBSD 4.4 STABLE build is broken. Thanks in advance :-) -- Edit this bug report at http://bugs.php.net/?id=15217&edit=1
Bug #15772 Updated: PHP is developed and maintained by morons
ID: 15772
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: *General Issues
Operating System: all
PHP Version: 4.0.6
New Comment:
> Fuck you ...php
This posting is most probably a fake, cause there is
noone at [EMAIL PROTECTED]
And for the rest of the trolls:
The patch from [EMAIL PROTECTED] will not be applied.
All his claims were as bogus as his patch.
He just added lots of redundant code. And the best:
In his patch every single variable is double freed.
You know how dangerous that is...
Previous Comments:
[2002-03-02 15:56:21] [EMAIL PROTECTED]
Fuck you ...php
[2002-03-01 07:03:10] [EMAIL PROTECTED]
I have had a long look at rfc1867.c v 1.71.2.2 2002/02/21
from a download of php4.1.2 today (1 Mar 10:00 CET). There are a large
number of dubious cases of handling of the buffer being processed. The
following diffs address most of these (I believe). I am posting the
patches to the php-dev list, since it's difficult if not impossible to
create a properfly formatted diff in this edit window.
[2002-02-28 17:50:58] [EMAIL PROTECTED]
How about this patch:
--- main/rfc1867.c.orig Thu Feb 28 14:08:25 2002
+++ main/rfc1867.c Thu Feb 28 14:33:03 2002
@@ -163,20 +163,28 @@
SAFE_RETURN;
}
/* some other headerfield
found, skip it */
- loc = (char *) memchr(ptr,
'\n', rem)+1;
+ loc = (char *) memchr(ptr,
'\n', rem);
if (!loc) {
/* broken */
php_error(E_WARNING,
"File Upload Mime headers garbled ptr: [%c%c%c%c%c]", *ptr, *(ptr + 1),
*(ptr + 2), *(ptr
+ 3), *(ptr + 4));
SAFE_RETURN;
}
+ else
+ {
+ loc++;
+ }
while (*loc == ' ' || *loc ==
'\t') {
/* other field is
folded, skip it */
- loc = (char *)
memchr(loc, '\n', rem-(loc-ptr))+1;
+ loc = (char *)
memchr(loc, '\n', rem-(loc-ptr));
if (!loc) {
/* broken */
php_error(E_WARNING, "File Upload Mime headers garbled ptr:
[%c%c%c%c%c]", *ptr, *(ptr + 1), *(ptr +
2), *(ptr + 3), *(ptr + 4));
SAFE_RETURN;
}
+ else
+ {
+ loc++;
+ }
}
rem -= (loc - ptr);
ptr = loc;
@@ -232,6 +240,10 @@
* pre 4.0.6 code here
*/
loc2 = memchr(loc + 1, '\n',
rem);
+ if (!loc2) {
+ php_error(E_WARNING,
"File Upload Mime headers - no newline");
+ SAFE_RETURN;
+ }
rem -= (loc2 - ptr) + 1;
ptr = loc2 + 1;
/* is_arr_upload is true when
name of file upload field
[2002-02-28 05:06:42] [EMAIL PROTECTED]
You are again wrong, cnt must be supplied.
I advise you to think before you speak.
A POST fileupload block can have lots of '\0's in it.
Without the number of bytes it would be impossibe to
handle such a block.
[2002-02-28 04:59:29] [EMAIL PROTECTED]
I'll admit that I did not examine the rest of the program to see if the
buffer was '\0'-terminated, however if it is, it's not just me that
thought it wasn't - whoever wrote the routine thought it wasn't eith
Bug #10108 Updated: cc 1501:218 file XXX contains an incorrect file suffix
ID: 10108 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: AIX V4.3.3 PHP Version: 4.0.6 New Comment: One last request, can you please try the latest PHP Release (4.1.2 at this time). A lot of fixes occured between 4.0.6 and 4.1 series. Previous Comments: [2001-09-10 05:11:10] [EMAIL PROTECTED] i have installed libtool 1.4 and have got the same problem. Michael [2001-08-31 08:58:45] [EMAIL PROTECTED] Have you tried using GCC ? Also, could you try with latest CVS snapshot: http://snaps.php.net/ as we now use libtool 1.4 it might have fixed some issues with AIX. --Jani [2001-08-31 08:32:50] [EMAIL PROTECTED] I tried the latest version : php-4.0.6. Got always the same problem. MichaeL [2001-06-20 10:13:46] [EMAIL PROTECTED] Try this link: www.php.net/~andi/php-4.0.6RC4.tar.gz [2001-06-20 10:06:38] [EMAIL PROTECTED] get this one: http://www.php.net/~andi/php-4.0.6RC4.tar.gz 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/10108 -- Edit this bug report at http://bugs.php.net/?id=10108&edit=1
Bug #11313 Updated: XML module not linked as 'shared'
ID: 11313 Updated by: [EMAIL PROTECTED] -Summary: XML module not linked as 'shared' Reported By: [EMAIL PROTECTED] -Status: Analyzed +Status: Closed Bug Type: Compile Failure Operating System: RH 7.0 PHP Version: 4.0.5 New Comment: This bug has been fixed in CVS. Previous Comments: [2001-08-18 15:33:09] [EMAIL PROTECTED] I tested this with latest CVS and it doesn't work in it either. --Jani [2001-06-06 11:44:42] [EMAIL PROTECTED] If you compile XML support as a shared module (./configure ... --with-xml=shared ...), all does compile fine but when you access any of the PHP XML functions you get the following type of error "Cant load module xml.so, no such function php_xml_parser_create". It turns out the the new config.m4 and Makefile.in in ext/xml dont seem to work. I copied across these files from PHP4.0.4pl1 and all is fine. Thats the only fix I have for now. -- Edit this bug report at http://bugs.php.net/?id=11313&edit=1
Bug #13798 Updated: Compilation error with oracle
ID: 13798 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: SYSTEM V PHP Version: 4.0.6 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". can you please try a recent release? Previous Comments: [2001-10-23 07:30:38] [EMAIL PROTECTED] I want to install PHP-4.0.6 on my system (SYSTEM V NCR) with apache-1.3.19. I use this command : ./configure --without-mysql --with-oracle --with-apache=../apache_1.3.19 --enable-track-vars This product this debug.log : m -ldl -lnsl -lsocket 1>&5 NCR High Performance C Compiler R3.0c (c) Copyright 1994-98, NCR Corporation (c) Copyright 1987-98, MetaWare Incorporated UX:ld: WARNING: /usr/lib/libresolv.so: warning: attempted multiple inclusion of file UX:ld: WARNING: /usr/lib/libresolv.so: warning: attempted multiple inclusion of file UX:ld: WARNING: /usr/lib/libnsl.so: warning: attempted multiple inclusion of fil e UX:ld: WARNING: /usr/lib/libsocket.so: warning: attempted multiple inclusion of file dynamic linker : ./conftest : error opening libclntsh.so.1.0 And produce this errors in the config.log file : -- configure:1916: checking whether cc accepts -g configure:1948: checking how to run the C preprocessor configure:1969: cc -E conftest.c >/dev/null 2>conftest.out NCR High Performance C Compiler R3.0c (c) Copyright 1994-98, NCR Corporation (c) Copyright 1987-98, MetaWare Incorporated configure: failed program was: #line 1963 "configure" #include "confdefs.h" #include Syntax Error configure:1986: cc -E -traditional-cpp conftest.c >/dev/null 2>conftest.out (cc:) Warning: -a (within -traditional-cpp) is not a recognizable option. (cc:) Warning: -d (within -traditional-cpp) is not a recognizable option. (cc:) Warning: -i (within -traditional-cpp) is not a recognizable option. (cc:) Warning: -i (within -traditional-cpp) is not a recognizable option. (cc:) Warning: -o (within -traditional-cpp) is not a recognizable option. (cc:) Warning: -n (within -traditional-cpp) is not a recognizable option. (cc:) Warning: -a (within -traditional-cpp) is not a recognizable option. (cc:) Warning: -l (within -traditional-cpp) is not a recognizable option. And next : configure:2455: cc -c conftest.c 1>&5 NCR High Performance C Compiler R3.0c (c) Copyright 1994-98, NCR Corporation (c) Copyright 1987-98, MetaWare Incorporated configure:2572: cc -o conftestconftest.c 1>&5 NCR High Performance C Compiler R3.0c (c) Copyright 1994-98, NCR Corporation (c) Copyright 1987-98, MetaWare Incorporated E "/usr/include/pthread.h",L110/C1: Can't open "dce/cma.h": No such file or directory w (#657): (info) How referenced files were included: |File /usr/include/pthread.h from configure. Unable to proceed Aborting(21)... configure: failed program was: #line 2554 "configure" -- When I run make, i have this mistake --- Making all in posix cc -I. -I/app/apache/php-4.0.6/ext/posix -I/app/apache/php-4.0.6/main - I/app/apache/php-4.0.6 -I/app/apache/apache_1.3.19/src/include -I/app/apache/apa che_1.3.19/src/os/unix -I/app/apache/php-4.0.6/Zend -I/app/oracle/product/734/rd bms/public -I/app/oracle/product/734/rdbms/demo -I/app/oracle/product/734/networ k/public -I/app/apache/php-4.0.6/ext/xml/expat/xmltok -I/app/apache/php-4.0.6/ex t/xml/expat/xmlparse -I/app/apache/php-4.0.6/TSRM -DSUPPORT_UTF8 -DXML_BYTE_ORD ER=21 -c posix.c && touch posix.lo NCR High Performance C Compiler R3.0c (c) Copyright 1994-98, NCR Corporation (c) Copyright 1987-98, MetaWare Incorporated w "/app/apache/php-4.0.6/Zend/zend_execute.h",L185/C5(#257):'=' encountered where '==' may have been intended. w "/app/apache/php-4.0.6/Zend/zend_execute.h",L198/C4(#257):'=' encountered where '==' may have been intended. w "/app/apache/php-4.0.6/ext/standard/php_string.h",L125/C5(#257): '=' enco untered where '==' may have been intended. E "posix.c",L357/C17(#237): NGROUPS_MAX: Identifier is undeclared. E "posix.c",L357/C9(#445): gidlist |Type of variable is an array of zero length. E "posix.c",L361/C21(#237): NGROUPS_MAX: Identifier is undeclared. w (#657): (info) How referenced files were included: |File /app/apache/php-4.0.6/Zend/zend_execute.h from /app/apache
Bug #14027 Updated: missing parameter
ID: 14027 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: Irix 5.3 PHP Version: 4.0.6 New Comment: This bug has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2001-11-12 06:44:10] [EMAIL PROTECTED] in main/main.c line 560 on IRIX 5.3 the function asctime_r takes 3 parameter: char *asctime_r (const struct tm *tm, char *buf, int buflen); Irix 6.5 is o.k. with 2 parameters. after adding the third paramter the system compiled fine and works well! -- Edit this bug report at http://bugs.php.net/?id=14027&edit=1
Bug #14557 Updated: Compile Failure (and potential fix)
ID: 14557 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed Bug Type: Compile Failure Operating System: MacOS X (10.1.1) PHP Version: 4.1.0 Assigned To: kalowsky Previous Comments: [2002-03-03 02:07:54] [EMAIL PROTECTED] Thank you for the submission of this. have you sent an email to the libtool group yet informing them of your findings as well? It might be useful :) Assigning to myself to keep me working on a proper fix. [2001-12-17 01:07:07] [EMAIL PROTECTED] Oops! One more thing! The full text of the tcsh script I'm using is available at http://leraz.dhs.org:8080/~squasar/ manual_php_compile.txt and a script which outputs a phpinfo() is available at http://leraz.dhs.org:8080/ ~squasar/info.php [2001-12-17 01:04:07] [EMAIL PROTECTED] (Incidently, I want to note that most of the problems with the compile seem to stem from libtool, which evidently has no clue what the heck it's doing.) [2001-12-17 01:01:26] [EMAIL PROTECTED] The compile of PHP 4.1.0 (source tarball) fails miserably out-of-the-box on MacOS X 10.1.1. The CGI version seems mostly alright, but the Apache DSO is a dismal mess. I'm running the latest released Apache (1.3.22). Also, I'm working with the CC shipped by Apple for OS X (this failed even MORE miserably with my compiled version of GCC, which is expected since OS X isn't supported by GCC yet) After some 5 days of wrestling, writing manual compiles, and running make -n and libtool --dry-run to get some idea of what the compilation is doing, I finally got it to work properly via writing a tcsh script that manually compiles the files involved (My configure is "./configure --with- apxs=/usr/sbin/apxs --enable-ftp --enable-mbstring -- enable-mbstr-enc-trans --with-mysql=/usr/local --enable- sockets --with-tsrm-pthreads --enable-ctype --with-zlib -- prefix=/usr --sysconfdir=/etc --localstatedir=/var -- mandir=/usr/share/man"). Instead of filling this text box beyond its buffer with the entire script (which gets a bit long in the tooth, obviously), here's a summary of what options it uses: cc command when compiling normal source files: /usr/bin/cc -dynamic -fPIC -fno-common -traditional-cpp -O2 -I(all the various include dirs) -D(all the various defines) -c (source file).c -o (source file).lo ld command when combining the .lo files in a dir into a .a: /usr/bin/ld -r -o lib(dir name).a (all the objects from the dir) cc command for creating the final libphp4.so: /usr/bin/cc - bundle -bundle_loader /usr/sbin/httpd -flat_namespace - undefined warning -lm -lz -L/usr/local/lib/mysql - lmysqlclient -o libphp4.so (all the .a's compiled above) # for this one, note that the -L and -l for mysql only apply for compiling with a non-bundled libmysql Putting all this together into a tcsh script gave me a successful PHP compile, and adding the appropriate install command (/usr/sbin/apxs -S LIBEXECDIR="/usr/libexec/httpd" -i -a -n php4 libphp4.so) gave me a working Apache + PHP 4.1.0 + MySQL. My humble suggestion is that whoever maintains the autoconf script for PHP use this information to make a normal ./configure work under Darwin. (incidently, `uname -a` == Darwin hostname 5.1 Darwin Kernel Version 5.1: Tue Oct 30 00:06:34 PST 2001; root:xnu/ xnu-201.5.obj~1/RELEASE_PPC Power Macintosh powerpc). Thanks :) -- Edit this bug report at http://bugs.php.net/?id=14557&edit=1
Bug #15081 Updated: Cannot load /usr/lib/libphp4.so into server : /usr/lib/apache/libphp4.so
ID: 15081 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *Compile Issues Operating System: redhat 7.2 PHP Version: 4.1.0 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Previous Comments: [2002-01-17 06:35:47] [EMAIL PROTECTED] Sorry having the some problem this is the error I get when trying to start apache Cannot load /usr/lib/libphp4.so into server : /usr/lib/apache/libphp4.so : undefined symbol : ap_block_alarms I Have try running ./configure --help | grep apxs2 This is what I get from this command -with-apxs2[=FILE] Build shared Apache 2.0 module. FILE is the optional Thankyou for your help secco -- Edit this bug report at http://bugs.php.net/?id=15081&edit=1
