#34381 [Opn->Csd]: nl2br() should have an option for XHTML/HTML compatible BR element
ID: 34381 Updated by: [EMAIL PROTECTED] Reported By: jasper at bryant-greene dot name -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: N/A PHP Version: 5.0.4 -Assigned To: +Assigned To: kalle New Comment: This feature has been implemented and is available as of PHP 5.3 Previous Comments: [2008-08-07 01:30:50] [EMAIL PROTECTED] Try this patch (for PHP_5_3 cvs): http://www.phpfi.com/340833 This adds a new parameter to nl2br() to enable nl2br() to return "" insted of "" [2008-03-13 15:28:15] holliwell at gmx dot net I second jasper's suggestion of an optional switch, if one wants plain old html 4.01 , default should be xhtml-compliant . [2007-10-25 17:25:29] nospam at wanted dot by dot me That tags generated by the NL2BR() function are not compliant with an HTML 4.01 DOCTYPE is now commented on otherwise legitimate pages by the W3C validator. I fail to understand why a new function wasn't invented to handle output intended for XHTML instead of simply amending this function intended for HTML output as of PHP 4.0.5 onwards - did you assume that everyone would immediately migrate to XHTML at that time? The only alternative for PHP authors who wish to generate HTML compliant markup at present are left with is to write their own version of NL2BR() and replace it's use throughout their script bases and libraries when generating HTML. A solution PHP could offer is a new function that enables PHP authors to specify whether an HTML page is being output or whether it is something else, like XHTML or XML. This function (or method) could be invoked at the same time as the DOCTYPE is output. It could also be defaulted by a php.ini switch quite handily. [2005-09-05 22:56:35] jasper at bryant-greene dot name Description: The nl2br() function, as of PHP 4.0.5, always inserts . However, in HTML a complaint parser should understand this as > (it is the SGML SHORTTAG syntax). For example, this code: | This isa paragraph should be rendered as this in an HTML document[1]: | This is | >a paragraph Therefore, in order to maintain compatibility with both HTML and XHTML specifications, I request that an option be added to nl2br() that allows XHTML or HTML compliant br elements to be inserted. [1] for more information, see http://hixie.ch/advocacy/xhtml -- Edit this bug report at http://bugs.php.net/?id=34381&edit=1
#45814 [Fbk->Csd]: unstable due to compiler problem
ID: 45814 User updated by: phpbug at sheard dot net -Summary: segfault when loading squirrelmail through lighttpd Reported By: phpbug at sheard dot net -Status: Feedback +Status: Closed Bug Type: CGI related Operating System: gentoo PHP Version: 5.2.6 New Comment: unstable due to compiler problem Previous Comments: [2008-08-13 23:46:03] [EMAIL PROTECTED] Hello, Can you provide a backtrace please? Does it crash when loading squirrelmail's index? Thanks. [2008-08-13 23:38:35] phpbug at sheard dot net Description: strace http://recon.unfx.net/php-crash.txt php version 5.2.6 lighttpd 1.4.19 -- Edit this bug report at http://bugs.php.net/?id=45814&edit=1
#45288 [NoF->Csd]: set_include_path() functionality broken
ID: 45288 User updated by: php at isnoop dot net Reported By: php at isnoop dot net -Status: No Feedback +Status: Closed Bug Type: Filesystem function related Operating System: Ubuntu 7.04 server PHP Version: 5.3CVS-2008-06-17 (snap) Assigned To: dmitry New Comment: Okay, it appears that the host in question was indeed using php_admin_value to set include_path, which is no longer able to be overridden at runtime. This change was introduced in 5.2.5, ticket #41561. Closing ticket. Previous Comments: [2008-08-09 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, 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". [2008-07-29 08:35:57] [EMAIL PROTECTED] Works fine with php.ini-dist [EMAIL PROTECTED] CGI-DEBUG]$ cat bug45288.php http://bugs.php.net/45288 -- Edit this bug report at http://bugs.php.net/?id=45288&edit=1
#45812 [Ver->Fbk]: Error in mssql_query when the script create large text files
ID: 45812 Updated by: [EMAIL PROTECTED] Reported By: leonardodeconti at yahoo dot com dot br -Status: Verified +Status: Feedback Bug Type: MSSQL related Operating System: Linux 2.6.24.2 PHP Version: 5.2.6 New Comment: And please, provide a working reproductible script. Yours is full of typos. Thank you. Previous Comments: [2008-08-14 00:01:52] [EMAIL PROTECTED] Hello, Could you tell me how many rows you have in that large base? It seems dbsqlexec() fails because dbresults set wasn't processed entirely According to the mssql's documentation: The most common reason for failing is a SQL syntax error. dbsqlexec will also fail if there are semantic errors, such as incorrect column or table names. Failure occurs if any of the commands in the batch contains a semantic or syntax error. dbsqlexec also fails if previous results had not been processed, or if the command buffer was empty. [2008-08-13 20:18:42] leonardodeconti at yahoo dot com dot br Description: Into of a loop(while): 1) I open the file handler (w) 2) Caught data on database (MSSQL 2005) 3) Record the data to file (fwrite) 4) Close handler 5) Continue loop until end If the file created (step 3) is large (over +- 25MB), the next query gives error. But if the file is small, the script works well. In my script, I have to make the export of large tables, separated. If I remove the element 'large_table' of the array $tables, the export will work perfectly. Reproduce code: --- Expected result: large_table exported medium_table exported small_table exported medium_table exported end Actual result: -- large_table exported Warning: mssql_query(): Query failed in /htdocs/export_data_as_sql_insert.php on line 15 -- Edit this bug report at http://bugs.php.net/?id=45812&edit=1
#45812 [Opn->Ver]: Error in mssql_query when the script create large text files
ID: 45812 Updated by: [EMAIL PROTECTED] Reported By: leonardodeconti at yahoo dot com dot br -Status: Open +Status: Verified Bug Type: MSSQL related Operating System: Linux 2.6.24.2 PHP Version: 5.2.6 New Comment: Hello, Could you tell me how many rows you have in that large base? It seems dbsqlexec() fails because dbresults set wasn't processed entirely According to the mssql's documentation: The most common reason for failing is a SQL syntax error. dbsqlexec will also fail if there are semantic errors, such as incorrect column or table names. Failure occurs if any of the commands in the batch contains a semantic or syntax error. dbsqlexec also fails if previous results had not been processed, or if the command buffer was empty. Previous Comments: [2008-08-13 20:18:42] leonardodeconti at yahoo dot com dot br Description: Into of a loop(while): 1) I open the file handler (w) 2) Caught data on database (MSSQL 2005) 3) Record the data to file (fwrite) 4) Close handler 5) Continue loop until end If the file created (step 3) is large (over +- 25MB), the next query gives error. But if the file is small, the script works well. In my script, I have to make the export of large tables, separated. If I remove the element 'large_table' of the array $tables, the export will work perfectly. Reproduce code: --- Expected result: large_table exported medium_table exported small_table exported medium_table exported end Actual result: -- large_table exported Warning: mssql_query(): Query failed in /htdocs/export_data_as_sql_insert.php on line 15 -- Edit this bug report at http://bugs.php.net/?id=45812&edit=1
#45815 [NEW]: Illegal stub for phar
From: felipensp at gmail dot com
Operating system: FreeBSD
PHP version: 5.3CVS-2008-08-13 (CVS)
PHP Bug Type: PHAR related
Bug description: Illegal stub for phar
Description:
In the end of compilation:
Generating phar.php
Generating phar.phar
pear: not found
Pear package PHP_Archive or Archive.php class file not found.
Fatal error: Uncaught exception 'PharException' with
message 'illegal stub for
phar "/usr/home/felipe/php5/ext/phar/phar.phar"'
in /usr/home/felipe/php5/ext/phar/phar.php:994
Stack trace:
#0 /usr/home/felipe/php5/ext/phar/phar.php(994):
Phar->setStub('#!/usr/local/bi...')
#1 /usr/home/felipe/php5/ext/phar/phar.php(1054):
PharCommand->phar_set_stub_begin(Object(Phar), '/usr/home/felip...',
'/usr/home/felip...', '/usr/local/bin/...')
#2 [internal function]: PharCommand->cli_cmd_run_pack(Array)
#3 /usr/home/felipe/php5/ext/phar/phar.php(225):
call_user_func(Array, Array)
#4 /usr/home/felipe/php5/ext/phar/phar.php(2073):
CLICommand->__construct(19, Array)
#5 {main}
thrown in /usr/home/felipe/php5/ext/phar/phar.php on line 994
*** Error code 255
Stop in /usr/home/felipe/php5.
--
Edit bug report at http://bugs.php.net/?id=45815&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45815&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45815&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45815&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45815&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45815&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45815&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45815&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45815&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45815&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45815&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45815&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45815&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45815&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45815&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45815&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45815&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45815&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45815&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45815&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45815&r=mysqlcfg
#45814 [Opn->Fbk]: segfault when loading squirrelmail through lighttpd
ID: 45814 Updated by: [EMAIL PROTECTED] Reported By: phpbug at sheard dot net -Status: Open +Status: Feedback Bug Type: CGI related Operating System: gentoo PHP Version: 5.2.6 New Comment: Hello, Can you provide a backtrace please? Does it crash when loading squirrelmail's index? Thanks. Previous Comments: [2008-08-13 23:38:35] phpbug at sheard dot net Description: strace http://recon.unfx.net/php-crash.txt php version 5.2.6 lighttpd 1.4.19 -- Edit this bug report at http://bugs.php.net/?id=45814&edit=1
#45814 [NEW]: segfault when loading squirrelmail through lighttpd
From: phpbug at sheard dot net Operating system: gentoo PHP version: 5.2.6 PHP Bug Type: CGI related Bug description: segfault when loading squirrelmail through lighttpd Description: strace http://recon.unfx.net/php-crash.txt php version 5.2.6 lighttpd 1.4.19 -- Edit bug report at http://bugs.php.net/?id=45814&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45814&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45814&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45814&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45814&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45814&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45814&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45814&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45814&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45814&r=support Expected behavior:http://bugs.php.net/fix.php?id=45814&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45814&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45814&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45814&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45814&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45814&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45814&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45814&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45814&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45814&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45814&r=mysqlcfg
#45801 [Fbk->Csd]: PHPUnit testcase crashes (segfault)
ID: 45801 Updated by: [EMAIL PROTECTED] Reported By: jtaal at eljakim dot nl -Status: Feedback +Status: Closed Bug Type: Reproducible crash Operating System: * PHP Version: 5.2.6 Assigned To: fb-req-jani New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Thanks to Dmitry. Previous Comments: [2008-08-13 07:51:33] jtaal at eljakim dot nl Sebastian Bergman managed to narrow it down: http://bugs.php.net/bug.php?id=45805 please close this bug [2008-08-13 01:04:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2008-08-12 16:22:27] jtaal at eljakim dot nl Description: I'm getting a segmentation fault when running a very simple PHPUnit testcase. I'm using the latest pear package from pear.phpunit.de. The testcase is issuing an E_STRICT. I think deep inside PHPUnit something happens that causes this to happen. However, since PHPUnit is "just" a bunch of PHP classes, I dare say this is a bug inside the PHP interpreter. I've been able to run and crash this on both Linux (debian lenny) and Windows XP SP3 (both using PHP 5.2.6). Reproduce code: --- getX(); } } Actual result: -- $ phpunit MyTest.php Strict Standards: Only variables should be assigned by reference in /home/jtaal/public_html/MyTest.php on line 18 PHPUnit 3.2.21 by Sebastian Bergmann. Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=45801&edit=1
#45776 [Com]: apache2 crashes without file (any file!) named php5ts.dll in %windir%
ID: 45776 Comment by: sskaje at gmail dot com Reported By: sskaje at gmail dot com Status: Feedback Bug Type: Reproducible crash Operating System: Windows XP sp3 PHP Version: 5.3CVS-2008-08-10 (snap) Assigned To: pajoye New Comment: This is a snapshot for that popup message. http://img227.imageshack.us/my.php?image=qqxp9.png I am on a Simplified Chinese OS, so translating(not sure it is what i am going to type below): title: httpd.exe - application error message body: Memory offset(?) "0x0006" referred by instruction "0x022723a1". Data on this address cant be 'read'. Click OK to terminate the program. Click Cancel to debug the program. Previous Comments: [2008-08-10 15:24:04] [EMAIL PROTECTED] > Pierre, your build stuff is fubar. Works on XP, 2k8, 2k3 and Vista. With apache 2.2 and 2.0. Be sure to have a clean install without old dlls lying around. > Otherwise there is a popup error when i have windows started What says this popup? [2008-08-10 15:13:32] [EMAIL PROTECTED] Pierre, your build stuff is fubar. [2008-08-10 08:10:53] sskaje at gmail dot com Description: Windows xp + apache 2.2.9 + php 5.3.0-dev In httpd.conf, i have following configuration for php: [code] # For PHP 5 do something like this: LoadModule php5_module "h:/server/php53/php5apache2_2.dll" AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps # configure the path to php.ini PHPIniDir "h:/server/php53" [/code] On php5.3, i have to copy php53\php5ts.dll to %windir%. Otherwise there is a popup error when i have windows started which has apache crashed on starting up(i have apache2 installed as a system service and have it running automatically ), and when i tried to start apache again with 'httpd -k start', a similar error was popup-ed. So, %windir%\php5ts.dll of php5.3 seems to be necessary, but when i have php5ts.dll cp-ed to \windows and then apache running, i can remove %windir%\php5ts.dll as i want. Hmm, that makes me feel that the php5ts.dll under %windir% is not necessary as it looks like. So i took a test: [code] C:\WINDOWS> C:\WINDOWS>move php5ts.dll _php5ts.dll C:\WINDOWS>echo > php5ts.dll C:\WINDOWS>dir *php5* Çý¶¯Æ÷ C ÖеľíûÓбêÇ©¡£ ¾íµÄÐòÁкÅÊÇ E854-17BC C:\WINDOWS µÄĿ¼ 2008-08-10 16:0521 php5ts.dll 2008-07-31 23:42 5,251,128 _php5ts.dll 2 ¸öÎļþ 5,251,149 ×Ö½Ú 0 ¸öĿ¼ 20,189,646,848 ¿ÉÓÃ×Ö½Ú C:\WINDOWS>type php5ts.dll ECHO ´¦ÓÚ´ò¿ª×´Ì¬¡£ C:\WINDOWS>httpd -k restart Warning: DocumentRoot [H:/SVN/newborn/pages] does not exist C:\WINDOWS> [/code] It works normally as it should be. The conclusion is, i dont really have a php5ts.dll copied to %windir%, but i have, at least, a file named php5ts.dll there, no matter what is in it, if i wanna my apache+php5.3 work -- Edit this bug report at http://bugs.php.net/?id=45776&edit=1
#45813 [NEW]: Segfault in error handling
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 6CVS-2008-08-13 (CVS) PHP Bug Type: Reproducible crash Bug description: Segfault in error handling Description: When error reporting is set to E_ALL, calling ob_start() in an error handler function causes a segfault when triggered by imap_open(). I don't know if this is an imap only issue, it didn't crash with a couple other functions I tested. PHP6 snapshot compiled with --with-imap --with-imap-ssl Reproduce code: --- Actual result: -- Segmentation fault Backtrace: -- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb6bd76d0 (LWP 32715)] php_output_handler_create_internal (name=0x0, output_handler=0x8279240 , chunk_size=0, flags=112) at /mnt/hd/gsoc/php6/Zend/zend.h:414 414 return ++pz->refcount__gc; (gdb) bt #0 php_output_handler_create_internal (name=0x0, output_handler=0x8279240 , chunk_size=0, flags=112) at /mnt/hd/gsoc/php6/Zend/zend.h:414 #1 0x0827a2e8 in php_output_start_user (output_handler=0x0, chunk_size=0, flags=112) at /mnt/hd/gsoc/php6/main/output.c:492 #2 0x0827a379 in zif_ob_start (ht=0, return_value=0x88000e4, return_value_ptr=0x8835638, this_ptr=0x0, return_value_used=0) at /mnt/hd/gsoc/php6/main/output.c:1346 #3 0x082edbb7 in zend_do_fcall_common_helper_SPEC (execute_data=0x88355e8) at /mnt/hd/gsoc/php6/Zend/zend_vm_execute.h:323 #4 0x082ed088 in execute (op_array=0x8833570) at /mnt/hd/gsoc/php6/Zend/zend_vm_execute.h:104 #5 0x082b400d in zend_call_function (fci=0xbf9a6044, fci_cache=0xbf9a5fcc) at /mnt/hd/gsoc/php6/Zend/zend_execute_API.c:933 #6 0x082b4dc8 in call_user_function_ex (function_table=0x86ac4c0, object_pp=0x0, function_name=0x87fff80, retval_ptr_ptr=0xbf9a60c0, param_count=5, params=0x88000c8, no_separation=1, symbol_table=0x0) at /mnt/hd/gsoc/php6/Zend/zend_execute_API.c:729 #7 0x082c4d88 in zend_error (type=8, format=0x8604722 "%s") at /mnt/hd/gsoc/php6/Zend/zend.c:1632 #8 0x08268d33 in php_verror (docref=0x0, params=0x83b9100 "", type=8, format=0x85b8978 "%s (errflg=%ld)", args=0xbf9a618c "hH\203\b\002") at /mnt/hd/gsoc/php6/main/main.c:818 #9 0x08269233 in php_error_docref0 (docref=0x0, type=8, format=0x85b8978 "%s (errflg=%ld)") at /mnt/hd/gsoc/php6/main/main.c:839 #10 0x080f8c08 in zm_deactivate_imap (type=1, module_number=20) at /mnt/hd/gsoc/php6/ext/imap/php_imap.c:1117 #11 0x082c5ae2 in module_registry_cleanup (module=0x8708728) at /mnt/hd/gsoc/php6/Zend/zend_API.c:2487 #12 0x082d1936 in zend_hash_apply (ht=0x86abf40, apply_func=0x82c5ac0 ) at /mnt/hd/gsoc/php6/Zend/zend_hash.c:920 #13 0x082c3318 in zend_deactivate_modules () at /mnt/hd/gsoc/php6/Zend/zend.c:1394 #14 0x08267ba6 in php_request_shutdown (dummy=0x0) at /mnt/hd/gsoc/php6/main/main.c:1600 #15 0x08359aa4 in main (argc=2, argv=0xbf9a6674) at /mnt/hd/gsoc/php6/sapi/cli/php_cli.c:1329 -- Edit bug report at http://bugs.php.net/?id=45813&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45813&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45813&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45813&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45813&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45813&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45813&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45813&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45813&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45813&r=support Expected behavior:http://bugs.php.net/fix.php?id=45813&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45813&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45813&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45813&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45813&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45813&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45813&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45813&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45813&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45813&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45813&r=mysqlcfg
#45220 [Csd]: curl_read callback returns -1 when needs to return size_t (unsigned)
ID: 45220 Updated by: [EMAIL PROTECTED] Reported By: brockn at gmail dot com Status: Closed Bug Type: cURL related Operating System: CentOS release 4.6 (Final) PHP Version: 5.2.6 New Comment: PHP 4 is dead and no fixes, even the simplest, will be applied to it. Previous Comments: [2008-08-13 18:55:30] brockn at gmail dot com Looks like php 4.4.9 is still broken. I know its not supported anymore, but people are going to be using it for quite some time so I'd think it might be prudent to fix itgiven that its so simple. [2008-07-12 21:20:53] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2008-07-12 20:34:52] nicolas at brousse dot info You can also simply "patch" php source by fixing line 789 in ext/curl/interface.c : # before int length = -1; # after int length = 0; [2008-06-16 17:32:15] brockn at gmail dot com Yes, if you set POSTFIELDS to "", then curl_read does not return -1. The root of the problem is that the default return value is -1, when it should be 0 as it returns a size_t which is an unsigned type. A check was added in libcurl 7.18 where the value is cast to size_t and compared. This is the ``effect'' of the problem, but the cause is that the php supplied curl_read callback is returning -1. [2008-06-16 17:25:25] randearievilo at gmail dot com I have a similar code using cURL that worked fine in two platforms, but failed on other two. Platforms working: - Debian 4.0 / PHP 5.2.0 / Apache 2.2.8 / libcurl 7.15.5 - Windows XP / PHP 4.4.7 / Apache 1.3.39 / libcurl 7.16.0 Platforms not working: - Linux / PHP 4.4.7 / Apache 1.3.41 / libcurl 7.18.1 - Linux / PHP 5.2.5 / Apache 1.3.41 / libcurl 7.18.1 As you can see, the libcurl 7.18.x may really have a bug/error/problem. I think there was a change in the option CURLOPT_POST. Now, to use this option, it seems to be necessary to set the option CURLOPT_POSTFIELDS (curl_setopt($ch, CURLOPT_POSTFIELDS, "");). 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/45220 -- Edit this bug report at http://bugs.php.net/?id=45220&edit=1
#45812 [NEW]: Error in mssql_query when the script create large text files
From: leonardodeconti at yahoo dot com dot br Operating system: Linux 2.6.24.2 PHP version: 5.2.6 PHP Bug Type: MSSQL related Bug description: Error in mssql_query when the script create large text files Description: Into of a loop(while): 1) I open the file handler (w) 2) Caught data on database (MSSQL 2005) 3) Record the data to file (fwrite) 4) Close handler 5) Continue loop until end If the file created (step 3) is large (over +- 25MB), the next query gives error. But if the file is small, the script works well. In my script, I have to make the export of large tables, separated. If I remove the element 'large_table' of the array $tables, the export will work perfectly. Reproduce code: --- Expected result: large_table exported medium_table exported small_table exported medium_table exported end Actual result: -- large_table exported Warning: mssql_query(): Query failed in /htdocs/export_data_as_sql_insert.php on line 15 -- Edit bug report at http://bugs.php.net/?id=45812&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45812&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45812&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45812&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45812&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45812&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45812&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45812&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45812&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45812&r=support Expected behavior:http://bugs.php.net/fix.php?id=45812&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45812&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45812&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45812&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45812&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45812&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45812&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45812&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45812&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45812&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45812&r=mysqlcfg
#41608 [Asn->Fbk]: user error handler crashes
ID: 41608 Updated by: [EMAIL PROTECTED] Reported By: aigors at inbox dot lv -Status: Assigned +Status: Feedback Bug Type: Reproducible crash Operating System: Windows XP PHP Version: 5.2.5 Assigned To: tony2001 New Comment: Does not crash (in Linux, non ZTS) with latest snapshots of PHP_5_2 and PHP_5_3 branches. Previous Comments: [2008-02-09 01:14:47] [EMAIL PROTECTED] Breaks for me in 5.3CVS head too. [2008-01-26 01:07:23] [EMAIL PROTECTED] Antony..you claimed to have fixed this? :) [2008-01-15 07:29:07] aigors at inbox dot lv Yes, it appears that bug is in the snapshots also. [2007-12-18 09:47:50] aigors at inbox dot lv Bug still exists in PHP 5.2.5. [2007-06-06 08:35:53] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. 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/41608 -- Edit this bug report at http://bugs.php.net/?id=41608&edit=1
#45811 [Opn->Asn]: file_exists crashes Apache when phar is enabled
ID: 45811 Updated by: [EMAIL PROTECTED] Reported By: guilhermeblanco at gmail dot com -Status: Open +Status: Assigned Bug Type: PHAR related Operating System: Windows Vista Home Premium 32bit PHP Version: 5.3CVS-2008-08-13 (snap) -Assigned To: +Assigned To: cellog New Comment: Assigned to the PHAR maintainer. Previous Comments: [2008-08-13 19:57:59] guilhermeblanco at gmail dot com Description: With phar enabled the code below crashes my Apache. I was requested to get a backtrace (#php.pecl @ efnet), here is the content: Analysis Summary TypeDescription Recommendation Error WARNING - DebugDiag was not able to locate debug symbols for C:\Server\php5.3.0-200808121402\ext\php_phar.dll, so the information below may be incomplete. In httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp the module C:\Server\php5.3.0-200808121402\ext\php_phar.dll has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 2 Please follow up with the vendor of this module, The PHP Group, for further assistance with this issue. Information DebugDiag determined that this dump file (httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp) is a crash dump and did not perform any hang analysis. If you wish to enable combined crash and hang analysis for crash dumps, edit the CrashHangAnalysis.asp script (located in the DebugDiag\Scripts folder) and set the g_DoCombinedAnalysis constant to True. Analysis Details Your browser settings are currently prohibiting this report's scripts from running. This is preventing some features of this analysis report from displaying properly. To enable scripts to run, right-click the security warning above and choose "Allow Blocked Content..." or enable the "Allow active content to run in files on My Computer*" setting on the Advanced tab of your "Internet Options" dialog to avoid being prompted in the future Table Of Contents httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp Faulting Thread Report for httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp Report for httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp Type of Analysis PerformedCrash Analysis Machine Name BLANCO-LAPTOP Operating System Windows Vista Service Pack 1 Number Of Processors 2 Process ID2124 Process Image C:\Server\Apache2.2.8\bin\httpd.exe System Up-Time14:44:18 Process Up-Time 00:00:24 Thread 2 - System ID 4924 Entry point msvcrt!beginthreadex+86 Create time 13/08/2008 16:42:10 Time spent in user mode 0 Days 0:0:0.0 Time spent in kernel mode 0 Days 0:0:0.0 FunctionArg 1 Arg 2 Arg 3 Source 0x 0001040ed2f0 php_phar+5d5b 0001040ed2f0 php5ts!execute+cc5 WARNING - DebugDiag was not able to locate debug symbols for C:\Server\php5.3.0-200808121402\ext\php_phar.dll, so the information below may be incomplete. In httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp the module C:\Server\php5.3.0-200808121402\ext\php_phar.dll has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 2 Module Information Image Name: C:\Server\php5.3.0-200808121402\ext\php_phar.dll Symbol Type: Export Base address: 0x00b0Time Stamp: Tue Aug 12 15:01:58 2008 Checksum: 0xComments: Thanks to Gregory Beaver, Marcus Boerger COM DLL:False Company Name: The PHP Group ISAPIExtension: False File Description: PHP Archive ISAPIFilter:False File Version: 5.3.0alpha2-dev Managed DLL:False Internal Name:PHAR extension VB DLL: False Legal Copyright: Copyright © 1997-2008 The PHP Group Loaded Image Name: php_phar.dll Legal Trademarks: PHP Mapped Image Name: C:\Server\php5.3.0-200808121402\ext\php_phar.dll Original filename: php_phar.dll Module name:php_phar Private Build: Single Threaded:False Product Name: PHP Module Size:224,00 KBytes Product Version: 5.3.0alpha2-dev Symbol File Name: php_phar.dll Special Build:& Script Summary Script Name Status Error Code Error SourceError Description Source Line CrashHangAnalysis.asp Completed
#45811 [NEW]: file_exists crashes Apache when phar is enabled
From: guilhermeblanco at gmail dot com Operating system: Windows Vista Home Premium 32bit PHP version: 5.3CVS-2008-08-13 (snap) PHP Bug Type: PHAR related Bug description: file_exists crashes Apache when phar is enabled Description: With phar enabled the code below crashes my Apache. I was requested to get a backtrace (#php.pecl @ efnet), here is the content: Analysis Summary TypeDescription Recommendation Error WARNING - DebugDiag was not able to locate debug symbols for C:\Server\php5.3.0-200808121402\ext\php_phar.dll, so the information below may be incomplete. In httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp the module C:\Server\php5.3.0-200808121402\ext\php_phar.dll has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 2 Please follow up with the vendor of this module, The PHP Group, for further assistance with this issue. Information DebugDiag determined that this dump file (httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp) is a crash dump and did not perform any hang analysis. If you wish to enable combined crash and hang analysis for crash dumps, edit the CrashHangAnalysis.asp script (located in the DebugDiag\Scripts folder) and set the g_DoCombinedAnalysis constant to True. Analysis Details Your browser settings are currently prohibiting this report's scripts from running. This is preventing some features of this analysis report from displaying properly. To enable scripts to run, right-click the security warning above and choose "Allow Blocked Content..." or enable the "Allow active content to run in files on My Computer*" setting on the Advanced tab of your "Internet Options" dialog to avoid being prompted in the future Table Of Contents httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp Faulting Thread Report for httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp Report for httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp Type of Analysis PerformedCrash Analysis Machine Name BLANCO-LAPTOP Operating System Windows Vista Service Pack 1 Number Of Processors 2 Process ID2124 Process Image C:\Server\Apache2.2.8\bin\httpd.exe System Up-Time14:44:18 Process Up-Time 00:00:24 Thread 2 - System ID 4924 Entry point msvcrt!beginthreadex+86 Create time 13/08/2008 16:42:10 Time spent in user mode 0 Days 0:0:0.0 Time spent in kernel mode 0 Days 0:0:0.0 FunctionArg 1 Arg 2 Arg 3 Source 0x 0001040ed2f0 php_phar+5d5b 0001040ed2f0 php5ts!execute+cc5 WARNING - DebugDiag was not able to locate debug symbols for C:\Server\php5.3.0-200808121402\ext\php_phar.dll, so the information below may be incomplete. In httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp the module C:\Server\php5.3.0-200808121402\ext\php_phar.dll has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 2 Module Information Image Name: C:\Server\php5.3.0-200808121402\ext\php_phar.dll Symbol Type: Export Base address: 0x00b0Time Stamp: Tue Aug 12 15:01:58 2008 Checksum: 0xComments: Thanks to Gregory Beaver, Marcus Boerger COM DLL:False Company Name: The PHP Group ISAPIExtension: False File Description: PHP Archive ISAPIFilter:False File Version: 5.3.0alpha2-dev Managed DLL:False Internal Name:PHAR extension VB DLL: False Legal Copyright: Copyright © 1997-2008 The PHP Group Loaded Image Name: php_phar.dll Legal Trademarks: PHP Mapped Image Name: C:\Server\php5.3.0-200808121402\ext\php_phar.dll Original filename: php_phar.dll Module name:php_phar Private Build: Single Threaded:False Product Name: PHP Module Size:224,00 KBytes Product Version: 5.3.0alpha2-dev Symbol File Name: php_phar.dll Special Build:& Script Summary Script Name Status Error Code Error SourceError Description Source Line CrashHangAnalysis.asp Completed Reproduce code: --- http://bugs.php.net/?id=45811&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45811&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45811&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/f
#45726 [Opn->Asn]: PHP_Archive / Archive.php missing
ID: 45726
Updated by: [EMAIL PROTECTED]
Reported By: Bjorn dot Wiberg at its dot uu dot se
-Status: Open
+Status: Assigned
Bug Type: PHAR related
Operating System: AIX 5.3 5300-08-01-0819
PHP Version: 5.3CVS-2008-08-06
-Assigned To:
+Assigned To: cellog
New Comment:
Assigned to the PHAR maintainer.
Previous Comments:
[2008-08-06 08:03:49] Bjorn dot Wiberg at its dot uu dot se
Sorry, same error with 5.3-dev (5.3-200808060630):
---8<--- excerpt ---8<---
t/power_510_32/usr/lib
-L/gestconf/project/GNOME_ACL/GNOME/build/acc_gnome2_14_0f1/export/power_510_32/usr/lib
-L/gestconf/project/GNOME_ACL/GNOME/build/GNOME_2_14_0/export/power_510_32/usr/lib
-L/users/project/PDP/PDP_51_vac_6_14/usr/ccs/lib
-L/users/project/PDP/PDP_51_vac_6_14/usr/lib -lz -lm -lz -ljpeg -lssl
-lcrypto -lgdbm -lbz2 -lz -lssl -lcrypto -lm -lz -liconv -lm -lcurl
-lssl -lcrypto -lz -lssl -lcrypto -lz -lz -liconv -lm -lz -liconv -lm
-lz -liconv -lm -lz -liconv -lm -lz -liconv -lm -lz -liconv -lm -lz
-liconv -lm -lz -liconv -lm -lxslt -lz -liconv -lm -lxml2 -lpthread -lz
-liconv -lm -lz -liconv -lm
-Wl,-blibpath:/usr/local/lib:/opt/freeware/lib:/usr/X11R6/lib:/opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.0.0:/opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.0.0/../../..:/usr/lib:/lib
ld: 0711-224 WARNING: Duplicate symbol: php_optidx
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.
ld: 0711-783 WARNING: TOC overflow. TOC size: 72664 Maximum size:
65536
Extra instructions are being generated for each reference to a
TOC
symbol if the symbol is in the TOC overflow area.
Generating phar.php
Generating phar.phar
Pear package PHP_Archive or Archive.php class file not found.
Fatal error: Uncaught exception 'PharException' with message 'illegal
stub for phar
"/home/bwiberg/rpm/BUILD/php5.3-200808060630/ext/phar/phar.phar"' in
/home/bwiberg/rpm/BUILD/php5.3-200808060630/ext/phar/phar.php:994
Stack trace:
#0 /home/bwiberg/rpm/BUILD/php5.3-200808060630/ext/phar/phar.php(994):
Phar->setStub('#!/apache/php/b...')
#1 /home/bwiberg/rpm/BUILD/php5.3-200808060630/ext/phar/phar.php(1054):
PharCommand->phar_set_stub_begin(Object(Phar), '/home/bwiberg/r...',
'/home/bwiberg/r...', '/apache/php/bin...')
#2 [internal function]: PharCommand->cli_cmd_run_pack(Array)
#3 /home/bwiberg/rpm/BUILD/php5.3-200808060630/ext/phar/phar.php(225):
call_user_func(Array, Array)
#4 /home/bwiberg/rpm/BUILD/php5.3-200808060630/ext/phar/phar.php(2073):
CLICommand->__construct(19, Array)
#5 {main}
thrown in
/home/bwiberg/rpm/BUILD/php5.3-200808060630/ext/phar/phar.php on line
994
make: *** [ext/phar/phar.phar] Error 255
Bad exit status from /var/opt/freeware/tmp/rpm-tmp.10312 (%build)
[EMAIL PROTECTED]:~/rpm/SPECS$ cd ..
[EMAIL PROTECTED]:~/rpm$ cd BUILD/php5.3-200808060630/
[EMAIL PROTECTED]:~/rpm/BUILD/php5.3-200808060630$
/opt/freeware/bin/find -iname Archive.php
[EMAIL PROTECTED]:~/rpm/BUILD/php5.3-200808060630$
--->8--- end excerpt --->8---
(No Archive.php anywhere...)
[2008-08-05 13:53:40] Bjorn dot Wiberg at its dot uu dot se
Description:
PHP complains about Archive.php / PHP_Archive not being found during
compilation.
Reproduce code:
---
#! /bin/sh
#
# Created by configure
LDFLAGS='-Wl,-bbigtoc' \
CC='gcc' \
'./configure' \
'--disable-fileinfo' \
'--enable-bcmath' \
'--enable-calendar' \
'--enable-cli' \
'--enable-dba' \
'--enable-dbase' \
'--enable-debug' \
'--enable-exif' \
'--enable-flatfile' \
'--enable-ftp' \
'--enable-gd-jis-conv' \
'--enable-gd-native-ttf' \
'--enable-inifile' \
'--enable-mbstring' \
'--enable-pcntl' \
'--enable-shmop' \
'--enable-soap' \
'--enable-sockets' \
'--enable-sqlite-utf8' \
'--enable-sysvmsg' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-wddx' \
'--enable-zip' \
'--enable-zend-multibyte' \
'--prefix=/apache/php' \
'--with-apxs2=/apache/bin/apxs' \
'--with-bz2' \
'--with-cdb' \
'--with-curl' \
'--with-freetype-dir' \
'--with-gd' \
'--with-gdbm' \
'--with-gettext' \
'--with-jpeg-dir' \
'--with-ldap' \
'--with-libxml-dir=/usr/local' \
'--with-mime-magic' \
'--with-mysql=mysqlnd' \
'--with-mysqli=mysqlnd' \
'--with-openssl=/opt/freeware' \
'--with-pdo-mysql=mysqlnd' \
'--with-png-dir' \
'--with-xmlrpc' \
'--with-xpm-dir' \
'--with-xsl' \
'--with-zlib' \
'--with-zlib-dir' \
"$@"
Followed by '/opt/freeware/bin/make' (GNU make).
Expected result:
No error message.
Actual result:
--
gcc -I/usr/include -g -fvisibility=hidden -O0 -Wall -Wl,-bbigtoc
-Wl,-brtl -Wl,-bE:php.sym ext/ereg/.libs/ereg.o
ext/ereg/regex/.libs/regcomp.o ext/ereg/regex/.libs/regexec.o
ext/ereg/regex/.libs/regerror.o ext/ereg/regex/.libs/regfree.o
ext/libxml/.libs/libxml.o ext/openssl/.libs/openssl.o
ext/openssl/.libs/xp_ssl.o ext/pcre/pcreli
#45761 [Opn->Fbk]: make test & make install failure
ID: 45761 Updated by: [EMAIL PROTECTED] Reported By: a dot sanders at manchester dot ac dot uk -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Solaris 9 PHP Version: 5.2CVS-2008-08-11 New Comment: Does this directory contain the sources of PHP or not: /home/copacw/php5.2-200808110110830/ If not, point that to the sources then..or where ever the hell the tests are you run when you do 'make test'.. Previous Comments: [2008-08-13 14:26:08] a dot sanders at manchester dot ac dot uk I don't think we're quite there yet. I copied and pasted your suggested command line and got the following: carew copacw/php5.2-200808110830 $ USE_ZEND_ALLOC=0 \ > TEST_PHP_EXECUTABLE=/home/copacw/php5.2-200808110830/sapi/cli/php \ > gdb --arg /home/copacw/php5.2-200808110830/sapi/cli/php -n \ > run-tests.php -n /home/copacw/php5.2-200808110110830/ GNU gdb 6.2.1 Copyright 2004 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 "sparc-sun-solaris2.9"... (gdb) run Starting program: /home/copacw/php5.2-200808110830/sapi/cli/php -n run-tests.php -n /home/copacw/php5.2-200808110110830/ bogus test name /home/copacw/php5.2-200808110110830/ Program exited normally. (gdb) (My apologies for being too dumb to sort this out myself.) [2008-08-13 14:20:22] [EMAIL PROTECTED] Almost there. :) You tried to execute the php binary as a script, leave that sapi/cli/php out of the last path, it's supposed to be the s.c. top_srcdir. This should be correct for you: # USE_ZEND_ALLOC=0 \ TEST_PHP_EXECUTABLE=/home/copacw/php5.2-200808110830/sapi/cli/php \ gdb --arg /home/copacw/php5.2-200808110830/sapi/cli/php -n \ run-tests.php -n /home/copacw/php5.2-200808110110830/ (gdb) run (gdb) bt Start copying the output of "bt" command from the line after the "run" command which has the line with the crash info. [2008-08-13 09:10:27] a dot sanders at manchester dot ac dot uk Output from gdb as follows. Is this what you were expecting? It doesn't crash out, so there's no backtrace. (gdb) run Starting program: /home/copacw/php5.2-200808110830/sapi/cli/php -n /home/copacw/php5.2-200808110830/sapi/cli/php run-tests.php -n /home/copacw/php5.2-200808110830/sapi/cli/php Warning: Unexpected character in input: '' (ASCII=16) state=1 in /home/copacw/php5.2-200808110830/sapi/cli/php on line 3309 Parse error: syntax error, unexpected T_STRING in /home/copacw/php5.2-200808110830/sapi/cli/php on line 3309 Program exited with code 0377. [2008-08-12 15:37:12] [EMAIL PROTECTED] This should work: # USE_ZEND_ALLOC=0 TEST_PHP_EXECUTABLE=/full/path/to/php \ gdb --arg /full/path/to/php -n /full/path/to/php \ run-tests.php -n /full/path/to/php/src/ [2008-08-12 15:13:20] a dot sanders at manchester dot ac dot uk When I compiled with ./configure --disable-all --enable-debug --with-pcre-regex I can do a make test and it gets to the same place as before (the cgi test) without core dumping. I then have to kill it before it consumes the system memory. You told me to run gdb as follows: USE_ZEND_ALLOC=0 gdb sapi/cli/php -n run-tests.php gdb wont accept such a command line, so I entered run -n run-tests.php from the gdb prompt and I then get the message: Starting program: /home/copacw/php5.2-200808110830/sapi/cli/php -n run-tests.php ERROR: environment variable TEST_PHP_EXECUTABLE must be set to specify PHP executable! Program exited with code 01. I've tried setting a TEST_PHP_EXECUTABLE environment variable to point to the php executable, but I still get the same message. 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/45761 -- Edit this bug report at http://bugs.php.net/?id=45761&edit=1
#44271 [Opn->Fbk]: open_basedir resolves links on link-specific operations
ID: 44271 Updated by: [EMAIL PROTECTED] Reported By: tautolog at gmail dot com -Status: Open +Status: Feedback Bug Type: Safe Mode/open_basedir Operating System: DragonFly BSD PHP Version: 5.2.5 Assigned To: fb-req-jani New Comment: Patches are always welcome. Previous Comments: [2008-08-12 18:05:15] tautolog at gmail dot com Hi, Thank you for your time and attention on this issue. I tested all of the functions at issue using the snapshot build php5.3-200808121630. I get the same result as before: the same warning, and it returns failure. Should I try again at a later date? Would you like me to take a shot at fixing it? I recognize that it is in a fairly sensitive area of the code, and you might rather just do it yourself, or not bother with changes there. I am not bothered about backporting. The workaround for my case was simple enough, and I am now at a different job that doesn't involve PHP. Thanks, Ben [2008-08-12 08:58:22] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz There are some fixes done in PHP_5_3 which most likely fix this problem. Note: Those fixes will NOT be backported to 5.2 branch! [2008-02-27 20:17:16] tautolog at gmail dot com Description: This is not a security issue. It is just a functionality issue. open_basedir resolves links on link-specific operations, getting in the way of expected behavior. I don't think that the ability to read a link target (the target itself, not the file the target resolves to) within the basedir is a security concern because it is no different than the ability to read a config file which refers to a file outside of the basedir. In my thinking about this issue, I am viewing a symbolic link as just an alternate way to associate data with a file that just happens to have common support for treating the data as a target. See my reproduce code. Clearly, "/tmp/testlink" is in the allowed path of "home/ben/public_html:/tmp", but since it resolves to "/test", it is not being allowed. The following system calls (and therefore PHP functions) do not follow symlinks, according to symlink(7) on my BSD system: lchown() lstat() readlink() rename() rmdir() unlink() remove() (just an alias to unlink which is not in PHP) I tested all of them. All of them have this issue. rmdir() is an odd one. According to the manual, if you use it on a symbolic link, it should return ENOTDIR. $ mkdir /tmp/link_target $ ln -s /tmp/link_target /tmp/testlink $ rmdir /tmp/testlink rmdir: /tmp/testlink: Not a directory I have been using symbolic links to back a fast, simple, global, atomic, persistent hash, where the link filename is the key and the link value is the value. I have been running the application with open_basedir set to try to find compatibility problems with it, and found this issue. To work around it, I prefix all values with "./" now. However, there are other cases that cannot be worked around. For example, a php file manager would not even be able to tell whether the file were a link, let alone read its value or delete it. I have some interest in working on a patch. If you agree that it is desirable for open_basedir to not resolve links in some cases, I may be able to provide a patch. Just in case, I also tested the case where a link is outside open_basedir, but it resolves within open_basedir, and it blocked that, which I agree should be the expected behavior. Reproduce code: --- Add /tmp to open_basedir $ ln -s /test /tmp/testlink Expected result: 1 Actual result: -- Warning: is_link(): open_basedir restriction in effect. File(/tmp/testlink) is not within the allowed path(s): (/home/ben/public_html:/tmp) in /home/ben/public_html/cvs/app-modernbill-admin/include/lib-action/migrate/- on line 1 -- Edit this bug report at http://bugs.php.net/?id=44271&edit=1
#44556 [Opn->Bgs]: ibase_connect() crashes
ID: 44556
Updated by: [EMAIL PROTECTED]
Reported By: shtabnoi at mail dot ru
-Status: Open
+Status: Bogus
Bug Type: InterBase related
Operating System: FreeBSD 7.0-RELEASE FreeBSD 7.0
PHP Version: 5.2.5
New Comment:
3rd party problem. Not PHP bug -> bogus.
Previous Comments:
[2008-04-07 09:09:05] roman dot demenkov at gmail dot com
I got same problem with FreeBSD 7.0 release + latest ports Apache (or
nginx), PHP, Firebird.
Problem is in firebird2-client-2.0.2 port. If you take client version
from 6.3 package tree:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.3-release/databases/firebird-client-2.0.3_1.tbz
then link some missing links in /usr/lib/ then php got work! =)
Now have (all from port tree):
nginx-devel-0.6.29 as webserver, apache will work also, im sure
php5-5.2.5
php5-interbase-5.2.5
firebird-server-2.0.3_1 (or firebird-server-2.0.3_2 tested both)
firebird-client-2.0.3_1 from pakage FreeBSD 6.3 (link above)
So i hope port submiter on FreeBSD will fix soon this problem.
Good luck.
[2008-04-02 09:59:28] shtabnoi at mail dot ru
Segmentation fault doesn't depend on installation type of apache, php
and firebird - whenether they are installed from source or package.
Changing OS version package like here:
http://bugs.php.net/bug.php?id=43388 does the same result.
[2008-03-28 09:40:17] shtabnoi at mail dot ru
Description:
ibase_connect
Apache/2.2.6 (FreeBSD) [Fri Mar 28 13:43:17 2008] [notice] child pid
1840 exit signal Segmentation fault (11)
Firebird-2.0.3 runs normally (isq, EMS SQL Manager and so on)
Any php code without ibase_ functions runs normally.
Reproduce code:
---
class TDB
{
var $host;
var $dbh;
var $username;
var $password;
var $SQL;
var $rows;
var $error;
var $rowcount;
var $fields;
function TDB($h,$u,$p)
{
$this->host=$h;
$this->username=$u;
$this->password=$p;
$this->dbh=$this->Connect();
}
function Connect()
{
$this->dbh=ibase_connect($this->host,$this->username,$this->password);
}
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x28401100 (LWP 100072)]
0x28be3dff in ThreadData::restoreSpecific () from
/usr/local/lib/libfbclient.so.2
(gdb)
(gdb) bt
#0 0x28be3dff in ThreadData::restoreSpecific () from
/usr/local/lib/libfbclient.so.2
#1 0x28bf8c5f in return_success () from
/usr/local/lib/libfbclient.so.2
#2 0x28c0061a in REM_attach_database () from
/usr/local/lib/libfbclient.so.2
#3 0x28bedb1b in isc_attach_database () from
/usr/local/lib/libfbclient.so.2
#4 0x288fb44e in _php_ibase_attach_db (args=0xbfbfcc00,
len=0xbfbfcbec, largs=0xbfbfcc3c, db=0xbfbfcc54)
at /tmp/php-5.2.5/ext/interbase/interbase.c:614
#5 0x288fb7da in _php_ibase_connect (ht=Variable "ht" is not
available.
) at /tmp/php-5.2.5/ext/interbase/interbase.c:718
#6 0x28aa67dc in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfbfcdc0) at zend_vm_execute.h:200
#7 0x28a98f5f in execute (op_array=0x28f1afcc) at
zend_vm_execute.h:92
#8 0x28aa624b in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfbfcfa0) at zend_vm_execute.h:234
#9 0x28a98f5f in execute (op_array=0x28f1abe8) at
zend_vm_execute.h:92
#10 0x28aa624b in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfbfd310) at zend_vm_execute.h:234
#11 0x28a98f5f in execute (op_array=0x28f17c80) at
zend_vm_execute.h:92
#12 0x28a7c0fa in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /tmp/php-5.2.5/Zend/zend.c:1134
#13 0x28a3cc35 in php_execute_script (primary_file=0xbfbfe8e8) at
/tmp/php-5.2.5/main/main.c:2004
#14 0x28af406b in php_handler (r=0x2900c050) at
/tmp/php-5.2.5/sapi/apache2handler/sapi_apache2.c:631
#15 0x080743a9 in ap_run_handler ()
#16 0x08077677 in ap_invoke_handler ()
#17 0x080822d0 in ap_process_request ()
#18 0x0807f5fb in ap_process_http_connection ()
#19 0x0807b4c9 in ap_run_process_connection ()
#20 0x08086577 in child_main ()
#21 0x08086843 in make_child ()
#22 0x080873f1 in ap_mpm_run ()
#23 0x08061fa5 in main ()
--
Edit this bug report at http://bugs.php.net/?id=44556&edit=1
#45220 [Csd]: curl_read callback returns -1 when needs to return size_t (unsigned)
ID: 45220 User updated by: brockn at gmail dot com Reported By: brockn at gmail dot com Status: Closed Bug Type: cURL related Operating System: CentOS release 4.6 (Final) PHP Version: 5.2.6 New Comment: Looks like php 4.4.9 is still broken. I know its not supported anymore, but people are going to be using it for quite some time so I'd think it might be prudent to fix itgiven that its so simple. Previous Comments: [2008-07-12 21:20:53] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2008-07-12 20:34:52] nicolas at brousse dot info You can also simply "patch" php source by fixing line 789 in ext/curl/interface.c : # before int length = -1; # after int length = 0; [2008-06-16 17:32:15] brockn at gmail dot com Yes, if you set POSTFIELDS to "", then curl_read does not return -1. The root of the problem is that the default return value is -1, when it should be 0 as it returns a size_t which is an unsigned type. A check was added in libcurl 7.18 where the value is cast to size_t and compared. This is the ``effect'' of the problem, but the cause is that the php supplied curl_read callback is returning -1. [2008-06-16 17:25:25] randearievilo at gmail dot com I have a similar code using cURL that worked fine in two platforms, but failed on other two. Platforms working: - Debian 4.0 / PHP 5.2.0 / Apache 2.2.8 / libcurl 7.15.5 - Windows XP / PHP 4.4.7 / Apache 1.3.39 / libcurl 7.16.0 Platforms not working: - Linux / PHP 4.4.7 / Apache 1.3.41 / libcurl 7.18.1 - Linux / PHP 5.2.5 / Apache 1.3.41 / libcurl 7.18.1 As you can see, the libcurl 7.18.x may really have a bug/error/problem. I think there was a change in the option CURLOPT_POST. Now, to use this option, it seems to be necessary to set the option CURLOPT_POSTFIELDS (curl_setopt($ch, CURLOPT_POSTFIELDS, "");). [2008-06-09 19:07:32] brockn at gmail dot com Here are the details of the problem which occurs inside libcurl: http://curl.haxx.se/mail/lib-2008-06/0109.html http://curl.haxx.se/mail/lib-2008-06/0111.html http://curl.haxx.se/mail/lib-2008-06/0123.html 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/45220 -- Edit this bug report at http://bugs.php.net/?id=45220&edit=1
#45809 [Opn->Fbk]: Apache crashes after replacing PHP-Version
ID: 45809 Updated by: [EMAIL PROTECTED] Reported By: typo3 at maltejansen dot de -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Windows CP SP2 PHP Version: 5.3.0alpha1 New Comment: Check your php.ini that you're not loading any shared extensions which might be from the PHP 5.2 installation. Best choice: remove ALL existing PHP stuff before you install new one.. Previous Comments: [2008-08-13 18:16:35] typo3 at maltejansen dot de Description: Wenn I'm replacing the PHP5.2 with the latest binaries of (5.3) from http://snaps.php.net/ the apache crashes. When I'm using the binaries of 6.0 the apache and php are working pretty fine. Reproduce code: --- * Installation of Xampp * Download binaries from http://snaps.php.net/ (php-5.3-dev (zip)) * Copy binaries to "...\xampp\php53\" * Replace simular line to new path (..\xampp\apache\conf\extra\httpd-xampp.conf): LoadModule php5_module "../xampp/php53alpha/php5apache2_2.dll" * Start Apache Expected result: The Apache should run smoothly. Actual result: -- Apache crashes -- Edit this bug report at http://bugs.php.net/?id=45809&edit=1
#45809 [NEW]: Apache crashes after replacing PHP-Version
From: typo3 at maltejansen dot de Operating system: Windows CP SP2 PHP version: 5.3.0alpha1 PHP Bug Type: Apache2 related Bug description: Apache crashes after replacing PHP-Version Description: Wenn I'm replacing the PHP5.2 with the latest binaries of (5.3) from http://snaps.php.net/ the apache crashes. When I'm using the binaries of 6.0 the apache and php are working pretty fine. Reproduce code: --- * Installation of Xampp * Download binaries from http://snaps.php.net/ (php-5.3-dev (zip)) * Copy binaries to "...\xampp\php53\" * Replace simular line to new path (..\xampp\apache\conf\extra\httpd-xampp.conf): LoadModule php5_module "../xampp/php53alpha/php5apache2_2.dll" * Start Apache Expected result: The Apache should run smoothly. Actual result: -- Apache crashes -- Edit bug report at http://bugs.php.net/?id=45809&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45809&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45809&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45809&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45809&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45809&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45809&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45809&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45809&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45809&r=support Expected behavior:http://bugs.php.net/fix.php?id=45809&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45809&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45809&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45809&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45809&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45809&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45809&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45809&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45809&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45809&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45809&r=mysqlcfg
#45804 [Opn->Bgs]: cgi crashes when using -n and -z ZendOptimizer 3.3.0
ID: 45804 Updated by: [EMAIL PROTECTED] Reported By: louis at steelbytes dot com -Status: Open +Status: Bogus Bug Type: CGI related Operating System: Vista SP1 x64 PHP Version: 5.2.6 New Comment: Do not file bugs when you have Zend extensions (zend_extension=) loaded. Examples are Zend Optimizer, Zend Debugger, Turck MM Cache, APC, Xdebug and ionCube loader. These extensions often modify engine behavior which is not related to PHP itself. If there's a problem the Zend guys can make a report which is way more precise Previous Comments: [2008-08-13 05:43:44] louis at steelbytes dot com Description: php 5.2.6 win32 zend optimizer 3.3.0 crashes. not 100% sure if this is zendopt of php's fault. so bug reporting to both :-) Reproduce code: --- crash: php-cgi.exe -n -z "C:\pathblah\php-5.2.x\ZendOptimizer.dll" no crash: php.exe -n -z "C:\pathblah\php-5.2.x\ZendOptimizer.dll" crash: php-cgi.exe -n -z "C:\pathblah\php-5.2.x\ZendOptimizer.dll" -i no crash: php-cgi.exe -n -i -z "C:\pathblah\php-5.2.x\ZendOptimizer.dll" -i go figure. Expected result: no crash Actual result: -- Faulting application php-cgi.exe, version 5.2.6.6, time stamp 0x481b8f5f, faulting module ZendOptimizer.dll, version 0.0.0.0, time stamp 0x4782498a, exception code 0xc005, fault offset 0x000180fb, process id 0x16fc, application start time 0x01c8fd067056e080. -- Edit this bug report at http://bugs.php.net/?id=45804&edit=1
#45761 [Fbk->Opn]: make test & make install failure
ID: 45761 User updated by: a dot sanders at manchester dot ac dot uk Reported By: a dot sanders at manchester dot ac dot uk -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Solaris 9 PHP Version: 5.2CVS-2008-08-11 Assigned To: fb-req-jani New Comment: I don't think we're quite there yet. I copied and pasted your suggested command line and got the following: carew copacw/php5.2-200808110830 $ USE_ZEND_ALLOC=0 \ > TEST_PHP_EXECUTABLE=/home/copacw/php5.2-200808110830/sapi/cli/php \ > gdb --arg /home/copacw/php5.2-200808110830/sapi/cli/php -n \ > run-tests.php -n /home/copacw/php5.2-200808110110830/ GNU gdb 6.2.1 Copyright 2004 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 "sparc-sun-solaris2.9"... (gdb) run Starting program: /home/copacw/php5.2-200808110830/sapi/cli/php -n run-tests.php -n /home/copacw/php5.2-200808110110830/ bogus test name /home/copacw/php5.2-200808110110830/ Program exited normally. (gdb) (My apologies for being too dumb to sort this out myself.) Previous Comments: [2008-08-13 14:20:22] [EMAIL PROTECTED] Almost there. :) You tried to execute the php binary as a script, leave that sapi/cli/php out of the last path, it's supposed to be the s.c. top_srcdir. This should be correct for you: # USE_ZEND_ALLOC=0 \ TEST_PHP_EXECUTABLE=/home/copacw/php5.2-200808110830/sapi/cli/php \ gdb --arg /home/copacw/php5.2-200808110830/sapi/cli/php -n \ run-tests.php -n /home/copacw/php5.2-200808110110830/ (gdb) run (gdb) bt Start copying the output of "bt" command from the line after the "run" command which has the line with the crash info. [2008-08-13 09:10:27] a dot sanders at manchester dot ac dot uk Output from gdb as follows. Is this what you were expecting? It doesn't crash out, so there's no backtrace. (gdb) run Starting program: /home/copacw/php5.2-200808110830/sapi/cli/php -n /home/copacw/php5.2-200808110830/sapi/cli/php run-tests.php -n /home/copacw/php5.2-200808110830/sapi/cli/php Warning: Unexpected character in input: '' (ASCII=16) state=1 in /home/copacw/php5.2-200808110830/sapi/cli/php on line 3309 Parse error: syntax error, unexpected T_STRING in /home/copacw/php5.2-200808110830/sapi/cli/php on line 3309 Program exited with code 0377. [2008-08-12 15:37:12] [EMAIL PROTECTED] This should work: # USE_ZEND_ALLOC=0 TEST_PHP_EXECUTABLE=/full/path/to/php \ gdb --arg /full/path/to/php -n /full/path/to/php \ run-tests.php -n /full/path/to/php/src/ [2008-08-12 15:13:20] a dot sanders at manchester dot ac dot uk When I compiled with ./configure --disable-all --enable-debug --with-pcre-regex I can do a make test and it gets to the same place as before (the cgi test) without core dumping. I then have to kill it before it consumes the system memory. You told me to run gdb as follows: USE_ZEND_ALLOC=0 gdb sapi/cli/php -n run-tests.php gdb wont accept such a command line, so I entered run -n run-tests.php from the gdb prompt and I then get the message: Starting program: /home/copacw/php5.2-200808110830/sapi/cli/php -n run-tests.php ERROR: environment variable TEST_PHP_EXECUTABLE must be set to specify PHP executable! Program exited with code 01. I've tried setting a TEST_PHP_EXECUTABLE environment variable to point to the php executable, but I still get the same message. [2008-08-12 14:32:08] [EMAIL PROTECTED] Add the output of '(gdb) bt' here of the crash. Compile using this configure line: # ./configure --disable-all --enable-debug Also, when you generate the backtrace, make sure you're not loading any php.ini file using the '-n' parameter. f.e. # USE_ZEND_ALLOC=0 gdb sapi/cli/php -n run-tests.php 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/45761 -- Edit this bug report at http://bugs.php.net/?id=45761&edit=1
#45786 [Opn->Asn]: FastCGI process exited unexpectedly
ID: 45786 Updated by: [EMAIL PROTECTED] Reported By: karelevzen at gmail dot com -Status: Open +Status: Assigned Bug Type: CGI related Operating System: Windows Vista Ultimate x64 SP1 PHP Version: 5.3CVS-2008-08-10 (CVS) -Assigned To: fb-req-jani +Assigned To: dmitry New Comment: Dmitry, something fishy with request shutdown in fastcgi? Note the ini options used by the user: cgi.force_redirect = 0 cgi.fix_pathinfo=1 fastcgi.impersonate = 1 Previous Comments: [2008-08-13 10:32:13] karelevzen at gmail dot com So hey, I managed to find a 5.3 release WITH debug files at http://downloads.php.net/pierre/ ! Here is the complete bugtrace. php_cgi!fcgi_free_var+4 001b2638 00c0ddcc php5ts!zend_hash_destroy+27 00c0fe00 0010 0001 php_cgi!fcgi_finish_request+2f 00c0ddcc 001b2638 001b2708 php_cgi!fcgi_accept_request+17 00c0ddcc php_cgi!main+69f 0001 001b2638 001b1690 php_cgi!mainCRTStartup+e3 7efde000 00c0ffd4 7752cfed kernel32!BaseThreadInitThunk+e 7efde000 7770f651 ntdll!__RtlUserThreadStart+23 00405ed6 7efde000 ntdll!_RtlUserThreadStart+1b 00405ed6 7efde000 PHP_CGI!FCGI_FREE_VAR+4In php-cgi__PID__4064__Date__08_13_2008__Time_12_29_14PM__838__Second_Chance_Exception_C005.dmp the assembly instruction at php_cgi!fcgi_free_var+4 in C:\Program Files (x86)\php\php-cgi.exe from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 0 [2008-08-13 06:28:16] karelevzen at gmail dot com I did that.I've downloaded the debug pack, unpacked it to: C:\Users\karel_evzen\Desktop\php-dbg and set the Symbol search path for analysis option in Debug Diagnostic Tool to: C:\Users\karel_evzen\Desktop\php-dbg Yet I get the symbols not found warning. Am I missing something? The debug pack contains runnable PHP, no pdb files. I cant find pdb files for the current 5.3 snapshot. Try it yourself. [2008-08-13 01:05:43] [EMAIL PROTECTED] Well, you propably should install the debug symbols then? They can be found at same place as the snapshots.. [2008-08-12 20:51:42] karelevzen at gmail dot com It tells me that it was not able to locate debug symbols, so I hope you find everything you need in this report. (I run it twice with the same results.) Entry point php_cgi+5ed6 Create time 12.8.2008 22:45:19 Time spent in user mode 0 Days 0:0:0.15 Time spent in kernel mode 0 Days 0:0:0.31 Function Arg 1 Arg 2 Arg 3 Source php_cgi+5604 01452638 00c0ddcc php5ts!zend_hash_destroy+27 PHP_CGI+5604WARNING - DebugDiag was not able to locate debug symbols for php-cgi.exe, so the information below may be incomplete. In php-cgi__PID__5468__Date__08_12_2008__Time_10_45_29PM__791__Second_Chance_Exception_C005.dmp the assembly instruction at php_cgi+5604 in C:\Program Files (x86)\php\php-cgi.exe from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 0 [2008-08-12 14:46:42] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, 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 for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. 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/45786 -- Edit this bug report at http://bugs.php.net/?id=45786&edit=1
#45761 [Opn->Fbk]: make test & make install failure
ID: 45761 Updated by: [EMAIL PROTECTED] Reported By: a dot sanders at manchester dot ac dot uk -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Solaris 9 PHP Version: 5.2CVS-2008-08-11 Assigned To: fb-req-jani New Comment: Almost there. :) You tried to execute the php binary as a script, leave that sapi/cli/php out of the last path, it's supposed to be the s.c. top_srcdir. This should be correct for you: # USE_ZEND_ALLOC=0 \ TEST_PHP_EXECUTABLE=/home/copacw/php5.2-200808110830/sapi/cli/php \ gdb --arg /home/copacw/php5.2-200808110830/sapi/cli/php -n \ run-tests.php -n /home/copacw/php5.2-200808110110830/ (gdb) run (gdb) bt Start copying the output of "bt" command from the line after the "run" command which has the line with the crash info. Previous Comments: [2008-08-13 09:10:27] a dot sanders at manchester dot ac dot uk Output from gdb as follows. Is this what you were expecting? It doesn't crash out, so there's no backtrace. (gdb) run Starting program: /home/copacw/php5.2-200808110830/sapi/cli/php -n /home/copacw/php5.2-200808110830/sapi/cli/php run-tests.php -n /home/copacw/php5.2-200808110830/sapi/cli/php Warning: Unexpected character in input: '' (ASCII=16) state=1 in /home/copacw/php5.2-200808110830/sapi/cli/php on line 3309 Parse error: syntax error, unexpected T_STRING in /home/copacw/php5.2-200808110830/sapi/cli/php on line 3309 Program exited with code 0377. [2008-08-12 15:37:12] [EMAIL PROTECTED] This should work: # USE_ZEND_ALLOC=0 TEST_PHP_EXECUTABLE=/full/path/to/php \ gdb --arg /full/path/to/php -n /full/path/to/php \ run-tests.php -n /full/path/to/php/src/ [2008-08-12 15:13:20] a dot sanders at manchester dot ac dot uk When I compiled with ./configure --disable-all --enable-debug --with-pcre-regex I can do a make test and it gets to the same place as before (the cgi test) without core dumping. I then have to kill it before it consumes the system memory. You told me to run gdb as follows: USE_ZEND_ALLOC=0 gdb sapi/cli/php -n run-tests.php gdb wont accept such a command line, so I entered run -n run-tests.php from the gdb prompt and I then get the message: Starting program: /home/copacw/php5.2-200808110830/sapi/cli/php -n run-tests.php ERROR: environment variable TEST_PHP_EXECUTABLE must be set to specify PHP executable! Program exited with code 01. I've tried setting a TEST_PHP_EXECUTABLE environment variable to point to the php executable, but I still get the same message. [2008-08-12 14:32:08] [EMAIL PROTECTED] Add the output of '(gdb) bt' here of the crash. Compile using this configure line: # ./configure --disable-all --enable-debug Also, when you generate the backtrace, make sure you're not loading any php.ini file using the '-n' parameter. f.e. # USE_ZEND_ALLOC=0 gdb sapi/cli/php -n run-tests.php [2008-08-11 09:45:59] a dot sanders at manchester dot ac dot uk I downloaded the latest this morning and did ./configure --disable-all make test I compiles okay and then still seg faults when it gets to the test part of make test: ... Build complete. Don't forget to run 'make test'. Segmentation Fault - core dumped make: [test] Error 139 (ignored) Same stuff as before from gdb: #0 0x0010003c in _zval_ptr_dtor (zval_ptr=0x23f1e0) at /home/copacw/php5.2-200808110830/Zend/zend_execute_API.c:412 412 (*zval_ptr)->refcount--; (gdb) print *zval_ptr $1 = (zval *) 0x1 (gdb) I recompiled again with the DEBUG_ZEND=2 flag and got the following result: Build complete. Don't forget to run 'make test'. +---+ | ! ERROR ! | | The test-suite requires that you have pcre extension | | enabled. To enable this extension either compile your PHP | | with --with-pcre-regex or if you've compiled pcre as a| | shared module load it via php.ini.| +---+ So reconfigured and recompiled again with --disbale-all --with-pcre_regex. This time it compiled and got to test 3519 when it again tried to spawn thousands of child processes. It was in danger of consuming all available memory, so I killed it at that point. TEST 3519/3546 [sapi/cgi/tests/001.phpt] 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
#32220 [Fbk->Opn]: [PATCH] thread_resources for thread not getting freed when apache kills thread
ID: 32220 User updated by: kameshj at fastmail dot fm Reported By: kameshj at fastmail dot fm -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: * PHP Version: 5CVS, 4CVS (2005-03-25) Assigned To: dmitry New Comment: It is 2.75 years since I touched PHP code Anyways from my backup, I copied the patch to. http://pastebin.ca/1169665 Previous Comments: [2008-08-12 16:54:21] [EMAIL PROTECTED] The patch is no longer available..? [2005-12-05 09:03:14] kameshj at fastmail dot fm Yes you are correct that only IIS sapi is making use of ts_free_thread. But If you look at my patch you can see that I am registering this ts_free_thread function to pthread_push_cleanup to make sure the pthread subsystem to do the cleanup for us as soon as the thread is getting killed not to wait for the main thread to free the full thread_resources. [2005-12-01 15:51:41] [EMAIL PROTECTED] I confirm that PHP doesn't call ts_free_thread() if Web Server (except IIS) kills some thread. As a result all thread resources are not freed before server shutdown. The proposed patch is invalid and even cannot be compiled on Linux. [2005-11-10 18:36:39] [EMAIL PROTECTED] Yes, but did you check out the patch..? [2005-11-08 09:50:11] [EMAIL PROTECTED] I am not able to reproduce this. Seems like a mess in report. Apache2 worker MPM doesn't support StartThreads and MaxThreads directives. 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/32220 -- Edit this bug report at http://bugs.php.net/?id=32220&edit=1
#39171 [Asn->Fbk]: pdo_mysql configure script sets empty default socket
ID: 39171 Updated by: [EMAIL PROTECTED] Reported By: spam02 at pornel dot net -Status: Assigned +Status: Feedback Bug Type: MySQL related Operating System: * PHP Version: 5CVS, 6CVS (2008-08-11) -Assigned To: andrey +Assigned To: mysql New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi We did quite a few changes to PDO_mysql in 5.3. Previous Comments: [2008-08-12 16:24:39] [EMAIL PROTECTED] Assigned to the maintainer. [2006-10-16 20:37:42] spam02 at pornel dot net Sorry, I've given wrong bug # in my report. The orignal issue was that PDO fails with: "Can't connect to local MySQL server through socket '' (2)" [2006-10-16 20:31:26] spam02 at pornel dot net Description: I've ran onto problem described in bug #34988 I aknowledge that there is workaround by setting appropriate socket in DSN, however the root cause is that PHP defaults to socket='', which certainly won't work. If proper socket can't be found, it would be wiser to fall back to built-in default or fail configure script and require user to supply socket via something like --with-pdo-mysql-socket. Requirement to use unix_socket in DSN ties code with machine-dependent configuration and AFAIK it's not possible to find that PDO has empty string for default socket without connection attempt - that makes it imperfect workaround. -- Edit this bug report at http://bugs.php.net/?id=39171&edit=1
#34852 [Com]: [PATCH] Failure in odbc_exec() using oracle-supplied odbc driver
ID: 34852 Comment by: a dot zagli at comune dot scandicci dot fi dot it Reported By: tim dot tassonis at trivadis dot com Status: No Feedback Bug Type: ODBC related Operating System: Linux PHP Version: 5CVS-2005-11-03 (cvs) New Comment: i have the same problem with php 4.4.9 oracle client >= 10.1 (i didn't try with versions < 10.1) i saw on msdn[1] that the function SQLSetStmtOption is deprecated starting from odbc 3.x in favor of SQLSetStmtAttr; it could be the problem. furthermore, the same pieces of code are present also in php 5.2, but i can't try to see if the error persists :-( [1]http://msdn.microsoft.com/en-us/library/ms713876(VS.85).aspx Previous Comments: [2007-05-17 22:26:07] temerson at cyberitas dot com RHEL 4 (up 2 date..) PHP 4.3 (RHEL distro supplied) error: odbc_prepare(): SQL error: [unixODBC][Driver Manager]Driver does not support this function, SQL state IM001 in SQLSetStmtOption [2007-02-08 22:08:35] rpowell at opriver dot com Just wanted to say thinks for posting this patch. The EasySoft version which worked out of the box cost over $1,500. I just couldn't justify that expense when recompiling with this patch made the Oracle driver work. [2006-07-10 19:19:34] cwthomas at llu dot edu Hello, I have the same problem, but it might not be an issue with the Oracle supplied ODBC driver because I used isql (the unixODBC client) to connect to my oracle databases and it works great. I'm running RHEL 4 Update 3 with php-4.3.9-3.12, php-odbc-4.3.9-3.12, unixODBC-2.2.11-1.RHEL4.1, and the Oracle Database 10g Client Release 2 10.2.0.1.0 (not the instant client). It would be cool when this bug gets fixed to back port it so it will be included in the next EL update. [2006-05-17 11:03:15] david dot fuhr at web dot de same problem with orcale XE-client supplied with the free oracle XE database... $ php -v PHP 4.4.2-0.dotdeb.1 (cli) (built: Jan 13 2006 16:48:04) Copyright (c) 1997-2006 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies $ uname -a Linux pinocchio 2.6.8-2-386 #1 Tue Aug 16 12:46:35 UTC 2005 i686 GNU/Linux $ dpkg -l|grep odbc ii odbcinst1 2.2.4-11 Support library and helper program for acces ii php4-odbc 4.4.2-0.dotdeb ODBC module for php4 ii unixodbc 2.2.4-11 ODBC tools libraries [2006-03-31 06:56:01] adrian dot chadd at uwa dot edu dot au We're having the same problem: matrix:~# php5 -v PHP 5.1.2-1 (cli) (built: Jan 18 2006 06:49:47) Copyright (c) 1997-2006 The PHP Group Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies matrix:~# cat adri.php5 matrix:~# php5 adri.php5 result: Array ( [server] => HISDEV [description] => OracleODBC-10g ) Warning: odbc_prepare(): SQL error: [unixODBC][Driver Manager]Driver does not support this function, SQL state IM001 in SQLSetStmtOption in /root/adri.php5 on line 12 matrix:~# dpkg -l | grep odbc rc odbcinst1 2.2.4-11 Support library and helper program for acces ii odbcinst1debia 2.2.11-10 Support library and helper program for acces ii php5-odbc 5.1.2-1ODBC module for php5 ii unixodbc 2.2.11-10 ODBC tools libraries Can someone shed some light on this? What can/should I try? adrian 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/34852 -- Edit this bug report at http://bugs.php.net/?id=34852&edit=1
#45786 [Com]: FastCGI process exited unexpectedly
ID: 45786 Comment by: karelevzen at gmail dot com Reported By: karelevzen at gmail dot com Status: Open Bug Type: CGI related Operating System: Windows Vista Ultimate x64 SP1 PHP Version: 5.3CVS-2008-08-10 (CVS) Assigned To: fb-req-jani New Comment: So hey, I managed to find a 5.3 release WITH debug files at http://downloads.php.net/pierre/ ! Here is the complete bugtrace. php_cgi!fcgi_free_var+4 001b2638 00c0ddcc php5ts!zend_hash_destroy+27 00c0fe00 0010 0001 php_cgi!fcgi_finish_request+2f 00c0ddcc 001b2638 001b2708 php_cgi!fcgi_accept_request+17 00c0ddcc php_cgi!main+69f 0001 001b2638 001b1690 php_cgi!mainCRTStartup+e3 7efde000 00c0ffd4 7752cfed kernel32!BaseThreadInitThunk+e 7efde000 7770f651 ntdll!__RtlUserThreadStart+23 00405ed6 7efde000 ntdll!_RtlUserThreadStart+1b 00405ed6 7efde000 PHP_CGI!FCGI_FREE_VAR+4In php-cgi__PID__4064__Date__08_13_2008__Time_12_29_14PM__838__Second_Chance_Exception_C005.dmp the assembly instruction at php_cgi!fcgi_free_var+4 in C:\Program Files (x86)\php\php-cgi.exe from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 0 Previous Comments: [2008-08-13 06:28:16] karelevzen at gmail dot com I did that.I've downloaded the debug pack, unpacked it to: C:\Users\karel_evzen\Desktop\php-dbg and set the Symbol search path for analysis option in Debug Diagnostic Tool to: C:\Users\karel_evzen\Desktop\php-dbg Yet I get the symbols not found warning. Am I missing something? The debug pack contains runnable PHP, no pdb files. I cant find pdb files for the current 5.3 snapshot. Try it yourself. [2008-08-13 01:05:43] [EMAIL PROTECTED] Well, you propably should install the debug symbols then? They can be found at same place as the snapshots.. [2008-08-12 20:51:42] karelevzen at gmail dot com It tells me that it was not able to locate debug symbols, so I hope you find everything you need in this report. (I run it twice with the same results.) Entry point php_cgi+5ed6 Create time 12.8.2008 22:45:19 Time spent in user mode 0 Days 0:0:0.15 Time spent in kernel mode 0 Days 0:0:0.31 Function Arg 1 Arg 2 Arg 3 Source php_cgi+5604 01452638 00c0ddcc php5ts!zend_hash_destroy+27 PHP_CGI+5604WARNING - DebugDiag was not able to locate debug symbols for php-cgi.exe, so the information below may be incomplete. In php-cgi__PID__5468__Date__08_12_2008__Time_10_45_29PM__791__Second_Chance_Exception_C005.dmp the assembly instruction at php_cgi+5604 in C:\Program Files (x86)\php\php-cgi.exe from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 0 [2008-08-12 14:46:42] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, 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 for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2008-08-12 14:41:54] karelevzen at gmail dot com I am not loading any extensions. It's a fresh install with recommended php.ini and only these changes: cgi.force_redirect = 0 cgi.fix_pathinfo=1 fastcgi.impersonate = 1 and correct extension_dir As I said, I've got all the extensions commented out. 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/45786 -- Edit this bug report at http://bugs.php.net/?id=45786&edit=1
#43592 [Com]: error: utf8_mime2text() has new signature, but U8T_CANONICAL is missing
ID: 43592 Comment by: tkevans at tkevans dot com Reported By: will at willspc dot net Status: No Feedback Bug Type: Compile Failure Operating System: Linux 2.6.9-55.0.6.EL PHP Version: 5.2.5 New Comment: Sorry, I meant Solaris 9, not Solaris 8. Previous Comments: [2008-08-13 09:54:58] tkevans at tkevans dot com This error also occurs with Solaris 8 and PHP 4.4.9 (not seen in 4.4.7, the last version I successfully built). [2007-12-25 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, 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". [2007-12-17 10:02:47] [EMAIL PROTECTED] How did you install the c-client library? What OS are you using? [2007-12-14 01:50:29] will at willspc dot net Description: 5.2.5 does not build because it's missing the definition of "U8T_CANONICAL" in the imap extension. I checked utf8.h on my system (buried in perl) and it does not have U8T_CANONICAL. I'm using a CENTOS/BlueQuartz box, which uses a DoveCot implementation of imap. Oddly enough, I originally tried using the exact configure command for 4.3.9, according to phpinfo (which was originally installed) and it did not build. I'm having to install many libraries to get it to work. Reproduce code: --- ./configure --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu --target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --cache-file=../config.cache --with-config-file-path=/etc --with-config-file-scan-dir=/etc/php.d --enable-force-cgi-redirect --disable-debug --enable-pic --disable-rpath --enable-inline-optimization --with-bz2 --with-db4=/usr --with-curl --with-exec-dir=/usr/bin --with-freetype-dir=/usr --with-png-dir=/usr --with-gd=shared --enable-gd-native-ttf --without-gdbm --with-gettext --with-ncurses=shared --with-gmp --with-iconv --with-jpeg-dir=/usr --with-openssl --with-png --with-pspell --with-xml --with-expat-dir=/usr --with-dom=shared,/usr --with-dom-xslt=/usr --with-dom-exslt=/usr --with-xmlrpc=shared --with-pcre-regex=/usr --with-zlib=/usr --with-layout=GNU --enable-bcmath --enable-exif --enable-ftp --enable-magic-quotes --enable-sockets --enable-sysvsem --enable-sysvshm --enable-track-vars --enable-trans-sid --enable-yp --enable-wddx --with-pear=/usr/share/pear --with-imap=shared --with-imap-ssl --with-kerberos --with-ldap=shared --with-mysql=shared,/usr --with-pgsql=shared --with-snmp=shared,/usr --with-snmp=shared --enable-ucd-snmp-hack --with-unixODBC=shared,/usr --enable-memory-limit --enable-shmop --enable-calendar --enable-dbx --enable-dio --enable-mbstring=shared --enable-mbstr-enc-trans --enable-mbregex --with-mime-magic=/usr/share/file/magic.mime Expected result: I expect configure to succeed. Actual result: -- checking if your cpp allows macro usage in include lines... yes checking for IMAP support... yes, shared checking for IMAP Kerberos support... yes checking for IMAP SSL support... yes checking for utf8_mime2text signature... new checking for U8T_CANONICAL... no configure: error: utf8_mime2text() has new signature, but U8T_CANONICAL is missing. This should not happen. Check config.log for additional information. -- Edit this bug report at http://bugs.php.net/?id=43592&edit=1
#43592 [Com]: error: utf8_mime2text() has new signature, but U8T_CANONICAL is missing
ID: 43592 Comment by: tkevans at tkevans dot com Reported By: will at willspc dot net Status: No Feedback Bug Type: Compile Failure Operating System: Linux 2.6.9-55.0.6.EL PHP Version: 5.2.5 New Comment: This error also occurs with Solaris 8 and PHP 4.4.9 (not seen in 4.4.7, the last version I successfully built). Previous Comments: [2007-12-25 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, 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". [2007-12-17 10:02:47] [EMAIL PROTECTED] How did you install the c-client library? What OS are you using? [2007-12-14 01:50:29] will at willspc dot net Description: 5.2.5 does not build because it's missing the definition of "U8T_CANONICAL" in the imap extension. I checked utf8.h on my system (buried in perl) and it does not have U8T_CANONICAL. I'm using a CENTOS/BlueQuartz box, which uses a DoveCot implementation of imap. Oddly enough, I originally tried using the exact configure command for 4.3.9, according to phpinfo (which was originally installed) and it did not build. I'm having to install many libraries to get it to work. Reproduce code: --- ./configure --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu --target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --cache-file=../config.cache --with-config-file-path=/etc --with-config-file-scan-dir=/etc/php.d --enable-force-cgi-redirect --disable-debug --enable-pic --disable-rpath --enable-inline-optimization --with-bz2 --with-db4=/usr --with-curl --with-exec-dir=/usr/bin --with-freetype-dir=/usr --with-png-dir=/usr --with-gd=shared --enable-gd-native-ttf --without-gdbm --with-gettext --with-ncurses=shared --with-gmp --with-iconv --with-jpeg-dir=/usr --with-openssl --with-png --with-pspell --with-xml --with-expat-dir=/usr --with-dom=shared,/usr --with-dom-xslt=/usr --with-dom-exslt=/usr --with-xmlrpc=shared --with-pcre-regex=/usr --with-zlib=/usr --with-layout=GNU --enable-bcmath --enable-exif --enable-ftp --enable-magic-quotes --enable-sockets --enable-sysvsem --enable-sysvshm --enable-track-vars --enable-trans-sid --enable-yp --enable-wddx --with-pear=/usr/share/pear --with-imap=shared --with-imap-ssl --with-kerberos --with-ldap=shared --with-mysql=shared,/usr --with-pgsql=shared --with-snmp=shared,/usr --with-snmp=shared --enable-ucd-snmp-hack --with-unixODBC=shared,/usr --enable-memory-limit --enable-shmop --enable-calendar --enable-dbx --enable-dio --enable-mbstring=shared --enable-mbstr-enc-trans --enable-mbregex --with-mime-magic=/usr/share/file/magic.mime Expected result: I expect configure to succeed. Actual result: -- checking if your cpp allows macro usage in include lines... yes checking for IMAP support... yes, shared checking for IMAP Kerberos support... yes checking for IMAP SSL support... yes checking for utf8_mime2text signature... new checking for U8T_CANONICAL... no configure: error: utf8_mime2text() has new signature, but U8T_CANONICAL is missing. This should not happen. Check config.log for additional information. -- Edit this bug report at http://bugs.php.net/?id=43592&edit=1
#45761 [Fbk->Opn]: make test & make install failure
ID: 45761 User updated by: a dot sanders at manchester dot ac dot uk Reported By: a dot sanders at manchester dot ac dot uk -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Solaris 9 PHP Version: 5.2CVS-2008-08-11 Assigned To: fb-req-jani New Comment: Output from gdb as follows. Is this what you were expecting? It doesn't crash out, so there's no backtrace. (gdb) run Starting program: /home/copacw/php5.2-200808110830/sapi/cli/php -n /home/copacw/php5.2-200808110830/sapi/cli/php run-tests.php -n /home/copacw/php5.2-200808110830/sapi/cli/php Warning: Unexpected character in input: '' (ASCII=16) state=1 in /home/copacw/php5.2-200808110830/sapi/cli/php on line 3309 Parse error: syntax error, unexpected T_STRING in /home/copacw/php5.2-200808110830/sapi/cli/php on line 3309 Program exited with code 0377. Previous Comments: [2008-08-12 15:37:12] [EMAIL PROTECTED] This should work: # USE_ZEND_ALLOC=0 TEST_PHP_EXECUTABLE=/full/path/to/php \ gdb --arg /full/path/to/php -n /full/path/to/php \ run-tests.php -n /full/path/to/php/src/ [2008-08-12 15:13:20] a dot sanders at manchester dot ac dot uk When I compiled with ./configure --disable-all --enable-debug --with-pcre-regex I can do a make test and it gets to the same place as before (the cgi test) without core dumping. I then have to kill it before it consumes the system memory. You told me to run gdb as follows: USE_ZEND_ALLOC=0 gdb sapi/cli/php -n run-tests.php gdb wont accept such a command line, so I entered run -n run-tests.php from the gdb prompt and I then get the message: Starting program: /home/copacw/php5.2-200808110830/sapi/cli/php -n run-tests.php ERROR: environment variable TEST_PHP_EXECUTABLE must be set to specify PHP executable! Program exited with code 01. I've tried setting a TEST_PHP_EXECUTABLE environment variable to point to the php executable, but I still get the same message. [2008-08-12 14:32:08] [EMAIL PROTECTED] Add the output of '(gdb) bt' here of the crash. Compile using this configure line: # ./configure --disable-all --enable-debug Also, when you generate the backtrace, make sure you're not loading any php.ini file using the '-n' parameter. f.e. # USE_ZEND_ALLOC=0 gdb sapi/cli/php -n run-tests.php [2008-08-11 09:45:59] a dot sanders at manchester dot ac dot uk I downloaded the latest this morning and did ./configure --disable-all make test I compiles okay and then still seg faults when it gets to the test part of make test: ... Build complete. Don't forget to run 'make test'. Segmentation Fault - core dumped make: [test] Error 139 (ignored) Same stuff as before from gdb: #0 0x0010003c in _zval_ptr_dtor (zval_ptr=0x23f1e0) at /home/copacw/php5.2-200808110830/Zend/zend_execute_API.c:412 412 (*zval_ptr)->refcount--; (gdb) print *zval_ptr $1 = (zval *) 0x1 (gdb) I recompiled again with the DEBUG_ZEND=2 flag and got the following result: Build complete. Don't forget to run 'make test'. +---+ | ! ERROR ! | | The test-suite requires that you have pcre extension | | enabled. To enable this extension either compile your PHP | | with --with-pcre-regex or if you've compiled pcre as a| | shared module load it via php.ini.| +---+ So reconfigured and recompiled again with --disbale-all --with-pcre_regex. This time it compiled and got to test 3519 when it again tried to spawn thousands of child processes. It was in danger of consuming all available memory, so I killed it at that point. TEST 3519/3546 [sapi/cgi/tests/001.phpt] [2008-08-08 18:12:01] [EMAIL PROTECTED] s/options/patches/ :) 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/45761 -- Edit this bug report at http://bugs.php.net/?id=45761&edit=1
#45801 [Com]: PHPUnit testcase crashes (segfault)
ID: 45801 Comment by: jtaal at eljakim dot nl Reported By: jtaal at eljakim dot nl Status: Feedback Bug Type: Reproducible crash Operating System: * PHP Version: 5.2.6 Assigned To: fb-req-jani New Comment: Sebastian Bergman managed to narrow it down: http://bugs.php.net/bug.php?id=45805 please close this bug Previous Comments: [2008-08-13 01:04:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2008-08-12 16:22:27] jtaal at eljakim dot nl Description: I'm getting a segmentation fault when running a very simple PHPUnit testcase. I'm using the latest pear package from pear.phpunit.de. The testcase is issuing an E_STRICT. I think deep inside PHPUnit something happens that causes this to happen. However, since PHPUnit is "just" a bunch of PHP classes, I dare say this is a bug inside the PHP interpreter. I've been able to run and crash this on both Linux (debian lenny) and Windows XP SP3 (both using PHP 5.2.6). Reproduce code: --- getX(); } } Actual result: -- $ phpunit MyTest.php Strict Standards: Only variables should be assigned by reference in /home/jtaal/public_html/MyTest.php on line 18 PHPUnit 3.2.21 by Sebastian Bergmann. Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=45801&edit=1
#45447 [Asn]: filesystem time functions
ID: 45447 Updated by: [EMAIL PROTECTED] Reported By: Bryan dot Gallant at hma dot com Status: Assigned Bug Type: Filesystem function related Operating System: Windows Server 2008 PHP Version: 5.2.6 Assigned To: pajoye New Comment: http://phpfi.com/342491 should fix it. I'm working on fixing many filesystem functions on Windows (touch, filemtime, stat, etc.). 98% of the file tests pass now on 2k8, xp and vista. Previous Comments: [2008-08-13 06:55:38] [EMAIL PROTECTED] What filesystem is used in the one that fails and on the one where it doesn't fail..? [2008-08-04 21:13:56] Bryan dot Gallant at hma dot com Interesting Update. using the same code on an old Win2k Box against the files on the 2008 server, it works as intended. [2008-07-08 00:12:21] Bryan dot Gallant at hma dot com Sorry, it's the full path in a string. [2008-07-07 23:57:46] Bryan dot Gallant at hma dot com So far I've tried all manner of office documents, tifs, jpegs, text files, etc. [2008-07-07 21:50:54] [EMAIL PROTECTED] And $file is..? 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/45447 -- Edit this bug report at http://bugs.php.net/?id=45447&edit=1
#45447 [Fbk->Asn]: filesystem time functions
ID: 45447 Updated by: [EMAIL PROTECTED] Reported By: Bryan dot Gallant at hma dot com -Status: Feedback +Status: Assigned Bug Type: Filesystem function related Operating System: Windows Server 2008 PHP Version: 5.2.6 -Assigned To: +Assigned To: pajoye Previous Comments: [2008-08-13 06:55:38] [EMAIL PROTECTED] What filesystem is used in the one that fails and on the one where it doesn't fail..? [2008-08-04 21:13:56] Bryan dot Gallant at hma dot com Interesting Update. using the same code on an old Win2k Box against the files on the 2008 server, it works as intended. [2008-07-08 00:12:21] Bryan dot Gallant at hma dot com Sorry, it's the full path in a string. [2008-07-07 23:57:46] Bryan dot Gallant at hma dot com So far I've tried all manner of office documents, tifs, jpegs, text files, etc. [2008-07-07 21:50:54] [EMAIL PROTECTED] And $file is..? 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/45447 -- Edit this bug report at http://bugs.php.net/?id=45447&edit=1
#45805 [Ver->Csd]: user error handler crashes
ID: 45805
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Verified
+Status: Closed
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5.3CVS-2008-08-13 (CVS)
Assigned To: dmitry
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2008-08-13 06:44:01] [EMAIL PROTECTED]
Description:
The attached PHP script segfaults with both PHP_5_2 and PHP_5_3.
Reproduce code:
---
getX();
}
public function bar() {
$m = new ReflectionMethod('B', 'foo');
$m->invoke($this);
}
}
set_error_handler(
array('PHPUnit_Util_ErrorHandler', 'handleError'), E_ALL | E_STRICT
);
$o = new B;
$o->bar();
?>
Actual result:
--
[EMAIL PROTECTED] ~ % gdb php
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(gdb) r test.php
Starting program: /usr/local/php-5.3/bin/php test.php
[Thread debugging using libthread_db enabled]
[New Thread 0xb77fc6b0 (LWP 21404)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb77fc6b0 (LWP 21404)]
0x085674c0 in _get_zval_ptr_var (node=0x8a5546c, Ts=0x8c0f888,
should_free=0xbfe03efc, tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/Zend/zend_execute.c:197
197 if (T->str_offset.str->type != IS_STRING
(gdb) bt
#0 0x085674c0 in _get_zval_ptr_var (node=0x8a5546c, Ts=0x8c0f888,
should_free=0xbfe03efc, tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/Zend/zend_execute.c:197
#1 0x085c65fa in ZEND_ASSIGN_SPEC_CV_VAR_HANDLER
(execute_data=0x8c0f82c, tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/Zend/zend_vm_execute.h:27470
#2 0x085c69fd in ZEND_ASSIGN_REF_SPEC_CV_VAR_HANDLER
(execute_data=0x8c0f82c, tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/Zend/zend_vm_execute.h:27515
#3 0x085628ec in execute (op_array=0x8be2214, tsrm_ls=0x8a53070) at
/usr/local/src/php/php-5.3/Zend/zend_vm_execute.h:104
#4 0x08523d5e in zend_call_function (fci=0xbfe04144,
fci_cache=0xbfe04168, tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/Zend/zend_execute_API.c:876
#5 0x08237261 in zim_reflection_method_invoke (ht=1,
return_value=0x8be3e5c, return_value_ptr=0x0, this_ptr=0x8be0854,
return_value_used=0, tsrm_ls=0x8a53070) at
/usr/local/src/php/php-5.3/ext/reflection/php_reflection.c:2510
#6 0x085639bf in zend_do_fcall_common_helper_SPEC
(execute_data=0x8c0f738, tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/Zend/zend_vm_execute.h:315
#7 0x08564a4f in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x8c0f738, tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/Zend/zend_vm_execute.h:428
#8 0x085628ec in execute (op_array=0x8be2b68, tsrm_ls=0x8a53070) at
/usr/local/src/php/php-5.3/Zend/zend_vm_execute.h:104
#9 0x085347e4 in zend_execute_scripts (type=8, tsrm_ls=0x8a53070,
retval=0x0, file_count=3)
at /usr/local/src/php/php-5.3/Zend/zend.c:1199
#10 0x084ad611 in php_execute_script (primary_file=0xbfe06630,
tsrm_ls=0x8a53070)
at /usr/local/src/php/php-5.3/main/main.c:2073
#11 0x085d19a4 in main (argc=2, argv=0xbfe067a4) at
/usr/local/src/php/php-5.3/sapi/cli/php_cli.c:1132
--
Edit this bug report at http://bugs.php.net/?id=45805&edit=1
