#35861 [NEW]: Segfault with -D_LARGEFILE_SOURCE
From: alberty at neptunelabs dot com
Operating system: Linux i686
PHP version: 4CVS-2005-12-31 (CVS)
PHP Bug Type: Reproducible crash
Bug description: Segfault with -D_LARGEFILE_SOURCE
Description:
Segfault with -D_LARGEFILE_SOURCE
A segfault prevent in the current cvs tree of php 4.4 that you can use PHP
with large files.
If you use these CFLAGS:
CFLAGS=$CFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
PHP crashes on the first GET request. This is a new bug, because in the
first 4.4.2rcX releases PHP works fine.
I've used Apache 2.2.0 (prefork) and PHP 4.4.2cvs.
Best regards,
Steve
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212994816 (LWP 13568)]
0xb78d336d in _zend_is_inconsistent (ht=0x0, file=0xb7a626c8
/usr/src/php_4_4/Zend/zend_hash.c, line=1007) at
/usr/src/php_4_4/Zend/zend_hash.c:94
94 if (ht-inconsistent==HT_OK) {
(gdb) bt
#0 0xb78d336d in _zend_is_inconsistent (ht=0x0, file=0xb7a626c8
/usr/src/php_4_4/Zend/zend_hash.c, line=1007) at
/usr/src/php_4_4/Zend/zend_hash.c:94
#1 0xb78d5c5b in zend_hash_internal_pointer_reset_ex (ht=0x0, pos=0x0) at
/usr/src/php_4_4/Zend/zend_hash.c:1007
#2 0xb78ea291 in apply_config (dummy=0x0) at
/usr/src/php_4_4/sapi/apache2handler/apache_config.c:161
#3 0xb78e97dd in php_handler (r=0x828e688) at
/usr/src/php_4_4/sapi/apache2handler/sapi_apache2.c:487
#4 0x0807c726 in ap_run_handler (r=0x828e688) at config.c:157
#5 0x0807ce5f in ap_invoke_handler (r=0x828e688) at config.c:371
#6 0x080aace3 in ap_process_request (r=0x828e688) at http_request.c:258
#7 0x080a7cbc in ap_process_http_connection (c=0x82885d0) at
http_core.c:171
#8 0x08083e51 in ap_run_process_connection (c=0x82885d0) at
connection.c:43
#9 0x08084255 in ap_process_connection (c=0x82885d0, csd=0x8288438) at
connection.c:178
#10 0x080b8bd6 in child_main (child_num_arg=0) at prefork.c:640
#11 0x080b8cb9 in make_child (s=0x80f1348, slot=0) at prefork.c:680
#12 0x080b91b3 in ap_mpm_run (_pconf=0x80ea0a8, plog=0x8124190,
s=0x80f1348) at prefork.c:956
#13 0x080674ff in main (argc=2, argv=0xbfdd2a94) at main.c:712
--
Edit bug report at http://bugs.php.net/?id=35861edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35861r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35861r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35861r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35861r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35861r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35861r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35861r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35861r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35861r=support
Expected behavior:http://bugs.php.net/fix.php?id=35861r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35861r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35861r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35861r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35861r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35861r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35861r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35861r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35861r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35861r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35861r=mysqlcfg
#35861 [Bgs-Opn]: Segfault with -D_LARGEFILE_SOURCE
ID: 35861
User updated by: alberty at neptunelabs dot com
Reported By: alberty at neptunelabs dot com
-Status: Bogus
+Status: Open
Bug Type: Reproducible crash
Operating System: Linux i686
PHP Version: 4CVS-2005-12-31 (CVS)
New Comment:
Lol,
since eternal times it's implemented in PHP. Please read the first
sentence in the documentation:
http://www.php.net/manual/en/ref.filesystem.php
Previous Comments:
[2005-12-31 17:38:35] [EMAIL PROTECTED]
There never has been any such support in PHP. There's something else
that is getting wrong with that setting.
[2005-12-31 17:25:01] alberty at neptunelabs dot com
Description:
Segfault with -D_LARGEFILE_SOURCE
A segfault prevent in the current cvs tree of php 4.4 that you can use
PHP with large files.
If you use these CFLAGS:
CFLAGS=$CFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
PHP crashes on the first GET request. This is a new bug, because in the
first 4.4.2rcX releases PHP works fine.
I've used Apache 2.2.0 (prefork) and PHP 4.4.2cvs.
Best regards,
Steve
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212994816 (LWP 13568)]
0xb78d336d in _zend_is_inconsistent (ht=0x0, file=0xb7a626c8
/usr/src/php_4_4/Zend/zend_hash.c, line=1007) at
/usr/src/php_4_4/Zend/zend_hash.c:94
94 if (ht-inconsistent==HT_OK) {
(gdb) bt
#0 0xb78d336d in _zend_is_inconsistent (ht=0x0, file=0xb7a626c8
/usr/src/php_4_4/Zend/zend_hash.c, line=1007) at
/usr/src/php_4_4/Zend/zend_hash.c:94
#1 0xb78d5c5b in zend_hash_internal_pointer_reset_ex (ht=0x0, pos=0x0)
at /usr/src/php_4_4/Zend/zend_hash.c:1007
#2 0xb78ea291 in apply_config (dummy=0x0) at
/usr/src/php_4_4/sapi/apache2handler/apache_config.c:161
#3 0xb78e97dd in php_handler (r=0x828e688) at
/usr/src/php_4_4/sapi/apache2handler/sapi_apache2.c:487
#4 0x0807c726 in ap_run_handler (r=0x828e688) at config.c:157
#5 0x0807ce5f in ap_invoke_handler (r=0x828e688) at config.c:371
#6 0x080aace3 in ap_process_request (r=0x828e688) at
http_request.c:258
#7 0x080a7cbc in ap_process_http_connection (c=0x82885d0) at
http_core.c:171
#8 0x08083e51 in ap_run_process_connection (c=0x82885d0) at
connection.c:43
#9 0x08084255 in ap_process_connection (c=0x82885d0, csd=0x8288438) at
connection.c:178
#10 0x080b8bd6 in child_main (child_num_arg=0) at prefork.c:640
#11 0x080b8cb9 in make_child (s=0x80f1348, slot=0) at prefork.c:680
#12 0x080b91b3 in ap_mpm_run (_pconf=0x80ea0a8, plog=0x8124190,
s=0x80f1348) at prefork.c:956
#13 0x080674ff in main (argc=2, argv=0xbfdd2a94) at main.c:712
--
Edit this bug report at http://bugs.php.net/?id=35861edit=1
#30973 [NEW]: segfault when accessing wrong url and get CURLINFO_CONTENT_TYPE
From: alberty at neptunelabs dot com
Operating system: linux_i686
PHP version: 4.3.9
PHP Bug Type: cURL related
Bug description: segfault when accessing wrong url and get
CURLINFO_CONTENT_TYPE
Description:
If you get a wrong url and get the content type via curl_getinfo($ch,
CURLINFO_CONTENT_TYPE); the cURL extention crashes with a segfault.
patch:
1213c1213,1215
RETURN_STRING(s_code, 1);
---
if (s_code){
RETURN_STRING(s_code, 1);
}
Regards,
Steve
Reproduce code:
---
?php
$ch = curl_init ('http://www.totallywrongdomain.com/');
if ($ch){
$result=curl_exec ($ch);
$returnvalue['content_type']=curl_getinfo($ch, CURLINFO_CONTENT_TYPE);
curl_close ($ch);
}
?
--
Edit bug report at http://bugs.php.net/?id=30973edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30973r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=30973r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=30973r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30973r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30973r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30973r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30973r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30973r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30973r=support
Expected behavior: http://bugs.php.net/fix.php?id=30973r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=30973r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=30973r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30973r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30973r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30973r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30973r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30973r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30973r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30973r=mysqlcfg
#30973 [Opn-Csd]: segfault when accessing wrong url and get CURLINFO_CONTENT_TYPE
ID: 30973
User updated by: alberty at neptunelabs dot com
Reported By: alberty at neptunelabs dot com
-Status: Open
+Status: Closed
Bug Type: cURL related
Operating System: linux_i686
PHP Version: 4.3.9
New Comment:
Okay, i've seen that's fixed in 4.3.10
Previous Comments:
[2004-12-03 10:46:54] alberty at neptunelabs dot com
Description:
If you get a wrong url and get the content type via curl_getinfo($ch,
CURLINFO_CONTENT_TYPE); the cURL extention crashes with a segfault.
patch:
1213c1213,1215
RETURN_STRING(s_code, 1);
---
if (s_code){
RETURN_STRING(s_code, 1);
}
Regards,
Steve
Reproduce code:
---
?php
$ch = curl_init ('http://www.totallywrongdomain.com/');
if ($ch){
$result=curl_exec ($ch);
$returnvalue['content_type']=curl_getinfo($ch,
CURLINFO_CONTENT_TYPE);
curl_close ($ch);
}
?
--
Edit this bug report at http://bugs.php.net/?id=30973edit=1
#14237 [Bgs-Opn]: reference calls in some cases very slow
ID: 14237
User updated by: alberty at neptunelabs dot com
Reported By: alberty at neptunelabs dot com
-Status: Bogus
+Status: Open
Bug Type: Performance problem
Operating System: i686-pc-linux-gnu
PHP Version: 4.1.0
New Comment:
I've seen you have close this bug report with an absolute
strange argument.
A switching of two double values in an addition have no
consequences for the sum.
There is no problem with the time between the tests.
Why do you don't test the example script and why do you
close this bug report without any questions, although many
people have also report this behavior?
Reopen, and please, don't touch any bug reports before you
check the consequences.
Previous Comments:
[2003-01-04 11:37:14] [EMAIL PROTECTED]
I modified the script a bit by adding var_dump(microtime())
around the function calls. The output :
With reference:
string(21) 0.58075200 1041701482
string(21) 0.20217700 1041701490
Without reference:
string(21) 0.20247500 1041701490
string(21) 0.20739800 1041701490
as everyone may see without reference is faster as it has to be
(according to some docs). I think that there is something wrong in the
way the script computes the time.
Ooops, I found it :
$tmp = explode(' ', microtime());
$measure['Start Reference']=(double)$tmp[0] + (double)$tmp[1];
the indexes are swapped must be
$measure['Start Reference']=(double)$tmp[1] + (double)$tmp[0];
Closing this.
[2002-01-31 05:12:55] bs_php at infeer dot com
I did some benchmark tests on loops and so that also delever some
strange results.
See it run at: http://phpxpath.sourceforge.net/benchmark/phpBench.php
Code at: http://phpxpath.sourceforge.net/benchmark/phpBench.php.txt
[2001-12-13 04:47:07] alberty at neptunelabs dot com
I think, this is an very annoying behavior of the zend engine and also
there are no warning or clue in the documentation.
Someone must change it.
[2001-12-12 20:06:28] [EMAIL PROTECTED]
That's a known issue with the current Zend Engine.
We could move it to a ZE feature request, but will it change anything
soon? I doubt ...
[2001-12-12 19:59:37] [EMAIL PROTECTED]
PHP Version updated to 4.1.0
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/14237
--
Edit this bug report at http://bugs.php.net/?id=14237edit=1
#20134 [NEW]: read from UDP results wrong data
From: [EMAIL PROTECTED]
Operating system: i686-pc-linux-gnu
PHP version: 4CVS-2002-10-28
PHP Bug Type: Sockets related
Bug description: read from UDP results wrong data
Hi,
If you open an UDP connection to a non open udp port
with fsockopen, fread reads the requested length, but
the content is sometimes wrong (nonsensical data)
This short script demonstrate the problem:
?php
header ('Cache-Control: no-store, no-cache, must-revalidate, post-check=0,
pre-check=0, no-risk, no-fun');
header ('Pragma: no-cache');
// Please replace the ip address with an existing host
$fp = fsockopen(udp://192.168.0.1, 4, $errno, $errstr);
if (!$fp) {
echo ERROR: $errno - $errstrbr\n;
}
else {
fwrite($fp,\n);
$content=fread($fp, 40);
echo hrread length: .strlen($content).hr;
echo $content.hr;
echo bin2hex($content).hr;
fclose($fp);
}
echo Finished @ .time();
?
I've test it with the lastest cvs version (28.10.2002)
Regards,
Steve
--
Edit bug report at http://bugs.php.net/?id=20134edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20134r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20134r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20134r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20134r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20134r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20134r=support
Expected behavior: http://bugs.php.net/fix.php?id=20134r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20134r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20134r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20134r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20134r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20134r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20134r=isapi
#19324 [Com]: show PHP source on client's browser
ID: 19324 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Output Control Operating System: Solaris8 x86 PHP Version: 4.2.3 New Comment: Hi , I have a small question to this bug, because I have the same problem. 1. stop apache 2. start apache in single process mode like: /path/to/apache/httpd -X 3. Request a page from a vhost/directory where PHP is enabled 4. Do that again :) 5. Request a page from a vhost/directory where PHP is disabled 6. Request a page from a vhost/directory where PHP is enabled (but not explicit with php_engine = on, just the 'default') 7. Request a page from a vhost/directory where PHP is enabled (implicit wirth php_engine = on) Please tell us when you see the source and when not. Test 3 and 4 with explicit php_engine directive or not (the same as 6)? However, with php_engine=on in a virtualhostlocation and also a concurrently php_engine off directive in another virtualhost, Apache results always the source code on my virtualhost with php_engine=on. Regards, -- Steve Previous Comments: [2002-09-30 03:27:58] [EMAIL PROTECTED] Will it fixed at next version? [2002-09-30 00:27:36] [EMAIL PROTECTED] Did you do the tests I asked you to do? Derick [2002-09-29 20:27:05] [EMAIL PROTECTED] No wonder the situation never arises in Apache2 . I haven't used php_engine=off in httpd.conf (Apache2 will report config error ! It doesn't know the instruct .) So, I just use AddType text/html .php to replace php_engine=off. It's work ! No showing source arise, and some directory can disable PHP. Thanks your help. [2002-09-28 12:36:59] [EMAIL PROTECTED] Okay, looks like an old bug resurfaced. Can you do the following test, and stick to it very precise: 1. stop apache 2. start apache in single process mode like: /path/to/apache/httpd -X 3. Request a page from a vhost/directory where PHP is enabled 4. Do that again :) 5. Request a page from a vhost/directory where PHP is disabled 6. Request a page from a vhost/directory where PHP is enabled (but not explicit with php_engine = on, just the 'default') 7. Request a page from a vhost/directory where PHP is enabled (implicit wirth php_engine = on) Please tell us when you see the source and when not. regards, Derick [2002-09-28 09:55:58] [EMAIL PROTECTED] Yes, I do. But I use Location tag to include it. because I want to make PHP can't work in some directories. Why the showing source arise randomly ? If I can't use php_engine=off , how I disable PHP in some directories, please ? 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/19324 -- Edit this bug report at http://bugs.php.net/?id=19324edit=1
#19324 [Com]: show PHP source on client's browser
ID: 19324 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Output Control Operating System: Solaris8 x86 PHP Version: 4.2.3 New Comment: 3. showing source code 4. showing source code 5. showing source code 6. no source code 7. showing source code Previous Comments: [2002-09-30 05:53:45] [EMAIL PROTECTED] 3 and 4 with the php_engine = on directive please (explicit). Derick [2002-09-30 05:50:54] [EMAIL PROTECTED] Hi , I have a small question to this bug, because I have the same problem. 1. stop apache 2. start apache in single process mode like: /path/to/apache/httpd -X 3. Request a page from a vhost/directory where PHP is enabled 4. Do that again :) 5. Request a page from a vhost/directory where PHP is disabled 6. Request a page from a vhost/directory where PHP is enabled (but not explicit with php_engine = on, just the 'default') 7. Request a page from a vhost/directory where PHP is enabled (implicit wirth php_engine = on) Please tell us when you see the source and when not. Test 3 and 4 with explicit php_engine directive or not (the same as 6)? However, with php_engine=on in a virtualhostlocation and also a concurrently php_engine off directive in another virtualhost, Apache results always the source code on my virtualhost with php_engine=on. Regards, -- Steve [2002-09-30 03:27:58] [EMAIL PROTECTED] Will it fixed at next version? [2002-09-30 00:27:36] [EMAIL PROTECTED] Did you do the tests I asked you to do? Derick [2002-09-29 20:27:05] [EMAIL PROTECTED] No wonder the situation never arises in Apache2 . I haven't used php_engine=off in httpd.conf (Apache2 will report config error ! It doesn't know the instruct .) So, I just use AddType text/html .php to replace php_engine=off. It's work ! No showing source arise, and some directory can disable PHP. Thanks your help. 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/19324 -- Edit this bug report at http://bugs.php.net/?id=19324edit=1
Bug #16985: register vars wrong
From: [EMAIL PROTECTED] Operating system: i686-pc-linux-gnu PHP version: 4.0CVS-2002-05-03 PHP Bug Type: Variables related Bug description: register vars wrong Hi, i have detect a different behavior between register variables in the current cvs tree und PHP 4.2.0 and previously. When i make a request like http://my.testserver/test.php?foo=123lokusbar=456 with version 4.2.0 PHP register: _GET[foo] 123 _GET[bar] 456 with the current cvs tree from 2. May 2002 PHP results: _GET[foo] 123 _GET[lokus] I think this behavior is not wanted. Regards, Steve -- Edit bug report at http://bugs.php.net/?id=16985edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16985r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16985r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16985r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16985r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16985r=support Expected behavior: http://bugs.php.net/fix.php?id=16985r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16985r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16985r=submittedtwice
Bug #16640: set_error_handler and oversized upload
From: [EMAIL PROTECTED]
Operating system: i686-pc-linux-gnu
PHP version: 4.0CVS-2002-04-16
PHP Bug Type: Scripting Engine problem
Bug description: set_error_handler and oversized upload
Hi,
in the documentation to set_error_handler() is declared that
an own error handler completely bypassed the php error functions.
But if i limit the post upload size with post_max_size and post a file
with a bigger size as the limit, php results a warning like
'Warning: POST Content-Length of 8796223 bytes exceeds the limit of
8388608 bytes in Unknown on line 0'
and the error handler is not affected!!!
Is this an error by design, because the script is in this case not
affected and not executed?
Here a test script:
---snip---
?php
function my_error_handler ($errno, $errstr, $errfile, $errline) {
echo error handler call;
}
set_error_handler('my_error_handler');
?
hrUpload Test Form
form name=uploadform enctype=multipart/form-data method=post
action=error_handler_test.php
input type=file name=checkfile size=50 accept=text/html
input type=submit value=upload
/form
---snap---
Regards,
Steve
--
Edit bug report at http://bugs.php.net/?id=16640edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16640r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16640r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16640r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16640r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16640r=support
Expected behavior: http://bugs.php.net/fix.php?id=16640r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16640r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16640r=submittedtwice
Bug #16570 Updated: error control operator and set_error_handler()
ID: 16570
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: i686-pc-linux-gnu
PHP Version: 4.0CVS-2002-04-12
New Comment:
sorry, my mistake.
Previous Comments:
[2002-04-12 17:08:33] [EMAIL PROTECTED]
Not a bug. If @ is used, error_reporting is set to 0.
You need to take care of it yourself in your error handler
function if you don't want to show errors in that case.
This is done this way to let users have as much control
as possible in their own error handlers.
And it is documented here:
http://www.php.net/manual/en/function.set-error-handler.php
--Jani
[2002-04-12 12:49:16] [EMAIL PROTECTED]
Hi,
the @ Error Control Operator doesnt suppress warnings
(e.g.:E_WARNING),
if an own error handler is declared.
the follow code snip demonstrate the problem:
?php
error_reporting(E_ALL);
function error_handler ($errno, $errstr, $errfile, $errline) {
echo $errstr brin $errfilebrline $errlinebr;
}
$old_error_handler = set_error_handler('error_handler');
$dbconnect=@mysql_pconnect('foobar-server', 'bart', 'simson');
?
I think this is a bug, because this behavior is not documented.
Regards,
Steve
--
Edit this bug report at http://bugs.php.net/?id=16570edit=1
Bug #16570: error control operator and set_error_handler()
From: [EMAIL PROTECTED]
Operating system: i686-pc-linux-gnu
PHP version: 4.0CVS-2002-04-12
PHP Bug Type: *Programming Data Structures
Bug description: error control operator and set_error_handler()
Hi,
the @ Error Control Operator doesnt suppress warnings (e.g.:E_WARNING),
if an own error handler is declared.
the follow code snip demonstrate the problem:
?php
error_reporting(E_ALL);
function error_handler ($errno, $errstr, $errfile, $errline) {
echo $errstr brin $errfilebrline $errlinebr;
}
$old_error_handler = set_error_handler('error_handler');
$dbconnect=@mysql_pconnect('foobar-server', 'bart', 'simson');
?
I think this is a bug, because this behavior is not documented.
Regards,
Steve
--
Edit bug report at http://bugs.php.net/?id=16570edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16570r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16570r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16570r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16570r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16570r=support
Expected behavior: http://bugs.php.net/fix.php?id=16570r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16570r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16570r=submittedtwice
Bug #16551: ceil results -0
From: [EMAIL PROTECTED] Operating system: i686-pc-linux-gnu PHP version: 4.0CVS-2002-04-11 PHP Bug Type: Variables related Bug description: ceil results -0 Hi, the follow code results -0, ?php $a=ceil((1/16)-1); echo $a; ? maybe, this is a convertion problem with float types. also, why the ceil() command results a floating point number and not an integer? It makes sense when the ceil command accept a precision like round()... Regards, Steve -- Edit bug report at http://bugs.php.net/?id=16551edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16551r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16551r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16551r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16551r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16551r=support Expected behavior: http://bugs.php.net/fix.php?id=16551r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16551r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16551r=submittedtwice
