[PHP-BUG] Bug #54585 [NEW]: track_errors causes segfault
From: Operating system: Linux PHP version: 5.3SVN-2011-04-21 (snap) Package: Reproducible crash Bug Type: Bug Bug description:track_errors causes segfault Description: When track_errors is On then simple code causes php segfault. It was tested with 5.3.6 final and also with recent php5.3-201104201030 snap. Test script: --- [arekm@t400 ~/public_html]$ cat a.ini [PHP] track_errors = On [arekm@t400 ~/public_html]$ cat a.php [arekm@t400 ~/public_html]$ php -n -c a.ini a.php zsh: segmentation fault php -n -c a.ini a.php Expected result: No segfault. Actual result: -- Starting program: /usr/bin/php -n -c php.ini a.php [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. zval_mark_grey (pz=) at /usr/src/debug/php-5.3.6.1/Zend/zend_gc.c:372 372 pz = *(zval**)p->pData; (gdb) bt #0 zval_mark_grey (pz=) at /usr/src/debug/php-5.3.6.1/Zend/zend_gc.c:372 #1 0x77cb7c35 in gc_mark_roots () at /usr/src/debug/php-5.3.6.1/Zend/zend_gc.c:435 #2 gc_collect_cycles () at /usr/src/debug/php-5.3.6.1/Zend/zend_gc.c:664 #3 0x77c9b0ed in zend_deactivate () at /usr/src/debug/php-5.3.6.1/Zend/zend.c:900 #4 0x77c48a20 in php_request_shutdown (dummy=) at /usr/src/debug/php-5.3.6.1/main/main.c:1637 #5 0x00403d0c in main (argc=5, argv=0x7fffeb68) at /usr/src/debug/php-5.3.6.1/sapi/cli/php_cli.c:1374 (gdb) print p $1 = (Bucket *) 0x4 (gdb) print p->pData Cannot access memory at address 0x40010 (gdb) -- Edit bug report at http://bugs.php.net/bug.php?id=54585&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54585&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54585&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54585&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54585&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54585&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54585&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54585&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54585&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54585&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54585&r=support Expected behavior: http://bugs.php.net/fix.php?id=54585&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54585&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54585&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54585&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54585&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54585&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54585&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54585&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54585&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54585&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54585&r=mysqlcfg
Bug #54583 [Opn->Fbk]: Segfault when trying to reexecute statement after exception with libmysql
Edit report at http://bugs.php.net/bug.php?id=54583&edit=1
ID: 54583
Updated by: johan...@php.net
Reported by:an0nym at narod dot ru
Summary:Segfault when trying to reexecute statement after
exception with libmysql
-Status: Open
+Status: Feedback
Type: Bug
Package:PDO related
Operating System: CentOS 5.5 x86_64
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
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.
Works for me with libmysql and mysqlnd. Please provide a stacktrace and
the version of libmysql you are using.
Previous Comments:
[2011-04-21 08:29:44] an0nym at narod dot ru
There was a similar problem that was patched in PHP 5.3.6.
http://bugs.php.net/53551
[2011-04-21 08:28:36] an0nym at narod dot ru
Description:
PHP segfaults when prepared statement that threw an exception is
reexecuted. pdo_mysql, libmysql. Haven't tested with mysqlnd yet.
Test script:
---
PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES => false));
$DB->exec("CREATE TEMPORARY TABLE t(f VARCHAR(1))");
$stmt = $DB->prepare("INSERT INTO t VALUES(:value)");
$value = "aa";
$stmt->bindParam(":value", $value);
try {
$stmt->execute();
} catch (PDOException $e) {}
$stmt->execute();
Expected result:
Script successfully executed
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/bug.php?id=54583&edit=1
Bug #54583 [Com]: Segfault when trying to reexecute statement after exception with libmysql
Edit report at http://bugs.php.net/bug.php?id=54583&edit=1
ID: 54583
Comment by: an0nym at narod dot ru
Reported by:an0nym at narod dot ru
Summary:Segfault when trying to reexecute statement after
exception with libmysql
Status: Feedback
Type: Bug
Package:PDO related
Operating System: CentOS 5.5 x86_64
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
It seems you don't have strict mode enabled.
Try this.
PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES => false,
PDO::MYSQL_ATTR_INIT_COMMAND => "SET SQL_MODE =
'STRICT_ALL_TABLES'"));
$DB->exec("CREATE TEMPORARY TABLE t(f VARCHAR(1))");
$stmt = $DB->prepare("INSERT INTO t VALUES(:value)");
$value = "aa";
$stmt->bindParam(":value", $value);
try {
$stmt->execute();
} catch (PDOException $e) {}
$stmt->execute();
Previous Comments:
[2011-04-21 11:28:22] johan...@php.net
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.
Works for me with libmysql and mysqlnd. Please provide a stacktrace and
the version of libmysql you are using.
[2011-04-21 08:29:44] an0nym at narod dot ru
There was a similar problem that was patched in PHP 5.3.6.
http://bugs.php.net/53551
[2011-04-21 08:28:36] an0nym at narod dot ru
Description:
PHP segfaults when prepared statement that threw an exception is
reexecuted. pdo_mysql, libmysql. Haven't tested with mysqlnd yet.
Test script:
---
PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES => false));
$DB->exec("CREATE TEMPORARY TABLE t(f VARCHAR(1))");
$stmt = $DB->prepare("INSERT INTO t VALUES(:value)");
$value = "aa";
$stmt->bindParam(":value", $value);
try {
$stmt->execute();
} catch (PDOException $e) {}
$stmt->execute();
Expected result:
Script successfully executed
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/bug.php?id=54583&edit=1
Bug #54583 [Fbk->Opn]: Segfault when trying to reexecute statement after exception with libmysql
Edit report at http://bugs.php.net/bug.php?id=54583&edit=1
ID: 54583
User updated by:an0nym at narod dot ru
Reported by:an0nym at narod dot ru
Summary:Segfault when trying to reexecute statement after
exception with libmysql
-Status: Feedback
+Status: Open
Type: Bug
Package:PDO related
Operating System: CentOS 5.5 x86_64
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Try new test code, please. I will submit backtrace when I manage to
generate it.
Previous Comments:
[2011-04-21 11:54:42] an0nym at narod dot ru
It seems you don't have strict mode enabled.
Try this.
PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES => false,
PDO::MYSQL_ATTR_INIT_COMMAND => "SET SQL_MODE =
'STRICT_ALL_TABLES'"));
$DB->exec("CREATE TEMPORARY TABLE t(f VARCHAR(1))");
$stmt = $DB->prepare("INSERT INTO t VALUES(:value)");
$value = "aa";
$stmt->bindParam(":value", $value);
try {
$stmt->execute();
} catch (PDOException $e) {}
$stmt->execute();
[2011-04-21 11:28:22] johan...@php.net
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.
Works for me with libmysql and mysqlnd. Please provide a stacktrace and
the version of libmysql you are using.
[2011-04-21 08:29:44] an0nym at narod dot ru
There was a similar problem that was patched in PHP 5.3.6.
http://bugs.php.net/53551
[2011-04-21 08:28:36] an0nym at narod dot ru
Description:
PHP segfaults when prepared statement that threw an exception is
reexecuted. pdo_mysql, libmysql. Haven't tested with mysqlnd yet.
Test script:
---
PDO::ERRMODE_EXCEPTION,
PDO::ATTR_EMULATE_PREPARES => false));
$DB->exec("CREATE TEMPORARY TABLE t(f VARCHAR(1))");
$stmt = $DB->prepare("INSERT INTO t VALUES(:value)");
$value = "aa";
$stmt->bindParam(":value", $value);
try {
$stmt->execute();
} catch (PDOException $e) {}
$stmt->execute();
Expected result:
Script successfully executed
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/bug.php?id=54583&edit=1
Bug #31562 [Com]: __autoload() problem with static variables
Edit report at http://bugs.php.net/bug.php?id=31562&edit=1 ID: 31562 Comment by: liujingfeng at snda dot com Reported by:aalbre99 at student dot hia dot no Summary:__autoload() problem with static variables Status: Closed Type: Bug Package:Scripting Engine problem Operating System: * PHP Version:5.* Assigned To:helly Block user comment: N Private report: N New Comment: I get the same bug. My php ver is 5.2 . Previous Comments: [2005-03-10 03:34:35] he...@php.net 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. [2005-03-06 22:59:09] aalbre99 at student dot hia dot no Sorry. Replaced all my PHP files with the files in http://snaps.php.net/win32/php5-win32-latest.zip. Still same error... (I'am using the built-in IIS in Windows XP SP2) - Output from 'test.php': - Fatal error: Class 'TestClass' not found in C:\_ECLIPSE_\test\other\Other.php on line 5 [2005-02-28 21:02:08] sni...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-01-15 13:51:02] aalbre99 at student dot hia dot no I have created an application which reproduces the error. And now I see that the error is caused by something other than I thought in the beginning... Put the following files in the following folder structure, and load 'test.php'... /test.php /class_files/ErrorHandler.php /class_files/TestClass.php /other/Other.php #test.php# #TestClass.php# #ErrorHandler.php# #Other.php# [2005-01-15 13:06:37] aalbre99 at student dot hia dot no YES. I managed to reproduce the error in my PHP application! (One line was changed...) I will now try to make a test application I can post here which generates the same error... Stay tuned... 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/bug.php?id=31562 -- Edit this bug report at http://bugs.php.net/bug.php?id=31562&edit=1
Bug #54580 [Opn]: get_browser() segmentation fault
Edit report at http://bugs.php.net/bug.php?id=54580&edit=1 ID: 54580 Updated by: cataphr...@php.net Reported by:tomas dot brastavicius at quantum dot lt Summary:get_browser() segmentation fault Status: Open Type: Bug Package:Unknown/Other Function Operating System: Ubuntu 10.10 (x86_64) PHP Version:trunk-SVN-2011-04-20 (SVN) Block user comment: N Private report: N New Comment: The problem is not ini_set, the segault occurs because PHP assumes the parse result of the code is initialized when the ini setting is non-empty; however, by using php_admin_value, the ini setting value is set after when the parsing code runs, so when it runs it leaves memory initialized because the ini setting is empty. This should be fixed by having the ini setting change via php_admin_value trigger the ini reading and structure initialization. Previous Comments: [2011-04-21 00:06:11] tomas dot brastavicius at quantum dot lt Description: PHP is running as an Apache module. The following configuration was used to compile PHP: ./configure --with-apxs2=/usr/bin/apxs2 --enable-debug --disable-all Test script: --- 1. Be sure browscap directive is commented out in php.ini 2. Set browscap setting in Apache configuration file, i.e. php_admin_value browscap "/some/path/browscap.ini" 3. Run the following PHP script: arBuckets[nIndex]; Full backtrace: #0 0x709db2af in zend_hash_find (ht=0x70e6e100, arKey=0x77f6b760 "User-Agent", nKeyLength=109, pData=0x7fffbdb8) at /a/php-trunk/Zend/zend_hash.c:905 #1 0x708ac3b1 in zif_get_browser (ht=0, return_value=0x77f62be8, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /a/php-trunk/ext/standard/browscap.c:360 #2 0x70a09972 in zend_do_fcall_common_helper_SPEC (execute_data=0x77f2e338) at /a/php-trunk/Zend/zend_vm_execute.h:642 #3 0x70a0ffd2 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x77f2e338) at /a/php-trunk/Zend/zend_vm_execute.h:1963 #4 0x70a08077 in execute (op_array=0x77f611c0) at /a/php-trunk/Zend/zend_vm_execute.h:410 #5 0x709c88a3 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /a/php-trunk/Zend/zend.c:1212 #6 0x70933982 in php_execute_script (primary_file=0x7fffe670) at /a/php-trunk/main/main.c:2349 #7 0x70b0de48 in php_handler (r=0x784bbea0) at /a/php-trunk/sapi/apache2handler/sapi_apache2.c:667 #8 0x77fd6310 in ap_run_handler (r=0x784bbea0) at /build/buildd/apache2-2.2.16/server/config.c:159 #9 0x77fd9c9e in ap_invoke_handler (r=0x784bbea0) at /build/buildd/apache2-2.2.16/server/config.c:377 #10 0x77fe77b8 in ap_process_request (r=0x784bbea0) at /build/buildd/apache2-2.2.16/modules/http/http_request.c:282 #11 0x77fe4748 in ap_process_http_connection (c=0x784adc90) at /build/buildd/apache2-2.2.16/modules/http/http_core.c:190 #12 0x77fddef8 in ap_run_process_connection (c=0x784adc90) at /build/buildd/apache2-2.2.16/server/connection.c:43 #13 0x77fec177 in child_main (child_num_arg=) at /build/buildd/apache2-2.2.16/server/mpm/prefork/prefork.c:662 #14 0x77fec446 in make_child (s=0x78214938, slot=0) at /build/buildd/apache2-2.2.16/server/mpm/prefork/prefork.c:702 #15 0x77feca93 in ap_mpm_run (_pconf=, plog=, s=) at /build/buildd/apache2-2.2.16/server/mpm/prefork/prefork.c:978 #16 0x77fc2530 in main (argc=2, argv=0x7fffecf8) at /build/buildd/apache2-2.2.16/server/main.c:742 -- Edit this bug report at http://bugs.php.net/bug.php?id=54580&edit=1
[PHP-BUG] Req #54587 [NEW]: RecursiveTreeIterator posfix is not implemented
From:
Operating system:
PHP version: 5.3.6
Package: SPL related
Bug Type: Feature/Change Request
Bug description:RecursiveTreeIterator posfix is not implemented
Description:
RecursiveTreeIterator posfix is not implemented, and
RecursiveTreeIterator::getPostfix return nothing (RETVAL_STRINGL("", 0,
1);)
I think it's will good to create const (POSTFIX_*) and
RecursiveTreeIterator::setProstfixPart
All postfix should be blank at the beginning
--
Edit bug report at http://bugs.php.net/bug.php?id=54587&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54587&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54587&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54587&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54587&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54587&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54587&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54587&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54587&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54587&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54587&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54587&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54587&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54587&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54587&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54587&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54587&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54587&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54587&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54587&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54587&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54587&r=mysqlcfg
Bug #54585 [Opn->Asn]: track_errors causes segfault
Edit report at http://bugs.php.net/bug.php?id=54585&edit=1 ID: 54585 Updated by: fel...@php.net Reported by:arekm at maven dot pl Summary:track_errors causes segfault -Status: Open +Status: Assigned Type: Bug Package:Reproducible crash Operating System: Linux PHP Version:5.3SVN-2011-04-21 (snap) -Assigned To: +Assigned To:dmitry Block user comment: N Private report: N Previous Comments: [2011-04-21 11:02:20] arekm at maven dot pl Description: When track_errors is On then simple code causes php segfault. It was tested with 5.3.6 final and also with recent php5.3-201104201030 snap. Test script: --- [arekm@t400 ~/public_html]$ cat a.ini [PHP] track_errors = On [arekm@t400 ~/public_html]$ cat a.php [arekm@t400 ~/public_html]$ php -n -c a.ini a.php zsh: segmentation fault php -n -c a.ini a.php Expected result: No segfault. Actual result: -- Starting program: /usr/bin/php -n -c php.ini a.php [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. zval_mark_grey (pz=) at /usr/src/debug/php-5.3.6.1/Zend/zend_gc.c:372 372 pz = *(zval**)p->pData; (gdb) bt #0 zval_mark_grey (pz=) at /usr/src/debug/php-5.3.6.1/Zend/zend_gc.c:372 #1 0x77cb7c35 in gc_mark_roots () at /usr/src/debug/php-5.3.6.1/Zend/zend_gc.c:435 #2 gc_collect_cycles () at /usr/src/debug/php-5.3.6.1/Zend/zend_gc.c:664 #3 0x77c9b0ed in zend_deactivate () at /usr/src/debug/php-5.3.6.1/Zend/zend.c:900 #4 0x77c48a20 in php_request_shutdown (dummy=) at /usr/src/debug/php-5.3.6.1/main/main.c:1637 #5 0x00403d0c in main (argc=5, argv=0x7fffeb68) at /usr/src/debug/php-5.3.6.1/sapi/cli/php_cli.c:1374 (gdb) print p $1 = (Bucket *) 0x4 (gdb) print p->pData Cannot access memory at address 0x40010 (gdb) -- Edit this bug report at http://bugs.php.net/bug.php?id=54585&edit=1
[PHP-BUG] Bug #54588 [NEW]: Included files should not output shebang
From: Operating system: All PHP version: 5.3SVN-2011-04-21 (snap) Package: Output Control Bug Type: Bug Bug description:Included files should not output shebang Description: When writing CLI scripts, one typically adds a shebang to the beginning of the script. When the script is executed, the shebang is not outputted. On occasion, it's useful to include another CLI script. When the file is included, the shebang on the included file is outputted, contrary to expected behavior. Test script: --- file1.php: #!/usr/bin/php file2.php: #!/usr/bin/php Expected result: Including file2 Inside file2 Actual result: -- Including file2 #!/usr/bin/php Inside file2 -- Edit bug report at http://bugs.php.net/bug.php?id=54588&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54588&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54588&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54588&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54588&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54588&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54588&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54588&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54588&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54588&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54588&r=support Expected behavior: http://bugs.php.net/fix.php?id=54588&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54588&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54588&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54588&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54588&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54588&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54588&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54588&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54588&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54588&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54588&r=mysqlcfg
Bug #48417 [Com]: Missing config.w32.h
Edit report at http://bugs.php.net/bug.php?id=48417&edit=1 ID: 48417 Comment by: jezmax at seznam dot cz Reported by:php at schubec dot com Summary:Missing config.w32.h Status: Bogus Type: Bug Package:Compile Failure Operating System: Windows PHP Version:5.3.0RC2 Block user comment: N Private report: N New Comment: svn Trunk Properties NameValue svn:ignore Makefile build-defs.h configuration-parser.c configuration-parser.h configuration-parser.output configuration-scanner.c internal_functions.c internal_functions_cli.c php_config.h php_config.h.in config.w32.h ... Previous Comments: [2009-05-28 18:18:37] php at schubec dot com Hi! >it is generated at configure time. Okay... thank you. But why was it part of the PHP 5.2.9 sourcecode download then? So the bug is not that it is missing in 5.3.0RC2 but that it was part of 5.2.9, right? Thank you! [2009-05-28 17:41:36] paj...@php.net it is generated at configure time. [2009-05-28 17:39:51] php at schubec dot com Description: File main/config.w32.h in PHP 5.3.0RC2 is missing. The file is required because Zend/zend_config.w32.h includes it. The missing file causes that PHP cannot be comiled. Compiler: VC6 OS: WindowsXP PS: The file was part of PHP 5.2.9 Sourcecode, I just looked that up. Reproduce code: --- Tryp compile PHP under Windows. Expected result: PHP able to compile :-) Actual result: -- PHP unable to compile :-( -- Edit this bug report at http://bugs.php.net/bug.php?id=48417&edit=1
