#21623 [NEW]: Turning on Magic quotes Segfaults PHP
From: [EMAIL PROTECTED] Operating system: RedHat PHP version: 5CVS-2003-01-13 (dev) PHP Bug Type: Reproducible crash Bug description: Turning on Magic quotes Segfaults PHP I thought this might be because I was running an older version 4.4-dev version of PHP from CVS that I had hacked up a bit, but it turns out it's in the current CVS as well.. I am honestly not sure why PHP is crashing, but it has something to do with turning magic_quotes_runtime on. It doesn't break all the time, only when using the PostNuke package. Unfortunately I have no idea how/where it crashes... here's the backtrace... (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. chunk_alloc (ar_ptr=0x401cd520, nb=105) at malloc.c:2993 2993malloc.c: No such file or directory. in malloc.c Obviously something has gone wrong trying to malloc memory, however I don't have any real way to see what PHP code actually breaks everything... Perhaps I'll try to install one of the realtime debuggers and attempt to determine where exactly it's crashing. Configured with: --with-mysql --with-apxs -- Edit bug report at http://bugs.php.net/?id=21623&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21623&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21623&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21623&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21623&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21623&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21623&r=support Expected behavior: http://bugs.php.net/fix.php?id=21623&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21623&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21623&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21623&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21623&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21623&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21623&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21623&r=gnused
#21623 [Fbk->Opn]: Turning on Magic quotes Segfaults PHP
ID: 21623 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: RedHat PHP Version: 5CVS-2003-01-13 (dev) New Comment: Here's the bt: One more thing -- magic_quotes_gpc is on and working fine... things also work if the magic quotes runtime are disabled. #0 chunk_alloc (ar_ptr=0x401cd520, nb=105) at malloc.c:2993 #1 0x4011b02c in __libc_malloc (bytes=100) at malloc.c:2811 #2 0x402ae54b in _emalloc (size=83) at /home/php/php4/Zend/zend_alloc.c:158 #3 0x402c0b03 in zend_hash_add_or_update (ht=0x8202e64, arKey=0x8216bc4 "s:30:\\\"Bad arguments for API function\\\";PNSVuid", nKeyLength=48, pData=0xbfff8b50, nDataSize=4, pDest=0x0, flag=1) at /home/php/php4/Zend/zend_hash.c:262 #4 0x402bff53 in zend_set_hash_symbol (symbol=0x823d7e4, name=0x8216bc4 "s:30:\\\"Bad arguments for API function\\\";PNSVuid", name_length=47, is_ref=0, num_symbol_tables=1) at /home/php/php4/Zend/zend_API.c:1261 #5 0x4021e4ea in php_set_session_var ( name=0x8216bc4 "s:30:\\\"Bad arguments for API function\\\";PNSVuid", namelen=47, state_val=0x823d7e4, var_hash=0xbfff8bc8) at /home/php/php4/ext/session/session.c:324 #6 0x4021ec90 in ps_srlzr_decode_php ( val=0x821693c "PNSVrand|i:625621835;PNSVlang|s:3:\\\"eng\\\";PNSVerrormsg|s:30:\\\"Bad arguments for API function\\\";PNSVuid|i:2;PNSVrememberme|i:1;", vallen=126) at /home/php/php4/ext/session/session.c:487 #7 0x4021ef46 in php_session_decode ( val=0x821693c "PNSVrand|i:625621835;PNSVlang|s:3:\\\"eng\\\";PNSVerrormsg|s:30:\\\"Bad arguments for API function\\\";PNSVuid|i:2;PNSVrememberme|i:1;", vallen=126) at /home/php/php4/ext/session/session.c:533 #8 0x4021f3c9 in php_session_initialize () at /home/php/php4/ext/session/session.c:692 #9 0x4022044f in php_session_start () at /home/php/php4/ext/session/session.c:1095 #10 0x402217b9 in zif_session_start (ht=0, return_value=0x823c43c, this_ptr=0x0, return_value_used=0) at /home/php/php4/ext/session/session.c:1540 #11 0x402cfe24 in execute (op_array=0x8204860) at /home/php/php4/Zend/zend_execute.c:1596 #12 0x402cffe2 in execute (op_array=0x812cea0) at /home/php/php4/Zend/zend_execute.c:1640 #13 0x402cffe2 in execute (op_array=0x8111434) at /home/php/php4/Zend/zend_execute.c:1640 #14 0x402bd630 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/php/php4/Zend/zend.c:925 #15 0x4029703d in php_execute_script (primary_file=0xb620) at /home/php/php4/main/main.c:1691 #16 0x402d73c6 in apache_php_module_main (r=0x8100e24, display_source_mode=0) at /home/php/php4/sapi/apache/sapi_apache.c:55 #17 0x402d7f32 in send_php (r=0x8100e24, display_source_mode=0, filename=0x0) at /home/php/php4/sapi/apache/mod_php4.c:589 #18 0x402d7f86 in send_parsed_php (r=0x8100e24) at /home/php/php4/sapi/apache/mod_php4.c:604 #19 0x0806a5f7 in ap_invoke_handler () #20 0x0807ee77 in process_request_internal () #21 0x0807f29b in ap_internal_redirect () #22 0x0805f530 in handle_dir () #23 0x0806a5f7 in ap_invoke_handler () #24 0x0807ee77 in process_request_internal () #25 0x0807eed8 in ap_process_request () #26 0x0807612d in child_main () #27 0x080762d8 in make_child () #28 0x0807644c in startup_children () #29 0x08076ac4 in standalone_main () #30 0x08077317 in main () #31 0x400bb306 in __libc_start_main (main=0x8076f80 , argc=2, ubp_av=0xbb34, init=0x804e5d8 <_init>, fini=0x8094460 <_fini>, rtld_fini=0x4000d2dc <_dl_fini>, stack_end=0xbb2c) at ../sysdeps/generic/libc-start.c:129 Previous Comments: [2003-01-13 13:33:06] [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 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. [2003-01-13 13:31:51] [EMAIL PROTECTED] I thought this might be because I was running an older version 4.4-dev version of PHP from CVS that I had hacked up a bit, but it turns out it's in the current CVS as well.. I am honestly not sure why PHP is crashing, but it has something to do with turning magic_quotes_runtime on. It doesn't break all the time, only when using the PostNuke package. Unfortunately I have no idea how/where it crashes... here's the backtrace... (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. chunk_alloc (ar_ptr=0x401cd520, nb=105) at malloc.c:2993 29
#21623 [Opn]: Turning on Magic quotes Segfaults PHP
ID: 21623 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: RedHat PHP Version: 5CVS-2003-01-13 (dev) New Comment: No, it seems to be breaking in 4.3.0 as well. Previous Comments: [2003-01-13 17:17:31] [EMAIL PROTECTED] Does it work with 4.3.0? :) [2003-01-13 13:44:20] [EMAIL PROTECTED] Here's the bt: One more thing -- magic_quotes_gpc is on and working fine... things also work if the magic quotes runtime are disabled. #0 chunk_alloc (ar_ptr=0x401cd520, nb=105) at malloc.c:2993 #1 0x4011b02c in __libc_malloc (bytes=100) at malloc.c:2811 #2 0x402ae54b in _emalloc (size=83) at /home/php/php4/Zend/zend_alloc.c:158 #3 0x402c0b03 in zend_hash_add_or_update (ht=0x8202e64, arKey=0x8216bc4 "s:30:\\\"Bad arguments for API function\\\";PNSVuid", nKeyLength=48, pData=0xbfff8b50, nDataSize=4, pDest=0x0, flag=1) at /home/php/php4/Zend/zend_hash.c:262 #4 0x402bff53 in zend_set_hash_symbol (symbol=0x823d7e4, name=0x8216bc4 "s:30:\\\"Bad arguments for API function\\\";PNSVuid", name_length=47, is_ref=0, num_symbol_tables=1) at /home/php/php4/Zend/zend_API.c:1261 #5 0x4021e4ea in php_set_session_var ( name=0x8216bc4 "s:30:\\\"Bad arguments for API function\\\";PNSVuid", namelen=47, state_val=0x823d7e4, var_hash=0xbfff8bc8) at /home/php/php4/ext/session/session.c:324 #6 0x4021ec90 in ps_srlzr_decode_php ( val=0x821693c "PNSVrand|i:625621835;PNSVlang|s:3:\\\"eng\\\";PNSVerrormsg|s:30:\\\"Bad arguments for API function\\\";PNSVuid|i:2;PNSVrememberme|i:1;", vallen=126) at /home/php/php4/ext/session/session.c:487 #7 0x4021ef46 in php_session_decode ( val=0x821693c "PNSVrand|i:625621835;PNSVlang|s:3:\\\"eng\\\";PNSVerrormsg|s:30:\\\"Bad arguments for API function\\\";PNSVuid|i:2;PNSVrememberme|i:1;", vallen=126) at /home/php/php4/ext/session/session.c:533 #8 0x4021f3c9 in php_session_initialize () at /home/php/php4/ext/session/session.c:692 #9 0x4022044f in php_session_start () at /home/php/php4/ext/session/session.c:1095 #10 0x402217b9 in zif_session_start (ht=0, return_value=0x823c43c, this_ptr=0x0, return_value_used=0) at /home/php/php4/ext/session/session.c:1540 #11 0x402cfe24 in execute (op_array=0x8204860) at /home/php/php4/Zend/zend_execute.c:1596 #12 0x402cffe2 in execute (op_array=0x812cea0) at /home/php/php4/Zend/zend_execute.c:1640 #13 0x402cffe2 in execute (op_array=0x8111434) at /home/php/php4/Zend/zend_execute.c:1640 #14 0x402bd630 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/php/php4/Zend/zend.c:925 #15 0x4029703d in php_execute_script (primary_file=0xb620) at /home/php/php4/main/main.c:1691 #16 0x402d73c6 in apache_php_module_main (r=0x8100e24, display_source_mode=0) at /home/php/php4/sapi/apache/sapi_apache.c:55 #17 0x402d7f32 in send_php (r=0x8100e24, display_source_mode=0, filename=0x0) at /home/php/php4/sapi/apache/mod_php4.c:589 #18 0x402d7f86 in send_parsed_php (r=0x8100e24) at /home/php/php4/sapi/apache/mod_php4.c:604 #19 0x0806a5f7 in ap_invoke_handler () #20 0x0807ee77 in process_request_internal () #21 0x0807f29b in ap_internal_redirect () #22 0x0805f530 in handle_dir () #23 0x0806a5f7 in ap_invoke_handler () #24 0x0807ee77 in process_request_internal () #25 0x0807eed8 in ap_process_request () #26 0x0807612d in child_main () #27 0x080762d8 in make_child () #28 0x0807644c in startup_children () #29 0x08076ac4 in standalone_main () #30 0x08077317 in main () #31 0x400bb306 in __libc_start_main (main=0x8076f80 , argc=2, ubp_av=0xbb34, init=0x804e5d8 <_init>, fini=0x8094460 <_fini>, rtld_fini=0x4000d2dc <_dl_fini>, stack_end=0xbb2c) at ../sysdeps/generic/libc-start.c:129 [2003-01-13 13:33:06] [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 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. [2003-01-13 13:31:51] [EMAIL PROTECTED] I thought this might be because I was running an older version 4.4-dev version of PHP from CVS that I had hacked up a bit, but it turns out it's in the current CVS as well.. I am honestly not sure why PHP is crashing, but it has something to do with turning magic_quotes_runtime on. It doesn't break all the time, only when using the P
#21695 [NEW]: CLI Return codes not working properly
From: [EMAIL PROTECTED] Operating system: Windows XP PHP version: 4.3.0 PHP Bug Type: *General Issues Bug description: CLI Return codes not working properly This very well may be a problem with Windows XP instead of PHP... but if nothing else it should be documented: On redhat, (of course, replacing the system call to the linux version of php-cli) this script echo's the return value as '1' which is the expected behavior. However, this same script ran in windows produces does not. Instead, it seems to be always return 254 regardless of the exit code. Please note that the above script has only been provided as an example of the problem -- it has been confirmed that system() and the -r argument are not causing this issue. -- Edit bug report at http://bugs.php.net/?id=21695&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21695&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21695&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21695&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21695&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21695&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21695&r=support Expected behavior: http://bugs.php.net/fix.php?id=21695&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21695&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21695&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21695&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21695&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21695&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21695&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21695&r=gnused
#21702 [WFx->Opn]: nested foreach on same array using reference fails
ID: 21702 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Wont fix +Status: Open Bug Type: Scripting Engine problem Operating System: Any PHP Version: Any New Comment: I don't want to cause too much of a fuss about this -- but after looking at it myself I do think it has some merit... There is no reason why by simply adding a reference to the array in question the foreach() statement should suddenly change it's behavior. I've seen "incorrect" behaviors in ZE not be treated as bogus before (such as when working with bit operations) -- this seems to fall under a simliar category. At the very least, it's a feature/change request. Previous Comments: [2003-01-21 23:11:38] [EMAIL PROTECTED] 1. No 2. Yes 3. No [2003-01-21 23:01:40] [EMAIL PROTECTED] Reopening due to lack of evidence that this is not a bug. Derick has not answered my email, he has not provided an explanation in his bug-closing comment, I have not found any discussion about this in the php-dev mailing list archive, and until recently, the behaviour has been in direct contradiction with the manual (while now the manual is unclear). Therefore, I have to assume that the statement "this is not a bug" is unfounded. I thought that this was an open source project? And even if the current behaviour was really intended, the documentation needs to be clarified. Let me ask three questions: 1) Is the current behaviour optimal? 2) If not, is it too late to correct it (because of backward compatibility)? 3) If not, is it important enough to invest time in it? My opinion: no, no, depends on who's time is in question. ;-) [2003-01-17 12:12:19] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php not a bug [2003-01-17 11:55:33] [EMAIL PROTECTED] > No matter what you call this, as a convention of open-source > projects, documentation is generally supposed to come up > after coding stuff. "Supposed to"? I hope not. It does, usually, that's true. But in this case, there _was_ documentation, and the program doesn't conform to it. And we're talking about language semantics, not something insignificant like configuration options. > the codes determine the design Tell me which programming language interpreter or compiler was created this way? As for the other nastiness example that you provided, it certainly does seem nasty. Should that mean "there is at least another one nastiness, so that is a good enough excuse to make ad-hoc language design decisions"? I don't get it. And yes, a language design decision it is, and it must be made. Either we correct the documentation (it's still not completely clear, though at least it's not so undoubtedly incorrect as two months ago), or we correct the implementation. Judging by the lack of interest so far (this is only the second bug report that I know of, and the docs have been incorrect for more than two years), not many people are relying on the current (broken) behaviour. (Anyway, why would anyone rely on such a thing?) Thus, we have a great opportunity to do the Right Thing! Anyway, I'm leaving for the weekend right now, so don't close this bug before I can have another round at it on Monday, ok? ;-) [2003-01-17 10:22:30] [EMAIL PROTECTED] No matter what you call this, as a convention of open-source projects, documentation is generally supposed to come up after coding stuff. In other words, the codes determine the design, and the documents are often elusive as there are some cases where they don't reflect the actual behaviour. Regarding the nastiness of references, it's special not only for foreach, but also for the following case. Surprisingly, this script results in -- test ??? -- For more about this, see bug #20993 (this is also marked as a doc-problem). 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/21702 -- Edit this bug report at http://bugs.php.net/?id=21702&edit=1
#22029 [NEW]: Segfault on startup using ZE2
From: [EMAIL PROTECTED] Operating system: Redhat PHP version: 5CVS-2003-02-03 (dev) PHP Bug Type: Zend Engine 2 problem Bug description: Segfault on startup using ZE2 ZE2 is segfaulting on startup in the PHP5 HEAD as well as the snapshot from last Monday (I didn't bother trying go to farther back then that). Checked the other segfault bugs that came up, and configured with --disable-all to make sure it wasn't an automatically turned on module.. Here is the BT: #0 0x081114b4 in zend_register_functions (scope=0x0, functions=0x4001a260, function_table=0x0, type=1) at /home/php/php4-ze2/Zend/zend_API.c:1099 #1 0x08111704 in zend_register_module (module=0x400237a0) at /home/php/php4-ze2/Zend/zend_API.c:1172 #2 0x080941a5 in php_dl (file=0x8183ee8, type=1, return_value=0xb860) at /home/php/php4-ze2/ext/standard/dl.c:242 #3 0x080ee128 in php_load_function_extension_cb (arg=0x8183ee8) at /home/php/php4-ze2/main/php_ini.c:247 #4 0x08108a35 in zend_llist_apply (l=0x8175c3c, func=0x80ee114 ) at /home/php/php4-ze2/Zend/zend_llist.c:190 #5 0x080ee5aa in php_ini_delayed_modules_startup () at /home/php/php4-ze2/main/php_ini.c:499 #6 0x080eb0bc in php_module_startup (sf=0x8174ac0, additional_modules=0x0, num_additional_modules=0) at /home/php/php4-ze2/main/main.c:1284 #7 0x08132530 in main (argc=1, argv=0xbaf4) at /home/php/php4-ze2/sapi/cli/php_cli.c:480 #8 0x400c8306 in __libc_start_main (main=0x8132420 , argc=1, ubp_av=0xbaf4, init=0x8063128 <_init>, fini=0x8133140 <_fini>, rtld_fini=0x4000d2dc <_dl_fini>, stack_end=0xbaec) at ../sysdeps/generic/libc-start.c:129 -- Edit bug report at http://bugs.php.net/?id=22029&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22029&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22029&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22029&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22029&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22029&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22029&r=support Expected behavior: http://bugs.php.net/fix.php?id=22029&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22029&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22029&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22029&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22029&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22029&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22029&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22029&r=gnused
#22029 [Fbk->Sus]: Segfault on startup using ZE2
ID: 22029 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Suspended Bug Type: Zend Engine 2 problem Operating System: Redhat PHP Version: 5CVS-2003-02-03 (dev) New Comment: Yep, you were right it was my php.ini file. I was loading java.so from it. I'll make it suspended because the engine shouldn't crash regardless of the situation, if you want I'll dig into it more and find out the details about that module (only one I was loading). Previous Comments: [2003-02-03 08:23:07] [EMAIL PROTECTED] What version of libc? and are you sure that any shared extensions are disabled in php.ini? [2003-02-03 07:30:41] [EMAIL PROTECTED] ZE2 is segfaulting on startup in the PHP5 HEAD as well as the snapshot from last Monday (I didn't bother trying go to farther back then that). Checked the other segfault bugs that came up, and configured with --disable-all to make sure it wasn't an automatically turned on module.. Here is the BT: #0 0x081114b4 in zend_register_functions (scope=0x0, functions=0x4001a260, function_table=0x0, type=1) at /home/php/php4-ze2/Zend/zend_API.c:1099 #1 0x08111704 in zend_register_module (module=0x400237a0) at /home/php/php4-ze2/Zend/zend_API.c:1172 #2 0x080941a5 in php_dl (file=0x8183ee8, type=1, return_value=0xb860) at /home/php/php4-ze2/ext/standard/dl.c:242 #3 0x080ee128 in php_load_function_extension_cb (arg=0x8183ee8) at /home/php/php4-ze2/main/php_ini.c:247 #4 0x08108a35 in zend_llist_apply (l=0x8175c3c, func=0x80ee114 ) at /home/php/php4-ze2/Zend/zend_llist.c:190 #5 0x080ee5aa in php_ini_delayed_modules_startup () at /home/php/php4-ze2/main/php_ini.c:499 #6 0x080eb0bc in php_module_startup (sf=0x8174ac0, additional_modules=0x0, num_additional_modules=0) at /home/php/php4-ze2/main/main.c:1284 #7 0x08132530 in main (argc=1, argv=0xbaf4) at /home/php/php4-ze2/sapi/cli/php_cli.c:480 #8 0x400c8306 in __libc_start_main (main=0x8132420 , argc=1, ubp_av=0xbaf4, init=0x8063128 <_init>, fini=0x8133140 <_fini>, rtld_fini=0x4000d2dc <_dl_fini>, stack_end=0xbaec) at ../sysdeps/generic/libc-start.c:129 -- Edit this bug report at http://bugs.php.net/?id=22029&edit=1
#22047 [Com]: PHP pollutes the namespace w/ (what looks like) its grammar tokens
ID: 22047
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Wont fix
Bug Type: *General Issues
Operating System: Linux
PHP Version: 4.3.0
New Comment:
In order to avoid breaking backward compatibility with existing
scripts, would it not be possible to allow pre-defined constants to be
hidden when a constant is defined in a script with the same name? As
long as a script doesn't need to use both the pre-defined constants,
and the new ones, (which a script designed for an old PHP version
should not need to do anyway), I can't think of any reason why that
wouldn't be an almost perfect solution - problems would only occur if a
script assumed that a constant which was not pre-defined, but not
defined in the script, evaluated to it's own name.
Previous Comments:
[2003-02-05 01:00:19] [EMAIL PROTECTED]
> A notice is fine,
redefinition of a constant being only a NOTICE?
you can't be serious!
[2003-02-05 00:49:18] [EMAIL PROTECTED]
How's changing a NOTICE into a WARNING going to break
anything, anyway?
diff -ur a/Zend/zend_constants.c b/Zend/zend_constants.c
--- a/Zend/zend_constants.c 2002-10-09 16:17:53.0 +0200
+++ b/Zend/zend_constants.c 2003-02-05 07:46:35.0 +0100
@@ -265,7 +265,7 @@
if (!(c->flags & CONST_PERSISTENT)) {
zval_dtor(&c->value);
}
- zend_error(E_NOTICE,"Constant %s already defined",
lowercase_name);
+ zend_error(E_WARNING, "Constant %s already defined",
lowercase_name);
ret = FAILURE;
}
free_alloca(lowercase_name);
[2003-02-04 12:46:48] [EMAIL PROTECTED]
Guys, if this is how you deal with backwards
compatibility issues, then I'm scared.
I've been maintaining a big PHP project that's about
1MB of very clean code and I need to keep it alive.
This particular bug gave me quite a bit of a headache.
I've provided valid arguments on why a (trivial) change
should be made, and you seem to not really care. That's
not giving me nice prospects into the future, is it?
Come on, we're talking about constants here!
If a constant is redefined by a program, then
that program is broken by definition and needs
to be told on an appropriate level.
[2003-02-04 12:31:13] [EMAIL PROTECTED]
It's fine as it is -> wont fix.
[2003-02-04 11:48:17] [EMAIL PROTECTED]
A NOTICE definitely is NOT sufficient.
Remember many setups running older PHP software set
"error_reporting = E_ALL & ~E_NOTICE", because the
amount of notices on undefined array indices and
undefined variables can be quite overwhelming --
and it is precisely these setups that are likely
to be bitten by this problem.
Redefinition of a constant should be a WARNING,
I must insist.
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/22047
--
Edit this bug report at http://bugs.php.net/?id=22047&edit=1
#13726 [Com]: mktime bug
ID: 13726 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Date/time related Operating System: windows NT4.0 PHP Version: 4.0.6 New Comment: My ISP is using a new release of glibc and now mktime strtotime are not working for dates prior to 1970. I need to be able to add subtract a day from dates between now and before 1870 anybody ? ie http://www.boxrec.com/date_search.php I need to generate the dates either side of the search date for the forward / backward links. Previous Comments: [2002-11-14 06:46:59] [EMAIL PROTECTED] In our fine manual: http://www.php.net/manual/en/function.date.php [2002-11-14 06:42:53] [EMAIL PROTECTED] What's the offical suggestion for getting UNIX timestamps for dates < 1970? Or is it not allowed to use them this way? BTW: The offical PHP docs say, that dates between 1902 and 2037 are _allowed_. But you say "so stay away from undefined value ranges"!? Very strange. Can you explain that to the users/developers community? [2001-10-18 05:55:54] [EMAIL PROTECTED] behaviour of unix timestamp functions for dates before 1.1.1970 is simply undefined and depends on the system *and* c library implementation you use so stay away from undefined value ranges :) [2001-10-18 02:31:32] [EMAIL PROTECTED] mktime(0,0,0,1,1,1969); is return -1. but in linux renturn valid value; maybe before 1970 bug in win32 version. -- Edit this bug report at http://bugs.php.net/?id=13726&edit=1
#20065 [Opn->Ver]: References to object members seem to be backwards
ID: 20065
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Verified
Bug Type: Class/Object related
Operating System: GNU/Linux 2.4.18-17.7.x (RedHat)
PHP Version: 4.2.3
-Assigned To:
+Assigned To: john
New Comment:
Very strange...
return $object->array;
should return a copy of the member variable $array, not a reference.
This is of course assuming the function isn't designed to return a
reference (denoted by a & in the function declaration)... You note
that
$foo = &$object->array;
return $foo
Which leads me to believe this is actually a real bug and not a
"feature"... Hence I'm changing the status to Verified
When I get a moment I'm going to investigate this a little bit, but it
wouldn't surprise me to see this cleaned up in ZE2.
Previous Comments:
[2002-10-24 13:22:12] [EMAIL PROTECTED]
I have stumbled onto a reference behavior I cannot explain. Here's my
problem: I'm trying to return a copy of a member variable. The function
is not declared to return a reference, but it seems as if the user can
override this. Here's a non-object example:
Running this yields exactly what you would expect:
=== array ===
array(3) {
[0]=>
string(3) "foo"
[1]=>
string(3) "bar"
[2]=>
string(3) "baz"
}
=== copiedArray ===
array(4) {
[0]=>
string(3) "foo"
[1]=>
string(3) "bar"
[2]=>
string(3) "baz"
[3]=>
string(4) "quux"
}
So far, so good. This is as expected (even if the caller tries to use
the '&', he's getting the reference to the copy). Now instead of a
global array, let's try the exact same thing with a member of a global
object:
array = array('baz', 'bar', 'foo');
// Same function as before, only it's returning a
// member variable
function testObject()
{
global $object;
return $object->array;
}
// Grab the return from the function (notice the '&')
$copiedArray = &testObject();
// Modify it
$copiedArray['lyx'] = 'quux';
// Print the original and the copy out
echo "=== array ===\n";
var_dump($object->array);
echo "=== copiedArray ===\n";
var_dump($copiedArray);
?>
Here, I would expect that the results would be exactly the same
(remember, there are absolutely no references in the declaration of
testObject() or in the body; everything *should* be a copy). Here's
what gets printed when this is run:
=== array ===
array(4) {
[0]=>
string(3) "baz"
[1]=>
string(3) "bar"
[2]=>
string(3) "foo"
["lyx"]=>
string(4) "quux"
}
=== copiedArray ===
array(4) {
[0]=>
string(3) "baz"
[1]=>
string(3) "bar"
[2]=>
string(3) "foo"
["lyx"]=>
string(4) "quux"
}
Whoa! $copiedArray is now a reference for the member variable! But look
what happens if I redefine the function slightly:
function testObject()
{
global $object;
$array = &$object->array;
return $array;
}
Now I get what I expect again ($copiedArray doesn't point to the member
variable after calling testObject()). So what gives? Why is "return
$object->member;" exempt from the return declaration of the function?
This is an interesting "feature". Not very intuitive...I'd call it a
bug. Has anyone else noticed this? The above behavior happens with
scalars (e.g., strings, numbers) too, not just arrays.
Now for something REALLY weird. Check this out:
myString = 'hello';
// Test function
function testObject()
{
global $object;
// Make a copy of the member variable (no '&')
$newString = $object->myString;
// Return the COPY
return $newString;
}
// Grab the return from the function (notice the '&')
$copiedString = &testObject();
// Modify it
$copiedString = 'goodbye';
// Print the original and the copy out
echo "=== array ===\n";
echo $object->myString . "\n";
?>
Here's the output:
=== array ===
goodbye
Huh?! I even made a copy inside the function! Note that just as before
(s
#20788 [NEW]: Improper timezone generation?
From: [EMAIL PROTECTED]
Operating system: Windows / Linux
PHP version: 4.2.2
PHP Bug Type: Date/time related
Bug description: Improper timezone generation?
I'm not sure if this is a doc bug, a Windows bug or perhaps it's not an
issue. Basically:
echo gmdate('T'); // date() could have been used
produces on Linux:
GMT
while on Windows:
GMT Standard Time
The same thing applies for other timezones:
EST (linux) -> Eastern Standard Time
This is an issue for a number of reasons:
1) The docs specify date('T') as producing only three-letter timezones
(EST, etc).
2) This behavior may screw up things like setcookie() (where I ran into
it)...
--
Edit bug report at http://bugs.php.net/?id=20788&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20788&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20788&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20788&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20788&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20788&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20788&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20788&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20788&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20788&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20788&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20788&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20788&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20788&r=isapi
#20449 [Opn]: sessions randomly fail
ID: 20449 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: redhat 7.3 PHP Version: 4.4.0-dev New Comment: Hmm.. I'm going to see if I can't reproduce this bug in some form, starting from the serialize() function... it's possible that serialize() isn't doing things correctly. Is this just a array problem? Or has someone also found this error in objects that don't use arrays? I'm going to write up some test scripts and see if I can break serialize()... I'll post my results here. Previous Comments: [2002-12-02 07:17:26] [EMAIL PROTECTED] [General Message - Not Bug Specific] In the past 12 months, I've raised a number of bugs relating to session problems that could not be reproduced consistently with the standard reply of 'its been fixed in CVS/Try CVS version'. I've tried the new CVS version and problems still continue (but still erratically). Over time, I've noticed a lot of developers problems (bugs) seem to be related to the global $_SESSION variable and I personally feel that the most stable session module is still in PHP version 4.0.6 before introduction in the 4.1 series. I'm not a hardened programmer, so this is a call to the current and previous developers/maintainers to consider a complete design and code walkthrough of the 'session related' code. Personally, I feel sessions is one of the key feature areas of PHP and something that needs to be highlighted to both Zend and the community to be made 'rock-solid'. Thanks Nick [2002-11-25 18:22:39] [EMAIL PROTECTED] After a good weekend we are having an incredible Monday. My code in place now uses serialize/unserialize. I also convert my arrays to strings with implode/explode before the serialization/unserialization process. I don't see any missing information anymore in my session table. I really think the session serialize code is at fault for this bug. Specifically I think it simply doesn't handle arrays. (perhaps objects but my object simply had the array in it. Removing the array from the object and not using objects did not work) This is an extremely serious bug that was costing us on average of about 30-50 orders a day. I am honestly not exaggerating on this figure. I tried the CVS version as late as 11-15-2002 and it still had the bug in it. Before that I was using the latest 4.2.3 version. I'd like a little feedback from the developers to at least say they are looking into it. I will try to assist in any way I can. However, as I have said before, it was very random and I myself never saw my session disappear. Also important to note is that I do not rely on Session Cookies so it is not related to cookies. Also, I tried doing the reset(arrayvar) after each session restoration as suggested on one of the session man pages. That too did not work. I hesitate to say but I really think it would be important to make note to people that the session code is not reliable. Perhaps in the man pages. I won't go to such length though as to warn them myself though I feel some duty to do so. Perhaps the bug only comes into play on high traffic servers. Either which way, not relying on the internal session code has made a huge difference. That in itself should prove something. [2002-11-25 11:46:34] [EMAIL PROTECTED] This seems to be exactly the same problem we are having with one particular visitor to one of my websites. He always has this problem, every time he logs in his session expires. I have gone through his client PC configuration very carefully, and cannot find anything unusual. What's more odd is that he used to be able to use my site without problems. Would this problem manifest itself at random, or would it affect specific PCs? I had assumed the problem was at his end until I read this message thread, and it looked strangely familiar. Jolyon [2002-11-22 16:20:08] [EMAIL PROTECTED] Just thought I'd add that we are having what - seems to be - the same problem. We are running on Solaris 8 and our sessions are being held in a tmpfs mount that's balanced across 4 sun 220's. PHP Version 4.2.2 and Apache 1.3.26 compiled staticly. We've been moving the session store method around thinking I/O was the issue but it hasn't helped. We've done NFS mounted share, local-only share on 1 220 (limiting the load-balancing for one site to only that box) and now tmpfs. Our sessions are rather large (at least for me) normally around 11,316 bytes with objects and arrays w/ members that are serialized objects. It's probably important to note that we are avoiding automatic serialize/
#20960 [NEW]: Checkdate very illogical
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.3 PHP Bug Type: Feature/Change Request Bug description: Checkdate very illogical I' ve just spent several wasted hours looking for a blindingly obvious problem. Checkdate takes it's params in a very illogical way ie checkdate ( int month, int day, int year) Surely it should be checkdate ( int day, int month, int year) or even checkdate ( int year, int month, int day) why on earth month day year ? -- Edit bug report at http://bugs.php.net/?id=20960&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20960&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20960&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20960&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20960&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20960&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20960&r=support Expected behavior: http://bugs.php.net/fix.php?id=20960&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20960&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20960&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20960&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20960&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20960&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20960&r=isapi
#8558 [WFx->Csd]: /e modifier in preg_replace
ID: 8558
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Won't fix
+Status: Closed
Bug Type: Misbehaving function
Operating System: Win32
PHP Version: 3.0.16
New Comment:
My original suggestion is about 20 months old, at which point it was an
issue. However, we're dropping PHP3 support in our software too, so
it's not a problem now. Thanks for the update, and I hope plans for
PHP5 continue to go well!
Cheers,
John
Previous Comments:
[2002-10-01 15:13:58] [EMAIL PROTECTED]
We are sorry, but can not support PHP 3 related problems anymore.
Momentum is gathering for PHP 5, and we think supporting PHP 3 will
lead to a waste of resources which we want to put into getting PHP 5
ready. Ofcourse PHP 4 will will continue to be supported for the
forseeable future.
[2001-01-04 17:41:15] [EMAIL PROTECTED]
When was the /e modifier added to PHP?
On PHP 3.0.16 / Apache CGI / Win32 it does not work, but on PHP 4.0.2 /
Apache Module / Linux it does work. Is this a platform issue, or a
version issue?
Are there any workarounds if this is a version issue?
Thanks,
John
Code sample:
$searcharray = array(
"/(\[)(list)(=)(['\"]?)([^\"']*)(\\4])(.*)(\[\/list\])/esiU",
"/(\[)(list)(])(.*)(\[\/list\])/esiU",
"/(\[)(url)(=)(['\"]?)([^\"']*)(\\4])(.*)(\[\/url\])/esiU",
"/(\[)(url)(])(.*)(\[\/url\])/esiU",
"/(\[)(code)(])(\r\n)*(.*)(\[\/code\])/esiU"
);
$replacearray = array(
"createlists('\\7', '\\5')",
"createlists('\\4')",
"checkurl('\\5', '\\7')",
"checkurl('\\4')",
"stripbrsfromcode('\\5')"
);
$bbcode=preg_replace($searcharray, $replacearray, $bbcode);
--
Edit this bug report at http://bugs.php.net/?id=8558&edit=1
#19830 [NEW]: Try to show the time but when running it, a parse error comes out
From: [EMAIL PROTECTED]
Operating system: Win2000 Adv Server
PHP version: 4.2.3
PHP Bug Type: Date/time related
Bug description: Try to show the time but when running it, a parse error comes out
what I did:
$hourtime=strftime("%H")strftime("%H:%M:%S
%p")-strftime("%H")${${"userName"."_session"}."time"."_session"};
what I expected to happen:
to show how long I stay in the website
what happened:
parse error, unexpected T_String
Anyone who knows how to solve this problem, please help...
--
Edit bug report at http://bugs.php.net/?id=19830&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=19830&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=19830&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=19830&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=19830&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=19830&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=19830&r=support
Expected behavior: http://bugs.php.net/fix.php?id=19830&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=19830&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=19830&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=19830&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19830&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=19830&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=19830&r=isapi
#20086 [NEW]: SQLDriverConnect supported by win32
From: [EMAIL PROTECTED] Operating system: W2K PHP version: 4CVS-2002-10-25 PHP Bug Type: ODBC related Bug description: SQLDriverConnect supported by win32 In ext/odbc/php_odbc.php dsn-less connections are only supported for empress and unixodbc. Windows also supports this connection method. Changing the line: #if defined(HAVE_EMPRESS) || defined(HAVE_UNIXODBC) to: #if defined(HAVE_EMPRESS) || defined(HAVE_UNIXODBC) || defined(WIN32) enables dsn-less connections under windows. -- Edit bug report at http://bugs.php.net/?id=20086&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20086&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20086&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20086&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20086&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20086&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20086&r=support Expected behavior: http://bugs.php.net/fix.php?id=20086&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20086&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20086&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20086&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20086&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20086&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20086&r=isapi
#20086 [Fbk->Opn]: SQLDriverConnect supported by win32
ID: 20086 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: ODBC related Operating System: W2K PHP Version: 4CVS-2002-10-25 New Comment: diff is now my new friend. Is this right? :-) 2110c2110 < #if defined(HAVE_EMPRESS) || defined(HAVE_UNIXODBC) --- > #if defined(HAVE_EMPRESS) || defined(HAVE_UNIXODBC) || defined(PHP_WIN32) 2133c2133 < rc = SQLDriverConnect((*conn)->hdbc, NULL, ldb, strlen(ldb), dsnbuf, 300, --- > rc = SQLDriverConnect((*conn)->hdbc, NULL, ldb, (short)strlen(ldb), dsnbuf, 300, The (short) typecast is to prevent a warning in win32 - don't know if it will have issues with other platforms. Now using PHP_WIN32 not WIN32 for consistency with other code. Previous Comments: [2002-10-27 19:46:08] [EMAIL PROTECTED] Unified diffs are your and my friends. Can you please provide one! [2002-10-25 09:45:46] [EMAIL PROTECTED] In ext/odbc/php_odbc.php dsn-less connections are only supported for empress and unixodbc. Windows also supports this connection method. Changing the line: #if defined(HAVE_EMPRESS) || defined(HAVE_UNIXODBC) to: #if defined(HAVE_EMPRESS) || defined(HAVE_UNIXODBC) || defined(WIN32) enables dsn-less connections under windows. -- Edit this bug report at http://bugs.php.net/?id=20086&edit=1
#14599 [Com]: Script Output Stops
ID: 14599
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Reproducible crash
Operating System: SuSE Linux 6.4
PHP Version: 4.1.0
New Comment:
I get this all the time when I include a recursive function call. I've
tried rewriting the function several ways and get intermitten
Segmentation faults.
I"ve tried just opening the fh and going down recursive directories
with this, got the seg faults often.This version
buffers the file names in an array, closes the directory handle then
processes the array, to count certain types of files in the directory
tree. Still segfaults often enough to make it unreliable. I turned on
the autoflush in php.ini and it dies in this routine.
FreeBSD 4.5-RELEASE
Apache/1.3.26 (Unix) PHP/4.2.2 mod_ssl/2.8.9 OpenSSL/0.9.6g
RegisterGlobals = On :)
function CountFiles($dir,$d) {
global $home;
global $prod_count;
$farray = array(); $d++;
if (is_dir("$home$dir")) {
print "\n";
if ($dfh = @opendir("$home$dir")) {
while (($fil = readdir($dfh)) !== false) {
if (!preg_match("/^\.+$/", $fil)) {
array_push($farray,"$fil");
}
}
closedir($dfh);
if (count($farray) > 0) {
while (list ($key, $file) = each ($farray)) {
if (is_dir("$home$dir/$file")) {
CountFiles("$dir/$file",$d);
flush();
} else if (preg_match("/^thumb_\w+\.|\.wav$|\.aif$/", $file))
{ $prod_count++;
print "\n";
flush();
}
}
}
}
}
flush();
}
It's not entirely reproducible, but once I got a directory where it
causes the segfault I can comment out this routine and it's okay,
comment it back and reload and it segfaults.
So in that sense it's reproducible. Restarting the web server has no
effect. Though if I reload enough times sometimes the script completes,
there is definitely some sort of bug, maybe the filehandle or array
declaration isn't local or leaks out, not sure.
Previous Comments:
[2002-01-09 02:10:59] [EMAIL PROTECTED]
No feedback. Closing.
[2001-12-19 07:30:43] [EMAIL PROTECTED]
Please provide a small script which can be used to produce this error,
and also, if you can, provide a backtrace.
http://bugs.php.net/bugs-generating-backtrace.php
R.
[2001-12-19 07:21:39] [EMAIL PROTECTED]
PHP script stops 3/4 of the way down a medium sized page. This happens
in exactly the same place.
Apache log shows:
[Wed Dec 19 11:24:55 2001] [notice] child pid 13078 exit signal
Segmentation fault (11)
[Wed Dec 19 11:26:55 2001] [notice] child pid 12877 exit signal
Segmentation fault (11)
[Wed Dec 19 11:27:51 2001] [notice] child pid 13465 exit signal
Segmentation fault (11)
[Wed Dec 19 11:28:45 2001] [notice] child pid 13468 exit signal
Segmentation fault (11)
[Wed Dec 19 11:30:54 2001] [notice] child pid 13469 exit signal
Segmentation fault (11)
[Wed Dec 19 11:34:17 2001] [notice] child pid 13566 exit signal
Segmentation fault (11)
[Wed Dec 19 11:34:37 2001] [notice] child pid 13580 exit signal
Segmentation fault (11)
[Wed Dec 19 11:34:39 2001] [notice] child pid 13581 exit signal
Segmentation fault (11)
[Wed Dec 19 11:34:48 2001] [notice] child pid 13582 exit signal
Segmentation fault (11)
[Wed Dec 19 11:39:15 2001] [notice] caught SIGTERM, shutting down
[Wed Dec 19 11:43:15 2001] [notice] Apache/1.3.12 (Unix) (SuSE/Linux)
mod_fastcgi/2.2.2 mod_perl/1.21 PHP/4.1.0 configured -- res
uming normal operations
[Wed Dec 19 11:43:15 2001] [notice] suEXEC mechanism enabled (wrapper:
/usr/sbin/suexec)
ild pid 13078 exit signal Segmentation fault (11)[Wed Dec 19 12:05:32
2001] [notice] child pid 163 exit signal Segmentation fault
The PHP page is meant to output a html form containing hidden form
fields.
--
Edit this bug report at http://bugs.php.net/?id=14599&edit=1
#20186 [NEW]: Segmentation fault (11) in recursive function call
From: [EMAIL PROTECTED]
Operating system: FreeBSD
PHP version: 4.2.2
PHP Bug Type: Reproducible crash
Bug description: Segmentation fault (11) in recursive function call
I get this all the time when I include a recursive function call. I've
tried rewriting the function several ways and get intermitten Segmentation
faults, saw a SuSe Linux report about scripts terminating with similar
output in the web server error_log.
I"ve tried just opening the fh and going down recursive directories with
this, got the seg faults often.This version
buffers the file names in an array, closes the directory handle then
processes the array, to count certain types of files in the directory
tree. Still segfaults often enough to make it unreliable. I turned on the
autoflush in php.ini and it dies in this routine.
FreeBSD 4.5-RELEASE
Apache/1.3.26 (Unix) PHP/4.2.2 mod_ssl/2.8.9 OpenSSL/0.9.6g
RegisterGlobals = On :)
I use a perl script for my apache coplilation, here's my php_config line.
--with-mysql=/usr/local --with-gd=/usr/local
--with-jpeg-dir=/usr/local/lib --with-png-dir=/usr/
local/lib --with-zlib-dir=/usr/lib $xpm --with-freetype-dir=/usr/local/lib
--with-mcrypt=/usr/local --with-gettext --wit
h-xml --with-zlib=/usr --with-bz2=/usr/local --with-zip=/usr/local
--with-mm=/usr/local --with-apache=../$apache --enable-ftp --disable-debug
--enable-track-vars
Here's the current version of the function
function CountFiles($dir,$d) {
global $home;
global $prod_count;
$farray = array(); $d++;
if (is_dir("$home$dir")) {
print "\n";
if ($dfh = @opendir("$home$dir")) {
while (($fil = readdir($dfh)) !== false) {
if (!preg_match("/^\.+$/", $fil)) {
array_push($farray,"$fil");
}
}
closedir($dfh);
if (count($farray) > 0) {
while (list ($key, $file) = each ($farray)) {
if (is_dir("$home$dir/$file")) {
CountFiles("$dir/$file",$d);
flush();
} else if (preg_match("/^thumb_\w+\.|\.wav$|\.aif$/", $file)) {
$prod_count++;
print "\n";
flush();
}
}
}
}
}
flush();
}
It's not entirely reproducible, but once I got a directory where it causes
the segfault I can comment out this routine and it's okay, comment it back
and reload and it segfaults.
So in that sense it's reproducible. Restarting the web server has no
effect. Though if I reload enough times sometimes the script completes,
there is definitely some sort of bug, maybe the filehandle or array
declaration isn't local or leaks out, not sure.
Hope it's not something stupid I overlooked. :)
--
Edit bug report at http://bugs.php.net/?id=20186&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20186&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20186&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20186&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20186&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20186&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20186&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20186&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20186&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20186&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20186&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20186&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20186&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20186&r=isapi
#20186 [Opn]: Segmentation fault (11) in recursive function call
ID: 20186
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: FreeBSD
PHP Version: 4.2.2
New Comment:
Sorry, might help to mention that I did try the function first without
using globals and returning the directory file_count and adding it up
and returning the total, also had the same problem.
Previous Comments:
[2002-10-31 03:50:10] [EMAIL PROTECTED]
I get this all the time when I include a recursive function call. I've
tried rewriting the function several ways and get intermitten
Segmentation faults, saw a SuSe Linux report about scripts terminating
with similar output in the web server error_log.
I"ve tried just opening the fh and going down recursive directories
with this, got the seg faults often.This version
buffers the file names in an array, closes the directory handle then
processes the array, to count certain types of files in the directory
tree. Still segfaults often enough to make it unreliable. I turned on
the autoflush in php.ini and it dies in this routine.
FreeBSD 4.5-RELEASE
Apache/1.3.26 (Unix) PHP/4.2.2 mod_ssl/2.8.9 OpenSSL/0.9.6g
RegisterGlobals = On :)
I use a perl script for my apache coplilation, here's my php_config
line.
--with-mysql=/usr/local --with-gd=/usr/local
--with-jpeg-dir=/usr/local/lib --with-png-dir=/usr/
local/lib --with-zlib-dir=/usr/lib $xpm
--with-freetype-dir=/usr/local/lib --with-mcrypt=/usr/local
--with-gettext --wit
h-xml --with-zlib=/usr --with-bz2=/usr/local --with-zip=/usr/local
--with-mm=/usr/local --with-apache=../$apache --enable-ftp
--disable-debug --enable-track-vars
Here's the current version of the function
function CountFiles($dir,$d) {
global $home;
global $prod_count;
$farray = array(); $d++;
if (is_dir("$home$dir")) {
print "\n";
if ($dfh = @opendir("$home$dir")) {
while (($fil = readdir($dfh)) !== false) {
if (!preg_match("/^\.+$/", $fil)) {
array_push($farray,"$fil");
}
}
closedir($dfh);
if (count($farray) > 0) {
while (list ($key, $file) = each ($farray)) {
if (is_dir("$home$dir/$file")) {
CountFiles("$dir/$file",$d);
flush();
} else if (preg_match("/^thumb_\w+\.|\.wav$|\.aif$/", $file)) {
$prod_count++;
print "\n";
flush();
}
}
}
}
}
flush();
}
It's not entirely reproducible, but once I got a directory where it
causes the segfault I can comment out this routine and it's okay,
comment it back and reload and it segfaults.
So in that sense it's reproducible. Restarting the web server has no
effect. Though if I reload enough times sometimes the script completes,
there is definitely some sort of bug, maybe the filehandle or array
declaration isn't local or leaks out, not sure.
Hope it's not something stupid I overlooked. :)
--
Edit this bug report at http://bugs.php.net/?id=20186&edit=1
#20086 [Csd]: SQLDriverConnect supported by win32
ID: 20086 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: ODBC related Operating System: W2K PHP Version: 4CVS-2002-10-25 New Comment: Snapshot tested OK - thanks John Previous Comments: [2002-10-30 20:57:29] [EMAIL PROTECTED] PHP is now your DSN-less friend. Please test a snapshot and make sure this is working properly for you. [2002-10-28 11:38:27] [EMAIL PROTECTED] diff is now my new friend. Is this right? :-) 2110c2110 < #if defined(HAVE_EMPRESS) || defined(HAVE_UNIXODBC) --- > #if defined(HAVE_EMPRESS) || defined(HAVE_UNIXODBC) || defined(PHP_WIN32) 2133c2133 < rc = SQLDriverConnect((*conn)->hdbc, NULL, ldb, strlen(ldb), dsnbuf, 300, --- > rc = SQLDriverConnect((*conn)->hdbc, NULL, ldb, (short)strlen(ldb), dsnbuf, 300, The (short) typecast is to prevent a warning in win32 - don't know if it will have issues with other platforms. Now using PHP_WIN32 not WIN32 for consistency with other code. [2002-10-27 19:46:08] [EMAIL PROTECTED] Unified diffs are your and my friends. Can you please provide one! [2002-10-25 09:45:46] [EMAIL PROTECTED] In ext/odbc/php_odbc.php dsn-less connections are only supported for empress and unixodbc. Windows also supports this connection method. Changing the line: #if defined(HAVE_EMPRESS) || defined(HAVE_UNIXODBC) to: #if defined(HAVE_EMPRESS) || defined(HAVE_UNIXODBC) || defined(WIN32) enables dsn-less connections under windows. -- Edit this bug report at http://bugs.php.net/?id=20086&edit=1
#20344 [NEW]: select a temp dir and filename that is diffrent than the one in php.ini
From: [EMAIL PROTECTED] Operating system: any PHP version: 4.3.0-pre2 PHP Bug Type: Feature/Change Request Bug description: select a temp dir and filename that is diffrent than the one in php.ini Here's an idea that would have to be included in php itself, but it would prove useful. The option to select a temp dir and filename that is diffrent than the one in php.ini. One could use a timestamp and user ID as a temp file name and track it's size in a new window to create a progress bar for the upload. any comments? -- Edit bug report at http://bugs.php.net/?id=20344&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20344&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20344&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20344&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20344&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20344&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20344&r=support Expected behavior: http://bugs.php.net/fix.php?id=20344&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20344&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20344&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20344&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20344&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20344&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20344&r=isapi
Bug #15880: select (name) from ..... doesnt work!
From: [EMAIL PROTECTED]
Operating system: linux
PHP version: 4.1.1
PHP Bug Type: ODBC related
Bug description: select (name) from . doesnt work!
Using the ODBC functions Im having problem with simple lines like:
select max(id) from ident;
select (name) from main;
But lines like this works fine:
select id, path, name from main order by path, name;
When Im trying the same lines using the MySQL functions it works fine.
Here is a script that shows my problem:
$dbh = mysql_connect("localhost", $user, $password);
mysql_select_db("vr", $dbh);
$rh = mysql_query("select max(id) from ident;") or die("SQL error");
$t = mysql_fetch_row($rh);
echo "Using MySQL I get id: ". $t[0];
mysql_close($dbh);
$dbh = odbc_connect($dsn, $user, $password);
$rh = odbc_exec($dbh, "select max(id) from ident;") or die("SQL error");
$t = odbc_fetch_row($rh);
echo "Using ODBC I get id: ". $t[0];
odbc_close($dbh);
What is does is it prints out the value it gets from each query. The
output I get is:
Using MySQL I get id: 68
Using ODBC I get id:
I can get this to work with perl using DBI and DBI-ODBC so I strongly
believes the problem lies in the ODBC implementation in php.
My configure line is like this:
'./configure' '--with-mysql=/usr/local/mysql'
'--with-apxs=/usr/local/apache/bin/apxs' '--with-db2' '--disable-debug'
'--disable-static' '--enable-sockets' '--with-yp' '--with-zlib'
'--with-iodbc=/usr/local/libiodbc-3.0.5'
--
Edit bug report at http://bugs.php.net/?id=15880&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15880&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15880&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15880&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15880&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15880&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15880&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15880&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15880&r=submittedtwice
Bug #15880 Updated: select (name) from ..... doesnt work!
ID: 15880
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: ODBC related
Operating System: linux
PHP Version: 4.1.1
New Comment:
SQL query:
select name from main;
doesnt work either.
Previous Comments:
[2002-03-05 10:29:54] [EMAIL PROTECTED]
Using the ODBC functions Im having problem with simple lines like:
select max(id) from ident;
select (name) from main;
But lines like this works fine:
select id, path, name from main order by path, name;
When Im trying the same lines using the MySQL functions it works fine.
Here is a script that shows my problem:
$dbh = mysql_connect("localhost", $user, $password);
mysql_select_db("vr", $dbh);
$rh = mysql_query("select max(id) from ident;") or die("SQL error");
$t = mysql_fetch_row($rh);
echo "Using MySQL I get id: ". $t[0];
mysql_close($dbh);
$dbh = odbc_connect($dsn, $user, $password);
$rh = odbc_exec($dbh, "select max(id) from ident;") or die("SQL
error");
$t = odbc_fetch_row($rh);
echo "Using ODBC I get id: ". $t[0];
odbc_close($dbh);
What is does is it prints out the value it gets from each query. The
output I get is:
Using MySQL I get id: 68
Using ODBC I get id:
I can get this to work with perl using DBI and DBI-ODBC so I strongly
believes the problem lies in the ODBC implementation in php.
My configure line is like this:
'./configure' '--with-mysql=/usr/local/mysql'
'--with-apxs=/usr/local/apache/bin/apxs' '--with-db2' '--disable-debug'
'--disable-static' '--enable-sockets' '--with-yp' '--with-zlib'
'--with-iodbc=/usr/local/libiodbc-3.0.5'
--
Edit this bug report at http://bugs.php.net/?id=15880&edit=1
Bug #14797 Updated: include (_path) in Apache SAPI and CGI on Win98SE does not work
ID: 14797 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Scripting Engine problem Operating System: Windows 98 SE PHP Version: 4.1.0 New Comment: I've always had problems with apache sapi under win32 with the include path. Finally discovered this works: php_value include_path "/.;C:\whatever" Why? I have no idea. Definite BUG. Previous Comments: [2002-03-13 20:50:45] [EMAIL PROTECTED] This is fixed in CVS. Fix will be in PHP 4.2.0. [2002-02-05 19:56:20] [EMAIL PROTECTED] Ive jsut installed XP and straight away none of the include that specify FULL path to the file work .. Relative works fine. Everythign used to work like it is suposed to under win2k. I found that the only way to solv this is to add a FULl FULL path including the drive letter. (before i used to add just the path to the root of the webserver)... Any idea what might be causing this Besides win XP? [2002-02-04 16:45:27] [EMAIL PROTECTED] I found solution %) php_value include_path "/.;C:\var\www;" Add in include_patch /. All working! Tested in php4.0.4rc1,4.0.6,4.1.1 [2002-01-30 12:55:33] [EMAIL PROTECTED] Hello, D:\127\Apache\Apache.exe -d "d:\127\apache" -k shutdown D:\127\Apache\Apache.exe -w -f "D:\127\Apache\conf\httpd.conf" -d "D:\127\Apache\" Martin [2002-01-30 12:50:54] [EMAIL PROTECTED] Martin, Just checking that you're restarting Apache after each edit to PHP.ini... You don't have to restart in CGI mode for changes to happen, but SAPI needs it (since PHP is loaded into Apache's memory space). -Garth 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/14797 -- Edit this bug report at http://bugs.php.net/?id=14797&edit=1
Bug #15880 Updated: select (name) from ..... doesnt work!
ID: 15880
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: ODBC related
Operating System: linux
PHP Version: 4.1.1
New Comment:
$rh = mysql_query("select max(id) from ident;") or die("SQL error");
This line works wonderfully on my described version of php and removing
the ending ';' doesn't change a thing.
This isn't the bug either! Read it through again and you'll see!
Previous Comments:
[2002-03-23 02:43:42] [EMAIL PROTECTED]
$rh = mysql_query("select max(id) from ident;") or die("SQL error");
// Will never work and is not a bug
$rh = mysql_query("select max(id) from ident") or die("SQL error"); //
This will
Please close this report
[2002-03-06 09:17:21] [EMAIL PROTECTED]
while using freetds+unixODBC+PHP i've found out that it's a problem of
odbc_fetch_row. In freetds.log there was a request and reply (correct)
but odbc_fetch_row gave empty value as output
[2002-03-05 10:37:42] [EMAIL PROTECTED]
SQL query:
select name from main;
doesnt work either.
[2002-03-05 10:29:54] [EMAIL PROTECTED]
Using the ODBC functions Im having problem with simple lines like:
select max(id) from ident;
select (name) from main;
But lines like this works fine:
select id, path, name from main order by path, name;
When Im trying the same lines using the MySQL functions it works fine.
Here is a script that shows my problem:
$dbh = mysql_connect("localhost", $user, $password);
mysql_select_db("vr", $dbh);
$rh = mysql_query("select max(id) from ident;") or die("SQL error");
$t = mysql_fetch_row($rh);
echo "Using MySQL I get id: ". $t[0];
mysql_close($dbh);
$dbh = odbc_connect($dsn, $user, $password);
$rh = odbc_exec($dbh, "select max(id) from ident;") or die("SQL
error");
$t = odbc_fetch_row($rh);
echo "Using ODBC I get id: ". $t[0];
odbc_close($dbh);
What is does is it prints out the value it gets from each query. The
output I get is:
Using MySQL I get id: 68
Using ODBC I get id:
I can get this to work with perl using DBI and DBI-ODBC so I strongly
believes the problem lies in the ODBC implementation in php.
My configure line is like this:
'./configure' '--with-mysql=/usr/local/mysql'
'--with-apxs=/usr/local/apache/bin/apxs' '--with-db2' '--disable-debug'
'--disable-static' '--enable-sockets' '--with-yp' '--with-zlib'
'--with-iodbc=/usr/local/libiodbc-3.0.5'
--
Edit this bug report at http://bugs.php.net/?id=15880&edit=1
Bug #16376: Transformation does not work inside PHP
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.1.2 PHP Bug Type: Sablotron XSL Bug description: Transformation does not work inside PHP Hello, I've used this sample code as well as the installation described at http://shanx.com/php/xsl/getXsl.htm. The result is that Sablotron itself works fine but this code produces following error "XML parser error 4: not well-formed (invalid token)". Thank you. -- Edit bug report at http://bugs.php.net/?id=16376&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16376&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16376&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16376&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16376&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16376&r=support Expected behavior: http://bugs.php.net/fix.php?id=16376&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16376&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16376&r=submittedtwice
#26662 [Opn->Ver]: Inconsistency in variable setting allows variables that start with numbers
ID: 26662
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Verified
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 4CVS-2003-12-18 (stable)
New Comment:
Confirmed this bug is in PHP 5 B3RC1 as well. It gets worse, you can
put whatever you want in ${} and it'll take it just fine...
Previous Comments:
[2003-12-18 21:06:52] [EMAIL PROTECTED]
Description:
It is possible to set variables that start with numbers.
I reproduced this with a PHP 4.3.x-dev snapshot AND PHP 5.0.0b2 (I was
unable to get a snap to compile. autoconf errors out the wazoo).
Reproduce code:
---
[EMAIL PROTECTED] cli $ ./php -r '${1} = "foo"; echo ${1}, "\n";'
foo
Expected result:
A parse error
Actual result:
--
Outputs 'foo'
--
Edit this bug report at http://bugs.php.net/?id=26662&edit=1
#32539 [Asn->Csd]: new tidy function
ID: 32539 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: Feature/Change Request Operating System: n/a PHP Version: 5CVS-2005-04-01 (dev) Assigned To: john 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: [2005-04-19 20:39:38] [EMAIL PROTECTED] Assigning to the extension maintainer. [2005-04-01 22:11:55] [EMAIL PROTECTED] Description: I've made a patch to add a new function to the tidy extension. This function allows you to retrieve the documentation related with each option. Patch: http://livedocs.aborla.net/patch.php?id=php.tidy-get-opt-doc Test: http://livedocs.aborla.net/018.phpt -- Edit this bug report at http://bugs.php.net/?id=32539&edit=1
#32643 [Csd->Fbk]: update tidy to reflect library change in tidyLoadConfig()
ID: 32643 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Feedback Bug Type: Feature/Change Request Operating System: n/a PHP Version: 5CVS-2005-04-09 (dev) Assigned To: john New Comment: Opps... meant to close the other report... I'm a little skeptical about this patch at first glance because you are changing the behavior from immediately returning to simply throwing a warning and continuing execution. Regardless of if the config file failed at parsing, or the config file failed to load they both should stop execution as far as I would think -- can you give me a reason otherwise? Previous Comments: [2005-04-25 22:50:11] [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. [2005-04-19 20:39:24] [EMAIL PROTECTED] Assigning to the extension maintainer. [2005-04-09 13:59:40] [EMAIL PROTECTED] Description: I've made a patch (which is backward compatible with older libraries) to update the tidy extension due to a change in the libtidy function tidyLoadConfig(). The change is described at: http://sourceforge.net/tracker/?func=detail&atid=390963&aid=937271&group_id=27659 The patch: http://livedocs.aborla.net/patch.php?id=php.tidy Nuno -- Edit this bug report at http://bugs.php.net/?id=32643&edit=1
#32643 [Asn->Csd]: update tidy to reflect library change in tidyLoadConfig()
ID: 32643 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: Feature/Change Request Operating System: n/a PHP Version: 5CVS-2005-04-09 (dev) Assigned To: john 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: [2005-04-19 20:39:24] [EMAIL PROTECTED] Assigning to the extension maintainer. [2005-04-09 13:59:40] [EMAIL PROTECTED] Description: I've made a patch (which is backward compatible with older libraries) to update the tidy extension due to a change in the libtidy function tidyLoadConfig(). The change is described at: http://sourceforge.net/tracker/?func=detail&atid=390963&aid=937271&group_id=27659 The patch: http://livedocs.aborla.net/patch.php?id=php.tidy Nuno -- Edit this bug report at http://bugs.php.net/?id=32643&edit=1
#25223 [Fbk->Csd]: ZE2 Crashes in non-debug mode (CLI only)
ID: 25223
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: Redhat 8
PHP Version: 5CVS-2003-08-25 (dev)
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
a cvs update between yesterday and today fixed the problem somehow.
Previous Comments:
[2003-08-24 23:23:45] [EMAIL PROTECTED]
Using latest CVS, I can _not_ reproduce this crash.
Get a clean checkout, or preferrably the latest snapshot..
[2003-08-24 15:46:28] [EMAIL PROTECTED]
Remove win98 from the equation. Updating libxml2.lib to the latest
version (2.5.10.win32) gets rid of the problem here. (Weird, John only
reported this because he could replicate it on redhat ! :)
[2003-08-24 12:04:51] [EMAIL PROTECTED]
Even a little thing like 'php -v' crashes the Release_TS cli version in
PHP5 here (although the command is executed first)..
(on win98)
[2003-08-24 12:00:02] [EMAIL PROTECTED]
Description:
ZE2 crashes from the latest HEAD when built in release (without
--enable-debug) trying to initialize the memory manager:
(gdb) r -v
Starting program: /home/john/working/php-src/sapi/cli/php -v
[New Thread 16384 (LWP 598)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 598)]
0x4207d297 in memset () from /lib/i686/libc.so.6
(gdb) bt
#0 0x4207d297 in memset () from /lib/i686/libc.so.6
#1 0x081d8ec8 in ?? ()
#2 0x08166ac1 in zend_mm_startup (heap=0x81d8f50, block_size=262144)
at /home/john/working/php-src/Zend/zend_mm.c:260
#3 0x08146a22 in start_memory_manager (tsrm_ls=0x81d5ff0)
at /home/john/working/php-src/Zend/zend_alloc.c:459
#4 0x081234a1 in ts_allocate_id (rsrc_id=0x81d5548, size=0, ctor=0,
dtor=0)
at /home/john/working/php-src/TSRM/TSRM.c:235
#5 0x08157859 in zend_startup (utility_functions=0xb850,
extensions=0x0,
start_builtin_functions=1) at
/home/john/working/php-src/Zend/zend.c:543
#6 0x081271b7 in php_module_startup (sf=0x81d26a0,
additional_modules=0x0,
num_additional_modules=0) at
/home/john/working/php-src/main/main.c:1300
#7 0x08177dc3 in main (argc=2, argv=0xba84)
at /home/john/working/php-src/sapi/cli/php_cli.c:592
#8 0x420158f7 in __libc_start_main () from /lib/i686/libc.so.6
(gdb)
My configure was simple:
'./configure' '--enable-maintainer-zts' '--disable-cgi'
--
Edit this bug report at http://bugs.php.net/?id=25223&edit=1
#27570 [Opn->Asn]: Tidy throw
ID: 27570
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Assigned
Bug Type: Unknown/Other Function
Operating System: *
PHP Version: 5CVS-2004-03-11 (dev)
New Comment:
This isn't really a bug per-se. Tidy is throwing an exception because
it couldn't find the file, if you want to continue operation then you
have to use a try / catch block. The only "bug" here is that when
called from a procedural context tidy should be generating E_WARNINGs
instead of throwing exceptions.
Previous Comments:
[2004-03-13 16:50:18] [EMAIL PROTECTED]
All functions that use TIDY_THROW exit PHP when an error is produced.
Closing PHP just because the file was not found isn't a really good
behaviour :)
[2004-03-13 04:55:53] [EMAIL PROTECTED]
And the problem is what? (AFAIK, this is the expected behaviour..)
[2004-03-11 11:24:43] [EMAIL PROTECTED]
Description:
Using the given example, PHP exits.
I think the problem is in TIDY_THROW.
Reproduce code:
---
Expected result:
ok
Actual result:
--
(gdb) run bug.php
Starting program: /home/Nuno/php5/sapi/cli/php.exe bug.php
Warning: tidy_parse_file(bogus.htm): failed to open stream: No such
file or dire
ctory in /home/Nuno/php5/sapi/cli/bug.php on line 2
Fatal error: Uncaught exception 'tidy_exception' with message 'Cannot
Load 'bogu
s.htm' into memory ' in /home/Nuno/php5/sapi/cli/bug.php:2
Stack trace:
#0 {main}
thrown in /home/Nuno/php5/sapi/cli/bug.php on line 2
Program exited with code 0377.
--
Edit this bug report at http://bugs.php.net/?id=27570&edit=1
#27570 [Asn->Csd]: Tidy throw
ID: 27570
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Closed
Bug Type: Unknown/Other Function
Operating System: *
PHP Version: 5CVS-2004-03-11 (dev)
Assigned To: john
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:
[2004-03-13 20:44:42] [EMAIL PROTECTED]
This isn't really a bug per-se. Tidy is throwing an exception because
it couldn't find the file, if you want to continue operation then you
have to use a try / catch block. The only "bug" here is that when
called from a procedural context tidy should be generating E_WARNINGs
instead of throwing exceptions.
[2004-03-13 16:50:18] [EMAIL PROTECTED]
All functions that use TIDY_THROW exit PHP when an error is produced.
Closing PHP just because the file was not found isn't a really good
behaviour :)
[2004-03-13 04:55:53] [EMAIL PROTECTED]
And the problem is what? (AFAIK, this is the expected behaviour..)
[2004-03-11 11:24:43] [EMAIL PROTECTED]
Description:
Using the given example, PHP exits.
I think the problem is in TIDY_THROW.
Reproduce code:
---
Expected result:
ok
Actual result:
--
(gdb) run bug.php
Starting program: /home/Nuno/php5/sapi/cli/php.exe bug.php
Warning: tidy_parse_file(bogus.htm): failed to open stream: No such
file or dire
ctory in /home/Nuno/php5/sapi/cli/bug.php on line 2
Fatal error: Uncaught exception 'tidy_exception' with message 'Cannot
Load 'bogu
s.htm' into memory ' in /home/Nuno/php5/sapi/cli/bug.php:2
Stack trace:
#0 {main}
thrown in /home/Nuno/php5/sapi/cli/bug.php on line 2
Program exited with code 0377.
--
Edit this bug report at http://bugs.php.net/?id=27570&edit=1
#28880 [Opn->WFx]: Tidy's "clean" option does not convert font tags to style rules
ID: 28880 Updated by: [EMAIL PROTECTED] -Summary: Tidy generate bogus xhtml Reported By: [EMAIL PROTECTED] -Status: Open +Status: Wont fix Bug Type: Unknown/Other Function -Operating System: all +Operating System: Windows -PHP Version: 5CVS-2004-06-22 (dev) +PHP Version: 5.0.0RC3 -Assigned To: +Assigned To: john New Comment: This isn't a PHP issue, it is a bug in the Tidy library. Please file the report with tidy.sourceforge.net. Previous Comments: [2004-06-22 13:40:19] [EMAIL PROTECTED] Description: Tidy is defaulting output-xhtml to 0, thus generating bogus xhtml. (note the difference between and ) Reproduce code: --- http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en"> test test HTML; $tidy = tidy_parse_string($xhtml); $tidy->CleanRepair(); echo $tidy; ?> Expected result: http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en"> test test Actual result: -- http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en"> test test -- Edit this bug report at http://bugs.php.net/?id=28880&edit=1
#29387 [Opn->Bgs]: pdf_open_file requires 2 arguments where 1 should be permitted
ID: 29387
Updated by: [EMAIL PROTECTED]
Reported By: emile dot axelrad at connect dot co dot uk
-Status: Open
+Status: Bogus
Bug Type: *PDF functions
Operating System: Windows 2000
PHP Version: 5.0.0
Assigned To: hholzgra
New Comment:
You're using the PHP 5 version of the extension and the API has
changed.
Previous Comments:
[2004-09-10 21:27:11] jeremydurham at gmail dot com
If you are searching for a resolution for this issue still, you should
contact pdflib. This is an issue with the implementation of the
functions in the pdf.c file. It can easily be corrected with a few
changes but it is likely not the correct way to solve this problem.
Jeremy
[2004-07-26 13:48:09] emile dot axelrad at connect dot co dot uk
Description:
The PHP manual describes pdf_open_file as working with just one
argument (the pdf handle).
This code works fine with PHP 4 but on PHP 5.0.0 does not work. It
thinks that the 'filename' argument is required, but it is in fact
optional.
Reproduce code:
---
$pdf = pdf_new();
pdf_open_file($pdf);
Expected result:
It should work without an error. Should create a PDF document in
memory, not in a file.
Actual result:
--
Fatal error: Uncaught exception 'PDFlibException' with message
'pdf_open_file() expects exactly 2 parameters, 1 given' in
C:\test.php:2 Stack trace: #0 {main} thrown in C:\test.php on line 2
--
Edit this bug report at http://bugs.php.net/?id=29387&edit=1
#23026 [Opn->Bgs]: Make Zend case-sensitive (classes, functions, remove case-insensitive)
ID: 23026
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: Any
PHP Version: 5CVS-2003-04-02 (dev)
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Previous Comments:
[2003-04-02 15:08:03] [EMAIL PROTECTED]
Keep subject for bugdb searching.
Make Zend case-sensitive (and therefore PHP) in regards to namesapces,
classes, functions. Basically everything which is currently
str_tolower()d inside the engine.
This is just a meta-bug to keep track of suggestions to this topic.
A big "NO" is to make such a thing php.ini dependant ("Not yet another
switch") but truly case-sensitive.
For a start our great Hero[tm] Andrei has made a patch some time ago
against ZE2 to achive this goal (see
http://www.gravitonic.com/software/php/ ). It doesn't apply cleanly to
current HEAD but given the patch size it should be trivial to get it
working.
The big "contra" many people are concerned is BC (backwards
compatibility). Yes, face it. Changing this behaviour will definitely
break millions of scripts. I'm having bad dreams remembering reading
code like $db = MySQL_Connect (and therefore failing my search for it
with 'grep mysql_connect *' because I was to lazy about three extra
characters ;).
Also see (bogusified) bug http://bugs.php.net/bug.php?id=15415 for a
VOTE on this issue.
Ok, there we go :)
--
Edit this bug report at http://bugs.php.net/?id=23026&edit=1
#24432 [Opn->WFx]: Change mimetypes to allow php 4&5 to run at the same time
ID: 24432 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Wont fix Bug Type: Feature/Change Request Operating System: All PHP Version: 5.0.0b1 (beta1) New Comment: There are other significant issues involved in trying to get PHP 4 and PHP 5 to run at the same time in Apache. If you must run one or the other check out the Apache ProxyPass directive. I've got a quick how-to here: http://wiki.coggeshall.org/Main/RunningPHP4AndPHP5Concurrently Previous Comments: [2003-07-01 06:39:17] [EMAIL PROTECTED] Description: Change or add application/x-httpd-php5 (instead) of application/x-httpd-php for apache to allow us to run both php4 and php5 at the same time using DSO modules. -- Edit this bug report at http://bugs.php.net/?id=24432&edit=1
#30580 [Opn->Bgs]: GD imagecolorallocate does not work after many allocations
ID: 30580
Updated by: [EMAIL PROTECTED]
Reported By: jay at kuantic dot com
-Status: Open
+Status: Bogus
Bug Type: GD related
Operating System: Linux fedora core 1
PHP Version: 5.0.2
New Comment:
You're reaching the palette limit. Create the image using
imagecreatetruecolor()
Previous Comments:
[2004-10-27 13:59:17] jay at kuantic dot com
Description:
After several color allocations, imagecolorallocate seems to no work
anymore. See code sample (illogical but point at the problem).
Reproduce code:
---
function letter($l, $x, $y, $img) {
$color1 = imagecolorallocate($img, 190, 190, 190);
imagestring ($img, 1, $x+1, $y+1, $l, $color1);
$color2 = imagecolorallocate($img, 190, 190, 190);
imagestring ($img, 1, $x-1, $y-1, $l, $color2);
$color3 = in a picture.($img, 255, 0, 0);
imagestring ($img, 1, $x, $y, $l, $color3);
}
$image = @imagecreate (1200, 500);
$background_color = imagecolorallocate ($image, 255, 255, 255);
for ($i = 0; $i < 100; $i++){
letter($i, $i*12, 50, $image);
}
header ("Content-type: image/png");
imagepng ($image);
imagedestroy($image);
Expected result:
expected : display 1 to 100 red digits with gray shadow in a picture.
Actual result:
--
result : displays 1 to 84 red digits with gray shadow in a picture.
After 84, digits and shadows are all red. imagecolorallocate seems to
not work anymore.
--
Edit this bug report at http://bugs.php.net/?id=30580&edit=1
#29225 [Opn->WFx]: java Extention is not availabe
ID: 29225
Updated by: [EMAIL PROTECTED]
Reported By: php4web at php4web dot com
-Status: Open
+Status: Wont fix
Bug Type: Java related
Operating System: windows xp professtional
PHP Version: 5.0.0
New Comment:
The Java extension is not available in PHP 5.
Previous Comments:
[2004-11-05 17:11:49] mz at salon-margit dot de
java integration failure using:
---
*CLI Mode
*OS: Windows 2000 pro SP4
*PHP 5.0.2 (cli) (built: Sep 24 2004 01:25:41)
*Java(TM) 2 Runtime Environment, Standard Edition
(build 1.4.2_05-b04)
Java HotSpot(TM) Client VM (build 1.4.2_05-b04, mixed mode)
--
PHP.ini:
extension=php_java.dll
--
Test via Docu-Example:
getProperty('java.version') . '';
echo 'Java vendor=' . $system->getProperty('java.vendor') . '';
echo 'OS=' . $system->getProperty('os.name') . ' ' .
$system->getProperty('os.version') . ' on ' .
$system->getProperty('os.arch') . ' ';
// java.util.Date example
$formatter = new Java('java.text.SimpleDateFormat',
", dd, 'at' h:mm:ss a ");
echo $formatter->format(new Java('java.util.Date'));
?>
--
Results in: (translated)
(Windows) Program failure:
php.exe caused an error and got shut down.
Restart the program.
A failure protocol is created.
--
PHP-Info for JAVA:
java.class.path no value no value
java.home no value no value
java.library jvm.dlljvm.dll
java.library.path no value no value
--
Best Regards
mz.
[2004-07-17 13:18:25] php4web at php4web dot com
Description:
this is no Java integration at all in PHP 5 !
there are dll but there no instrction or installation note
the setting from php.ini for Java is removed !
--
Edit this bug report at http://bugs.php.net/?id=29225&edit=1
#28110 [Opn->Csd]: Interpreter crashes reproducibly (2)
ID: 28110
Updated by: [EMAIL PROTECTED]
Reported By: cpuidle at gmx dot de
-Status: Open
+Status: Closed
Bug Type: Reproducible crash
Operating System: WinXP SP1
PHP Version: 5CVS-2004-04-22 (dev)
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:
[2004-10-12 09:36:45] [EMAIL PROTECTED]
This has nothing to do with Apache since it's a crash in Zend.
[2004-10-11 19:05:30] joel at preacherboy dot net
I'm seeing this occur with Apache 2.0.52, PHP 5.0.2, and Windows 2003.
I'm not doing anything particularly special in the PHP. Most of the
hosted files are 100% HTML going through PHP.
[2004-06-28 23:20:06] chris at leftbrained dot org
I, too, am getting that same error message in the apache error log, but
I can duplicate it differently.
Every call to bcmul(), I tried various values, and various values for
bcscale), where either of the arguments is 0 will produce this error.
$fStepX = '0.0075';
bcmul($fStepX,0);
The system:
PHP 5.0, RC3 (Module, Pre-compiled , downloaded from php.net[Hurricane
Electric mirror])
Windows 2000 Pro, SP4 [5.00.2195]
Apache 2.0.49 (Pre-compiled, downloaded from apache.org, No SSL)
Error message in Apache error log:
[Mon Jun 28 13:52:23 2004] [notice] Parent: child process exited with
status 3221225477 -- Restarting.
[Mon Jun 28 13:52:23 2004] [notice] Parent: Created child process 2000
I wasn't sure whether I should give this a new bug report, or tack it
on to one of the exisitings ones. I chose this one because it was the
only relevant open report I could find.
[2004-06-03 14:27:07] messju at lammfellpuschen dot de
event simpler code that reproduces this crash:
plugins['function']['counter'][0]();
}
?>
note: the function doesn't need to be called. it already
crashes during parsing.
with php-5.0.0RC3RC2 on linux i get:
(gdb) r
Starting
program: /mnt/debbie/home/messju/build/php-5.0.0RC3RC2/sapi/cli/php
/usr/local/httpd/messju/foo.php
[Thread debugging using libthread_db enabled]
[New Thread 1078702752 (LWP 14190)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1078702752 (LWP 14190)]
0x08207bb3 in zend_binary_strcasecmp (s1=0x0, len1=7,
s2=0x83ad53c "__clone", len2=7)
at ctype.h:192
192 {
(gdb) bt
#0 0x08207bb3 in zend_binary_strcasecmp (s1=0x0, len1=7,
s2=0x83ad53c "__clone", len2=7)
at ctype.h:192
#1 0x081f7b0f in zend_do_begin_method_call
(left_bracket=0xbfffc0bc)
at
/home/messju/debbie/build/php-5.0.0RC3RC2/Zend/zend_compile.c:1203
#2 0x081ed16b in zendparse () at
Zend/zend_language_parser.c:3229
#3 0x081ee671 in compile_file (file_handle=0x2, type=2)
at Zend/zend_language_scanner.c:3141
#4 0x0820a6bb in zend_execute_scripts (type=8,
retval=0x0, file_count=3)
at /home/messju/debbie/build/php-5.0.0RC3RC2/Zend/zend.c:1057
#5 0x081d049f in php_execute_script
(primary_file=0xb4d0)
at /home/messju/debbie/build/php-5.0.0RC3RC2/main/main.c:1627
#6 0x082350ae in main (argc=2, argv=0xb594)
at /home/messju/debbie/build/php-5.0.0RC3RC2/sapi/cli/php_cli.c:943
[2004-04-22 18:43:40] cpuidle at gmx dot de
Not sure the two are related, but I've also found bug 28108, please
cross-check.
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/28110
--
Edit this bug report at http://bugs.php.net/?id=28110&edit=1
#30660 [Opn]: Using Tidy as shared extension crashes PHP (CLI)
ID: 30660 Updated by: [EMAIL PROTECTED] Reported By: margus at zone dot ee Status: Open Bug Type: Reproducible crash Operating System: SuSe Linux 9.0 PHP Version: 5.0.2 -Assigned To: +Assigned To: john New Comment: I'll look into it, hopefully I'll be able to reproduce it in RH Previous Comments: [2004-11-02 14:23:54] margus at zone dot ee linux:/home/margus/install/php-5.0.2 # gdb sapi/cli/php GNU gdb 5.3.92 Copyright 2003 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 "i586-suse-linux"... (gdb) run -c . tidytest.php Starting program: /home/margus/install/php-5.0.2/sapi/cli/php -c . tidytest.php [New Thread 16384 (LWP 21668)] Exiting... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 21668)] 0x0816a055 in _zval_dtor (zvalue=0x826ad1c) at /home/margus/install/php-5.0.2/Zend/zend_variables.c:61 61 Z_OBJ_HT_P(zvalue)->del_ref(zvalue TSRMLS_CC); (gdb) bt #0 0x0816a055 in _zval_dtor (zvalue=0x826ad1c) at /home/margus/install/php-5.0.2/Zend/zend_variables.c:61 #1 0x08161e89 in _zval_ptr_dtor (zval_ptr=0x826fe48) at /home/margus/install/php-5.0.2/Zend/zend_execute_API.c:394 #2 0x081715e9 in zend_hash_apply_deleter (ht=0x81ea6d0, p=0x826fe3c) at /home/margus/install/php-5.0.2/Zend/zend_hash.c:574 #3 0x08171679 in zend_hash_graceful_reverse_destroy (ht=0x81ea6d0) at /home/margus/install/php-5.0.2/Zend/zend_hash.c:640 #4 0x08161944 in shutdown_executor () at /home/margus/install/php-5.0.2/Zend/zend_execute_API.c:210 #5 0x0816b126 in zend_deactivate () at /home/margus/install/php-5.0.2/Zend/zend.c:818 #6 0x081395c7 in php_request_shutdown (dummy=0x0) at /home/margus/install/php-5.0.2/main/main.c:1212 #7 0x081987d0 in main (argc=4, argv=0xb704) at /home/margus/install/php-5.0.2/sapi/cli/php_cli.c:1046 (gdb) [2004-11-02 13:41:01] [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 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. Oops, clicked the wrong link before... [2004-11-02 13:34:32] margus at zone dot ee "); echo "Exiting..."; ?> [2004-11-02 13:28:19] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2004-11-02 13:26:02] margus at zone dot ee Description: When building and using Tidy extension separately as shared module, then PHP-CLI crashes at the end. Everything seems to work, when compiling the extension directly into PHP binary. Reproduce code: --- build LIBTIDY: - /bin/sh build/gnuauto/setup.sh - ./configure --with-prefix=/usr - make - make install - ldconfig build PHP5 (5.0.2): - ./configure --with-tidy=shared,/usr - make changes in PHP.INI: extension_dir=. script tidytest.php: "); echo "Exiting..."; ?> Expected result: Exiting... Actual result: -- Exiting...Segmentation Fault -- Edit this bug report at http://bugs.php.net/?id=30660&edit=1
#28841 [Opn->Asn]: Tidy's "clean" option does not convert font tags to style rules
ID: 28841
Updated by: [EMAIL PROTECTED]
Reported By: mlee at kanhan dot com
-Status: Open
+Status: Assigned
Bug Type: Unknown/Other Function
Operating System: Windows
PHP Version: 5.0.0RC3
-Assigned To:
+Assigned To: john
New Comment:
Currently in HEAD this actually segfaulting inside of libtidy itself.
I'm not sure if this is a libtidy bug, or if the extension is doing
something it shouldn't be. I'll look into it and see what I can dig up.
Previous Comments:
[2004-06-19 17:01:51] mlee at kanhan dot com
Description:
Supposedly Tidy should "strip out surplus presentational tags and
attributes replacing them by style rules and structural markup as
appropriate" if the "clean" option is set. For example:
TRUE);
$tidy = tidy_parse_file("clean_ex1.html", $conf);
tidy_clean_repair($tidy);
echo $tidy;
?>
And clean_ex1.html looks like this:
Hello, World!
More Text...
It seems that Tidy just removes the font tags without adding any style
rules.
--
Edit this bug report at http://bugs.php.net/?id=28841&edit=1
#38904 [Ana->Asn]: apache2filter changes cwd to /
ID: 38904
Updated by: [EMAIL PROTECTED]
Reported By: hannes dot magnusson at gmail dot com
-Status: Analyzed
+Status: Assigned
Bug Type: Apache2 related
Operating System: FreeBSD6.1
PHP Version: 5CVS-2006-09-20 (CVS)
-Assigned To:
+Assigned To: john
Previous Comments:
[2006-09-22 12:42:13] [EMAIL PROTECTED]
Patch: http://php.is/bugs/38904/apache2filter.patch.txt
[2006-09-20 16:30:47] hannes dot magnusson at gmail dot com
Description:
running apache2filter changes cwd to /
Caused by the re-implementation see:
http://news.php.net/php.cvs/39024
Reproduce code:
---
var_dump(getcwd(), realpath("."));
Actual result:
--
string(1) "/" string(1) "/"
--
Edit this bug report at http://bugs.php.net/?id=38904&edit=1
#37438 [Bgs]: PDO_MySQL segfaults Apache child
ID: 37438 Updated by: [EMAIL PROTECTED] Reported By: indeyets at gmail dot com Status: Bogus Bug Type: PDO related Operating System: FreeBSD PHP Version: 5.1.4 New Comment: This appears to be a bug related to the Primary Key. I experienced the issue with a table that had an integer primary key (non auto inc) and PHP would segfault if the table had a row who's PK == 0. Deleting the row solved the problem Previous Comments: [2006-05-15 10:04:52] [EMAIL PROTECTED] See #37445 for more info. [2006-05-14 16:22:19] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2006-05-14 16:15:40] indeyets at gmail dot com Description: After upgrading from 5.1.2 to 5.1.4 apache childs began to segfault at some requests. Backtrace showed, that the problem lies inside of PDO_MySQL. The issue was originally mentioned here: http://pecl.php.net/bugs/bug.php?id=7433 reverting this patch solves the issue: http://cvs.php.net/viewcvs.cgi/php-src/ext/pdo_mysql/mysql_statement.c?r1=1.48.2.12&r2=1.48.2.13 Actual result: -- #0 0x2908180a in mysql_more_results () from /usr/local/lib/mysql/libmysqlclient.so.15 #1 0x29064c4c in pdo_mysql_stmt_dtor (stmt=0x8743124) at /usr/ports/lang/php5/work/php-5.1.4/ext/pdo_mysql/mysql_statement.c:79 #2 0x29022bee in free_statement (stmt=0x8743124) at /usr/ports/lang/php5/work/php-5.1.4/ext/pdo/pdo_stmt.c:2200 #3 0x29022c63 in pdo_dbstmt_free_storage (stmt=0x8743124) at /usr/ports/lang/php5/work/php-5.1.4/ext/pdo/pdo_stmt.c:2245 #4 0x28740a46 in ?? () from /usr/local/libexec/apache22/libphp5.so -- Edit this bug report at http://bugs.php.net/?id=37438&edit=1
#37438 [Bgs->Ana]: PDO_MySQL segfaults Apache child
ID: 37438 Updated by: [EMAIL PROTECTED] Reported By: indeyets at gmail dot com -Status: Bogus +Status: Analyzed Bug Type: PDO related Operating System: FreeBSD PHP Version: 5.1.4 Previous Comments: [2006-09-22 15:48:47] [EMAIL PROTECTED] This appears to be a bug related to the Primary Key. I experienced the issue with a table that had an integer primary key (non auto inc) and PHP would segfault if the table had a row who's PK == 0. Deleting the row solved the problem [2006-05-15 10:04:52] [EMAIL PROTECTED] See #37445 for more info. [2006-05-14 16:22:19] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2006-05-14 16:15:40] indeyets at gmail dot com Description: After upgrading from 5.1.2 to 5.1.4 apache childs began to segfault at some requests. Backtrace showed, that the problem lies inside of PDO_MySQL. The issue was originally mentioned here: http://pecl.php.net/bugs/bug.php?id=7433 reverting this patch solves the issue: http://cvs.php.net/viewcvs.cgi/php-src/ext/pdo_mysql/mysql_statement.c?r1=1.48.2.12&r2=1.48.2.13 Actual result: -- #0 0x2908180a in mysql_more_results () from /usr/local/lib/mysql/libmysqlclient.so.15 #1 0x29064c4c in pdo_mysql_stmt_dtor (stmt=0x8743124) at /usr/ports/lang/php5/work/php-5.1.4/ext/pdo_mysql/mysql_statement.c:79 #2 0x29022bee in free_statement (stmt=0x8743124) at /usr/ports/lang/php5/work/php-5.1.4/ext/pdo/pdo_stmt.c:2200 #3 0x29022c63 in pdo_dbstmt_free_storage (stmt=0x8743124) at /usr/ports/lang/php5/work/php-5.1.4/ext/pdo/pdo_stmt.c:2245 #4 0x28740a46 in ?? () from /usr/local/libexec/apache22/libphp5.so -- Edit this bug report at http://bugs.php.net/?id=37438&edit=1
#37438 [Ana]: PDO_MySQL segfaults Apache child
ID: 37438 Updated by: [EMAIL PROTECTED] Reported By: indeyets at gmail dot com Status: Analyzed Bug Type: PDO related Operating System: FreeBSD -PHP Version: 5.1.4 +PHP Version: 5.1.4 & 5.1.6 New Comment: Bug still exists in 5.1.6 Previous Comments: [2006-09-22 15:48:47] [EMAIL PROTECTED] This appears to be a bug related to the Primary Key. I experienced the issue with a table that had an integer primary key (non auto inc) and PHP would segfault if the table had a row who's PK == 0. Deleting the row solved the problem [2006-05-15 10:04:52] [EMAIL PROTECTED] See #37445 for more info. [2006-05-14 16:22:19] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2006-05-14 16:15:40] indeyets at gmail dot com Description: After upgrading from 5.1.2 to 5.1.4 apache childs began to segfault at some requests. Backtrace showed, that the problem lies inside of PDO_MySQL. The issue was originally mentioned here: http://pecl.php.net/bugs/bug.php?id=7433 reverting this patch solves the issue: http://cvs.php.net/viewcvs.cgi/php-src/ext/pdo_mysql/mysql_statement.c?r1=1.48.2.12&r2=1.48.2.13 Actual result: -- #0 0x2908180a in mysql_more_results () from /usr/local/lib/mysql/libmysqlclient.so.15 #1 0x29064c4c in pdo_mysql_stmt_dtor (stmt=0x8743124) at /usr/ports/lang/php5/work/php-5.1.4/ext/pdo_mysql/mysql_statement.c:79 #2 0x29022bee in free_statement (stmt=0x8743124) at /usr/ports/lang/php5/work/php-5.1.4/ext/pdo/pdo_stmt.c:2200 #3 0x29022c63 in pdo_dbstmt_free_storage (stmt=0x8743124) at /usr/ports/lang/php5/work/php-5.1.4/ext/pdo/pdo_stmt.c:2245 #4 0x28740a46 in ?? () from /usr/local/libexec/apache22/libphp5.so -- Edit this bug report at http://bugs.php.net/?id=37438&edit=1
#20984 [NEW]: copy( "file.txt" , "file.txt" ) empties the file
From: [EMAIL PROTECTED] Operating system: w2k PHP version: 4.2.3 PHP Bug Type: Unknown/Other Function Bug description: copy( "file.txt" , "file.txt" ) empties the file copy( "toto.txt" , "toto.txt"); // then toto.txt is empty -- Edit bug report at http://bugs.php.net/?id=20984&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20984&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20984&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20984&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20984&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20984&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20984&r=support Expected behavior: http://bugs.php.net/fix.php?id=20984&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20984&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20984&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20984&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20984&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20984&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20984&r=isapi
#20984 [Com]: copy( "file.txt" , "file.txt" ) empties the file
ID: 20984 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Unknown/Other Function Operating System: w2k PHP Version: 4.2.3 New Comment: Well, It's not allowed to do that in a command window. Why should this function empty the file. I suggest return false only and leave the file as it is like in the command window. Previous Comments: [2002-12-13 04:05:32] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [2002-12-13 03:39:33] [EMAIL PROTECTED] copy( "toto.txt" , "toto.txt"); // then toto.txt is empty -- Edit this bug report at http://bugs.php.net/?id=20984&edit=1
#21442 [NEW]: empty recipient for mail() function crashed Apache
From: [EMAIL PROTECTED] Operating system: Windows NT4 Server PHP version: 4.3.0 PHP Bug Type: Reproducible crash Bug description: empty recipient for mail() function crashed Apache A script like crashed Apache server (1.3.26). PHP is installed as a Apache module. -- Edit bug report at http://bugs.php.net/?id=21442&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21442&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21442&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21442&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21442&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21442&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21442&r=support Expected behavior: http://bugs.php.net/fix.php?id=21442&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21442&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21442&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21442&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21442&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21442&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21442&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21442&r=gnused
#21442 [Bgs]: empty recipient for mail() function crashed Apache
ID: 21442 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Reproducible crash Operating System: Windows NT4 Server PHP Version: 4.3.0 New Comment: I can certainly send email if a valid email address is specified. The problem is that passing an empty string as the first parameter of mail() in Windows version of PHP 4.3.0 and Apache crashed (Dr. Watson popped up and said address violation) is not normal. I expect some error messages are sent to the browser instead of crashing Apache. Previous Comments: [2003-01-05 15:52:56] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. [2003-01-05 14:57:44] [EMAIL PROTECTED] A script like crashed Apache server (1.3.26). PHP is installed as a Apache module. -- Edit this bug report at http://bugs.php.net/?id=21442&edit=1
#21442 [Opn->Bgs]: empty recipient for mail() function crashed Apache
ID: 21442 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Windows NT4 Server PHP Version: 4.3.0 New Comment: I am using Windows version of PHP and how can sendmail involved! I read from the doc. that PHP forward the mail to a SMTP server for Win version of PHP. Previous Comments: [2003-01-05 16:27:39] [EMAIL PROTECTED] sendmail on windows? Let's keep it open until we have somebody who can reproduce this on windows, I just tried with the CLI and couldn't get it to crash (latest CVS), so you might want to try a snapshot from snaps.php.net (go for a development snapshot). [2003-01-05 16:24:55] [EMAIL PROTECTED] it is sendmail that should handle this, not php... [2003-01-05 16:11:30] [EMAIL PROTECTED] I can certainly send email if a valid email address is specified. The problem is that passing an empty string as the first parameter of mail() in Windows version of PHP 4.3.0 and Apache crashed (Dr. Watson popped up and said address violation) is not normal. I expect some error messages are sent to the browser instead of crashing Apache. [2003-01-05 15:52:56] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. [2003-01-05 14:57:44] [EMAIL PROTECTED] A script like crashed Apache server (1.3.26). PHP is installed as a Apache module. -- Edit this bug report at http://bugs.php.net/?id=21442&edit=1
Bug #17350: ldap_bind not working for servers running on ports other than the default
From: [EMAIL PROTECTED]
Operating system: RedHat 7.3
PHP version: 4.1.2
PHP Bug Type: LDAP related
Bug description: ldap_bind not working for servers running on ports other than the
default
When running OpenLdap on a port other than the default 389, ldap_bind fails
to function - giving the following error message -
Warning: LDAP: Unable to bind to server: Can't contact LDAP server in
/var/www/html/connext.phtml on line 29
The related php section of connext.phtml being -
\n";
$host = "ldap://ip.goes.here";;
$port = 37337;
$binddn = "cn=Manager, o=netfaves, c=ie";
$bindpw = "secret";
$check = ldap_connect( $host, $port );
echo "check = " ;print("$check ");
if($check)
{
echo "Connected successfully \n";
$bindcheck = ldap_bind( $check, "cn=Manager, o=netfaves, c=ie",
"secret" );
print("bindcheck = '$bindcheck'");
if ($bindcheck)
echo "Succesfully Bound\n";
else
echo "No luck this time buddy...\n";
}
else
echo "Error! Could not connect to ldap host $host\n";
echo "end php block code \n";
?>
ldap_connect functions as expected here and returns "Resource id #1".
When I restart slapd, this time running on port 389, ldap_bind has no
problem connecting and returning "1". I tried running slapd on various
other high ports, each time getting the same error message. This pretty
much means that you need to run slapd as root to be able to interact with
it via php.
I had a quick look through the source but couldn't pinpoint anything that
might be at fault - but my C isn't the best anyway.
I had the same problem with php 4.2.1 aswell, but haven't had the chance
to try reproduce it.
Regards,
John Canavan
--
Edit bug report at http://bugs.php.net/?id=17350&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17350&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17350&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17350&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17350&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17350&r=support
Expected behavior: http://bugs.php.net/fix.php?id=17350&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17350&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17350&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17350&r=globals
#19735 [NEW]: Oracle - kgepop error OciNewCollection
From: [EMAIL PROTECTED]
Operating system: NT4 SP3
PHP version: 4.2.1
PHP Bug Type: Reproducible crash
Bug description: Oracle - kgepop error OciNewCollection
When run from command line:
$Conn = OciLogon("user", "pass", "db") or die("error");
$Coll = OciNewCollection($Conn, "valid_type_or_nonsense");
consistently causes following error:
kgepop: no error frame to pop to for error 21522
Don't know if same error occurs on web server (don't use version with
collection capabilities on server)
php.exe straight from win32 zip.
php_oc8.dll extension enabled.
--
Edit bug report at http://bugs.php.net/?id=19735&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=19735&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=19735&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=19735&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=19735&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=19735&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=19735&r=support
Expected behavior: http://bugs.php.net/fix.php?id=19735&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=19735&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=19735&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=19735&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19735&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=19735&r=dst
Bug #15493: PHP sends no location header when output_buffering = On
From: [EMAIL PROTECTED]
Operating system: Linux 2.4.8
PHP version: 4.0.6
PHP Bug Type: Output Control
Bug description: PHP sends no location header when output_buffering = On
//Bug in PHP 4.0.6
If output_buffer = On AND
session_start() AND
header("Location: ..) AND
no HTML output then
PHP sends no header
You expect the browser to redirect to Location URL.
What really happends depends on the browser:
- Netscape: waits a while and nothing happens
- IE: redirects to search engine
- Konqueror: connection lost
- Some browsers indicate empty document received
Work around:
- when output buffering is on, then add blank line before start of
script
- switch output buffering off
Example PHP page excerpt:
--
Edit bug report at http://bugs.php.net/?id=15493&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15493&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15493&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15493&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15493&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15493&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15493&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15493&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15493&r=submittedtwice
Bug #15493 Updated: PHP sends no location header when output_buffering = On
ID: 15493
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Output Control
Operating System: Linux 2.4.8
PHP Version: 4.0.6
New Comment:
I tried to follow the instructions in INSTALL.
Configure option --with-apxs was not working as this package was not
installed on my machine.
As package apxs was not delivered with Mandrake 8.1 AND PHP 4.0.6 was
running fine without this package it did not look required to me (maybe
I am wrong).
I decided to take over the options as indicated by phpinfo() in
php4.0.6.
After "make install" all files in /usr/lib/php were updated.
Directory /usr/lib contained a new binary of php (3.1 Mb).
However a new version of php module libphp4.so was not generated.
phpinfo() shows that 4.0.6 is still running on my system.
Previous Comments:
[2002-02-13 08:34:39] [EMAIL PROTECTED]
4.2.0's output related code differs from 4.1.1. Could you try
snapshot?
http://snaps.php.net/
Please report the result. Thanks.
[2002-02-13 02:03:39] [EMAIL PROTECTED]
4.2.0's output related code differs from 4.1.1. Could you try
snapshot?
http://snaps.php.net/
Please report the result. Thanks.
[2002-02-10 18:16:43] [EMAIL PROTECTED]
//Bug in PHP 4.0.6
If output_buffer = On AND
session_start() AND
header("Location: ..) AND
no HTML output then
PHP sends no header
You expect the browser to redirect to Location URL.
What really happends depends on the browser:
- Netscape: waits a while and nothing happens
- IE: redirects to search engine
- Konqueror: connection lost
- Some browsers indicate empty document received
Work around:
- when output buffering is on, then add blank line before start of
script
- switch output buffering off
Example PHP page excerpt:
--
Edit this bug report at http://bugs.php.net/?id=15493&edit=1
Bug #15834: segmentation fault starting apache with pfpro
From: [EMAIL PROTECTED] Operating system: linux RH7.1 PHP version: 4.1.2 PHP Bug Type: Reproducible crash Bug description: segmentation fault starting apache with pfpro I get a segmentation fault when start apache when php4.1.2 is compiled with verisign payflowpro. If a recompile with this option everything is OK. I have encountered this problem with all previous versions also. -- Edit bug report at http://bugs.php.net/?id=15834&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15834&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15834&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15834&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15834&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15834&r=support Expected behavior: http://bugs.php.net/fix.php?id=15834&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15834&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15834&r=submittedtwice
Bug #15834 Updated: segmentation fault starting apache with pfpro
ID: 15834 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: linux RH7.1 PHP Version: 4.1.2 New Comment: Not sure how this could be generated since apache will not start. Follwing is the message that I received when trying to start apache. line 184: 3736 Segmentation fault $HTTPD /usr/local/apache/bin/apachectl start: httpd could not be started Previous Comments: [2002-03-02 11:19:15] [EMAIL PROTECTED] To properly diagnose this bug, 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 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". [2002-03-02 11:18:41] [EMAIL PROTECTED] I get a segmentation fault when start apache when php4.1.2 is compiled with verisign payflowpro. If a recompile with this option everything is OK. I have encountered this problem with all previous versions also. -- Edit this bug report at http://bugs.php.net/?id=15834&edit=1
Bug #15834 Updated: segmentation fault starting apache with pfpro
ID: 15834 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: linux RH7.1 PHP Version: 4.1.2 New Comment: Following is the message. Thanks. Program received signal SIGSEGV, Segmentation fault. 0x400d528c in __umoddi3 () from /usr/local/verisign/payflowpro/linux/lib/libpfpro.so Previous Comments: [2002-03-02 11:27:02] [EMAIL PROTECTED] gdb /path/to/httpd and enter on the prompt: run -X [2002-03-02 11:25:26] [EMAIL PROTECTED] Not sure how this could be generated since apache will not start. Follwing is the message that I received when trying to start apache. line 184: 3736 Segmentation fault $HTTPD /usr/local/apache/bin/apachectl start: httpd could not be started [2002-03-02 11:19:15] [EMAIL PROTECTED] To properly diagnose this bug, 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 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". [2002-03-02 11:18:41] [EMAIL PROTECTED] I get a segmentation fault when start apache when php4.1.2 is compiled with verisign payflowpro. If a recompile with this option everything is OK. I have encountered this problem with all previous versions also. -- Edit this bug report at http://bugs.php.net/?id=15834&edit=1
Bug #15834 Updated: segmentation fault starting apache with pfpro
ID: 15834 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: linux RH7.1 PHP Version: 4.1.2 New Comment: Here it is. #0 0x400d528c in __umoddi3 () from /usr/local/verisign/payflowpro/linux/lib/libpfpro.so No symbol table info available. #1 0x400b7678 in PNVersion () from /usr/local/verisign/payflowpro/linux/lib/libpfpro.so No symbol table info available. Cannot access memory at address 0x3 Previous Comments: [2002-03-02 11:38:26] [EMAIL PROTECTED] Oops :) Can you hit 'bt full' on the prompt after the crash and post the results again? regards, derick [2002-03-02 11:36:56] [EMAIL PROTECTED] Following is the message. Thanks. Program received signal SIGSEGV, Segmentation fault. 0x400d528c in __umoddi3 () from /usr/local/verisign/payflowpro/linux/lib/libpfpro.so [2002-03-02 11:27:02] [EMAIL PROTECTED] gdb /path/to/httpd and enter on the prompt: run -X [2002-03-02 11:25:26] [EMAIL PROTECTED] Not sure how this could be generated since apache will not start. Follwing is the message that I received when trying to start apache. line 184: 3736 Segmentation fault $HTTPD /usr/local/apache/bin/apachectl start: httpd could not be started [2002-03-02 11:19:15] [EMAIL PROTECTED] To properly diagnose this bug, 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 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". 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/15834 -- Edit this bug report at http://bugs.php.net/?id=15834&edit=1
Bug #15834 Updated: segmentation fault starting apache with pfpro
ID: 15834 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: linux RH7.1 PHP Version: 4.1.2 New Comment: Same error and message. Following are my configuration parameters - if this helps. Thanks. ./configure --with-apache=/usr/local/apache_1.3.22.src --prefix=/usr/local --enable-libgcc --enable-pic --enable-shared --enable-inline-optimization --with-exec-dir=/usr/local --with-png --with-zlib --enable-magic-quotes --enable-safe-mode --enable-sockets --enable-sysvsem --enable-sysvshm --enable-track-vars --enable-yp --enable-ftp --enable-wddx --with-mysql --with-xml --with-mcrypt --with-jpeg --with-tiff --with-pfpro=/usr/local/verisign/payflowpro/linux Previous Comments: [2002-03-02 22:08:06] [EMAIL PROTECTED] This can happen when you link a library not compiled/linked with gcc into an app that is, or vice versa. Try adding this switch to your PHP ./configure line: --enable-libgcc [2002-03-02 11:43:02] [EMAIL PROTECTED] Here it is. #0 0x400d528c in __umoddi3 () from /usr/local/verisign/payflowpro/linux/lib/libpfpro.so No symbol table info available. #1 0x400b7678 in PNVersion () from /usr/local/verisign/payflowpro/linux/lib/libpfpro.so No symbol table info available. Cannot access memory at address 0x3 [2002-03-02 11:38:26] [EMAIL PROTECTED] Oops :) Can you hit 'bt full' on the prompt after the crash and post the results again? regards, derick [2002-03-02 11:36:56] [EMAIL PROTECTED] Following is the message. Thanks. Program received signal SIGSEGV, Segmentation fault. 0x400d528c in __umoddi3 () from /usr/local/verisign/payflowpro/linux/lib/libpfpro.so [2002-03-02 11:27:02] [EMAIL PROTECTED] gdb /path/to/httpd and enter on the prompt: run -X 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/15834 -- Edit this bug report at http://bugs.php.net/?id=15834&edit=1
Req #38508 [Com]: Addition of Magic __toArray() function
Edit report at https://bugs.php.net/bug.php?id=38508&edit=1
ID: 38508
Comment by: john at john dot com
Reported by:doublecompile at gmail dot com
Summary:Addition of Magic __toArray() function
Status: Closed
Type: Feature/Change Request
Package:Feature/Change Request
PHP Version:*
Block user comment: N
Private report: N
New Comment:
this magic function would be great to have
Previous Comments:
[2011-05-23 23:32:13] spark at limao dot com dot br
Because of the magic __toString I was able to write a String class with the
same methods as the Java String class.
I was trying to write an Array class to map the one in Adobe AS3, but then I
came across the lack of __toArray.
I don't want a __toArray, or even a toString
I want classes with reasonable methods and not lots of functions with no naming
rules nor parameter order standard.
I know it may sound rude but that's how I feel when I see a language getting so
far and still not following any coding convetion.
[2006-08-20 11:12:22] he...@php.net
Why not simply have a method asArray() maybe even as par of an interface:
interface ArrayConversion
{
function asArray();
}
See, we have __toString as it is supported in language constructs like echo,
print and other internal functions. But we decided against an autoconversion
for arrays already. So itwill never be supported in any language construct.
That said there is no needed for this and nothing you would win against the
above interface. In fact you would make it php more complex because you'd add
just one more magic feature.
[2006-08-19 00:40:17] doublecompile at gmail dot com
Description:
Doing this:
$newarray = (array)$object;
will take the properties of an object and assign them as the values of keys in
an array.
As of PHP 5.2, doing this:
$stringified = (string)$object;
will call the magic __toString() function for a user-specified formatting of
the object as a string.
It would be a great addition to call a magic __toArray() function if an object
is cast as an array, instead of converting its public members to array
elements. (For instance, the class might not have public members). Classes
without the function could use the default method of mapping property names to
array keys.
Just my two cents.
Reproduce code:
---
'bar');
}
}
$test = new magicExample();
$array = (array)$test;
print_r($array); // should show foo=>bar, not aoeu=>htns
?>
--
Edit this bug report at https://bugs.php.net/bug.php?id=38508&edit=1
#27299 [NEW]: Preg_replace cannot handle ticks(')
From: john at supernerd dot com
Operating system: Windows 2000
PHP version: 4.3.4
PHP Bug Type: PCRE related
Bug description: Preg_replace cannot handle ticks(')
Description:
returns an error of
Parse error: parse error, unexpected T_CONSTANT_ENCAPSED_STRING in
C:\Documents and Settings\john\Desktop\ttms
desktop\php\gui\Smarty_Compiler.class.php(288) : regexp code on line 2
Reproduce code:
---
$ldq = preg_quote('{', '!');
$rdq = preg_quote('}', '!');
$search =
"!{$ldq}\*(.*?)\*{$rdq}|{$ldq}\s*literal\s*{$rdq}(.*?){$ldq}\s*/literal\s*{$rdq}|{$ldq}\s*php\s*{$rdq}(.*?){$ldq}\s*/php\s*{$rdq}!s";
$source_content = preg_replace($search.'e', "'"
. '{' . 'php'
. "' . str_repeat(\"\n\",
substr_count('\\0', \"\n\")) .'"
. '}'
. "'",
"a
{literal}b{/literal}c{php}d;s{/php}e{* hello's *}");
Expected result:
a{php}c{php}e{php}
Actual result:
--
Parse error: parse error, unexpected T_CONSTANT_ENCAPSED_STRING in
C:\Documents and Settings\john\Desktop\ttms desktop\php\index.php(17) :
regexp code on line 2
Fatal error: Failed evaluating code: '{php' . str_repeat(" ",
substr_count('{* hello''s *}', " ")) .'}' in C:\Documents and
Settings\john\Desktop\ttms desktop\php\index.php on line 17
--
Edit bug report at http://bugs.php.net/?id=27299&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27299&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27299&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27299&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27299&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27299&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27299&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27299&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27299&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27299&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27299&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27299&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27299&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27299&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27299&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27299&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27299&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27299&r=float
#27299 [Opn]: Preg_replace cannot handle ticks(')
ID: 27299
User updated by: john at supernerd dot com
Reported By: john at supernerd dot com
Status: Open
Bug Type: PCRE related
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
yeah, I tested on mac/linux. It only fails on windows.
Previous Comments:
[2004-02-17 21:27:30] [EMAIL PROTECTED]
works fine on mac/linux.
[2004-02-17 21:19:45] john at supernerd dot com
Description:
returns an error of
Parse error: parse error, unexpected T_CONSTANT_ENCAPSED_STRING in
C:\Documents and Settings\john\Desktop\ttms
desktop\php\gui\Smarty_Compiler.class.php(288) : regexp code on line 2
Reproduce code:
---
$ldq = preg_quote('{', '!');
$rdq = preg_quote('}', '!');
$search =
"!{$ldq}\*(.*?)\*{$rdq}|{$ldq}\s*literal\s*{$rdq}(.*?){$ldq}\s*/literal\s*{$rdq}|{$ldq}\s*php\s*{$rdq}(.*?){$ldq}\s*/php\s*{$rdq}!s";
$source_content = preg_replace($search.'e', "'"
. '{' . 'php'
. "' . str_repeat(\"\n\",
substr_count('\\0', \"\n\")) .'"
. '}'
. "'",
"a
{literal}b{/literal}c{php}d;s{/php}e{* hello's *}");
Expected result:
a{php}c{php}e{php}
Actual result:
--
Parse error: parse error, unexpected T_CONSTANT_ENCAPSED_STRING in
C:\Documents and Settings\john\Desktop\ttms desktop\php\index.php(17) :
regexp code on line 2
Fatal error: Failed evaluating code: '{php' . str_repeat(" ",
substr_count('{* hello''s *}', " ")) .'}' in C:\Documents and
Settings\john\Desktop\ttms desktop\php\index.php on line 17
--
Edit this bug report at http://bugs.php.net/?id=27299&edit=1
#27299 [Fbk->Opn]: Preg_replace cannot handle ticks(')
ID: 27299
User updated by: john at supernerd dot com
Reported By: john at supernerd dot com
-Status: Feedback
+Status: Open
Bug Type: PCRE related
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
I found that only with magic_quotes_sybase on did the error occur. I
was then able to work around it. I will try the cvs snapshot tomorrow
and let you know what happens.
Previous Comments:
[2004-02-17 23:16:49] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Works fine in win32 using latest CVS snapshot..
[2004-02-17 21:59:21] john at supernerd dot com
yeah, I tested on mac/linux. It only fails on windows.
[2004-02-17 21:27:30] [EMAIL PROTECTED]
works fine on mac/linux.
[2004-02-17 21:19:45] john at supernerd dot com
Description:
returns an error of
Parse error: parse error, unexpected T_CONSTANT_ENCAPSED_STRING in
C:\Documents and Settings\john\Desktop\ttms
desktop\php\gui\Smarty_Compiler.class.php(288) : regexp code on line 2
Reproduce code:
---
$ldq = preg_quote('{', '!');
$rdq = preg_quote('}', '!');
$search =
"!{$ldq}\*(.*?)\*{$rdq}|{$ldq}\s*literal\s*{$rdq}(.*?){$ldq}\s*/literal\s*{$rdq}|{$ldq}\s*php\s*{$rdq}(.*?){$ldq}\s*/php\s*{$rdq}!s";
$source_content = preg_replace($search.'e', "'"
. '{' . 'php'
. "' . str_repeat(\"\n\",
substr_count('\\0', \"\n\")) .'"
. '}'
. "'",
"a
{literal}b{/literal}c{php}d;s{/php}e{* hello's *}");
Expected result:
a{php}c{php}e{php}
Actual result:
--
Parse error: parse error, unexpected T_CONSTANT_ENCAPSED_STRING in
C:\Documents and Settings\john\Desktop\ttms desktop\php\index.php(17) :
regexp code on line 2
Fatal error: Failed evaluating code: '{php' . str_repeat(" ",
substr_count('{* hello''s *}', " ")) .'}' in C:\Documents and
Settings\john\Desktop\ttms desktop\php\index.php on line 17
--
Edit this bug report at http://bugs.php.net/?id=27299&edit=1
#25876 [Com]: session_start(): Failed to initialize storage module
ID: 25876
Comment by: john at fluidhosting dot com
Reported By: golden at riscom dot com
Status: Open
Bug Type: Session related
Operating System: freebsd 4.8
PHP Version: 4.3.3
New Comment:
Seeing this bug on FreeBSD 4.10 with PHP 4.3.10.
Previous Comments:
[2004-12-26 20:44:36] phpbugs at expires-200501 dot dpits dot com
I can confirm that this bug is still present on Apache 1.3.X with PHP
4.3.10. Today i had some Problems, after Apache restart it works well
(but how long?)... Thankyou.
[2004-12-26 17:59:52] johan at ekenberg dot se
This isn't just on Freebsd - we're seeing this on all our
Linux servers after upgrade -> 4.3.10 (big webhosting
provider in Sweden). A few users are setting
session.save_handler to 'user' with ini_set(); this sticks
and overrides the default ('files'), resulting in broken
sessions for all the other users on the servers.
Temporary solution by using auto_prepend_file in php.ini to
include something like:
seems to work (just tried it, keeping fingers crossed).
This is a critical bug since the security issues in 4.3.9
make a downgrade impossible.
[2004-12-26 11:43:25] peter at mapledesign dot co dot uk
I can confirm that this bug is still present on Apache 1.3.X with PHP
4.3.10.
I am trying to set the session.save_handler back to files manually, but
consider the need to do this (assuming it works) to be a bug - it should
default back to this, not stick in a process with the previous status.
I am encountering this problem now at two different hosting companies,
and never had this problem before they upgraded to 4.3.10
[2004-12-26 11:25:12] [EMAIL PROTECTED]
Confirmed on SF.net 4.3.10 Linux
Try several times until error.
http://farplugins.sourceforge.net/test/php.php
http://farplugins.sourceforge.net/test/in.php
/home/groups/f/fa/farplugins/htdocs/test/.htaccess
php_value session.save_path
"/home/groups/f/fa/farplugins/htdocs/test/tmp"
[2004-09-28 23:12:14] coadmin at hostings dot pl
We have the same problem.
FreeBSD 4.10-STABLE, PHP 4.3.8, Apache 1.3.31
how to repeat:
then refresh the website a many times.
you will receive an error:
Fatal error: session_start(): Failed to initialize storage module:
user (path: /tmp) in /home/xxx/public_html/index.php on line 2
the problem still exists also when using custom dir for saving session
files.
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/25876
--
Edit this bug report at http://bugs.php.net/?id=25876&edit=1
#31440 [NEW]: GLOBALS array overwritten from GET/POST/COOKIE vars
From: john at jelsoft dot com Operating system: All PHP version: 4.3.10 PHP Bug Type: Scripting Engine problem Bug description: GLOBALS array overwritten from GET/POST/COOKIE vars Description: With register_globals on it is possible to overwrite the $GLOBALS array from GET/POST/COOKIE vars. For example, try the script below: script.php (will print the full GLOBALS array) script.php?GLOBALS[php]=error (will print a GLOBALS array with just one entry) _GET, _POST, etc superglobals are no vulnerable. PHP5 does not exhibit this behaviour. Reproduce code: --- kill GLOBALS Expected result: Full display of GLOBALS array Actual result: -- GLOBALS array with just one entry -- Edit bug report at http://bugs.php.net/?id=31440&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31440&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31440&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31440&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31440&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31440&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31440&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31440&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31440&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31440&r=support Expected behavior: http://bugs.php.net/fix.php?id=31440&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31440&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31440&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31440&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31440&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31440&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31440&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31440&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31440&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31440&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31440&r=mysqlcfg
#31440 [Opn]: GLOBALS array overwritten from GET/POST/COOKIE vars
ID: 31440
User updated by: john at jelsoft dot com
Reported By: john at jelsoft dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: All
PHP Version: 4.3.10
New Comment:
Just to clarify why this is a very serious issue: any scripts using the
$GLOBALS array to clear all global variables set when registerglobals is
on (in order to simulate registerglobals being off) will run into major
problems. So:
foreach( $GLOBALS as $key => $val ) {
unset( $$key );
}
if ( $_GET['expression'] ) {
$output = "hello";
}
echo $output;
Will fail to unset all the global variables and so $output could have
bad values injected into it. It should be impossible to inject data
into $output, but this bug allows it to happen.
Previous Comments:
[2005-01-07 13:36:49] john at jelsoft dot com
Description:
With
register_globals on
it is possible to overwrite the $GLOBALS array from GET/POST/COOKIE
vars.
For example, try the script below:
script.php
(will print the full GLOBALS array)
script.php?GLOBALS[php]=error
(will print a GLOBALS array with just one entry)
_GET, _POST, etc superglobals are no vulnerable.
PHP5 does not exhibit this behaviour.
Reproduce code:
---
kill GLOBALS
Expected result:
Full display of GLOBALS array
Actual result:
--
GLOBALS array with just one entry
--
Edit this bug report at http://bugs.php.net/?id=31440&edit=1
#31440 [Fbk->Opn]: GLOBALS array overwritten from GET/POST/COOKIE vars
ID: 31440 User updated by: john at jelsoft dot com Reported By: john at jelsoft dot com -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: All PHP Version: 4.3.10 New Comment: I have tested it on Apache 2/Linux (RH9 I think) and on IIS/WinXP. phpinfo for WinXP is below: PHP Logo PHP Version 4.3.10 System Windows NT NEWPC 5.1 build 2600 Build Date Dec 14 2004 17:46:48 Server API CGI/FastCGI Virtual Directory Support enabled Configuration File (php.ini) Path C:\WINDOWS\php.ini PHP API 20020918 PHP Extension 20020429 Zend Extension 20021010 Debug Build no Thread Safety enabled Registered PHP Streams php, http, ftp, compress.zlib Zend logo This program makes use of the Zend Scripting Language Engine: Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies PHP Credits Configuration PHP Core Directive Local Value Master Value allow_call_time_pass_reference On On allow_url_fopen On On always_populate_raw_post_data Off Off arg_separator.input & & arg_separator.output& & asp_tagsOff Off auto_append_fileno valueno value auto_prepend_file no valueno value browscapno valueno value default_charset no valueno value default_mimetypetext/html text/html define_syslog_variables Off Off disable_classes no valueno value disable_functions no valueno value display_errors On On display_startup_errors Off Off doc_rootno valueno value docref_ext no valueno value docref_root no valueno value enable_dl On On error_append_string no valueno value error_log no valueno value error_prepend_stringno valueno value error_reporting 20472047 expose_php On On extension_dir ./ ./ file_uploadsOn On gpc_order GPC GPC highlight.bg#FF #FF highlight.comment #FF8000 #FF8000 highlight.default #BB #BB highlight.html #00 #00 highlight.keyword #007700 #007700 highlight.string#DD #DD html_errors On On ignore_repeated_errors Off Off ignore_repeated_source Off Off ignore_user_abort Off Off implicit_flush Off Off include_path.;c:\php4\pear .;c:\php4\pear log_errors Off Off log_errors_max_len 10241024 magic_quotes_gpcOn On magic_quotes_runtimeOff Off magic_quotes_sybase Off Off max_execution_time 30 30 max_input_time 60 60 open_basedirno valueno value output_bufferingno valueno value output_handler no valueno value post_max_size 8M 8M precision 12 12 register_argc_argv On On register_globalsOn On report_memleaks On On safe_mode Off Off safe_mode_exec_dir no valueno value safe_mode_gid Off Off safe_mode_include_dir no valueno value sendmail_from [EMAIL PROTECTED] [EMAIL PROTECTED] sendmail_path no valueno value serialize_precision 100 100 short_open_tag On On SMTPmail.jelsoft.commail.jelsoft.com smtp_port 25 25 sql.safe_mode Off Off track_errorsOff Off unserialize_callback_func no valueno value upload_max_filesize 2M 2M upload_tmp_dir C:\Program Files\PHP\uploadtemp C:\Program Files\PHP\uploadtemp user_dirno valueno value variables_order EGPCS EGPCS xmlrpc_error_number 0 0 xmlrpc_errors Off Off y2k_compliance On On bcmath BCMath support enabled calendar Calendar supportenabled com Directive Local Value Master Value com.allow_dcom Off Off com.autoregister_casesensitive On On com.autoregister_typelibOff Off com.autoregister_verboseOff Off com.typelib_fileno valueno value ctype ctype functions enabled ftp FTP support enabled mysql MySQL Support enabled Active Persistent Links 0 Active Links0 Client API version 3.23.49 Directive Local Value Master Value mysql.allow_persistent On On mysql.connect_timeout 60 60 mysql.default_host no valueno value mysql.default_password no valueno value mysql.default_port no valueno value mysql.default_socketno valueno value mysql.default_user no valueno value mysql.max_links Unlimited Unlimited mysql.max_persistentUnlimited Unlimited mysql.trace_modeOff Off odbc ODBC Supportenabled Active Persistent Links 0 Active Links0 ODBC libraryWin32 Directive Local Value Master Value odbc.allow_persistent On On odbc.check_persist
#31332 [Com]: unserialize() works terribly slow on huge strings compared to 4.3.9
ID: 31332 Comment by: john at jelsoft dot com Reported By: marekm at apnet dot pl Status: Verified Bug Type: Performance problem Operating System: * PHP Version: 4CVS, 5CVS (2005-01-04) New Comment: I would agree with what Gik just said. To quote from the PHP manual: "serialize -- Generates a storable representation of a value" Or later: "serialize() returns a string containing a byte-stream representation of value that can be stored anywhere. This is useful for storing or passing PHP values around without losing their type and structure." I tried some comparisons a while back on different ways to store PHP array data in a DB. I tried storing it in a form where I could run eval($data) and it turned out to be a lot slower than unserialize($data). (Perhaps this would be different given this bug). serialize() seems to be ideal for this situation where large array or object data is to be stored in a DB or shm. So I was surprised that the usages outlined above are 'abuses', as they seem to be using serialize() for exactly what it was intended for. Perhaps the manual needs clarifying if this isn't the case? Previous Comments: [2005-01-14 13:52:06] gik at zap dot cl As far as I know, objects stored in shared memory using shm_put_var() are stored serialized. I haven't looked at the sources yet, but the problem affecting unserialize() should also degrade the performance of shm_put_var() which is vastly used to store arrays or other objects in shared memory for _quick_ access. I don't know if there are other functions which use this method internally. I wouldn't call it an abuse to serialize and store an array with 1000 elements in shm, as this is a very efficient way to do data caching. The performance degradation is large enough to make a web server collapse, because of the extra time required to process each request. [2005-01-14 09:05:51] [EMAIL PROTECTED] Sorry to say... but abusing serialize for this is not a good idea in the first place. It's not meant for storing data in this way in the first place. But of course the slowdown shouldn't have been this much. [2005-01-13 21:11:06] gik at zap dot cl The excessively high load average of a server recently updated to php 4.3.10 was driving me nuts. This bug is critical for many php based systems as drupal, vBulletin and others. Gik. [2005-01-10 13:43:52] kier at vbulletin dot com I can confirm this problem from my experience with 4.3.10 and 5.0.3. Unserialize() under the latest versions appears to be massively slower than was previously so. We have had wide reports of vBulletin installations running significantly slower since we recommended that customers upgrade to 4.3.10 / 5.0.3. Hoping for a quick resolution to this problem, as it affects so many people so drastically. [2005-01-09 15:11:39] ralf dot praschak at gmx dot net i use vbulletin 3.0.5. the forumcache is also unserialized. i tracked this with the nusphere profiler. with php 4.3.9 (or 5.0.2) it takes around 300ms. with php 4.3.10 (or 5.0.3) it takes 17s and more !!! the cache is around 2.5 megs big ;( 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/31332 -- Edit this bug report at http://bugs.php.net/?id=31332&edit=1
#31440 [Fbk->Opn]: GLOBALS array overwritten from GET/POST/COOKIE vars
ID: 31440 User updated by: john at jelsoft dot com Reported By: john at jelsoft dot com -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: All PHP Version: 4.3.10 New Comment: I have just downloaded the latest snapshot and the bug remains. Build date from my phpinfo() is Jan 18 2005 14:14:51. Previous Comments: [2005-01-17 18:27:21] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2005-01-11 19:52:53] john at jelsoft dot com I have tested it on Apache 2/Linux (RH9 I think) and on IIS/WinXP. phpinfo for WinXP is below: PHP Logo PHP Version 4.3.10 System Windows NT NEWPC 5.1 build 2600 Build Date Dec 14 2004 17:46:48 Server API CGI/FastCGI Virtual Directory Support enabled Configuration File (php.ini) Path C:\WINDOWS\php.ini PHP API 20020918 PHP Extension 20020429 Zend Extension 20021010 Debug Build no Thread Safety enabled Registered PHP Streams php, http, ftp, compress.zlib Zend logo This program makes use of the Zend Scripting Language Engine: Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies PHP Credits Configuration PHP Core Directive Local Value Master Value allow_call_time_pass_reference On On allow_url_fopen On On always_populate_raw_post_data Off Off arg_separator.input & & arg_separator.output& & asp_tagsOff Off auto_append_fileno valueno value auto_prepend_file no valueno value browscapno valueno value default_charset no valueno value default_mimetypetext/html text/html define_syslog_variables Off Off disable_classes no valueno value disable_functions no valueno value display_errors On On display_startup_errors Off Off doc_rootno valueno value docref_ext no valueno value docref_root no valueno value enable_dl On On error_append_string no valueno value error_log no valueno value error_prepend_stringno valueno value error_reporting 20472047 expose_php On On extension_dir ./ ./ file_uploadsOn On gpc_order GPC GPC highlight.bg#FF #FF highlight.comment #FF8000 #FF8000 highlight.default #BB #BB highlight.html #00 #00 highlight.keyword #007700 #007700 highlight.string#DD #DD html_errors On On ignore_repeated_errors Off Off ignore_repeated_source Off Off ignore_user_abort Off Off implicit_flush Off Off include_path.;c:\php4\pear .;c:\php4\pear log_errors Off Off log_errors_max_len 10241024 magic_quotes_gpcOn On magic_quotes_runtimeOff Off magic_quotes_sybase Off Off max_execution_time 30 30 max_input_time 60 60 open_basedirno valueno value output_bufferingno valueno value output_handler no valueno value post_max_size 8M 8M precision 12 12 register_argc_argv On On register_globalsOn On report_memleaks On On safe_mode Off Off safe_mode_exec_dir no valueno value safe_mode_gid Off Off safe_mode_include_dir no valueno value sendmail_from [EMAIL PROTECTED] [EMAIL PROTECTED] sendmail_path no valueno value serialize_precision 100 100 short_open_tag On On SMTPmail.jelsoft.commail.jelsoft.com smtp_port 25 25 sql.safe_mode Off Off track_errorsOff Off unserialize_callback_func no valueno value upload_max_filesize 2M 2M upload_tmp_dir C:\Program Files\PHP\uploadtemp C:\Program Files\PHP\uploadtemp user_dirno valueno value variables_order EGPCS EGPCS xmlrpc_error_number 0 0 xmlrpc_errors Off Off y2k_compliance On On bcmath BCMath support enabled calendar Calendar supportenabled com Directive Local Value Master Value com.allow_dcom Off Off com.autoregister_casesensitive On On com.autoregister_typelibOff Off com.autoregister_verboseOff Off com.typelib_fileno valueno value ctype ctype functions enabled ftp FTP support enabled mysql MySQL Support enabled Active Persistent Links 0 Active Links0 Client API version 3.23.49 Directive Local Value Master Value mysql.allow_persistent On On mysql.connect_timeout 60 60 mysql.default_host no value
#31440 [Bgs->Opn]: GLOBALS array overwritten from GET/POST/COOKIE vars
ID: 31440 User updated by: john at jelsoft dot com Reported By: john at jelsoft dot com -Status: Bogus +Status: Open Bug Type: Scripting Engine problem Operating System: All PHP Version: 4.3.10 New Comment: I have just tried the CVS latest again (phpinfo build time is Jan 19 2005 06:13:47) and the issue remains. Please note that register_globals must be on. My phpinfo is below: PHP Logo PHP Version 4.3.11-dev System Windows NT NEWPC 5.1 build 2600 Build Date Jan 19 2005 06:13:47 Server API CGI/FastCGI Virtual Directory Support enabled Configuration File (php.ini) Path C:\WINDOWS\php.ini PHP API 20020918 PHP Extension 20020429 Zend Extension 20021010 Debug Build no Thread Safety enabled Registered PHP Streams php, http, ftp, compress.zlib Zend logo This program makes use of the Zend Scripting Language Engine: Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies PHP Credits Configuration PHP Core Directive Local Value Master Value allow_call_time_pass_reference On On allow_url_fopen On On always_populate_raw_post_data Off Off arg_separator.input & & arg_separator.output& & asp_tagsOff Off auto_append_fileno valueno value auto_prepend_file no valueno value browscapno valueno value default_charset no valueno value default_mimetypetext/html text/html define_syslog_variables Off Off disable_classes no valueno value disable_functions no valueno value display_errors On On display_startup_errors Off Off doc_rootno valueno value docref_ext no valueno value docref_root no valueno value enable_dl On On error_append_string no valueno value error_log no valueno value error_prepend_stringno valueno value error_reporting 20472047 expose_php On On extension_dir ./ ./ file_uploadsOn On gpc_order GPC GPC highlight.bg#FF #FF highlight.comment #FF8000 #FF8000 highlight.default #BB #BB highlight.html #00 #00 highlight.keyword #007700 #007700 highlight.string#DD #DD html_errors On On ignore_repeated_errors Off Off ignore_repeated_source Off Off ignore_user_abort Off Off implicit_flush Off Off include_path.;c:\php4\pear .;c:\php4\pear log_errors Off Off log_errors_max_len 10241024 magic_quotes_gpcOn On magic_quotes_runtimeOff Off magic_quotes_sybase Off Off max_execution_time 30 30 max_input_time 60 60 open_basedirno valueno value output_bufferingno valueno value output_handler no valueno value post_max_size 8M 8M precision 12 12 register_argc_argv On On register_globalsOn On report_memleaks On On safe_mode Off Off safe_mode_exec_dir no valueno value safe_mode_gid Off Off safe_mode_include_dir no valueno value sendmail_from [EMAIL PROTECTED] [EMAIL PROTECTED] sendmail_path no valueno value serialize_precision 100 100 short_open_tag On On SMTPmail.jelsoft.commail.jelsoft.com smtp_port 25 25 sql.safe_mode Off Off track_errorsOff Off unserialize_callback_func no valueno value upload_max_filesize 2M 2M upload_tmp_dir C:\Program Files\PHP\uploadtemp C:\Program Files\PHP\uploadtemp user_dirno valueno value variables_order EGPCS EGPCS xmlrpc_error_number 0 0 xmlrpc_errors Off Off y2k_compliance On On bcmath BCMath support enabled calendar Calendar supportenabled com Directive Local Value Master Value com.allow_dcom Off Off com.autoregister_casesensitive On On com.autoregister_typelibOff Off com.autoregister_verboseOff Off com.typelib_fileno valueno value ctype ctype functions enabled ftp FTP support enabled mysql MySQL Support enabled Active Persistent Links 0 Active Links0 Client API version 3.23.49 Directive Local Value Master Value mysql.allow_persistent On On mysql.connect_timeout 60 60 mysql.default_host no valueno value mysql.default_password no valueno value mysql.default_port no valueno value mysql.default_socketno valueno value mysql.default_user no valueno value mysql.max_links Unlimited Unlimited mysql.max_persistentUnlimited Unlimited mysql.trace_modeOff Off odbc ODBC Supportenabled Active Persistent Links 0 Active Links0 ODBC libraryWin32 Directive
#31440 [Opn]: GLOBALS array overwritten from GET/POST/COOKIE vars
ID: 31440 User updated by: john at jelsoft dot com Reported By: john at jelsoft dot com Status: Open Bug Type: Scripting Engine problem Operating System: All PHP Version: 4.3.10 New Comment: A number of comments appear to have disappeared from this bug report. I don't understand why! Please note that register_globals must be ON. This is not fixed in the latest php build (build date from phpinfo is Jan 19 2005 22:14:31) PHP Logo PHP Version 4.3.11-dev System Windows NT NEWPC 5.1 build 2600 Build Date Jan 19 2005 22:14:31 Server API CGI/FastCGI Virtual Directory Support enabled Configuration File (php.ini) Path C:\WINDOWS\php.ini PHP API 20020918 PHP Extension 20020429 Zend Extension 20021010 Debug Build no Thread Safety enabled Registered PHP Streams php, http, ftp, compress.zlib Zend logo This program makes use of the Zend Scripting Language Engine: Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies PHP Credits Configuration PHP Core Directive Local Value Master Value allow_call_time_pass_reference On On allow_url_fopen On On always_populate_raw_post_data Off Off arg_separator.input & & arg_separator.output& & asp_tagsOff Off auto_append_fileno valueno value auto_prepend_file no valueno value browscapno valueno value default_charset no valueno value default_mimetypetext/html text/html define_syslog_variables Off Off disable_classes no valueno value disable_functions no valueno value display_errors On On display_startup_errors Off Off doc_rootno valueno value docref_ext no valueno value docref_root no valueno value enable_dl On On error_append_string no valueno value error_log no valueno value error_prepend_stringno valueno value error_reporting 20472047 expose_php On On extension_dir ./ ./ file_uploadsOn On gpc_order GPC GPC highlight.bg#FF #FF highlight.comment #FF8000 #FF8000 highlight.default #BB #BB highlight.html #00 #00 highlight.keyword #007700 #007700 highlight.string#DD #DD html_errors On On ignore_repeated_errors Off Off ignore_repeated_source Off Off ignore_user_abort Off Off implicit_flush Off Off include_path.;c:\php4\pear .;c:\php4\pear log_errors Off Off log_errors_max_len 10241024 magic_quotes_gpcOn On magic_quotes_runtimeOff Off magic_quotes_sybase Off Off max_execution_time 30 30 max_input_time 60 60 open_basedirno valueno value output_bufferingno valueno value output_handler no valueno value post_max_size 8M 8M precision 12 12 register_argc_argv On On register_globalsOn On report_memleaks On On safe_mode Off Off safe_mode_exec_dir no valueno value safe_mode_gid Off Off safe_mode_include_dir no valueno value sendmail_from [EMAIL PROTECTED] [EMAIL PROTECTED] sendmail_path no valueno value serialize_precision 100 100 short_open_tag On On SMTPmail.jelsoft.commail.jelsoft.com smtp_port 25 25 sql.safe_mode Off Off track_errorsOff Off unserialize_callback_func no valueno value upload_max_filesize 2M 2M upload_tmp_dir C:\Program Files\PHP\uploadtemp C:\Program Files\PHP\uploadtemp user_dirno valueno value variables_order EGPCS EGPCS xmlrpc_error_number 0 0 xmlrpc_errors Off Off y2k_compliance On On bcmath BCMath support enabled calendar Calendar supportenabled com Directive Local Value Master Value com.allow_dcom Off Off com.autoregister_casesensitive On On com.autoregister_typelibOff Off com.autoregister_verboseOff Off com.typelib_fileno valueno value ctype ctype functions enabled ftp FTP support enabled mysql MySQL Support enabled Active Persistent Links 0 Active Links0 Client API version 3.23.49 Directive Local Value Master Value mysql.allow_persistent On On mysql.connect_timeout 60 60 mysql.default_host no valueno value mysql.default_password no valueno value mysql.default_port no valueno value mysql.default_socketno valueno value mysql.default_user no valueno value mysql.max_links Unlimited Unlimited mysql.max_persistentUnlimited Unlimited mysql.trace_modeOff Off odbc ODBC Supportenabled Active Persistent Links 0 Active Links0
#31440 [Opn]: GLOBALS array overwritten from GET/POST/COOKIE vars
ID: 31440
User updated by: john at jelsoft dot com
Reported By: john at jelsoft dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: All
PHP Version: 4.3.10
New Comment:
phpinfo was requested: From [EMAIL PROTECTED] [2005-01-11 02:56:35] (a
message which was deleted):
"What Web server? Tell us more about your configuration as well."
Please just say that you don't want phpinfo rather than randomly
deleting messages and confusing us all.
Now how about this bug...it's been nearly 2 weeks for a pretty serious
bug IMHO...
Previous Comments:
[2005-01-20 19:02:35] [EMAIL PROTECTED]
Please don't add the phpinfo() output if not asked for.
[2005-01-19 00:53:31] [EMAIL PROTECTED]
Works fine with latest CVS.
----
[2005-01-18 19:50:36] john at jelsoft dot com
I have just downloaded the latest snapshot and the bug remains. Build
date from my phpinfo() is Jan 18 2005 14:14:51.
----
[2005-01-07 23:07:45] john at jelsoft dot com
Just to clarify why this is a very serious issue: any scripts using the
$GLOBALS array to clear all global variables set when registerglobals is
on (in order to simulate registerglobals being off) will run into major
problems. So:
foreach( $GLOBALS as $key => $val ) {
unset( $$key );
}
if ( $_GET['expression'] ) {
$output = "hello";
}
echo $output;
Will fail to unset all the global variables and so $output could have
bad values injected into it. It should be impossible to inject data
into $output, but this bug allows it to happen.
[2005-01-07 13:36:49] john at jelsoft dot com
Description:
With
register_globals on
it is possible to overwrite the $GLOBALS array from GET/POST/COOKIE
vars.
For example, try the script below:
script.php
(will print the full GLOBALS array)
script.php?GLOBALS[php]=error
(will print a GLOBALS array with just one entry)
_GET, _POST, etc superglobals are no vulnerable.
PHP5 does not exhibit this behaviour.
Reproduce code:
---
kill GLOBALS
Expected result:
Full display of GLOBALS array
Actual result:
--
GLOBALS array with just one entry
--
Edit this bug report at http://bugs.php.net/?id=31440&edit=1
#31440 [Opn]: GLOBALS array overwritten from GET/POST/COOKIE vars
ID: 31440
User updated by: john at jelsoft dot com
Reported By: john at jelsoft dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: All
PHP Version: 4.3.10
New Comment:
To reply to Iliaa, since my earlier comment was removed: this isn't
fixed in 200501210530 build. To reproduce, you need to turn
register_globals on.
Previous Comments:
[2005-01-20 19:33:55] john at jelsoft dot com
phpinfo was requested: From [EMAIL PROTECTED] [2005-01-11 02:56:35] (a
message which was deleted):
"What Web server? Tell us more about your configuration as well."
Please just say that you don't want phpinfo rather than randomly
deleting messages and confusing us all.
Now how about this bug...it's been nearly 2 weeks for a pretty serious
bug IMHO...
[2005-01-20 19:02:35] [EMAIL PROTECTED]
Please don't add the phpinfo() output if not asked for.
[2005-01-19 00:53:31] [EMAIL PROTECTED]
Works fine with latest CVS.
----
[2005-01-18 19:50:36] john at jelsoft dot com
I have just downloaded the latest snapshot and the bug remains. Build
date from my phpinfo() is Jan 18 2005 14:14:51.
----
[2005-01-07 23:07:45] john at jelsoft dot com
Just to clarify why this is a very serious issue: any scripts using the
$GLOBALS array to clear all global variables set when registerglobals is
on (in order to simulate registerglobals being off) will run into major
problems. So:
foreach( $GLOBALS as $key => $val ) {
unset( $$key );
}
if ( $_GET['expression'] ) {
$output = "hello";
}
echo $output;
Will fail to unset all the global variables and so $output could have
bad values injected into it. It should be impossible to inject data
into $output, but this bug allows it to happen.
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/31440
--
Edit this bug report at http://bugs.php.net/?id=31440&edit=1
#31645 [NEW]: apache_lookup_uri prevents further headers from being sent
From: john at jelsoft dot com Operating system: Linux PHP version: 4CVS-2005-01-21 (stable) PHP Bug Type: Apache2 related Bug description: apache_lookup_uri prevents further headers from being sent Description: Any calls to the header() function after apache_lookup_uri() is called are not processed properly, so that the headers are not sent. Running 4.3.11-dev, build date Jan 16 2005 16:25:34 Save the following in test.php: Reproduce code: --- Expected result: The header X-John2: test2 to be sent. Actual result: -- It's not sent, while X-John: test is sent. -- Edit bug report at http://bugs.php.net/?id=31645&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31645&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31645&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31645&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31645&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31645&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31645&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31645&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31645&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31645&r=support Expected behavior: http://bugs.php.net/fix.php?id=31645&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31645&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31645&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31645&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31645&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31645&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31645&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31645&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31645&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31645&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31645&r=mysqlcfg
#31645 [Fbk->Opn]: apache_lookup_uri prevents further headers from being sent
ID: 31645 User updated by: john at jelsoft dot com Reported By: john at jelsoft dot com -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Linux PHP Version: 4CVS-2005-01-21 (stable) New Comment: >From my phpinfo, from the 'Loaded modules' section of apache2handler, it has sapi_apache2. Also listed in the modules section is worker. PHP's server API is reported as Apache 2.0 Handler. Is that the information you're after? Thanks! Previous Comments: [2005-01-22 01:12:16] [EMAIL PROTECTED] What Apache SAPI are you using? [2005-01-21 19:25:10] john at jelsoft dot com Description: Any calls to the header() function after apache_lookup_uri() is called are not processed properly, so that the headers are not sent. Running 4.3.11-dev, build date Jan 16 2005 16:25:34 Save the following in test.php: Reproduce code: --- Expected result: The header X-John2: test2 to be sent. Actual result: -- It's not sent, while X-John: test is sent. -- Edit this bug report at http://bugs.php.net/?id=31645&edit=1
#31440 [Fbk->Opn]: GLOBALS array overwritten from GET/POST/COOKIE vars
ID: 31440 User updated by: john at jelsoft dot com Reported By: john at jelsoft dot com -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: * PHP Version: 4CVS-2005-01-21 New Comment: Bug still remains in build dated Feb 1 2005 14:12:59. Previous Comments: [2005-02-01 19:06:15] [EMAIL PROTECTED] 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-21 11:57:10] john at jelsoft dot com To reply to Iliaa, since my earlier comment was removed: this isn't fixed in 200501210530 build. To reproduce, you need to turn register_globals on. [2005-01-20 19:33:55] john at jelsoft dot com phpinfo was requested: From [EMAIL PROTECTED] [2005-01-11 02:56:35] (a message which was deleted): "What Web server? Tell us more about your configuration as well." Please just say that you don't want phpinfo rather than randomly deleting messages and confusing us all. Now how about this bug...it's been nearly 2 weeks for a pretty serious bug IMHO... [2005-01-20 19:02:35] [EMAIL PROTECTED] Please don't add the phpinfo() output if not asked for. [2005-01-19 00:53:31] [EMAIL PROTECTED] Works fine with latest CVS. 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/31440 -- Edit this bug report at http://bugs.php.net/?id=31440&edit=1
#23467 [Fbk->Opn]: Showing incorrect Time Zone
ID: 23467
User updated by: John at JGSystems dot net
Reported By: John at JGSystems dot net
-Status: Feedback
+Status: Open
Bug Type: Date/time related
Operating System: Windows 2000 & XP
PHP Version: 4.3.2-RC1
New Comment:
Same thing as before. Shows:
This page was last modified:
Monday - May 19, 2003 at 4:22 PM BST.
BST instead of MDT
We are -0600
Previous Comments:
[2003-08-19 19:16:21] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-05-06 13:03:50] John at JGSystems dot net
Here ya go!
Tue, 6 May 2003 11:59:58 -0600
1
And my XP shows:
Current Time Zone: Mountain Daylight Time
[2003-05-06 12:28:02] michael dot mauch at gmx dot de
This example shows exactly how braindead these abbreviations are:
a) Nobody knows what they mean.
b) According to <http://www.worldtimezone.com/wtz-names/wtz-bst.html>,
"BST" means also "Brazil Standard Time" and "Bering Summer Time".
c) Everybody invents their own zone names - e.g.
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_crt__tzset.asp>
features a "GST" for "German standard time", which definitely doesn't
exist here in Germany.
John, can you please post the result of:
echo date("r"),"\n";
echo date("I"),"\n"; // uppercase "i"
And can you please make sure that your Windows machine knows in which
timezone it is?
[2003-05-06 06:09:39] [EMAIL PROTECTED]
Actually (just to be nit-pickily accurate), British *Summer* Time.
[2003-05-03 15:38:50] [EMAIL PROTECTED]
BullShit Time :-) Nope, it's Brittish Standard Time... and the weird
thing is that I encountered the same on my machine (with 4.3.2RC1).
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/23467
--
Edit this bug report at http://bugs.php.net/?id=23467&edit=1
#23467 [Fbk->Opn]: Showing incorrect Time Zone
ID: 23467
User updated by: John at JGSystems dot net
Reported By: John at JGSystems dot net
-Status: Feedback
+Status: Open
Bug Type: Date/time related
Operating System: Windows 2000 & XP
PHP Version: 4.3.2-RC1
New Comment:
It's a local machine. Win XP. Nothings changed from the items listed
below in this thread or I would have mentioned it.
I downloaded the link, installed it after erasing the last version you
all had me try and the same result. I did tell you that it was
supposed to be --> MDT <-- not --> BST <--
Thanks...
Previous Comments:
[2003-08-19 21:00:56] [EMAIL PROTECTED]
You need to always tell what the time SHOULD be.
Also, is this on local machine? Or some remote machine where you upload
the script?
[2003-08-19 20:03:54] John at JGSystems dot net
Same thing as before. Shows:
This page was last modified:
Monday - May 19, 2003 at 4:22 PM BST.
BST instead of MDT
We are -0600
[2003-08-19 19:16:21] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-05-06 13:03:50] John at JGSystems dot net
Here ya go!
Tue, 6 May 2003 11:59:58 -0600
1
And my XP shows:
Current Time Zone: Mountain Daylight Time
[2003-05-06 12:28:02] michael dot mauch at gmx dot de
This example shows exactly how braindead these abbreviations are:
a) Nobody knows what they mean.
b) According to <http://www.worldtimezone.com/wtz-names/wtz-bst.html>,
"BST" means also "Brazil Standard Time" and "Bering Summer Time".
c) Everybody invents their own zone names - e.g.
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_crt__tzset.asp>
features a "GST" for "German standard time", which definitely doesn't
exist here in Germany.
John, can you please post the result of:
echo date("r"),"\n";
echo date("I"),"\n"; // uppercase "i"
And can you please make sure that your Windows machine knows in which
timezone it 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/23467
--
Edit this bug report at http://bugs.php.net/?id=23467&edit=1
#23467 [Fbk->Opn]: Showing incorrect Time Zone
ID: 23467
User updated by: John at JGSystems dot net
Reported By: John at JGSystems dot net
-Status: Feedback
+Status: Open
Bug Type: Date/time related
Operating System: Windows 2000 & XP
PHP Version: 4.3.2-RC1
New Comment:
The time last modified was pasted in the reply.
This page was last modified:
Monday - May 19, 2003 at 4:22 PM BST.
I'll get the current time pasted in tomorrow...
The results of:
echo date("r"),"\n";
echo date("I"),"\n"; // uppercase "i"
Too late tonight...
Previous Comments:
[2003-08-19 22:48:30] [EMAIL PROTECTED]
I wanted to know the TIME...not the time zone..
----
[2003-08-19 21:12:06] John at JGSystems dot net
It's a local machine. Win XP. Nothings changed from the items listed
below in this thread or I would have mentioned it.
I downloaded the link, installed it after erasing the last version you
all had me try and the same result. I did tell you that it was
supposed to be --> MDT <-- not --> BST <--
Thanks...
[2003-08-19 21:00:56] [EMAIL PROTECTED]
You need to always tell what the time SHOULD be.
Also, is this on local machine? Or some remote machine where you upload
the script?
[2003-08-19 20:03:54] John at JGSystems dot net
Same thing as before. Shows:
This page was last modified:
Monday - May 19, 2003 at 4:22 PM BST.
BST instead of MDT
We are -0600
[2003-08-19 19:16:21] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
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/23467
--
Edit this bug report at http://bugs.php.net/?id=23467&edit=1
#23467 [Opn]: Showing incorrect Time Zone
ID: 23467
User updated by: John at JGSystems dot net
Reported By: John at JGSystems dot net
Status: Open
Bug Type: Date/time related
Operating System: Windows 2000 & XP
-PHP Version: 4.3.3RC5-dev
+PHP Version: 4.3.2-RC1
New Comment:
Here ya go:
Commands:
echo date("r"),"\n";
echo date("I"),"\n"; // uppercase "i"
echo date("T"),"\n";
Result:
Wed, 20 Aug 2003 19:33:34 -0600
1
BST
This what you wanted? (I hope)
Previous Comments:
----
[2003-08-19 23:12:26] John at JGSystems dot net
The time last modified was pasted in the reply.
This page was last modified:
Monday - May 19, 2003 at 4:22 PM BST.
I'll get the current time pasted in tomorrow...
The results of:
echo date("r"),"\n";
echo date("I"),"\n"; // uppercase "i"
Too late tonight...
[2003-08-19 22:48:30] [EMAIL PROTECTED]
I wanted to know the TIME...not the time zone..
[2003-08-19 21:12:06] John at JGSystems dot net
It's a local machine. Win XP. Nothings changed from the items listed
below in this thread or I would have mentioned it.
I downloaded the link, installed it after erasing the last version you
all had me try and the same result. I did tell you that it was
supposed to be --> MDT <-- not --> BST <--
Thanks...
[2003-08-19 21:00:56] [EMAIL PROTECTED]
You need to always tell what the time SHOULD be.
Also, is this on local machine? Or some remote machine where you upload
the script?
[2003-08-19 20:03:54] John at JGSystems dot net
Same thing as before. Shows:
This page was last modified:
Monday - May 19, 2003 at 4:22 PM BST.
BST instead of MDT
We are -0600
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/23467
--
Edit this bug report at http://bugs.php.net/?id=23467&edit=1
#23467 [Opn]: Showing incorrect Time Zone
ID: 23467
User updated by: John at JGSystems dot net
Reported By: John at JGSystems dot net
Status: Open
Bug Type: Date/time related
-Operating System: win32 only
+Operating System: Windows 2000 & XP
-PHP Version: 4.3.3RC5-dev, 5.0.0b2-dev
+PHP Version: 4.3.2-RC1
New Comment:
Yuppers!
I actually first noticed it using the page last mod date testing
BadBlue :-) But yes, date shows incorrect also. This has been around
a LONG time through several versions. I am not a C coder, but with the
100% reproduceable results, you'd think it'd be an easy fix. Shows you
what I know... =|;-)
Previous Comments:
[2003-08-26 16:16:12] radio_jed at hotmail dot com
Results of "r", "I", "T":
Tue, 26 Aug 2003 14:15:16 -0700
1
BST
(This is on Apache 2.0.43, Win XP, PHP 4.3.2)
[2003-08-26 16:13:27] radio_jed at hotmail dot com
I just submitted a bug with the exact same thing, but this is
reproducible on my XP machine.
I get "BST" as well, and I'm in America/Los_Angeles (should be "PST" or
"PDT"). Coincidentally, my problem was while using filemtime() (I note
that you used getlastmod()), but it also works when using date() naked.
----
[2003-08-20 20:35:39] John at JGSystems dot net
Here ya go:
Commands:
echo date("r"),"\n";
echo date("I"),"\n"; // uppercase "i"
echo date("T"),"\n";
Result:
Wed, 20 Aug 2003 19:33:34 -0600
1
BST
This what you wanted? (I hope)
[2003-08-19 23:12:26] John at JGSystems dot net
The time last modified was pasted in the reply.
This page was last modified:
Monday - May 19, 2003 at 4:22 PM BST.
I'll get the current time pasted in tomorrow...
The results of:
echo date("r"),"\n";
echo date("I"),"\n"; // uppercase "i"
Too late tonight...
[2003-08-19 22:48:30] [EMAIL PROTECTED]
I wanted to know the TIME...not the time zone..
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/23467
--
Edit this bug report at http://bugs.php.net/?id=23467&edit=1
#25565 [NEW]: upgrade to 4.3.3 breaks email attachments
From: john at sysop dot com Operating system: win32 PHP version: 4.3.3 PHP Bug Type: Mail related Bug description: upgrade to 4.3.3 breaks email attachments Description: Running a script which attaches a Word .rtf file to an email via MIME encoding. script works fine under 4.3.2, but causes the attachment to be corrupt under 4.3.3. Not sure why, do not fully understand the code we copied to do this. Yeah, it's ugly code that I've no time to clean up. Sorry. It does work without flaw on PHP 4.3.2 Win32, though. Only change to the server was removal of 4.3.2, insertion of 4.3.3 and a restart of IIS (5). No changes to the script were made nor to any other software on the system. Reproduce code: --- http://www.powerpointerspage.com/php_433_mime_bug.txt Expected result: code SHOULD produce an email addressed to a customer which contains a text message and a MIME attachment of an RTF file. The RTF should be immediately openable by the end user upon receipt of the email. Actual result: -- Outlook reports "The file appears to be corrupt" when doing test-sends to ourselves. So, something during the attachment process is not working the same way as it used to - base64 encoding, chunk_split(), something along those lines. Looking at the way in generates the mime boundary, I can tell that MD5 is working right, at least. I do get a different, "valid" md5 string on each test-send. The problem totally disappears upon reversion to PHP 4.3.2. Normal email attachment resumes at that point. -- Edit bug report at http://bugs.php.net/?id=25565&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25565&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25565&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25565&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25565&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25565&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25565&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25565&r=support Expected behavior: http://bugs.php.net/fix.php?id=25565&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25565&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25565&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25565&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25565&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25565&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25565&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25565&r=gnused
#25629 [NEW]: session cookie being set to deleted when deleting a session
From: john at tarot dot com
Operating system: Linux mike 2.4.19-16mdkenterpris
PHP version: 4.3.1
PHP Bug Type: Session related
Bug description: session cookie being set to deleted when deleting a session
Description:
We have a session-based app with a very large user base. Upon closing the
session a few users would end up having their session cookie set to
'deleted'. Upon subsequent visits to the site, users would find that they
were logged in as someone else because they were not the only user whose
session cookie specified "PHPSESSID=deleted". I have found a workaround
by testing whether the session cookie specifies "PHPSESSID=deleted". when
a session read occurs.
Reproduce code:
---
function sess_close() {
//close connection
global $SESS_DBH;
if( isset($SESS_DBH) )
$SESS_DBH->close();
return(true);
}
Expected result:
I expect the session cookie to be deleted.
Actual result:
--
session cookie is set to specify "PHPSESSID=deleted"
--
Edit bug report at http://bugs.php.net/?id=25629&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25629&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25629&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=25629&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=25629&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25629&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=25629&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25629&r=support
Expected behavior: http://bugs.php.net/fix.php?id=25629&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25629&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25629&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=25629&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25629&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=25629&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=25629&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25629&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=25629&r=float
#25994 [NEW]: Won't compile
From: john at petbrain dot com Operating system: Mac OS X 10.3 PHP version: 4.3.3 PHP Bug Type: Dynamic loading Bug description: Won't compile Description: I downloaded: Apache 1.3.28 php 4.3.3, 4.2.2, 5.x beta Apache: ./configure --prefix=/www --enable-module=so make;make install PHP: ./configure --with-apxs=/www/sbin/apxs --with-mysql make This is where the module dies. I did the SIMPLIEST install that one can do with a DSO module. I tried to compile INTO apache, and had the same problem. I did a ./configure --help | grep "dns" and there seems to be NO DNS aspect to turn off. not like I WOULD want to do it, but this is the best I can do. Help. I have looked on the internet placing the bottom code into the google.com search field, and notice that OTHER people are having the same problems. Temp solution that I've trying to find out if it works, is to compile the source on my OTHER laptop running 10.2.8 and copy the binary try over and run it on my 10.3 laptop. Otherwise I'm in a bit of a jam. There are NO possible solutions for this release. :( - john Reproduce code: --- gcc -Iext/standard/ -I/opt/apache/php-4.3.3/ext/standard/ -DPHP_ATOM_INC -I/opt/apache/php-4.3.3/include -I/opt/apache/php-4.3.3/main -I/opt/apache/php-4.3.3 -I/opt/apache/php-4.3.3/Zend -I/opt/apache/php-4.3.3/ext/xml/expat -no-cpp-precomp -no-cpp-precomp -I/opt/apache/php-4.3.3/TSRM -g -O2 -c /opt/apache/php-4.3.3/ext/standard/dns.c -o ext/standard/dns.o && echo > ext/standard/dns.lo /opt/apache/php-4.3.3/ext/standard/dns.c: In function `zif_checkdnsrr': /opt/apache/php-4.3.3/ext/standard/dns.c:228: error: `T_MX' undeclared (first use in this function) /opt/apache/php-4.3.3/ext/standard/dns.c:228: error: (Each undeclared identifier is reported only once /opt/apache/php-4.3.3/ext/standard/dns.c:228: error: for each function it appears in.) /opt/apache/php-4.3.3/ext/standard/dns.c:239: error: `T_A' undeclared (first use in this function) /opt/apache/php-4.3.3/ext/standard/dns.c:240: error: `T_NS' undeclared (first use in this function) /opt/apache/php-4.3.3/ext/standard/dns.c:242: error: `T_PTR' undeclared (first use in this function) /opt/apache/php-4.3.3/ext/standard/dns.c:243: error: `T_ANY' undeclared (first use in this function) /opt/apache/php-4.3.3/ext/standard/dns.c:244: error: `T_SOA' undeclared (first use in this function) /opt/apache/php-4.3.3/ext/standard/dns.c:245: error: `T_CNAME' undeclared (first use in this function) /opt/apache/php-4.3.3/ext/standard/dns.c:256: error: `C_IN' undeclared (first use in this function) /opt/apache/php-4.3.3/ext/standard/dns.c: In function `zif_getmxrr': /opt/apache/php-4.3.3/ext/standard/dns.c:288: error: `HEADER' undeclared (first use in this function) /opt/apache/php-4.3.3/ext/standard/dns.c:288: error: `hp' undeclared (first use in this function) /opt/apache/php-4.3.3/ext/standard/dns.c:317: error: `C_IN' undeclared (first use in this function) /opt/apache/php-4.3.3/ext/standard/dns.c:317: error: `T_MX' undeclared (first use in this function) /opt/apache/php-4.3.3/ext/standard/dns.c:324: error: parse error before ')' token make: *** [ext/standard/dns.lo] Error 1 Expected result: Compile. Actual result: -- Didn't compile -- Edit bug report at http://bugs.php.net/?id=25994&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25994&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25994&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25994&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25994&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25994&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25994&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25994&r=support Expected behavior: http://bugs.php.net/fix.php?id=25994&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25994&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25994&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25994&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25994&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25994&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25994&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25994&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25994&r=float
#30124 [NEW]: Provide way to configure php apache module name
From: john at wws5 dot com Operating system: Red Hat Linux 3 ES PHP version: 4.3.8 PHP Bug Type: Feature/Change Request Bug description: Provide way to configure php apache module name Description: My purpose for filing this bug report is to help provide a way of using two php apache modules with the same apache server. I have searched high and low but have not found any documentation on how to do this except using sym links in conjunction with the cgi-bin version of php. Using --enable-versioning you can concurrently run php version 3 and version 4 at the same time, however using two modules of version 4 is not supported unless you manually edit the source files. Perhaps there is a reason for this so I apologize if I am making a blunder. My suggested solution is to provide a way of specifying the module name with the configure command when building php. An alternative way would be to enhance the --enable-versioning configuration switch to name the module phpx_y_z_module where x, y and z are the version numbers. For example, php4_3_8_module. Thank you for all your hard work!! -- Edit bug report at http://bugs.php.net/?id=30124&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30124&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30124&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30124&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30124&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30124&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30124&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30124&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30124&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30124&r=support Expected behavior: http://bugs.php.net/fix.php?id=30124&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30124&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30124&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30124&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30124&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30124&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30124&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30124&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30124&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30124&r=mysqlcfg
#30124 [Opn]: Provide way to configure php apache module name
ID: 30124 User updated by: john at wws5 dot com Reported By: john at wws5 dot com Status: Open Bug Type: Feature/Change Request Operating System: Red Hat Linux 3 ES PHP Version: 4.3.8 New Comment: After doing some more digging I realized that for this to work you would also need to provide a way of changing the php MIME type when doing the build. Sorry, not that familiar with how apache modules work, although I think that has changed after this experience!! Previous Comments: [2004-09-16 23:36:07] john at wws5 dot com Description: My purpose for filing this bug report is to help provide a way of using two php apache modules with the same apache server. I have searched high and low but have not found any documentation on how to do this except using sym links in conjunction with the cgi-bin version of php. Using --enable-versioning you can concurrently run php version 3 and version 4 at the same time, however using two modules of version 4 is not supported unless you manually edit the source files. Perhaps there is a reason for this so I apologize if I am making a blunder. My suggested solution is to provide a way of specifying the module name with the configure command when building php. An alternative way would be to enhance the --enable-versioning configuration switch to name the module phpx_y_z_module where x, y and z are the version numbers. For example, php4_3_8_module. Thank you for all your hard work!! -- Edit this bug report at http://bugs.php.net/?id=30124&edit=1
#28610 [Com]: ISAPI MSSQL horribly slow
ID: 28610
Comment by: john at appliedgroup dot com
Reported By: michael dot lidgren at cypoint dot se
Status: Open
Bug Type: Performance problem
Operating System: Windows Server 2003
PHP Version: 4.3.6
New Comment:
I am having the same issue with W2K3/IIS and mysql.
Same problem with php 4.3.7 and 4.3.9
Even weirder is that only some systems on the network were
affected
Changing to CGI speeded everything up.
Previous Comments:
[2004-06-08 23:35:27] andy at advancethermal dot com
Experiencing the same problem with WindowsXP / Apache 2.0 / PHP 4.3.7 /
MS SQL Server 2k (Evaluation Version).
Queries take about 3-4x longer through mssql_query than odbc_exec.
[2004-06-02 16:38:39] michael dot lidgren at cypoint dot se
Description:
SQL queries take several seconds under the ISAPI module; with the same
queries taking virtually no time at all using the CGI module. Same
.ini, same everything except ISAPI vs CGI.
W2k3/IIS, PHP 4.3.6
Reproduce code:
---
mssql_connect(...);
mssql_query("SELECT * FROM any_table");
--
Edit this bug report at http://bugs.php.net/?id=28610&edit=1
#30616 [NEW]: Cant return as reference from offsetget() for mysqli_stmt->bind_param()
From: john at milsson dot nu
Operating system: Windows
PHP version: 5.0.2
PHP Bug Type: MySQLi related
Bug description: Cant return as reference from offsetget() for
mysqli_stmt->bind_param()
Description:
Fatal error: Objects used as arrays in post/pre increment/decrement must
return values by reference
when I try to use
$mysqli_stmt->bind_param('s',$arrayAccessObj['offset']);
even though offsetget is declared as
function &offsetGet($key) {
return $this->{'_'.strtolower($key)};
}
--
Edit bug report at http://bugs.php.net/?id=30616&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30616&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30616&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30616&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30616&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30616&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30616&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30616&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30616&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30616&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30616&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30616&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30616&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30616&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30616&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30616&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30616&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30616&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30616&r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30616&r=mysqlcfg
#30616 [Fbk->Csd]: Cant return as reference from offsetget() for mysqli_stmt->bind_param()
ID: 30616
User updated by: john at milsson dot nu
Reported By: john at milsson dot nu
-Status: Feedback
+Status: Closed
Bug Type: MySQLi related
Operating System: Windows
PHP Version: 5.0.2
New Comment:
Tried to trigger this at home. But it works as expected.
But:
1. This is a linux machine.
2. Home compiled
3. I'm not stressed out...
4. The code is much cleaner.
My guess is that I screwd up with one of the '&' in some deep nested
retuen tree
As I said, this code works:
class ArrayObj implements ArrayAccess {
private $_val;
public $valAsProp;
function __construct($val){
$this->_val = $val;
$this->valAsProp =& $this->_val;
}
//
// ArrayAccess interface
//
function offsetExists($key) { return isset($this->{'_'.$key});
}
function &offsetGet($key) { return
$this->{'get'.ucfirst($key)}();}
function offsetSet($key,$val) { $this->{'_'.$key} =
$val; }
function offsetUnset($key){ $this->{'_'.$key} =
null; }
function &__get($key) { return $this->{'_'.$key};
}
function &getVal() {
return $this->_val;
}
}
$arrayobj = new ArrayObj(new ArrayObj('an other val'));
$db = new mysqli('localhost');
$stmt = $db->prepare("SELECT ? as `val`");
//$stmt->bind_param('s', $arrayobj->valAsProp);
//$stmt->bind_param('s', $arrayobj->val);
$stmt->bind_param('s', $arrayobj['val']['val']);
$stmt->execute();
$stmt->bind_result($res);
$stmt->fetch();
$stmt->close();
echo "\n$res\n";
?>
Previous Comments:
[2004-10-30 00:56:11] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
[2004-10-29 21:26:35] john at milsson dot nu
Description:
Fatal error: Objects used as arrays in post/pre increment/decrement
must return values by reference
when I try to use
$mysqli_stmt->bind_param('s',$arrayAccessObj['offset']);
even though offsetget is declared as
function &offsetGet($key) {
return $this->{'_'.strtolower($key)};
}
--
Edit this bug report at http://bugs.php.net/?id=30616&edit=1
#29554 [Fbk->Opn]: compile failure when using --with-pspell=/usr/local
ID: 29554 User updated by: John at Albin dot Net Reported By: John at Albin dot Net -Status: Feedback +Status: Open Bug Type: Pspell related Operating System: * PHP Version: 4CVS, 5CVS (2005-02-03) New Comment: As per sniper's request, I tried the latest CVS snapshot, php4-STABLE-200502152130, but received the same error during compile: ld: ext/pspell/pspell.o illegal reference to symbol: _aspell_word_list_elements defined in indirectly referenced dynamic library /usr/local/lib/ libaspell.15.dylib The fix mentioned in my first posting still works. Previous Comments: [2005-02-11 05:43:19] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2005-01-19 21:50:17] dhaveconfig at elitemail dot org same issue with OS X Server 10.3.7 and php 4.3.10. same fix resolved it. [2004-10-01 11:59:09] BjarneDM This is also an issue with PHP 5.0.x and PHP 4.3.9 Mac OS X 10.3.5 I'm upgrading the ServerLogistics PHP4 package that includes aspell: [Titanen:~] bjarne% aspell -v @(#) International Ispell Version 3.1.20 (but really Aspell 0.50.4.1) [Titanen:~] bjarne% which aspell /Library/PHP4/bin/aspell Installing the aspell packages from either fink or darwinports doesn't resolve this issue. Running these commands in the build directory before ./configure solves the problem for both PHP4 and PHP5: sed 's/\(LIBS="\)\(-lpspell \$LIBS"\)/\1-laspell \2/' configure > configure.1 mv configure.1 configure chmod a+x configure I've set up a site at http://webadmin.mathiesen.info/ where I make build scripts, comments, etc available for the ServerLogistics Complete* packages ---- [2004-08-06 20:45:00] John at Albin dot Net Description: Environment: * Mac OS X 10.3.4 * aspell 0.50.5 and aspell-en 0.51-1 (installed into /usr/local from source files) * PHP 4.3.8 I've verified that aspell works from the command line, but PHP won't compile. I'm configuring with '--with-pspell=/usr/local' and when I run make, it errors out saying: "ld: ext/pspell/ pspell.o illegal reference to symbol: _aspell_error_number defined in indirectly referenced dynamic library /usr/local/lib/libaspell.15.dylib" I have never installed pspell. And I have installed aspell for the first time today on this machine. When I run 'sudo /usr/libexec/locate.updatedb' and then 'locate libpspell' I find (ignoring my build directory in /usr/ local/src): /usr/local/lib/libpspell.15.0.3.dylib /usr/local/lib/libpspell.15.dylib /usr/local/lib/libpspell.dylib /usr/local/lib/libpspell.la 'locate libaspell' returns: /usr/local/lib/libaspell.15.0.3.dylib /usr/local/lib/libaspell.15.dylib /usr/local/lib/libaspell.dylib /usr/local/lib/libaspell.la The compile error is easily fixed with a small change to 'configure'. PHP compiles fine, when I edit php-4.3.8/ configure and change line 71624 from: LIBS="-lpspell $LIBS" to: LIBS="-laspell -lpspell $LIBS" I have also talked to other Mac OS X/PHP/aspell users who have the same issue and the configure modification fixes their issue as well. This bug is very similar to bug #23089. From looking at that bug, it seems that this bug might be reproducable on any machine that has no legacy aspell/pspell libraries and only the most recent aspell library. Undoubtably, this was caused my the author of aspell changing the name of the library multiple times. But can this relatively minor fix please be added to PHP's configure script? Or would this impact Pspell users (those without the newer aspell)? If so, is there a way to check for this in the configure file? Unfortunately, I'm not an expert in configure files or I would attempt a patch myself. -- Edit this bug report at http://bugs.php.net/?id=29554&edit=1
#32287 [Fbk->Opn]: Segmentation fault in simple PHP script
ID: 32287
User updated by: john at swartzentruber dot us
Reported By: john at swartzentruber dot us
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Fedora Core3
PHP Version: 5CVS-2005-03-12 (dev)
New Comment:
I'm not sure what is being asked for that wasn't provided. The problem
seems to be specific to mysqli, so needs to use the database. The
database in this case is the standard example world database used in
the PHP mysqli examples. As the comment indicates, the include is only
to set $rootpass. If you want to just code your root password directly
instead of including that file, that will work.
Previous Comments:
[2005-03-12 23:53:10] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-03-12 22:51:21] john at swartzentruber dot us
Description:
When I run the example script using my browser, there is a segmentation
fault on the call to $result->fetch_array(MYSQLI_ASSOC) on line 16. When
I run it from the command line, the script appears to work. The
segmentation fault only occurs when fetching the associative array.
Using MYSQLI_NUM works, but MYSQLI_BOTH also crashes.
Reproduce code:
---
host_info);
/* check connection */
if (mysqli_connect_errno()) {
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
}
$query = "SELECT Name, CountryCode FROM City ORDER by ID LIMIT 3";
$result = $mysqli->query($query);
/* numeric array */
$row = $result->fetch_array(MYSQLI_NUM);
printf ("%s (%s)\n", $row[0], $row[1]);
/* associative array */
$row = $result->fetch_array(MYSQLI_ASSOC);
printf ("%s (%s)\n", $row["Name"], $row["CountryCode"]);
$result->close();
$mysqli->close();
?>
Expected result:
Kabul (AFG)
Qandahar (AFG)
Actual result:
--
#0 0x0018d96b in strlen () from /lib/tls/libc.so.6
#1 0x0231cc70 in php_mysqli_fetch_into_hash (ht=1,
return_value=0x9ed2454, this_ptr=0x9ed16fc, return_value_used=1,
override_flags=0, into_object=0) at
/usr/local/src/php5-STABLE-200503121930/ext/mysqli/mysqli.c:663
#2 0x02326b79 in zif_mysqli_fetch_array (ht=1, return_value=0x9ed2454,
this_ptr=0x9ed16fc, return_value_used=1)
at
/usr/local/src/php5-STABLE-200503121930/ext/mysqli/mysqli_nonapi.c:193
#3 0x024c3f31 in zend_do_fcall_common_helper (execute_data=0xbfee64d0,
opline=0x9ed61b8, op_array=0x9e78dd4)
at
/usr/local/src/php5-STABLE-200503121930/Zend/zend_execute.c:2727
#4 0x024c4645 in zend_do_fcall_by_name_handler
(execute_data=0xbfee64d0, opline=0x9ed61b8, op_array=0x9e78dd4)
at
/usr/local/src/php5-STABLE-200503121930/Zend/zend_execute.c:2841
#5 0x024bf0ee in execute (op_array=0x9e78dd4) at
/usr/local/src/php5-STABLE-200503121930/Zend/zend_execute.c:1406
#6 0x0249b364 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/local/src/php5-STABLE-200503121930/Zend/zend.c:1068
#7 0x0245c516 in php_execute_script (primary_file=0xbfee8830) at
/usr/local/src/php5-STABLE-200503121930/main/main.c:1630
#8 0x024c9b29 in php_handler (r=0x9ebf8d8)
at
/usr/local/src/php5-STABLE-200503121930/sapi/apache2handler/sapi_apache2.c:555
#9 0x007bf9f7 in ap_run_handler () from /usr/sbin/httpd
#10 0x09b83888 in ?? ()
#11 0x007bf9ce in ap_run_handler () from /usr/sbin/httpd
#12 0x09ebf8d8 in ?? ()
#13 0x09ebf8d8 in ?? ()
#14 0xbfee89a8 in ?? ()
#15 0x007bfe63 in ap_invoke_handler () from /usr/sbin/httpd
Previous frame inner to this frame (corrupt stack?)
--
Edit this bug report at http://bugs.php.net/?id=32287&edit=1
#32287 [Opn]: Segmentation fault in simple PHP script
ID: 32287
User updated by: john at swartzentruber dot us
Reported By: john at swartzentruber dot us
Status: Open
Bug Type: Reproducible crash
Operating System: Fedora Core3
PHP Version: 5CVS-2005-03-12 (dev)
New Comment:
I'm an experienced C++ programmer, but unfortunately not a GNU debugger
user. So I went way back to my really early days and put a few printf
calls at the problem area. Here is my output:
field_len = 0x88bf358, *field_len = 5, fields=0x4f9c285,
mysql_num_fields(result) = 2
field_len = 0x88bf358, *field_len = 8, fields=0x88c3a30,
mysql_num_fields(result) = 2
fields[0].name = 0x88c3a78
fields[0].name = Name
fields[0].org_name = 0x88c3a70
fields[0].org_name = City
fields[0].table = (nil)
fields[0].org_table = 0xfe
Segmentation fault
This segmentation fault is in one of my printfs. The interesting thing
is that org_name has a value that *should* be the value for table. And
org_table is bogus, causing this segfault.
It looks like something is not using the most recent mysql.h file and
there is a structure mismatch.
I went back and looked at my phpinfo(). It says that the mysqli client
API version is 3.23.58. I'm running version 4.1.10a of MySQL, so that
doesn't look right. That might be the cause of the problem. My big
question now is why is it using that version (if that is the case)?
Where does that come from?
I hope something here helps.
Previous Comments:
[2005-03-13 01:47:03] john at swartzentruber dot us
I'm not sure what is being asked for that wasn't provided. The problem
seems to be specific to mysqli, so needs to use the database. The
database in this case is the standard example world database used in
the PHP mysqli examples. As the comment indicates, the include is only
to set $rootpass. If you want to just code your root password directly
instead of including that file, that will work.
[2005-03-12 23:53:10] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
----
[2005-03-12 22:51:21] john at swartzentruber dot us
Description:
When I run the example script using my browser, there is a segmentation
fault on the call to $result->fetch_array(MYSQLI_ASSOC) on line 16. When
I run it from the command line, the script appears to work. The
segmentation fault only occurs when fetching the associative array.
Using MYSQLI_NUM works, but MYSQLI_BOTH also crashes.
Reproduce code:
---
host_info);
/* check connection */
if (mysqli_connect_errno()) {
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
}
$query = "SELECT Name, CountryCode FROM City ORDER by ID LIMIT 3";
$result = $mysqli->query($query);
/* numeric array */
$row = $result->fetch_array(MYSQLI_NUM);
printf ("%s (%s)\n", $row[0], $row[1]);
/* associative array */
$row = $result->fetch_array(MYSQLI_ASSOC);
printf ("%s (%s)\n", $row["Name"], $row["CountryCode"]);
$result->close();
$mysqli->close();
?>
Expected result:
Kabul (AFG)
Qandahar (AFG)
Actual result:
--
#0 0x0018d96b in strlen () from /lib/tls/libc.so.6
#1 0x0231cc70 in php_mysqli_fetch_into_hash (ht=1,
return_value=0x9ed2454, this_ptr=0x9ed16fc, return_value_used=1,
override_flags=0, into_object=0) at
/usr/local/src/php5-STABLE-200503121930/ext/mysqli/mysqli.c:663
#2 0x02326b79 in zif_mysqli_fetch_array (ht=1, return_value=0x9ed2454,
this_ptr=0x9ed16fc, return_value_used=1)
at
/usr/local/src/php5-STABLE-200503121930/ext/mysqli/mysqli_nonapi.c:193
#3 0x024c3f31 in zend_do_fcall_common_helper (execute_data=0xbfee64d0,
opline=0x9ed61b8, op_array=0x9e78dd4)
at
/usr/local/src/php5-STABLE-200503121930/Zend/zend_execute.c:2727
#4 0x024c4645 in zend_do_fcall_by_name_handler
(execute_data=0xbfee64d0, opline=0x9ed61b8, op_array=0x9e78dd4)
at
/usr/local/src/php5-STABLE-200503121930/Zend/zend_execute.c:2841
#5 0x024bf0ee in execute (op_array=0x9e78dd4) at
/usr/local/src/php5-STABLE-200503121930/Zend/zend_execute.c:1406
#6 0x0249b364 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/local/src/php5-STABLE-200503121930/Zend/zend.c:1068
#7 0x0245c516 in php_execute_script (primary_file=0xbfee8830) at
/usr/local/src/php5-STABLE-200503121930/main/main.c:1630
#8 0x024c9b29 in php_handler (r=0x9eb
#32287 [Opn]: Segmentation fault in simple PHP script
ID: 32287
User updated by: john at swartzentruber dot us
Reported By: john at swartzentruber dot us
Status: Open
Bug Type: Reproducible crash
Operating System: Fedora Core3
PHP Version: 5CVS-2005-03-12 (dev)
New Comment:
I believe I found the problem. From my default installation I had
mod_auth_mysql.so loading, and it was using an old version of MySQL. By
removing that RPM and no longer loading mod_auth_mysql, the problem went
away. Sorry about the false alarm.
Previous Comments:
[2005-03-13 02:58:38] john at swartzentruber dot us
I'm an experienced C++ programmer, but unfortunately not a GNU debugger
user. So I went way back to my really early days and put a few printf
calls at the problem area. Here is my output:
field_len = 0x88bf358, *field_len = 5, fields=0x4f9c285,
mysql_num_fields(result) = 2
field_len = 0x88bf358, *field_len = 8, fields=0x88c3a30,
mysql_num_fields(result) = 2
fields[0].name = 0x88c3a78
fields[0].name = Name
fields[0].org_name = 0x88c3a70
fields[0].org_name = City
fields[0].table = (nil)
fields[0].org_table = 0xfe
Segmentation fault
This segmentation fault is in one of my printfs. The interesting thing
is that org_name has a value that *should* be the value for table. And
org_table is bogus, causing this segfault.
It looks like something is not using the most recent mysql.h file and
there is a structure mismatch.
I went back and looked at my phpinfo(). It says that the mysqli client
API version is 3.23.58. I'm running version 4.1.10a of MySQL, so that
doesn't look right. That might be the cause of the problem. My big
question now is why is it using that version (if that is the case)?
Where does that come from?
I hope something here helps.
[2005-03-13 01:47:03] john at swartzentruber dot us
I'm not sure what is being asked for that wasn't provided. The problem
seems to be specific to mysqli, so needs to use the database. The
database in this case is the standard example world database used in
the PHP mysqli examples. As the comment indicates, the include is only
to set $rootpass. If you want to just code your root password directly
instead of including that file, that will work.
[2005-03-12 23:53:10] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
----
[2005-03-12 22:51:21] john at swartzentruber dot us
Description:
When I run the example script using my browser, there is a segmentation
fault on the call to $result->fetch_array(MYSQLI_ASSOC) on line 16. When
I run it from the command line, the script appears to work. The
segmentation fault only occurs when fetching the associative array.
Using MYSQLI_NUM works, but MYSQLI_BOTH also crashes.
Reproduce code:
---
host_info);
/* check connection */
if (mysqli_connect_errno()) {
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
}
$query = "SELECT Name, CountryCode FROM City ORDER by ID LIMIT 3";
$result = $mysqli->query($query);
/* numeric array */
$row = $result->fetch_array(MYSQLI_NUM);
printf ("%s (%s)\n", $row[0], $row[1]);
/* associative array */
$row = $result->fetch_array(MYSQLI_ASSOC);
printf ("%s (%s)\n", $row["Name"], $row["CountryCode"]);
$result->close();
$mysqli->close();
?>
Expected result:
Kabul (AFG)
Qandahar (AFG)
Actual result:
--
#0 0x0018d96b in strlen () from /lib/tls/libc.so.6
#1 0x0231cc70 in php_mysqli_fetch_into_hash (ht=1,
return_value=0x9ed2454, this_ptr=0x9ed16fc, return_value_used=1,
override_flags=0, into_object=0) at
/usr/local/src/php5-STABLE-200503121930/ext/mysqli/mysqli.c:663
#2 0x02326b79 in zif_mysqli_fetch_array (ht=1, return_value=0x9ed2454,
this_ptr=0x9ed16fc, return_value_used=1)
at
/usr/local/src/php5-STABLE-200503121930/ext/mysqli/mysqli_nonapi.c:193
#3 0x024c3f31 in zend_do_fcall_common_helper (execute_data=0xbfee64d0,
opline=0x9ed61b8, op_array=0x9e78dd4)
at
/usr/local/src/php5-STABLE-200503121930/Zend/zend_execute.c:2727
#4 0x024c4645 in zend_do_fcall_by_name_handler
(execute_data=0xbfee64d0, opline=0x9ed61b8, op_array=0x9e78dd4)
at
/usr/local/src/php5-STABLE-200503121930/Zend/zend_execute.c:2841
#5 0x024bf0ee in execute
#32575 [NEW]: Accented character 'echo'ed randomly
From: john at jcoppens dot com Operating system: linux 2.4.26 PHP version: 4.3.10 PHP Bug Type: *Languages/Translation Bug description: Accented character 'echo'ed randomly Description: I have a very simple web-page script with mainly 'echo' commands. Randomly the accented characters are replaced by question-marks. If or not the question mark appears seems to be depending on the page contents, though at least in one of the cases, the only thing that changes in the page is a GIF image. All this happens in the same html-session, using the same script. I've seen other -similar- reports, though none about 'echo'. I can't be sure if this is an apache problem or php-related. Sorry if was already solved... Please indicate. Reproduce code: --- echo "Página Índice"; Expected result: Página Índice Actual result: -- Randomly Página Índice P?gina ?ndice -- Edit bug report at http://bugs.php.net/?id=32575&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32575&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32575&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32575&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32575&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32575&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32575&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32575&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32575&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32575&r=support Expected behavior: http://bugs.php.net/fix.php?id=32575&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32575&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32575&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32575&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32575&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32575&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32575&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32575&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32575&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32575&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32575&r=mysqlcfg
#32575 [Bgs]: Accented character 'echo'ed randomly
ID: 32575 User updated by: john at jcoppens dot com Reported By: john at jcoppens dot com Status: Bogus Bug Type: *Languages/Translation Operating System: linux 2.4.26 PHP Version: 4.3.10 New Comment: Thanks for the reply. Just so other people finding this description are pointed in the correct direction, this problem appears to be a bug in Mozilla. PHP serves the accented characters correctly, the browser randomly changes them into question marks. Firefox/Opera/Dillo don't have this problem (apparently). I found this out by tracing the HTTP transfer. Previous Comments: [2005-04-05 01:06:52] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. [2005-04-04 21:38:44] john at jcoppens dot com Description: I have a very simple web-page script with mainly 'echo' commands. Randomly the accented characters are replaced by question-marks. If or not the question mark appears seems to be depending on the page contents, though at least in one of the cases, the only thing that changes in the page is a GIF image. All this happens in the same html-session, using the same script. I've seen other -similar- reports, though none about 'echo'. I can't be sure if this is an apache problem or php-related. Sorry if was already solved... Please indicate. Reproduce code: --- echo "Página Índice"; Expected result: Página Índice Actual result: -- Randomly Página Índice P?gina ?ndice -- Edit this bug report at http://bugs.php.net/?id=32575&edit=1
#32287 [NEW]: Segmentation fault in simple PHP script
From: john at swartzentruber dot us
Operating system: Fedora Core3
PHP version: 5CVS-2005-03-12 (dev)
PHP Bug Type: Reproducible crash
Bug description: Segmentation fault in simple PHP script
Description:
When I run the example script using my browser, there is a segmentation
fault on the call to $result->fetch_array(MYSQLI_ASSOC) on line 16. When I
run it from the command line, the script appears to work. The segmentation
fault only occurs when fetching the associative array. Using MYSQLI_NUM
works, but MYSQLI_BOTH also crashes.
Reproduce code:
---
host_info);
/* check connection */
if (mysqli_connect_errno()) {
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
}
$query = "SELECT Name, CountryCode FROM City ORDER by ID LIMIT 3";
$result = $mysqli->query($query);
/* numeric array */
$row = $result->fetch_array(MYSQLI_NUM);
printf ("%s (%s)\n", $row[0], $row[1]);
/* associative array */
$row = $result->fetch_array(MYSQLI_ASSOC);
printf ("%s (%s)\n", $row["Name"], $row["CountryCode"]);
$result->close();
$mysqli->close();
?>
Expected result:
Kabul (AFG)
Qandahar (AFG)
Actual result:
--
#0 0x0018d96b in strlen () from /lib/tls/libc.so.6
#1 0x0231cc70 in php_mysqli_fetch_into_hash (ht=1,
return_value=0x9ed2454, this_ptr=0x9ed16fc, return_value_used=1,
override_flags=0, into_object=0) at
/usr/local/src/php5-STABLE-200503121930/ext/mysqli/mysqli.c:663
#2 0x02326b79 in zif_mysqli_fetch_array (ht=1, return_value=0x9ed2454,
this_ptr=0x9ed16fc, return_value_used=1)
at
/usr/local/src/php5-STABLE-200503121930/ext/mysqli/mysqli_nonapi.c:193
#3 0x024c3f31 in zend_do_fcall_common_helper (execute_data=0xbfee64d0,
opline=0x9ed61b8, op_array=0x9e78dd4)
at /usr/local/src/php5-STABLE-200503121930/Zend/zend_execute.c:2727
#4 0x024c4645 in zend_do_fcall_by_name_handler (execute_data=0xbfee64d0,
opline=0x9ed61b8, op_array=0x9e78dd4)
at /usr/local/src/php5-STABLE-200503121930/Zend/zend_execute.c:2841
#5 0x024bf0ee in execute (op_array=0x9e78dd4) at
/usr/local/src/php5-STABLE-200503121930/Zend/zend_execute.c:1406
#6 0x0249b364 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /usr/local/src/php5-STABLE-200503121930/Zend/zend.c:1068
#7 0x0245c516 in php_execute_script (primary_file=0xbfee8830) at
/usr/local/src/php5-STABLE-200503121930/main/main.c:1630
#8 0x024c9b29 in php_handler (r=0x9ebf8d8)
at
/usr/local/src/php5-STABLE-200503121930/sapi/apache2handler/sapi_apache2.c:555
#9 0x007bf9f7 in ap_run_handler () from /usr/sbin/httpd
#10 0x09b83888 in ?? ()
#11 0x007bf9ce in ap_run_handler () from /usr/sbin/httpd
#12 0x09ebf8d8 in ?? ()
#13 0x09ebf8d8 in ?? ()
#14 0xbfee89a8 in ?? ()
#15 0x007bfe63 in ap_invoke_handler () from /usr/sbin/httpd
Previous frame inner to this frame (corrupt stack?)
--
Edit bug report at http://bugs.php.net/?id=32287&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32287&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32287&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32287&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32287&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32287&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32287&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32287&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32287&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32287&r=support
Expected behavior: http://bugs.php.net/fix.php?id=32287&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32287&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32287&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32287&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32287&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32287&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32287&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32287&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32287&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32287&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32287&r=mysqlcfg
#24308 [NEW]: opendir() doesn't handle Windows filesnames with spaces
From: john at cloudyhands dot com Operating system: Windows XP PHP version: 4.3.1 PHP Bug Type: Filesystem function related Bug description: opendir() doesn't handle Windows filesnames with spaces Description: here is the error: Warning: opendir(C:\Documents and Settings\john\My Documents\My Pictures\2003_0622) [function.opendir]: failed to open dir: Invalid argument in C:\jf\php\htmlScan\showPics.php on line 202 Cannot find C:\Documents and Settings\john\My Documents\My Pictures\2003_0622. There is such a directory, and trying a different directory with no spaces does work. So, Windows gets you again! :) Reproduce code: --- $dfltRoot = "C:\\Documents and Settings\\john\\My Documents\\My Pictures\\2003_0622"; opendir($dfltRoot); Expected result: opendir() returns the directory handle. Actual result: -- see error listed in description -- Edit bug report at http://bugs.php.net/?id=24308&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24308&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24308&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24308&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24308&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24308&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24308&r=support Expected behavior: http://bugs.php.net/fix.php?id=24308&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24308&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24308&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24308&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24308&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24308&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24308&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24308&r=gnused
#24308 [Bgs]: opendir() doesn't handle Windows filesnames with spaces
ID: 24308 User updated by: john at cloudyhands dot com Reported By: john at cloudyhands dot com Status: Bogus Bug Type: Filesystem function related Operating System: Windows XP -PHP Version: 4.3.1 +PHP Version: PHP Version 4.3.2 New Comment: unless I'm missing something, this ain't fixed. back at you. Previous Comments: [2003-06-26 12:06:28] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. PHP 4.3.2 is already released with lot of fixes. [2003-06-24 02:45:52] john at cloudyhands dot com Description: here is the error: Warning: opendir(C:\Documents and Settings\john\My Documents\My Pictures\2003_0622) [function.opendir]: failed to open dir: Invalid argument in C:\jf\php\htmlScan\showPics.php on line 202 Cannot find C:\Documents and Settings\john\My Documents\My Pictures\2003_0622. There is such a directory, and trying a different directory with no spaces does work. So, Windows gets you again! :) Reproduce code: --- $dfltRoot = "C:\\Documents and Settings\\john\\My Documents\\My Pictures\\2003_0622"; opendir($dfltRoot); Expected result: opendir() returns the directory handle. Actual result: -- see error listed in description -- Edit this bug report at http://bugs.php.net/?id=24308&edit=1
