#50399 [NEW]: segfault when using SAPI
From: ikickdogsforfun at hotmail dot com
Operating system: Debian 5
PHP version: 5.3.1
PHP Bug Type: Scripting Engine problem
Bug description: segfault when using SAPI
Description:
When using PHP SAPI and values have been added to the global $_SERVER
variable, shutdown segfaults in zend_gc. If I remove the setting of the
global variables it doesn't seg fault.
This is possibly not a fault the SAPI, but I've been unable to resolve,
removing the destroy and free commands in shutdown function doesn't stop it
from segfaulting.
Reproduce code:
---
The entire source code file is available at
https://crispycrisp.org/php.txt this is the function that causes a segfault
in shutdown if it has been called:
void php_set_superglobal_server(char *name, char *val)
{
zend_first_try {
HashTable* locals = EG(symbol_table);
zval *type;
/* Fetch $_SERVER from the global scope */
zend_hash_find(locals, _SERVER, sizeof(_SERVER),
(void**)SERVER);
ALLOC_INIT_ZVAL(type);
ZVAL_STRING(type, val, 1);
ZEND_SET_SYMBOL(Z_ARRVAL_PP(SERVER), name, type);
} zend_end_try();
}
Expected result:
No segfault
Actual result:
--
==17605== Thread 2:
==17605== Invalid read of size 4
==17605==at 0x43B4BB9: gc_remove_zval_from_buffer (zend_gc.h:189)
==17605==by 0x438E18F: _zval_ptr_dtor (zend_execute_API.c:434)
==17605==by 0x43A4C7D: zend_hash_destroy (zend_hash.c:526)
==17605==by 0x804A88A: php_shutdown (php.c:143)
==17605==by 0x804A955: php (php.c:168)
==17605==by 0x8049D94: parsing_request (handler.c:180)
==17605==by 0x80496FE: handle (handler.c:25)
==17605==by 0x4032F3A: start_thread (in /lib/libpthread-2.7.so)
==17605==by 0x4793BED: clone (in /lib/libc-2.7.so)
==17605== Address 0x1c is not stack'd, malloc'd or (recently) free'd
==17605==
==17605== Process terminating with default action of signal 11 (SIGSEGV)
==17605== Access not within mapped region at address 0x1C
==17605==at 0x43B4BB9: gc_remove_zval_from_buffer (zend_gc.h:189)
==17605==by 0x438E18F: _zval_ptr_dtor (zend_execute_API.c:434)
==17605==by 0x43A4C7D: zend_hash_destroy (zend_hash.c:526)
==17605==by 0x804A88A: php_shutdown (php.c:143)
==17605==by 0x804A955: php (php.c:168)
==17605==by 0x8049D94: parsing_request (handler.c:180)
==17605==by 0x80496FE: handle (handler.c:25)
==17605==by 0x4032F3A: start_thread (in /lib/libpthread-2.7.so)
==17605==by 0x4793BED: clone (in /lib/libc-2.7.so)
--
Edit bug report at http://bugs.php.net/?id=50399edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50399r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50399r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50399r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50399r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50399r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50399r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50399r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50399r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50399r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50399r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50399r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50399r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50399r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50399r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50399r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50399r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50399r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50399r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50399r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50399r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50399r=mysqlcfg
#50399 [Com]: segfault when using SAPI
ID: 50399
Comment by: ikickdogsforfun at hotmail dot com
Reported By: ikickdogsforfun at hotmail dot com
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Debian 5
PHP Version: 5.3.1
New Comment:
I added that line to my php.ini and checked phpinfo(); which showed
zend.gc=off
Still having the same problem I'm afraid and valgrind output shows
segfault at the same location.
Previous Comments:
[2009-12-07 14:20:40] paj...@php.net
Can you try with:
zend.enable_gc=Off
In your php.ini please?
[2009-12-07 13:56:16] ikickdogsforfun at hotmail dot com
Description:
When using PHP SAPI and values have been added to the global $_SERVER
variable, shutdown segfaults in zend_gc. If I remove the setting of the
global variables it doesn't seg fault.
This is possibly not a fault the SAPI, but I've been unable to resolve,
removing the destroy and free commands in shutdown function doesn't stop
it from segfaulting.
Reproduce code:
---
The entire source code file is available at
https://crispycrisp.org/php.txt this is the function that causes a
segfault in shutdown if it has been called:
void php_set_superglobal_server(char *name, char *val)
{
zend_first_try {
HashTable* locals = EG(symbol_table);
zval *type;
/* Fetch $_SERVER from the global scope */
zend_hash_find(locals, _SERVER, sizeof(_SERVER),
(void**)SERVER);
ALLOC_INIT_ZVAL(type);
ZVAL_STRING(type, val, 1);
ZEND_SET_SYMBOL(Z_ARRVAL_PP(SERVER), name, type);
} zend_end_try();
}
Expected result:
No segfault
Actual result:
--
==17605== Thread 2:
==17605== Invalid read of size 4
==17605==at 0x43B4BB9: gc_remove_zval_from_buffer (zend_gc.h:189)
==17605==by 0x438E18F: _zval_ptr_dtor (zend_execute_API.c:434)
==17605==by 0x43A4C7D: zend_hash_destroy (zend_hash.c:526)
==17605==by 0x804A88A: php_shutdown (php.c:143)
==17605==by 0x804A955: php (php.c:168)
==17605==by 0x8049D94: parsing_request (handler.c:180)
==17605==by 0x80496FE: handle (handler.c:25)
==17605==by 0x4032F3A: start_thread (in /lib/libpthread-2.7.so)
==17605==by 0x4793BED: clone (in /lib/libc-2.7.so)
==17605== Address 0x1c is not stack'd, malloc'd or (recently) free'd
==17605==
==17605== Process terminating with default action of signal 11
(SIGSEGV)
==17605== Access not within mapped region at address 0x1C
==17605==at 0x43B4BB9: gc_remove_zval_from_buffer (zend_gc.h:189)
==17605==by 0x438E18F: _zval_ptr_dtor (zend_execute_API.c:434)
==17605==by 0x43A4C7D: zend_hash_destroy (zend_hash.c:526)
==17605==by 0x804A88A: php_shutdown (php.c:143)
==17605==by 0x804A955: php (php.c:168)
==17605==by 0x8049D94: parsing_request (handler.c:180)
==17605==by 0x80496FE: handle (handler.c:25)
==17605==by 0x4032F3A: start_thread (in /lib/libpthread-2.7.so)
==17605==by 0x4793BED: clone (in /lib/libc-2.7.so)
--
Edit this bug report at http://bugs.php.net/?id=50399edit=1
#50399 [Com]: garbage collection crashes
ID: 50399 Comment by: ikickdogsforfun at hotmail dot com Reported By: ikickdogsforfun at hotmail dot com Status: Assigned Bug Type: Reproducible crash Operating System: Debian 5 PHP Version: 5.3.1 Assigned To: dmitry New Comment: Thanks guys that fixed it. I replaced: ZEND_SET_SYMBOL(Z_ARRVAL_PP(SERVER), name, type); with: php_register_variable_ex(name, type, PG(http_globals)[TRACK_VARS_SERVER]); No segfault. I assume that method is either incorrect or not properly supported via the embedded SAPI. Nevermind, fixed and I'll just replace the other methods with this method using the track vars :) Previous Comments: [2009-12-07 18:46:06] j...@php.net See also bug #50382 [2009-12-07 17:36:06] scott...@php.net Can you try using the following within php_set_superglobal_server as the way to modify the _SERVER value. php_register_variable_ex(name, type, PG(http_globals)[TRACK_VARS_SERVER]); Also you don't need to destroy the servers zval, it will be handled by php_embed_shutdown() [2009-12-07 15:33:32] paj...@php.net Dmitry, can you take a look at it pls? [2009-12-07 15:28:19] ikickdogsforfun at hotmail dot com I added that line to my php.ini and checked phpinfo(); which showed zend.gc=off Still having the same problem I'm afraid and valgrind output shows segfault at the same location. [2009-12-07 14:20:40] paj...@php.net Can you try with: zend.enable_gc=Off In your php.ini please? 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/50399 -- Edit this bug report at http://bugs.php.net/?id=50399edit=1
#50399 [Asn-Csd]: garbage collection crashes
ID: 50399 User updated by: ikickdogsforfun at hotmail dot com Reported By: ikickdogsforfun at hotmail dot com -Status: Assigned +Status: Closed Bug Type: Reproducible crash Operating System: Debian 5 PHP Version: 5.3.1 Assigned To: dmitry New Comment: Sorry, have to provide a comment to close ;) Previous Comments: [2009-12-07 20:11:34] ikickdogsforfun at hotmail dot com Thanks guys that fixed it. I replaced: ZEND_SET_SYMBOL(Z_ARRVAL_PP(SERVER), name, type); with: php_register_variable_ex(name, type, PG(http_globals)[TRACK_VARS_SERVER]); No segfault. I assume that method is either incorrect or not properly supported via the embedded SAPI. Nevermind, fixed and I'll just replace the other methods with this method using the track vars :) [2009-12-07 18:46:06] j...@php.net See also bug #50382 [2009-12-07 17:36:06] scott...@php.net Can you try using the following within php_set_superglobal_server as the way to modify the _SERVER value. php_register_variable_ex(name, type, PG(http_globals)[TRACK_VARS_SERVER]); Also you don't need to destroy the servers zval, it will be handled by php_embed_shutdown() [2009-12-07 15:33:32] paj...@php.net Dmitry, can you take a look at it pls? [2009-12-07 15:28:19] ikickdogsforfun at hotmail dot com I added that line to my php.ini and checked phpinfo(); which showed zend.gc=off Still having the same problem I'm afraid and valgrind output shows segfault at the same location. 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/50399 -- Edit this bug report at http://bugs.php.net/?id=50399edit=1
#50178 [NEW]: Some memleaks from valgrind
From: ikickdogsforfun at hotmail dot com Operating system: Gentoo Linux PHP version: 5.2.11 PHP Bug Type: Scripting Engine problem Bug description: Some memleaks from valgrind Description: When runnig my C application using PHP SAPI, valgrind reports some mem leaks that appear to be coming from ZEND/SAPI. Reproduce code: --- The line that is pointed to by valgrind is: php_embed_init(argv, argc PTSRMLS_CC); The entire php.c can be seen at http://crispycrisp.org/php.txt Expected result: No me leaks Actual result: -- Here is the entire valgrind output: http://crispycrisp.org/valgrind.txt The relevant memleaks: ==24466== 20 bytes in 1 blocks are definitely lost in loss record 12 of 24 ==24466==at 0x40240F8: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==24466==by 0x5B7DAE7: ??? ==24466==by 0x5B7DCB6: ??? ==24466==by 0x5B4C6AF: ??? ==24466==by 0x5B43E34: ??? ==24466==by 0x5B44402: ??? ==24466==by 0x402D905: ??? ==24466==by 0x402DA1A: ??? ==24466==by 0x402D0DC: ??? ==24466==by 0x402D2FD: ??? ==24466==by 0x47EEE8C: getservbyname_r (in /lib/libc-2.8.so) ==24466==by 0x47EECF5: getservbyname (in /lib/libc-2.8.so) ==24466==by 0x4C11E71: mysql_server_init (in /usr/lib/mysql/libmysqlclient.so.15.0.0) ==24466==by 0x4292E16: zm_startup_mysqli (mysqli.c:498) ==24466==by 0x4499235: zend_startup_module_ex (zend_API.c:1472) ==24466==by 0x44A04AC: zend_hash_apply (zend_hash.c:673) ==24466==by 0x44993F0: zend_startup_modules (zend_API.c:1519) ==24466==by 0x4442394: php_module_startup (main.c:1843) ==24466==by 0x450F337: php_embed_startup (php_embed.c:104) ==24466==by 0x450F3B3: php_embed_init (php_embed.c:182) ==24466==by 0x804A365: php_startup (php.c:134) ==24466==by 0x804A453: php (php.c:161) ==24466==by 0x80499D8: parsing_request (handler.c:141) ==24466==by 0x804944D: handle (handler.c:25) ==24466==by 0x403719A: (within /lib/libpthread-2.8.so) ==24466==by 0x47D786D: clone (in /lib/libc-2.8.so) ==24466== 21 bytes in 1 blocks are definitely lost in loss record 13 of 24 ==24466==at 0x40240F8: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==24466==by 0x5B7DAE7: ??? ==24466==by 0x5B7DCB6: ??? ==24466==by 0x5B4C6AF: ??? ==24466==by 0x5B43E34: ??? ==24466==by 0x5B44402: ??? ==24466==by 0x402D905: ??? ==24466==by 0x402DA1A: ??? ==24466==by 0x402C38C: ??? ==24466==by 0x402C696: ??? ==24466==by 0x47EEB35: getprotobyname_r (in /lib/libc-2.8.so) ==24466==by 0x47EE9C8: getprotobyname (in /lib/libc-2.8.so) ==24466==by 0x43291EE: zm_startup_sockets (sockets.c:528) ==24466==by 0x4499235: zend_startup_module_ex (zend_API.c:1472) ==24466==by 0x44A04AC: zend_hash_apply (zend_hash.c:673) ==24466==by 0x44993F0: zend_startup_modules (zend_API.c:1519) ==24466==by 0x4442394: php_module_startup (main.c:1843) ==24466==by 0x450F337: php_embed_startup (php_embed.c:104) ==24466==by 0x450F3B3: php_embed_init (php_embed.c:182) ==24466==by 0x804A365: php_startup (php.c:134) ==24466==by 0x804A453: php (php.c:161) ==24466==by 0x80499D8: parsing_request (handler.c:141) ==24466==by 0x804944D: handle (handler.c:25) ==24466==by 0x403719A: (within /lib/libpthread-2.8.so) ==24466==by 0x47D786D: clone (in /lib/libc-2.8.so) ==24466== ==24466== ==24466== 21 bytes in 1 blocks are definitely lost in loss record 14 of 24 ==24466==at 0x40240F8: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==24466==by 0x5B7DAE7: ??? ==24466==by 0x5B7DCB6: ??? ==24466==by 0x5B4C6AF: ??? ==24466==by 0x5B43E34: ??? ==24466==by 0x5B44402: ??? ==24466==by 0x402D905: ??? ==24466==by 0x402DA1A: ??? ==24466==by 0x402C38C: ??? ==24466==by 0x402C696: ??? ==24466==by 0x47EEB35: getprotobyname_r (in /lib/libc-2.8.so) ==24466==by 0x47EE9C8: getprotobyname (in /lib/libc-2.8.so) ==24466==by 0x43291AC: zm_startup_sockets (sockets.c:524) ==24466==by 0x4499235: zend_startup_module_ex (zend_API.c:1472) ==24466==by 0x44A04AC: zend_hash_apply (zend_hash.c:673) ==24466==by 0x44993F0: zend_startup_modules (zend_API.c:1519) ==24466==by 0x4442394: php_module_startup (main.c:1843) ==24466==by 0x450F337: php_embed_startup (php_embed.c:104) ==24466==by 0x450F3B3: php_embed_init (php_embed.c:182) ==24466==by 0x804A365: php_startup (php.c:134) ==24466==by 0x804A453: php (php.c:161) ==24466==by 0x80499D8: parsing_request (handler.c:141) ==24466==by 0x804944D: handle (handler.c:25) ==24466==by 0x403719A: (within /lib/libpthread-2.8.so) ==24466==by 0x47D786D: clone (in /lib/libc-2.8.so) -- Edit bug report at http://bugs.php.net/?id=50178edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50178r=trysnapshot52 Try a snapshot (PHP 5.3): http
#50179 [NEW]: Some memleaks from valgrind
From: ikickdogsforfun at hotmail dot com Operating system: Gentoo Linux PHP version: 5.2.11 PHP Bug Type: Scripting Engine problem Bug description: Some memleaks from valgrind Description: When runnig my C application using PHP SAPI, valgrind reports some mem leaks that appear to be coming from ZEND/SAPI. Reproduce code: --- The line that is pointed to by valgrind is: php_embed_init(argv, argc PTSRMLS_CC); The entire php.c can be seen at http://crispycrisp.org/php.txt Expected result: No me leaks Actual result: -- Here is the entire valgrind output: http://crispycrisp.org/valgrind.txt The relevant memleaks: ==24466== 20 bytes in 1 blocks are definitely lost in loss record 12 of 24 ==24466==at 0x40240F8: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==24466==by 0x5B7DAE7: ??? ==24466==by 0x5B7DCB6: ??? ==24466==by 0x5B4C6AF: ??? ==24466==by 0x5B43E34: ??? ==24466==by 0x5B44402: ??? ==24466==by 0x402D905: ??? ==24466==by 0x402DA1A: ??? ==24466==by 0x402D0DC: ??? ==24466==by 0x402D2FD: ??? ==24466==by 0x47EEE8C: getservbyname_r (in /lib/libc-2.8.so) ==24466==by 0x47EECF5: getservbyname (in /lib/libc-2.8.so) ==24466==by 0x4C11E71: mysql_server_init (in /usr/lib/mysql/libmysqlclient.so.15.0.0) ==24466==by 0x4292E16: zm_startup_mysqli (mysqli.c:498) ==24466==by 0x4499235: zend_startup_module_ex (zend_API.c:1472) ==24466==by 0x44A04AC: zend_hash_apply (zend_hash.c:673) ==24466==by 0x44993F0: zend_startup_modules (zend_API.c:1519) ==24466==by 0x4442394: php_module_startup (main.c:1843) ==24466==by 0x450F337: php_embed_startup (php_embed.c:104) ==24466==by 0x450F3B3: php_embed_init (php_embed.c:182) ==24466==by 0x804A365: php_startup (php.c:134) ==24466==by 0x804A453: php (php.c:161) ==24466==by 0x80499D8: parsing_request (handler.c:141) ==24466==by 0x804944D: handle (handler.c:25) ==24466==by 0x403719A: (within /lib/libpthread-2.8.so) ==24466==by 0x47D786D: clone (in /lib/libc-2.8.so) ==24466== 21 bytes in 1 blocks are definitely lost in loss record 13 of 24 ==24466==at 0x40240F8: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==24466==by 0x5B7DAE7: ??? ==24466==by 0x5B7DCB6: ??? ==24466==by 0x5B4C6AF: ??? ==24466==by 0x5B43E34: ??? ==24466==by 0x5B44402: ??? ==24466==by 0x402D905: ??? ==24466==by 0x402DA1A: ??? ==24466==by 0x402C38C: ??? ==24466==by 0x402C696: ??? ==24466==by 0x47EEB35: getprotobyname_r (in /lib/libc-2.8.so) ==24466==by 0x47EE9C8: getprotobyname (in /lib/libc-2.8.so) ==24466==by 0x43291EE: zm_startup_sockets (sockets.c:528) ==24466==by 0x4499235: zend_startup_module_ex (zend_API.c:1472) ==24466==by 0x44A04AC: zend_hash_apply (zend_hash.c:673) ==24466==by 0x44993F0: zend_startup_modules (zend_API.c:1519) ==24466==by 0x4442394: php_module_startup (main.c:1843) ==24466==by 0x450F337: php_embed_startup (php_embed.c:104) ==24466==by 0x450F3B3: php_embed_init (php_embed.c:182) ==24466==by 0x804A365: php_startup (php.c:134) ==24466==by 0x804A453: php (php.c:161) ==24466==by 0x80499D8: parsing_request (handler.c:141) ==24466==by 0x804944D: handle (handler.c:25) ==24466==by 0x403719A: (within /lib/libpthread-2.8.so) ==24466==by 0x47D786D: clone (in /lib/libc-2.8.so) ==24466== ==24466== ==24466== 21 bytes in 1 blocks are definitely lost in loss record 14 of 24 ==24466==at 0x40240F8: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==24466==by 0x5B7DAE7: ??? ==24466==by 0x5B7DCB6: ??? ==24466==by 0x5B4C6AF: ??? ==24466==by 0x5B43E34: ??? ==24466==by 0x5B44402: ??? ==24466==by 0x402D905: ??? ==24466==by 0x402DA1A: ??? ==24466==by 0x402C38C: ??? ==24466==by 0x402C696: ??? ==24466==by 0x47EEB35: getprotobyname_r (in /lib/libc-2.8.so) ==24466==by 0x47EE9C8: getprotobyname (in /lib/libc-2.8.so) ==24466==by 0x43291AC: zm_startup_sockets (sockets.c:524) ==24466==by 0x4499235: zend_startup_module_ex (zend_API.c:1472) ==24466==by 0x44A04AC: zend_hash_apply (zend_hash.c:673) ==24466==by 0x44993F0: zend_startup_modules (zend_API.c:1519) ==24466==by 0x4442394: php_module_startup (main.c:1843) ==24466==by 0x450F337: php_embed_startup (php_embed.c:104) ==24466==by 0x450F3B3: php_embed_init (php_embed.c:182) ==24466==by 0x804A365: php_startup (php.c:134) ==24466==by 0x804A453: php (php.c:161) ==24466==by 0x80499D8: parsing_request (handler.c:141) ==24466==by 0x804944D: handle (handler.c:25) ==24466==by 0x403719A: (within /lib/libpthread-2.8.so) ==24466==by 0x47D786D: clone (in /lib/libc-2.8.so) -- Edit bug report at http://bugs.php.net/?id=50179edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50179r=trysnapshot52 Try a snapshot (PHP 5.3): http
#50179 [Opn-Bgs]: Incorrect double submission - See error
ID: 50179 User updated by: ikickdogsforfun at hotmail dot com -Summary: Some memleaks from valgrind Reported By: ikickdogsforfun at hotmail dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Gentoo Linux PHP Version: 5.2.11 New Comment: Was getting error: Authentication failed: Incorrect username Authentication failed: Incorrect username Warning: Cannot modify header information - headers already sent by (output started at /home/Web/sites/php-bugs-web/include/auth.inc:30) in /home/Web/sites/php-bugs-web/report.php on line 201 Didn't know it had submitted Previous Comments: [2009-11-15 10:27:37] ikickdogsforfun at hotmail dot com Description: When runnig my C application using PHP SAPI, valgrind reports some mem leaks that appear to be coming from ZEND/SAPI. Reproduce code: --- The line that is pointed to by valgrind is: php_embed_init(argv, argc PTSRMLS_CC); The entire php.c can be seen at http://crispycrisp.org/php.txt Expected result: No me leaks Actual result: -- Here is the entire valgrind output: http://crispycrisp.org/valgrind.txt The relevant memleaks: ==24466== 20 bytes in 1 blocks are definitely lost in loss record 12 of 24 ==24466==at 0x40240F8: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==24466==by 0x5B7DAE7: ??? ==24466==by 0x5B7DCB6: ??? ==24466==by 0x5B4C6AF: ??? ==24466==by 0x5B43E34: ??? ==24466==by 0x5B44402: ??? ==24466==by 0x402D905: ??? ==24466==by 0x402DA1A: ??? ==24466==by 0x402D0DC: ??? ==24466==by 0x402D2FD: ??? ==24466==by 0x47EEE8C: getservbyname_r (in /lib/libc-2.8.so) ==24466==by 0x47EECF5: getservbyname (in /lib/libc-2.8.so) ==24466==by 0x4C11E71: mysql_server_init (in /usr/lib/mysql/libmysqlclient.so.15.0.0) ==24466==by 0x4292E16: zm_startup_mysqli (mysqli.c:498) ==24466==by 0x4499235: zend_startup_module_ex (zend_API.c:1472) ==24466==by 0x44A04AC: zend_hash_apply (zend_hash.c:673) ==24466==by 0x44993F0: zend_startup_modules (zend_API.c:1519) ==24466==by 0x4442394: php_module_startup (main.c:1843) ==24466==by 0x450F337: php_embed_startup (php_embed.c:104) ==24466==by 0x450F3B3: php_embed_init (php_embed.c:182) ==24466==by 0x804A365: php_startup (php.c:134) ==24466==by 0x804A453: php (php.c:161) ==24466==by 0x80499D8: parsing_request (handler.c:141) ==24466==by 0x804944D: handle (handler.c:25) ==24466==by 0x403719A: (within /lib/libpthread-2.8.so) ==24466==by 0x47D786D: clone (in /lib/libc-2.8.so) ==24466== 21 bytes in 1 blocks are definitely lost in loss record 13 of 24 ==24466==at 0x40240F8: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==24466==by 0x5B7DAE7: ??? ==24466==by 0x5B7DCB6: ??? ==24466==by 0x5B4C6AF: ??? ==24466==by 0x5B43E34: ??? ==24466==by 0x5B44402: ??? ==24466==by 0x402D905: ??? ==24466==by 0x402DA1A: ??? ==24466==by 0x402C38C: ??? ==24466==by 0x402C696: ??? ==24466==by 0x47EEB35: getprotobyname_r (in /lib/libc-2.8.so) ==24466==by 0x47EE9C8: getprotobyname (in /lib/libc-2.8.so) ==24466==by 0x43291EE: zm_startup_sockets (sockets.c:528) ==24466==by 0x4499235: zend_startup_module_ex (zend_API.c:1472) ==24466==by 0x44A04AC: zend_hash_apply (zend_hash.c:673) ==24466==by 0x44993F0: zend_startup_modules (zend_API.c:1519) ==24466==by 0x4442394: php_module_startup (main.c:1843) ==24466==by 0x450F337: php_embed_startup (php_embed.c:104) ==24466==by 0x450F3B3: php_embed_init (php_embed.c:182) ==24466==by 0x804A365: php_startup (php.c:134) ==24466==by 0x804A453: php (php.c:161) ==24466==by 0x80499D8: parsing_request (handler.c:141) ==24466==by 0x804944D: handle (handler.c:25) ==24466==by 0x403719A: (within /lib/libpthread-2.8.so) ==24466==by 0x47D786D: clone (in /lib/libc-2.8.so) ==24466== ==24466== ==24466== 21 bytes in 1 blocks are definitely lost in loss record 14 of 24 ==24466==at 0x40240F8: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==24466==by 0x5B7DAE7: ??? ==24466==by 0x5B7DCB6: ??? ==24466==by 0x5B4C6AF: ??? ==24466==by 0x5B43E34: ??? ==24466==by 0x5B44402: ??? ==24466==by 0x402D905: ??? ==24466==by 0x402DA1A: ??? ==24466==by 0x402C38C: ??? ==24466==by 0x402C696: ??? ==24466==by 0x47EEB35: getprotobyname_r (in /lib/libc-2.8.so) ==24466==by 0x47EE9C8: getprotobyname (in /lib/libc-2.8.so) ==24466==by 0x43291AC: zm_startup_sockets (sockets.c:524) ==24466==by 0x4499235: zend_startup_module_ex (zend_API.c:1472) ==24466==by 0x44A04AC: zend_hash_apply (zend_hash.c:673) ==24466==by 0x44993F0: zend_startup_modules (zend_API.c:1519) ==24466==by 0x4442394: php_module_startup (main.c:1843) ==24466
#50178 [Bgs]: Some memleaks from valgrind
ID: 50178 User updated by: ikickdogsforfun at hotmail dot com Reported By: ikickdogsforfun at hotmail dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: Gentoo Linux PHP Version: 5.2.11 New Comment: Yes and they are quite obviously outside my C code. As I'm using the PHP SAPI doesn't that make it relating to php.net? Previous Comments: [2009-11-15 17:37:42] j...@php.net Those leaks are quite obviously outside PHP code. [2009-11-15 10:26:32] ikickdogsforfun at hotmail dot com Description: When runnig my C application using PHP SAPI, valgrind reports some mem leaks that appear to be coming from ZEND/SAPI. Reproduce code: --- The line that is pointed to by valgrind is: php_embed_init(argv, argc PTSRMLS_CC); The entire php.c can be seen at http://crispycrisp.org/php.txt Expected result: No me leaks Actual result: -- Here is the entire valgrind output: http://crispycrisp.org/valgrind.txt The relevant memleaks: ==24466== 20 bytes in 1 blocks are definitely lost in loss record 12 of 24 ==24466==at 0x40240F8: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==24466==by 0x5B7DAE7: ??? ==24466==by 0x5B7DCB6: ??? ==24466==by 0x5B4C6AF: ??? ==24466==by 0x5B43E34: ??? ==24466==by 0x5B44402: ??? ==24466==by 0x402D905: ??? ==24466==by 0x402DA1A: ??? ==24466==by 0x402D0DC: ??? ==24466==by 0x402D2FD: ??? ==24466==by 0x47EEE8C: getservbyname_r (in /lib/libc-2.8.so) ==24466==by 0x47EECF5: getservbyname (in /lib/libc-2.8.so) ==24466==by 0x4C11E71: mysql_server_init (in /usr/lib/mysql/libmysqlclient.so.15.0.0) ==24466==by 0x4292E16: zm_startup_mysqli (mysqli.c:498) ==24466==by 0x4499235: zend_startup_module_ex (zend_API.c:1472) ==24466==by 0x44A04AC: zend_hash_apply (zend_hash.c:673) ==24466==by 0x44993F0: zend_startup_modules (zend_API.c:1519) ==24466==by 0x4442394: php_module_startup (main.c:1843) ==24466==by 0x450F337: php_embed_startup (php_embed.c:104) ==24466==by 0x450F3B3: php_embed_init (php_embed.c:182) ==24466==by 0x804A365: php_startup (php.c:134) ==24466==by 0x804A453: php (php.c:161) ==24466==by 0x80499D8: parsing_request (handler.c:141) ==24466==by 0x804944D: handle (handler.c:25) ==24466==by 0x403719A: (within /lib/libpthread-2.8.so) ==24466==by 0x47D786D: clone (in /lib/libc-2.8.so) ==24466== 21 bytes in 1 blocks are definitely lost in loss record 13 of 24 ==24466==at 0x40240F8: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==24466==by 0x5B7DAE7: ??? ==24466==by 0x5B7DCB6: ??? ==24466==by 0x5B4C6AF: ??? ==24466==by 0x5B43E34: ??? ==24466==by 0x5B44402: ??? ==24466==by 0x402D905: ??? ==24466==by 0x402DA1A: ??? ==24466==by 0x402C38C: ??? ==24466==by 0x402C696: ??? ==24466==by 0x47EEB35: getprotobyname_r (in /lib/libc-2.8.so) ==24466==by 0x47EE9C8: getprotobyname (in /lib/libc-2.8.so) ==24466==by 0x43291EE: zm_startup_sockets (sockets.c:528) ==24466==by 0x4499235: zend_startup_module_ex (zend_API.c:1472) ==24466==by 0x44A04AC: zend_hash_apply (zend_hash.c:673) ==24466==by 0x44993F0: zend_startup_modules (zend_API.c:1519) ==24466==by 0x4442394: php_module_startup (main.c:1843) ==24466==by 0x450F337: php_embed_startup (php_embed.c:104) ==24466==by 0x450F3B3: php_embed_init (php_embed.c:182) ==24466==by 0x804A365: php_startup (php.c:134) ==24466==by 0x804A453: php (php.c:161) ==24466==by 0x80499D8: parsing_request (handler.c:141) ==24466==by 0x804944D: handle (handler.c:25) ==24466==by 0x403719A: (within /lib/libpthread-2.8.so) ==24466==by 0x47D786D: clone (in /lib/libc-2.8.so) ==24466== ==24466== ==24466== 21 bytes in 1 blocks are definitely lost in loss record 14 of 24 ==24466==at 0x40240F8: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==24466==by 0x5B7DAE7: ??? ==24466==by 0x5B7DCB6: ??? ==24466==by 0x5B4C6AF: ??? ==24466==by 0x5B43E34: ??? ==24466==by 0x5B44402: ??? ==24466==by 0x402D905: ??? ==24466==by 0x402DA1A: ??? ==24466==by 0x402C38C: ??? ==24466==by 0x402C696: ??? ==24466==by 0x47EEB35: getprotobyname_r (in /lib/libc-2.8.so) ==24466==by 0x47EE9C8: getprotobyname (in /lib/libc-2.8.so) ==24466==by 0x43291AC: zm_startup_sockets (sockets.c:524) ==24466==by 0x4499235: zend_startup_module_ex (zend_API.c:1472) ==24466==by 0x44A04AC: zend_hash_apply (zend_hash.c:673) ==24466==by 0x44993F0: zend_startup_modules (zend_API.c:1519) ==24466==by 0x4442394: php_module_startup (main.c:1843) ==24466==by 0x450F337: php_embed_startup (php_embed.c:104) ==24466==by 0x450F3B3: php_embed_init (php_embed.c:182) ==24466
#47536 [NEW]: Build warnings with embedded SAPI
From: ikickdogsforfun at hotmail dot com Operating system: Gentoo PHP version: 5.2.9 PHP Bug Type: Compile Warning Bug description: Build warnings with embedded SAPI Description: When compiling a C program that makes use of the embedded SAPI (embed.h), there are a few compile warnings that would be nice if they could be fixed :) Also, this is a manually compiled version of PHP, not emerged from Gentoo's portage. Reproduce code: --- Compiled using the following: gcc -I/usr/lib/php5/include/php/ -I/usr/lib/php5/include/php/main -I/usr/lib/php5/include/php/Zend -I/usr/lib/php5/include/php/TSRM -I/usr/lib/php5/include/php/sapi/embed -L/home/crisp/php/local/lib -Wall -Wextra -lpthread -ggdb -o httpd *.c /home/crisp/php/local/lib/libphp5.so The code itself is here: http://crispycrisp.org/test.txt Expected result: No compile warnings Actual result: -- In file included from /usr/lib/php5/include/php/Zend/zend.h:664, from /usr/lib/php5/include/php/main/php.h:34, from /usr/lib/php5/include/php/sapi/embed/php_embed.h:23, from test.c:1: /usr/lib/php5/include/php/Zend/zend_variables.h:30: warning: unused parameter '__zend_filename' /usr/lib/php5/include/php/Zend/zend_variables.h:30: warning: unused parameter '__zend_lineno' /usr/lib/php5/include/php/Zend/zend_variables.h:40: warning: unused parameter '__zend_filename' /usr/lib/php5/include/php/Zend/zend_variables.h:40: warning: unused parameter '__zend_lineno' In file included from /usr/lib/php5/include/php/Zend/zend_API.h:30, from /usr/lib/php5/include/php/main/php.h:38, from /usr/lib/php5/include/php/sapi/embed/php_embed.h:23, from test.c:1: /usr/lib/php5/include/php/Zend/zend_execute.h:65: warning: unused parameter '__zend_orig_filename' /usr/lib/php5/include/php/Zend/zend_execute.h:65: warning: unused parameter '__zend_orig_lineno' -- Edit bug report at http://bugs.php.net/?id=47536edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47536r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47536r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47536r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47536r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47536r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47536r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47536r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47536r=needscript Try newer version: http://bugs.php.net/fix.php?id=47536r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47536r=support Expected behavior: http://bugs.php.net/fix.php?id=47536r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47536r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47536r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47536r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47536r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47536r=dst IIS Stability: http://bugs.php.net/fix.php?id=47536r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47536r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47536r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47536r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47536r=mysqlcfg
#44767 [Opn-Bgs]: Incorrect handling of a closing # to # based comments
ID: 44767
User updated by: ikickdogsforfun at hotmail dot com
Reported By: ikickdogsforfun at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Gentoo Linux
PHP Version: 5.2.6RC5
New Comment:
Ah I see. Thanks for the explanation, it had puzzled me somewhat. As
for whose logic is right, it's not mine =P But thanks that's clarified a
few things for me.
I have also marked this bug as 'bogus' (If it will let me), I hope that
was correct =)
Previous Comments:
[2008-05-05 21:35:19] whitewolf24 at hotmail dot com
no, # is a ONE line comment. the end of the line ended the comment.
as for the error. you should get them as that code would break anyway.
your lacking ; on the end of lines. {they are commented out}
nothing on the line after the first # is read by the parser.
the problem your having is that your ending your code before it's
closed line three is ? and the interpreter is seeing this and asking
you about the messed up syntax
?
echo \some .
?
these should be the two errors you are getting
Warning: Unexpected character in input: '\' (ASCII=92) state=1 in file
on line 2
Parse error: syntax error, unexpected ';' in file on line 3
done believe me? try this line which is a code complete and doesn't
error
?
echo this ;#works# echo works.;
?
if you were right about your logic then you should get this works
else if I'm correct you will just get this
[2008-05-02 13:27:13] ikickdogsforfun at hotmail dot com
In which case the comment is handled incorrectly if a second # appears,
note the code above which produces 2 errors. One of the errors refers to
a third line, even though there is only code on line. This suggests that
the interpretor has closed the comment and is attempting to handle the
rest of the code after the second # by treating it as a new line.
[2008-04-29 23:28:07] whitewolf24 at hotmail dot com
um, last I checked and have read in the manual
# comments to the end of the line OR the end of the php block, which
ever happens first. not to another #
[2008-04-17 20:49:53] ikickdogsforfun at hotmail dot com
Description:
A # comment can be closed by a second # causing PHP to act rather
oddly. Any errors that occur on the same line but after the closing #
are reported as an error on the next line, however if there are no
errors anything after the second # is ignored and not processed as if it
was a comment. I think based on this, there needs to be some concistency
about what happens when a second # is encountered. Are these intended to
be embedded comments which can be be closed? Or should everything being
ignored after the first # untill a new line character is encountered?
Reproduce code:
---
This produces 2 errors, one on line 2, one on line 3, though they are
both about line 3:
?
echo \some .# This is an imbedded comment#text;
?
This only echos out 'some':
?
echo some .# This is an imbedded comment#hi;
?
Expected result:
I would expect to see 'some text' echoed out, as I was under the
impression these kinds of comments were imbedded.
Actual result:
--
See the code section
--
Edit this bug report at http://bugs.php.net/?id=44767edit=1
#44767 [Opn]: Incorrect handling of a closing # to # based comments
ID: 44767 User updated by: ikickdogsforfun at hotmail dot com Reported By: ikickdogsforfun at hotmail dot com Status: Open Bug Type: Scripting Engine problem Operating System: Gentoo Linux PHP Version: 5.2.6RC5 New Comment: In which case the comment is handled incorrectly if a second # appears, note the code above which produces 2 errors. One of the errors refers to a third line, even though there is only code on line. This suggests that the interpretor has closed the comment and is attempting to handle the rest of the code after the second # by treating it as a new line. Previous Comments: [2008-04-29 23:28:07] whitewolf24 at hotmail dot com um, last I checked and have read in the manual # comments to the end of the line OR the end of the php block, which ever happens first. not to another # [2008-04-17 20:49:53] ikickdogsforfun at hotmail dot com Description: A # comment can be closed by a second # causing PHP to act rather oddly. Any errors that occur on the same line but after the closing # are reported as an error on the next line, however if there are no errors anything after the second # is ignored and not processed as if it was a comment. I think based on this, there needs to be some concistency about what happens when a second # is encountered. Are these intended to be embedded comments which can be be closed? Or should everything being ignored after the first # untill a new line character is encountered? Reproduce code: --- This produces 2 errors, one on line 2, one on line 3, though they are both about line 3: ? echo \some .# This is an imbedded comment#text; ? This only echos out 'some': ? echo some .# This is an imbedded comment#hi; ? Expected result: I would expect to see 'some text' echoed out, as I was under the impression these kinds of comments were imbedded. Actual result: -- See the code section -- Edit this bug report at http://bugs.php.net/?id=44767edit=1
#44767 [NEW]: Incorrect handling of a closing # to # based comments
From: ikickdogsforfun at hotmail dot com Operating system: Gentoo Linux PHP version: 5.2.6RC5 PHP Bug Type: *General Issues Bug description: Incorrect handling of a closing # to # based comments Description: A # comment can be closed by a second # causing PHP to act rather oddly. Any errors that occur on the same line but after the closing # are reported as an error on the next line, however if there are no errors anything after the second # is ignored and not processed as if it was a comment. I think based on this, there needs to be some concistency about what happens when a second # is encountered. Are these intended to be embedded comments which can be be closed? Or should everything being ignored after the first # untill a new line character is encountered? Reproduce code: --- This produces 2 errors, one on line 2, one on line 3, though they are both about line 3: ? echo \some .# This is an imbedded comment#text; ? This only echos out 'some': ? echo some .# This is an imbedded comment#hi; ? Expected result: I would expect to see 'some text' echoed out, as I was under the impression these kinds of comments were imbedded. Actual result: -- See the code section -- Edit bug report at http://bugs.php.net/?id=44767edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44767r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44767r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44767r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44767r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44767r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44767r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44767r=needscript Try newer version:http://bugs.php.net/fix.php?id=44767r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44767r=support Expected behavior:http://bugs.php.net/fix.php?id=44767r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44767r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44767r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44767r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44767r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44767r=dst IIS Stability:http://bugs.php.net/fix.php?id=44767r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44767r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44767r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44767r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44767r=mysqlcfg
