#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=35861&edit=1
#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=35861&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35861&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35861&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35861&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35861&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35861&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35861&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35861&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35861&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35861&r=support
Expected behavior:http://bugs.php.net/fix.php?id=35861&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35861&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35861&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35861&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35861&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35861&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35861&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35861&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35861&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35861&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35861&r=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:
---
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=30973&edit=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:
---
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=30973&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30973&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=30973&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=30973&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30973&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30973&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30973&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30973&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30973&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30973&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30973&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=30973&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=30973&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30973&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30973&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30973&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30973&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30973&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30973&r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30973&r=mysqlcfg
#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=14237&edit=1
