[PHP-BUG] Req #65577 [NEW]: session_start() file:line of call just like header()
From: ly...@php.net Operating system: N/A PHP version: Irrelevant Package: Unknown/Other Function Bug Type: Feature/Change Request Bug description:session_start() file:line of call just like header() Description: When the first output happens, there is a record of that in PHP core. Then, the error message for the header() that follows output can tell the programmer exactly where in their mass of code the output started. While not quite the same scope, in a large code base, even grepping for session_start() is going to have a lot of hits. Would it be hard to notate where session_start() got called, and include in the error message... -- Edit bug report at https://bugs.php.net/bug.php?id=65577&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65577&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65577&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65577&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65577&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65577&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65577&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65577&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65577&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65577&r=support Expected behavior: https://bugs.php.net/fix.php?id=65577&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65577&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65577&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65577&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65577&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65577&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65577&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65577&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65577&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65577&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65577&r=mysqlcfg
Req #60075 [Com]: using -t /myPath does not add /myPath to include_path
Edit report at https://bugs.php.net/bug.php?id=60075&edit=1
ID: 60075
Comment by: ly...@php.net
Reported by:paul dot a dot norman at gmail dot com
Summary:using -t /myPath does not add /myPath to
include_path
Status: Assigned
Type: Feature/Change Request
Package:Built-in web server
Operating System: Win32
PHP Version:5.4.0beta1
Assigned To:moriyoshi
Block user comment: N
Private report: N
New Comment:
You don't need a new flag.
php -B ini_set('include_path', get_include_path() . PATH_SEPARATOR . '/myPath')
NOTE:
Never used -B, so maybe you need "" around it or whatever, but you get the
point.
Previous Comments:
[2012-03-08 05:09:14] reeze dot xia at gmail dot com
Hi, Stuart
I think add doc-root to include_path may impact the behavior of your
application, because this changes the include path of your application too.
maybe some application didn't add docroot to it's include_path , but the server
add it. (include require autoload etc.).
if you just want to set router script easily, I don't think it deserve the
change. And this behavior different with the way we use cli tools:
ie:
$ ls -l file.php
just print the information of $PWD's file.php but not some other folder's
file.php. This is confusing
If we want to add include path maybe a new option like -I /new/include/path
maybe useful.
so -1 for me ;-)
Thanks.
reeze
[2012-03-04 18:04:05] stuart at 3ft9 dot com
This is my first patch so I may have missed something. This patch simply
prepends
the document root to include_path for each request.
[2011-10-17 07:59:21] paul dot a dot norman at gmail dot com
Description:
If the php internal server is launched using php -S localhost:8001 -t /myPath
server_process.php
and server_process.php is in /myPath the following would result
Warning: Unknown: failed to open stream: No such file or directory in Unknown
on
line 0
Fatal error: Unknown: Failed opening required 'server_process.php'
(include_path='.;C:\php\pear') in Unknown on line 0
Obviously using: ... -t /myPath /myPath/server_process.php
works as expected,
but it would seem intuitive that when using:
php -S localhost:8001 -t something
that "something" would be automatically added to the include_path ?
P.S. the php internal server is a brilliant addition, facilitates making
virtual
desktop applications in the browser a cinch! Allows the leveraging of browser
technology jQuery and all the rest with php on the client -- very powerful!!!
Add in http://gluescript.sourceforge.net/ http://gtk.php.net/ or simillar for
local wxWdiget dialogues called as necessary from php
http://php.net/manual/en/function.system.php and an almost complete powerful
solution is available.
Paul
--
Edit this bug report at https://bugs.php.net/bug.php?id=60075&edit=1
[PHP-BUG] Bug #65193 [NEW]: openssl_private_encrypt OAEP only works AFTER PKCS1
From: ly...@php.net
Operating system: CentOS 2.6.18
PHP version: 5.3.26
Package: OpenSSL related
Bug Type: Bug
Bug description:openssl_private_encrypt OAEP only works AFTER PKCS1
Description:
A call to openssl_private_encrypt(..., OPENSSL_PKCS1_OAEP_PADDING) fails
unless you call it AFTER openssl_private_encrypt(...,
OPENSSL_PKCS1_PADDING)
Test script:
---
$private_key_text = file_get_contents('private.pem');
openssl_private_encrypt($decrypted_message, $encrypted_message,
$private_key_text, OPENSSL_PKCS1_OAEP_PADDING);
echo "PKCS1_OAEP fails:\n";
var_dump(base64_encode($encrypted_message));
echo "\n";
openssl_private_encrypt($decrypted_message, $encrypted_message,
$private_key_text, OPENSSL_PKCS1_PADDING);
echo "PKCS1 works:\n";
var_dump(base64_encode($encrypted_message));
echo "\n";
openssl_private_encrypt($decrypted_message, $encrypted_message,
$private_key_text, OPENSSL_PKCS1_OAEP_PADDING);
echo "PKCS1_OAEP works only AFTER PKCS1:\n";
var_dump(base64_encode($encrypted_message));
echo "\n";
Expected result:
All three outputs the same.
Actual result:
--
First output is blank string.
--
Edit bug report at https://bugs.php.net/bug.php?id=65193&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65193&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65193&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65193&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65193&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65193&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65193&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65193&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65193&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65193&r=support
Expected behavior: https://bugs.php.net/fix.php?id=65193&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65193&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65193&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65193&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65193&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65193&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65193&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65193&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65193&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65193&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65193&r=mysqlcfg
Bug #65193 [Opn]: openssl_private_encrypt OAEP only works AFTER PKCS1
Edit report at https://bugs.php.net/bug.php?id=65193&edit=1
ID: 65193
User updated by: ly...@php.net
Reported by: ly...@php.net
Summary:openssl_private_encrypt OAEP only works AFTER PKCS1
Status: Open
Type: Bug
Package:OpenSSL related
Operating System: CentOS 2.6.18
-PHP Version:5.3.26
+PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
The PHP Version popup in report form was in a time warp... Corrected here.
OpenSSL version: 0.9.8b
Actual output:
PKCS1_OAEP fails:
string(0) ""
PKCS1 works:
string(172)
"gVJcDQJnKJG7PX3+axZMyjph5xi3TFMLWXY2OLD4d62YYhlAmCUnr+WQP/F6//ykx3L/rXS7zfjXFPoyzn5v7dwysM107fS0tXwzngZ1fRjH5iU+1Dv4TJf4dXRZXzYKClDSSiQ0ZrmoGhVo5wx3PY61mEkBLNbS5IvZ75rCLSo="
PKCS1_OAEP works only AFTER PKCS1:
string(172)
"gVJcDQJnKJG7PX3+axZMyjph5xi3TFMLWXY2OLD4d62YYhlAmCUnr+WQP/F6//ykx3L/rXS7zfjXFPoyzn5v7dwysM107fS0tXwzngZ1fRjH5iU+1Dv4TJf4dXRZXzYKClDSSiQ0ZrmoGhVo5wx3PY61mEkBLNbS5IvZ75rCLSo="
Previous Comments:
----
[2013-07-03 15:04:47] ly...@php.net
Description:
A call to openssl_private_encrypt(..., OPENSSL_PKCS1_OAEP_PADDING) fails
unless you call it AFTER openssl_private_encrypt(..., OPENSSL_PKCS1_PADDING)
Test script:
---
$private_key_text = file_get_contents('private.pem');
openssl_private_encrypt($decrypted_message, $encrypted_message,
$private_key_text, OPENSSL_PKCS1_OAEP_PADDING);
echo "PKCS1_OAEP fails:\n";
var_dump(base64_encode($encrypted_message));
echo "\n";
openssl_private_encrypt($decrypted_message, $encrypted_message,
$private_key_text, OPENSSL_PKCS1_PADDING);
echo "PKCS1 works:\n";
var_dump(base64_encode($encrypted_message));
echo "\n";
openssl_private_encrypt($decrypted_message, $encrypted_message,
$private_key_text, OPENSSL_PKCS1_OAEP_PADDING);
echo "PKCS1_OAEP works only AFTER PKCS1:\n";
var_dump(base64_encode($encrypted_message));
echo "\n";
Expected result:
All three outputs the same.
Actual result:
--
First output is blank string.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65193&edit=1
[PHP-BUG] Bug #61947 [NEW]: curl Segmentation fault
From: Operating system: Linux PHP version: Irrelevant Package: cURL related Bug Type: Bug Bug description:curl Segmentation fault Description: libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 It's PHP 5.1.3, so you may not care, but that's what was handed to me on the GoDaddy server by my client, and I hesitate to upgrade until we take the issue up with GoDaddy first. In the meantime, since I have a stacktrace with at least some debugging symbols in it, and it specifically mentions Curl_cookie_cleanup, I thought it might be something useful, even if it's an older PHP version. curl with CURLOPT_COOKIEJAR and CURLOPT_COOKIE file. I'm using curl_multi functions, so I guess it could be a factor. I'm hitting the same URL with different cookie files and log files, create with tempnam. I would assume that using two curl handles with the same cookie file and/or log file would be a Bad Idea. I have tail all the /tmp/curllog* files. Some are just empty. Others have nothing interesting at the end. I suppose the empty one could be the ones that correspond to the segfaults, but don't quite see how that info would be useful... Unless it narrows down a portion of the code. Test script: --- Could be this one: curl_setopt($curl, CURLOPT_RETURNTRANSFER, TRUE) or ($errors[] = 'RETURNTRANSFER'); curl_setopt($curl, CURLOPT_FOLLOWLOCATION, TRUE) or ($errors[] = 'FOLLOWLOCATION'); curl_setopt($curl, CURLOPT_HEADER, FALSE) or ($errors[] = 'HEADER'); curl_setopt($curl, CURLOPT_HTTPGET, TRUE) or ($errors[] = 'HTTPGET'); curl_setopt($curl, CURLOPT_TIMEOUT, 60) or ($errors[] = 'TIMEOUT'); curl_setopt($curl, CURLOPT_COOKIEFILE, $depart_cookies) or ($errors[] = 'COOKIEFILE'); curl_setopt($curl, CURLOPT_COOKIEJAR, dirname(__FILE__) . "/$direction.txt") or ($errors[] = 'COOKIEJAR'); curl_setopt($curl, CURLOPT_VERBOSE, TRUE) or ($errors[] = 'VERBOSE'); $log = fopen($curllog, 'a+') or ($errors[] = "FOPEN $curllog"); curl_setopt($curl, CURLOPT_STDERR, $log) or ($errors[] = 'STDERR'); Or it could be that one above with the following changes to the $curl handle: curl_setopt($curl, CURLOPT_POST, TRUE); curl_setopt($curl, CURLOPT_POSTFIELDS, $post_data); I will try to error_log something in between to narrow it down. Expected result: PHP to not crash. Actual result: -- *** glibc detected *** /usr/sbin/httpd: free(): corrupted unsorted chunks: 0xb87a8508 *** === Backtrace: = /lib/libc.so.6[0xb7bbd5a5] /lib/libc.so.6(cfree+0x59)[0xb7bbd9e9] /usr/lib/libcurl.so.3[0xb72e37ae] /usr/lib/libcurl.so.3(Curl_cookie_cleanup+0x3a)[0xb72e391a] /usr/lib/libcurl.so.3(Curl_close+0x127)[0xb72f44e7] /usr/lib/libcurl.so.3(curl_easy_cleanup+0x21)[0xb72ff421] /usr/lib/httpd/modules/libphp5.so[0xb7478e77] /usr/lib/httpd/modules/libphp5.so(list_entry_destructor+0xa3)[0xb75dd2c3] /usr/lib/httpd/modules/libphp5.so(zend_hash_del_key_or_index+0x221)[0xb75dc751] /usr/lib/httpd/modules/libphp5.so(_zend_list_delete+0x8a)[0xb75dd55a] /usr/lib/httpd/modules/libphp5.so(_zval_dtor_func+0x9a)[0xb75cfefa] /usr/lib/httpd/modules/libphp5.so(_zval_ptr_dtor+0x78)[0xb75c4598] /usr/lib/httpd/modules/libphp5.so(zend_hash_destroy+0x47)[0xb75da697] /usr/lib/httpd/modules/libphp5.so(_zval_dtor_func+0x50)[0xb75cfeb0] /usr/lib/httpd/modules/libphp5.so(_zval_ptr_dtor+0x78)[0xb75c4598] /usr/lib/httpd/modules/libphp5.so(zend_hash_destroy+0x47)[0xb75da697] /usr/lib/httpd/modules/libphp5.so(_zval_dtor_func+0x50)[0xb75cfeb0] /usr/lib/httpd/modules/libphp5.so(_zval_ptr_dtor+0x78)[0xb75c4598] /usr/lib/httpd/modules/libphp5.so[0xb75da339] /usr/lib/httpd/modules/libphp5.so(zend_hash_graceful_reverse_destroy+0x27)[0xb75da5b7] /usr/lib/httpd/modules/libphp5.so(shutdown_executor+0x485)[0xb75c4d35] /usr/lib/httpd/modules/libphp5.so(zend_deactivate+0xb3)[0xb75d07b3] /usr/lib/httpd/modules/libphp5.so(php_request_shutdown+0x243)[0xb758d1e3] /usr/lib/httpd/modules/libphp5.so[0xb76532dc] /usr/sbin/httpd(ap_run_handler+0x6d)[0xb7f47a4d] /usr/sbin/httpd(ap_invoke_handler+0x73)[0xb7f4b413] /usr/sbin/httpd(ap_process_request+0x1ae)[0xb7f5752e] /usr/sbin/httpd[0xb7f542cf] /usr/sbin/httpd(ap_run_process_connection+0x6d)[0xb7f4f94d] /usr/sbin/httpd(ap_process_connection+0x4c)[0xb7f4fa4c] /usr/sbin/httpd[0xb7f5be14] /usr/sbin/httpd[0xb7f5c121] /usr/sbin/httpd(ap_mpm_run+0x913)[0xb7f5cb23] /usr/sbin/httpd(main+0x8c7)[0xb7f33157] /lib/libc.so.6(__libc_start_main+0xdc)[0xb7b69e9c] /usr/sbin/httpd[0xb7f32221] === Memory map: b3f78000-b3ff6000 rw-s 00:86 1055943031 b3ff6000-b4037000 rw-p b3ff6000 00:00 0 b4038000-b40ba000 rw-p b4038000 00:00 0 b40bb000-b413d000 rw-p b40bb000 00:00 0 b413e000-b41c rw-p b413e000 00:00 0 b41c1000-b4243000 rw-p b41c1000 00:00 0
Bug #61947 [Opn]: curl Segmentation fault
Edit report at https://bugs.php.net/bug.php?id=61947&edit=1 ID: 61947 User updated by: ly...@php.net Reported by: ly...@php.net Summary:curl Segmentation fault Status: Open Type: Bug Package:cURL related Operating System: Linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: It is definitely the second one, with the POST that is crashing. Repeatable. Previous Comments: [2012-05-05 05:00:00] ceo at l-i-e dot com I've got 9 more of these backtraces if you want them. And about 8 of these with no backtrace or anything at all: [Fri May 04 10:59:37 2012] [notice] child pid 24011 exit signal Segmentation fault (11) [Fri May 04 11:10:00 2012] [notice] child pid 24050 exit signal Segmentation fault (11) [Fri May 04 11:10:03 2012] [notice] child pid 24044 exit signal Segmentation fault (11) [Fri May 04 18:23:31 2012] [notice] child pid 27659 exit signal Segmentation fault (11) [Fri May 04 19:15:25 2012] [notice] child pid 27830 exit signal Segmentation fault (11) [Fri May 04 19:15:34 2012] [notice] child pid 27832 exit signal Segmentation fault (11) [Fri May 04 19:17:53 2012] [notice] child pid 26396 exit signal Segmentation fault (11) [Fri May 04 20:17:11 2012] [notice] child pid 28059 exit signal Segmentation fault (11) Those look more like apache crashes, I presume... PHP may have been the root cause, however, if something is scrambling RAM. [2012-05-05 04:52:36] ly...@php.net Description: libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 It's PHP 5.1.3, so you may not care, but that's what was handed to me on the GoDaddy server by my client, and I hesitate to upgrade until we take the issue up with GoDaddy first. In the meantime, since I have a stacktrace with at least some debugging symbols in it, and it specifically mentions Curl_cookie_cleanup, I thought it might be something useful, even if it's an older PHP version. curl with CURLOPT_COOKIEJAR and CURLOPT_COOKIE file. I'm using curl_multi functions, so I guess it could be a factor. I'm hitting the same URL with different cookie files and log files, create with tempnam. I would assume that using two curl handles with the same cookie file and/or log file would be a Bad Idea. I have tail all the /tmp/curllog* files. Some are just empty. Others have nothing interesting at the end. I suppose the empty one could be the ones that correspond to the segfaults, but don't quite see how that info would be useful... Unless it narrows down a portion of the code. Test script: --- Could be this one: curl_setopt($curl, CURLOPT_RETURNTRANSFER, TRUE) or ($errors[] = 'RETURNTRANSFER'); curl_setopt($curl, CURLOPT_FOLLOWLOCATION, TRUE) or ($errors[] = 'FOLLOWLOCATION'); curl_setopt($curl, CURLOPT_HEADER, FALSE) or ($errors[] = 'HEADER'); curl_setopt($curl, CURLOPT_HTTPGET, TRUE) or ($errors[] = 'HTTPGET'); curl_setopt($curl, CURLOPT_TIMEOUT, 60) or ($errors[] = 'TIMEOUT'); curl_setopt($curl, CURLOPT_COOKIEFILE, $depart_cookies) or ($errors[] = 'COOKIEFILE'); curl_setopt($curl, CURLOPT_COOKIEJAR, dirname(__FILE__) . "/$direction.txt") or ($errors[] = 'COOKIEJAR'); curl_setopt($curl, CURLOPT_VERBOSE, TRUE) or ($errors[] = 'VERBOSE'); $log = fopen($curllog, 'a+') or ($errors[] = "FOPEN $curllog"); curl_setopt($curl, CURLOPT_STDERR, $log) or ($errors[] = 'STDERR'); Or it could be that one above with the following changes to the $curl handle: curl_setopt($curl, CURLOPT_POST, TRUE); curl_setopt($curl, CURLOPT_POSTFIELDS, $post_data); I will try to error_log something in between to narrow it down. Expected result: PHP to not crash. Actual result: -- *** glibc detected *** /usr/sbin/httpd: free(): corrupted unsorted chunks: 0xb87a8508 *** === Backtrace: = /lib/libc.so.6[0xb7bbd5a5] /lib/libc.so.6(cfree+0x59)[0xb7bbd9e9] /usr/lib/libcurl.so.3[0xb72e37ae] /usr/lib/libcurl.so.3(Curl_cookie_cleanup+0x3a)[0xb72e391a] /usr/lib/libcurl.so.3(Curl_close+0x127)[0xb72f44e7] /usr/lib/libcurl.so.3(curl_easy_cleanup+0x21)[0xb72ff421] /usr/lib/httpd/modules/libphp5.so[0xb7478e77] /usr/lib/httpd/modules/libphp5.so(list_entry_destructor+0xa3)[0xb75dd2c3] /usr/lib/httpd/modules/libphp5.so(zend_hash_del_key_or_index+0x221)[0xb75dc751] /usr/lib/httpd/modules/libphp5.so(_zend_list_delete+0x8a)[0xb75dd55a] /usr/lib/httpd/modules/libphp5.so(_zval_dtor_func+0x9a)[0xb7
Bug #61947 [Com]: curl Segmentation fault
Edit report at https://bugs.php.net/bug.php?id=61947&edit=1 ID: 61947 Comment by: ly...@php.net Reported by: ly...@php.net Summary:curl Segmentation fault Status: Feedback Type: Bug Package:cURL related Operating System: Linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: I have reproduced this on an RHEL5.7 box with PHP 5.3.3 Still not supported, but getting closer... Previous Comments: [2012-05-05 15:28:01] ras...@php.net There were known libcurl+curl_multi crashes in curl 7.15-7.19. See bug #47773 [2012-05-05 11:16:58] paj...@php.net Please do it already, the shorter script we get, the easier it will be to work on a fix. [2012-05-05 11:12:57] ly...@php.net If it helps, I now have a script that crashes every time, with a similar backtrace. Not a short script, mind you, but the libcurl bits aren't all that long either. If I hear back from somebody that wants to look at it, I'll strip out the non-curl parts, see if it crashes, and put here. Might just do that anyway, since I'm kind of stalled right now... [2012-05-05 05:39:24] ly...@php.net It is definitely the second one, with the POST that is crashing. Repeatable. [2012-05-05 05:00:00] ceo at l-i-e dot com I've got 9 more of these backtraces if you want them. And about 8 of these with no backtrace or anything at all: [Fri May 04 10:59:37 2012] [notice] child pid 24011 exit signal Segmentation fault (11) [Fri May 04 11:10:00 2012] [notice] child pid 24050 exit signal Segmentation fault (11) [Fri May 04 11:10:03 2012] [notice] child pid 24044 exit signal Segmentation fault (11) [Fri May 04 18:23:31 2012] [notice] child pid 27659 exit signal Segmentation fault (11) [Fri May 04 19:15:25 2012] [notice] child pid 27830 exit signal Segmentation fault (11) [Fri May 04 19:15:34 2012] [notice] child pid 27832 exit signal Segmentation fault (11) [Fri May 04 19:17:53 2012] [notice] child pid 26396 exit signal Segmentation fault (11) [Fri May 04 20:17:11 2012] [notice] child pid 28059 exit signal Segmentation fault (11) Those look more like apache crashes, I presume... PHP may have been the root cause, however, if something is scrambling RAM. 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 https://bugs.php.net/bug.php?id=61947 -- Edit this bug report at https://bugs.php.net/bug.php?id=61947&edit=1
Bug #61947 [Com]: curl Segmentation fault
Edit report at https://bugs.php.net/bug.php?id=61947&edit=1 ID: 61947 Comment by: ly...@php.net Reported by: ly...@php.net Summary:curl Segmentation fault Status: Feedback Type: Bug Package:cURL related Operating System: Linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Short test script, for what its' worth: http://www.6112northwolcott.com/curl_bug/test.phps libcurl is 7.15.5 on both boxes. I'll close this out. SORRY! I did search, but missed the other bug somehow. Previous Comments: [2012-05-07 16:05:04] ras...@php.net The PHP version is less important than the libcurl version on this one. [2012-05-07 16:03:19] ly...@php.net I have reproduced this on an RHEL5.7 box with PHP 5.3.3 Still not supported, but getting closer... [2012-05-05 15:28:01] ras...@php.net There were known libcurl+curl_multi crashes in curl 7.15-7.19. See bug #47773 [2012-05-05 11:16:58] paj...@php.net Please do it already, the shorter script we get, the easier it will be to work on a fix. [2012-05-05 11:12:57] ly...@php.net If it helps, I now have a script that crashes every time, with a similar backtrace. Not a short script, mind you, but the libcurl bits aren't all that long either. If I hear back from somebody that wants to look at it, I'll strip out the non-curl parts, see if it crashes, and put here. Might just do that anyway, since I'm kind of stalled right now... 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 https://bugs.php.net/bug.php?id=61947 -- Edit this bug report at https://bugs.php.net/bug.php?id=61947&edit=1
Bug #61947 [Fbk->Csd]: curl Segmentation fault
Edit report at https://bugs.php.net/bug.php?id=61947&edit=1 ID: 61947 User updated by: ly...@php.net Reported by: ly...@php.net Summary:curl Segmentation fault -Status: Feedback +Status: Closed Type: Bug Package:cURL related Operating System: Linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: libcurl 7.15.5 known non-php issue https://bugs.php.net/bug.php?id=47773 Previous Comments: [2012-05-07 16:06:59] ly...@php.net Short test script, for what its' worth: http://www.6112northwolcott.com/curl_bug/test.phps libcurl is 7.15.5 on both boxes. I'll close this out. SORRY! I did search, but missed the other bug somehow. [2012-05-07 16:05:04] ras...@php.net The PHP version is less important than the libcurl version on this one. [2012-05-07 16:03:19] ly...@php.net I have reproduced this on an RHEL5.7 box with PHP 5.3.3 Still not supported, but getting closer... [2012-05-05 15:28:01] ras...@php.net There were known libcurl+curl_multi crashes in curl 7.15-7.19. See bug #47773 [2012-05-05 11:16:58] paj...@php.net Please do it already, the shorter script we get, the easier it will be to work on a fix. 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 https://bugs.php.net/bug.php?id=61947 -- Edit this bug report at https://bugs.php.net/bug.php?id=61947&edit=1
