#34731 [Fbk->Opn]: segmentation fault during request shutdown
ID: 34731 User updated by: novicky at aarongroup dot cz Reported By: novicky at aarongroup dot cz -Status: Feedback +Status: Open Bug Type: OCI8 related Operating System: All PHP Version: 5CVS-2005-10-04 (CVS) Assigned To: tony2001 New Comment: It is hard to reproduce but working on deallocated memory blocks is extremely dangerous. We had problems with segmentation faults on Sparc/Solaris 9. Have a look on following code coming from oci8.c - first a session pointer is inserted into the list zend_list_insert(), while few lines bellow the session structure is copied into a new location zend_llist_add_element() and the original memory block is deallocated by efree(). Thus destructor applied on list would work on deallocated memory!!! session->num = zend_list_insert(session, le_session); session->is_open = 1; mutex_lock(mx_lock); num_links++; if (!exclusive) { zend_llist_add_element(session_list, session); efree(session); session = (oci_session*) session_list->tail->data; num_persistent++; } mutex_unlock(mx_lock); oci_debug("_oci_open_session new sess=%d user=%s",session->num,username); return session; Previous Comments: [2005-10-04 18:48:20] [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-10-04 18:29:23] [EMAIL PROTECTED] Assigned to the maintainer. ---- [2005-10-04 15:59:20] novicky at aarongroup dot cz Description: There is an incorrect session destructor registration. The pointer registered by zend_list_insert points to a memory block which is then released by efree. This can lead to segmentation fault when destructor is called. A proposed patch follows (the same problem is id development branch) --- php5-STABLE-200510041238/ext/oci8/oci8.c.ORIG 2005-10-04 15:39:42.301952856 +0200 +++ php5-STABLE-200510041238/ext/oci8/oci8.c2005-10-04 15:40:58.979935427 +0200 @@ -2879,7 +2879,6 @@ ) ); - session->num = zend_list_insert(session, le_session); session->is_open = 1; mutex_lock(mx_lock); @@ -2892,6 +2891,7 @@ } mutex_unlock(mx_lock); + session->num = zend_list_insert(session, le_session); oci_debug("_oci_open_session new sess=%d user=%s",session->num,username); return session; -- Edit this bug report at http://bugs.php.net/?id=34731&edit=1
#34731 [NEW]: segmentation fault during request shutdown
From: novicky at aarongroup dot cz Operating system: All PHP version: 5CVS-2005-10-04 (CVS) PHP Bug Type: OCI8 related Bug description: segmentation fault during request shutdown Description: There is an incorrect session destructor registration. The pointer registered by zend_list_insert points to a memory block which is then released by efree. This can lead to segmentation fault when destructor is called. A proposed patch follows (the same problem is id development branch) --- php5-STABLE-200510041238/ext/oci8/oci8.c.ORIG 2005-10-04 15:39:42.301952856 +0200 +++ php5-STABLE-200510041238/ext/oci8/oci8.c2005-10-04 15:40:58.979935427 +0200 @@ -2879,7 +2879,6 @@ ) ); - session->num = zend_list_insert(session, le_session); session->is_open = 1; mutex_lock(mx_lock); @@ -2892,6 +2891,7 @@ } mutex_unlock(mx_lock); + session->num = zend_list_insert(session, le_session); oci_debug("_oci_open_session new sess=%d user=%s",session->num,username); return session; -- Edit bug report at http://bugs.php.net/?id=34731&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34731&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34731&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34731&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34731&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34731&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34731&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34731&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34731&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34731&r=support Expected behavior: http://bugs.php.net/fix.php?id=34731&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34731&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34731&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34731&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34731&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34731&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34731&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34731&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34731&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34731&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34731&r=mysqlcfg
#28883 [Fbk->Opn]: [PATCH] fix for crash during module shutdown
ID: 28883 User updated by: novicky at aarongroup dot cz Reported By: novicky at aarongroup dot cz -Status: Feedback +Status: Open Bug Type: Informix related Operating System: All -PHP Version: 4.3.7 +PHP Version: 4.3.10 New Comment: The problem still persists. There is no change even in latest CVS. The function php_error_docref cannot be used within resource destructors. The submitted patch simply removes error reporting from destructor. Previous Comments: [2005-02-03 05:04:08] [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 [2004-06-22 19:08:12] novicky at aarongroup dot cz Description: There is a problem in function ifx_do_close which can lead to crash during module shutdown. The function ifx_do_close is called during shutdown from list destrucors _close_ifx_link and _close_ifx_plink. If something goes wrong in this function, error reporting is performed and emalloc is called. Calling emalloc is not possible during memory destruction and can cause segfault. It is necessary to remove all error reporting from ifx_do_close (which is in fact useless). Here is a patch: --- ifx.ec.orig 2004-06-01 02:52:14.0 +0200 +++ ifx.ec 2004-06-22 18:46:01.0 +0200 @@ -295,7 +295,6 @@ PARAMETER char *link; EXEC SQL END DECLARE SECTION; { - char *ifx_err = NULL; TSRMLS_FETCH(); EXEC SQL SET CONNECTION :link; @@ -310,32 +309,12 @@ if (ifx_check() == 0) { /* DISCONNECT again, after rollback */ EXEC SQL DISCONNECT :link; - if (ifx_check() < 0) { - IFXG(sv_sqlcode) = SQLCODE; - php_error_docref(NULL TSRMLS_CC, E_WARNING, "Disconnect link %s after Automatic Rollback fails (%s)", link, (ifx_err = ifx_error(link))); } - } - if (ifx_check() < 0) { + else if (ifx_check() < 0) { /* CLOSE database if rollback or disconnect fails */ EXEC SQL CLOSE DATABASE; - if (ifx_check() < 0) { - IFXG(sv_sqlcode) = SQLCODE; - php_error_docref(NULL TSRMLS_CC, E_WARNING, "Close database fails %s (%s)", link, (ifx_err = ifx_error(link))); - } } } - else if (SQLCODE < 0) { - IFXG(sv_sqlcode) = SQLCODE; - php_error_docref(NULL TSRMLS_CC, E_WARNING, "Disconnect link %s fails (%s)", link, (ifx_err = ifx_error(link))); - } - } - else { - IFXG(sv_sqlcode) = SQLCODE; - php_error_docref(NULL TSRMLS_CC, E_WARNING, "Set connection %s fails (%s)", link, (ifx_err = ifx_error(link))); - } - - if (ifx_err) { - efree(ifx_err); } } -- Edit this bug report at http://bugs.php.net/?id=28883&edit=1
#28883 [NEW]: crash during module shutdown
From: novicky at aarongroup dot cz Operating system: All PHP version: 4.3.7 PHP Bug Type: Informix related Bug description: crash during module shutdown Description: There is a problem in function ifx_do_close which can lead to crash during module shutdown. The function ifx_do_close is called during shutdown from list destrucors _close_ifx_link and _close_ifx_plink. If something goes wrong in this function, error reporting is performed and emalloc is called. Calling emalloc is not possible during memory destruction and can cause segfault. It is necessary to remove all error reporting from ifx_do_close (which is in fact useless). Here is a patch: --- ifx.ec.orig 2004-06-01 02:52:14.0 +0200 +++ ifx.ec 2004-06-22 18:46:01.0 +0200 @@ -295,7 +295,6 @@ PARAMETER char *link; EXEC SQL END DECLARE SECTION; { - char *ifx_err = NULL; TSRMLS_FETCH(); EXEC SQL SET CONNECTION :link; @@ -310,32 +309,12 @@ if (ifx_check() == 0) { /* DISCONNECT again, after rollback */ EXEC SQL DISCONNECT :link; - if (ifx_check() < 0) { - IFXG(sv_sqlcode) = SQLCODE; - php_error_docref(NULL TSRMLS_CC, E_WARNING, "Disconnect link %s after Automatic Rollback fails (%s)", link, (ifx_err = ifx_error(link))); } - } - if (ifx_check() < 0) { + else if (ifx_check() < 0) { /* CLOSE database if rollback or disconnect fails */ EXEC SQL CLOSE DATABASE; - if (ifx_check() < 0) { - IFXG(sv_sqlcode) = SQLCODE; - php_error_docref(NULL TSRMLS_CC, E_WARNING, "Close database fails %s (%s)", link, (ifx_err = ifx_error(link))); - } } } - else if (SQLCODE < 0) { - IFXG(sv_sqlcode) = SQLCODE; - php_error_docref(NULL TSRMLS_CC, E_WARNING, "Disconnect link %s fails (%s)", link, (ifx_err = ifx_error(link))); - } - } - else { - IFXG(sv_sqlcode) = SQLCODE; - php_error_docref(NULL TSRMLS_CC, E_WARNING, "Set connection %s fails (%s)", link, (ifx_err = ifx_error(link))); - } - - if (ifx_err) { - efree(ifx_err); } } -- Edit bug report at http://bugs.php.net/?id=28883&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28883&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28883&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28883&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28883&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28883&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28883&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28883&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28883&r=support Expected behavior: http://bugs.php.net/fix.php?id=28883&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28883&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28883&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28883&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28883&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28883&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28883&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28883&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28883&r=float
#28568 [Bgs]: known_post_content_types is not thread safe
ID: 28568 User updated by: novicky at aarongroup dot cz Reported By: novicky at aarongroup dot cz Status: Bogus Bug Type: Reproducible crash Operating System: win32 PHP Version: 4.3.7RC1 New Comment: It does change at least in MBSTRING module where post handlers are being registered. We have debugged crash of PHP as IIS isapi module and there was a problem with different threads manipulates the same memory of known_post_content_types. Previous Comments: [2004-05-30 19:47:30] [EMAIL PROTECTED] It is safe because it does not actually change. [2004-05-29 15:07:41] novicky at aarongroup dot cz Description: Variable known_post_content_types used in SAPI.c is declared as static which is not thread safe and can lead to crash under multithread webservers like IIS. Here is a patch for SAPI.h and SAPI.c --- php-4.3.7RC1.orig/main/SAPI.h 2003-04-09 22:27:55.0 +0200 +++ php-4.3.7RC1/main/SAPI.h2004-05-26 10:08:34.0 +0200 @@ -120,6 +120,7 @@ long post_max_size; int options; zend_bool sapi_started; + HashTable known_post_content_types; } sapi_globals_struct; --- php-4.3.7RC1.orig/main/SAPI.c 2004-03-27 02:45:44.0 +0100 +++ php-4.3.7RC1/main/SAPI.c2004-05-29 14:34:47.0 +0200 @@ -48,7 +48,6 @@ #include "php_content_types.h" -static HashTable known_post_content_types; #ifdef ZTS SAPI_API int sapi_globals_id; @@ -59,6 +58,11 @@ static void sapi_globals_ctor(sapi_globals_struct *sapi_globals TSRMLS_DC) { memset(sapi_globals, 0, sizeof(*sapi_globals)); + zend_hash_init_ex(&SG(known_post_content_types), 5, NULL, NULL, 1, 0); +} + +static void sapi_globals_dtor(sapi_globals_struct *sapi_globals TSRMLS_DC) { + zend_hash_destroy(&SG(known_post_content_types)); } /* True globals (no need for thread safety) */ @@ -68,10 +72,9 @@ SAPI_API void sapi_startup(sapi_module_struct *sf) { sapi_module = *sf; - zend_hash_init_ex(&known_post_content_types, 5, NULL, NULL, 1, 0); #ifdef ZTS - ts_allocate_id(&sapi_globals_id, sizeof(sapi_globals_struct), (ts_allocate_ctor) sapi_globals_ctor, NULL); + ts_allocate_id(&sapi_globals_id, sizeof(sapi_globals_struct), (ts_allocate_ctor) sapi_globals_ctor, (ts_allocate_dtor)sapi_globals_dtor); #else sapi_globals_ctor(&sapi_globals TSRMLS_CC); #endif @@ -98,7 +101,6 @@ tsrm_win32_shutdown(); #endif - zend_hash_destroy(&known_post_content_types); } @@ -151,7 +153,7 @@ } /* now try to find an appropriate POST content handler */ - if (zend_hash_find(&known_post_content_types, content_type, content_type_length+1, (void **) &post_entry)==SUCCESS) { + if (zend_hash_find(&SG(known_post_content_types), content_type, content_type_length+1, (void **) &post_entry)==SUCCESS) { /* found one, register it for use */ SG(request_info).post_entry = post_entry; post_reader_func = post_entry->post_reader; @@ -795,12 +797,14 @@ SAPI_API int sapi_register_post_entry(sapi_post_entry *post_entry) { - return zend_hash_add(&known_post_content_types, post_entry->content_type, post_entry->content_type_len+1, (void *) post_entry, sizeof(sapi_post_entry), NULL); + TSRMLS_FETCH(); + return zend_hash_add(&SG(known_post_content_types), post_entry->content_type, post_entry->content_type_len+1, (void *) post_entry, sizeof(sapi_post_entry), NULL); } SAPI_API void sapi_unregister_post_entry(sapi_post_entry *post_entry) { - zend_hash_del(&known_post_content_types, post_entry->content_type, post_entry->content_type_len+1); + TSRMLS_FETCH(); + zend_hash_del(&SG(known_post_content_types), post_entry->content_type, post_entry->content_type_len+1); } -- Edit this bug report at http://bugs.php.net/?id=28568&edit=1
#28569 [NEW]: connection id is not thread safe, possible crash during module shutdown
From: novicky at aarongroup dot cz Operating system: all PHP version: 4.3.7RC1 PHP Bug Type: Informix related Bug description: connection id is not thread safe, possible crash during module shutdown Description: Identification strings used for connections, statements and descriptors are not thread safe. There is a possible mix-up of identifications under multithread webservers. There is a possible memory allocation during module shutdown in function ifx_do_close which can lead crash. Here is a patch for ifx.ec --- php-4.3.7RC1.orig/ext/informix/ifx.ec 2003-11-03 00:14:06.0 +0100 +++ php-4.3.7RC1/ext/informix/ifx.ec2004-05-29 18:14:16.0 +0200 @@ -297,30 +297,13 @@ if (ifx_check() == 0) { /* DISCONNECT again, after rollback */ EXEC SQL DISCONNECT :link; - if (ifx_check() < 0) { - IFXG(sv_sqlcode) = SQLCODE; - php_error_docref(NULL TSRMLS_CC, E_WARNING, "Disconnect link %s after Automatic Rollback fails (%s)", link, ifx_error(link)); - } } - if (ifx_check() < 0) { + else if (ifx_check() < 0) { /* CLOSE database if rollback or disconnect fails */ EXEC SQL CLOSE DATABASE; - if (ifx_check() < 0) { - IFXG(sv_sqlcode) = SQLCODE; - php_error_docref(NULL TSRMLS_CC, E_WARNING, "Close database fails %s (%s)", link, ifx_error(link)); - } - } - } - else if (SQLCODE < 0) { - IFXG(sv_sqlcode) = SQLCODE; - php_error_docref(NULL TSRMLS_CC, E_WARNING, "Disconnect link %s fails (%s)", link, ifx_error(link)); } } - else { - IFXG(sv_sqlcode) = SQLCODE; - php_error_docref(NULL TSRMLS_CC, E_WARNING, "Set connection %s fails (%s)", link, ifx_error(link)); } - } static void _close_ifx_link(zend_rsrc_list_entry *rsrc TSRMLS_DC) @@ -532,7 +515,11 @@ /* create the link */ ifx = (char *) malloc(sizeof(IFX)); IFXG(connectionid)++; +#ifdef ZTS + sprintf(ifx, "%s%x_%x", SAFE_STRING(user), tsrm_thread_id(), IFXG(connectionid)); +#else sprintf(ifx, "%s%x", SAFE_STRING(user), IFXG(connectionid)); +#endif EXEC SQL CONNECT TO :host AS :ifx USER :user USING :passwd WITH CONCURRENT TRANSACTION; @@ -629,7 +616,11 @@ ifx = (char *) emalloc(sizeof(IFX)); IFXG(connectionid)++; +#ifdef ZTS + sprintf(ifx, "connec%x_%x", tsrm_thread_id(), IFXG(connectionid)); +#else sprintf(ifx, "connec%x", IFXG(connectionid)); +#endif EXEC SQL CONNECT TO :host AS :ifx USER :user USING :passwd WITH CONCURRENT TRANSACTION; @@ -800,10 +791,17 @@ statement = Z_STRVAL_PP(query); IFXG(cursorid)++; +#ifdef ZTS + sprintf(statemid, "statem%x_%x", tsrm_thread_id(), IFXG(cursorid)); + sprintf(cursorid, "cursor%x_%x", tsrm_thread_id(), IFXG(cursorid)); + sprintf(descrpid, "descrp%x_%x", tsrm_thread_id(), IFXG(cursorid)); + sprintf(i_descrpid, "i_descrp%x_%x", tsrm_thread_id(), IFXG(cursorid)); +#else sprintf(statemid, "statem%x", IFXG(cursorid)); sprintf(cursorid, "cursor%x", IFXG(cursorid)); sprintf(descrpid, "descrp%x", IFXG(cursorid)); sprintf(i_descrpid, "i_descrp%x", IFXG(cursorid)); +#endif EXEC SQL set connection :ifx; PHP_IFX_CHECK_CONNECTION(ifx); @@ -1206,10 +1204,17 @@ statement = Z_STRVAL_PP(query); IFXG(cursorid)++; +#ifdef ZTS + sprintf(statemid, "statem%x_%x", tsrm_thread_id(), IFXG(cursorid)); + sprintf(cursorid, "cursor%x_%x", tsrm_thread_id(), IFXG(cursorid)); + sprintf(descrpid, "descrp%x_%x", tsrm_thread_id(), IFXG(cursorid)); + sprintf(i_descrpid, "i_descrp%x_%x", tsrm_thread_id(), IFXG(cursorid)); +#else sprintf(statemid, "statem%x", IFXG(cursorid)); sprintf(cursorid, "cursor%x", IFXG(cursorid)); sprintf(descrpid, "descrp%x", IFXG(cursorid)); sprintf(i_descrpid, "i_descrp%x", IFXG(cursorid)); +#endif EXEC SQL set con
#28568 [NEW]: known_post_content_types is not thread safe
From: novicky at aarongroup dot cz Operating system: win32 PHP version: 4.3.7RC1 PHP Bug Type: Reproducible crash Bug description: known_post_content_types is not thread safe Description: Variable known_post_content_types used in SAPI.c is declared as static which is not thread safe and can lead to crash under multithread webservers like IIS. Here is a patch for SAPI.h and SAPI.c --- php-4.3.7RC1.orig/main/SAPI.h 2003-04-09 22:27:55.0 +0200 +++ php-4.3.7RC1/main/SAPI.h2004-05-26 10:08:34.0 +0200 @@ -120,6 +120,7 @@ long post_max_size; int options; zend_bool sapi_started; + HashTable known_post_content_types; } sapi_globals_struct; --- php-4.3.7RC1.orig/main/SAPI.c 2004-03-27 02:45:44.0 +0100 +++ php-4.3.7RC1/main/SAPI.c2004-05-29 14:34:47.0 +0200 @@ -48,7 +48,6 @@ #include "php_content_types.h" -static HashTable known_post_content_types; #ifdef ZTS SAPI_API int sapi_globals_id; @@ -59,6 +58,11 @@ static void sapi_globals_ctor(sapi_globals_struct *sapi_globals TSRMLS_DC) { memset(sapi_globals, 0, sizeof(*sapi_globals)); + zend_hash_init_ex(&SG(known_post_content_types), 5, NULL, NULL, 1, 0); +} + +static void sapi_globals_dtor(sapi_globals_struct *sapi_globals TSRMLS_DC) { + zend_hash_destroy(&SG(known_post_content_types)); } /* True globals (no need for thread safety) */ @@ -68,10 +72,9 @@ SAPI_API void sapi_startup(sapi_module_struct *sf) { sapi_module = *sf; - zend_hash_init_ex(&known_post_content_types, 5, NULL, NULL, 1, 0); #ifdef ZTS - ts_allocate_id(&sapi_globals_id, sizeof(sapi_globals_struct), (ts_allocate_ctor) sapi_globals_ctor, NULL); + ts_allocate_id(&sapi_globals_id, sizeof(sapi_globals_struct), (ts_allocate_ctor) sapi_globals_ctor, (ts_allocate_dtor)sapi_globals_dtor); #else sapi_globals_ctor(&sapi_globals TSRMLS_CC); #endif @@ -98,7 +101,6 @@ tsrm_win32_shutdown(); #endif - zend_hash_destroy(&known_post_content_types); } @@ -151,7 +153,7 @@ } /* now try to find an appropriate POST content handler */ - if (zend_hash_find(&known_post_content_types, content_type, content_type_length+1, (void **) &post_entry)==SUCCESS) { + if (zend_hash_find(&SG(known_post_content_types), content_type, content_type_length+1, (void **) &post_entry)==SUCCESS) { /* found one, register it for use */ SG(request_info).post_entry = post_entry; post_reader_func = post_entry->post_reader; @@ -795,12 +797,14 @@ SAPI_API int sapi_register_post_entry(sapi_post_entry *post_entry) { - return zend_hash_add(&known_post_content_types, post_entry->content_type, post_entry->content_type_len+1, (void *) post_entry, sizeof(sapi_post_entry), NULL); + TSRMLS_FETCH(); + return zend_hash_add(&SG(known_post_content_types), post_entry->content_type, post_entry->content_type_len+1, (void *) post_entry, sizeof(sapi_post_entry), NULL); } SAPI_API void sapi_unregister_post_entry(sapi_post_entry *post_entry) { - zend_hash_del(&known_post_content_types, post_entry->content_type, post_entry->content_type_len+1); + TSRMLS_FETCH(); + zend_hash_del(&SG(known_post_content_types), post_entry->content_type, post_entry->content_type_len+1); } -- Edit bug report at http://bugs.php.net/?id=28568&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28568&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28568&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28568&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28568&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28568&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28568&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28568&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28568&r=support Expected behavior: http://bugs.php.net/fix.php?id=28568&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28568&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28568&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28568&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28568&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28568&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28568&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28568&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28568&r=float
#28317 [NEW]: stack overflow
From: novicky at aarongroup dot cz Operating system: win32 PHP version: 4.3.6 PHP Bug Type: PCRE related Bug description: stack overflow Description: Stack overflow during preg_match() on complex regular expressions used for long data. As written in pcre.c ... /*** RECURSION IN THE match() FUNCTION The match() function is highly recursive. Some regular expressions can cause it to recurse thousands of times. I was writing for Unix, so I just let it call itself recursively. This uses the stack for saving everything that has to be saved for a recursive call. On Unix, the stack can be large, and this works fine. It turns out that on non-Unix systems there are problems with programs that use a lot of stack. (This despite the fact that every last chip has oodles of memory these days, and techniques for extending the stack have been known for decades.) So There is a fudge, triggered by defining NO_RECURSE, which avoids recursive calls by keeping local variables that need to be preserved in blocks of memory obtained from malloc instead instead of on the stack. Macros are used to achieve this so that the actual code doesn't look very different to what it always used to. ***/ Thus NO_RECURSE should be set in win32 compiler oprions. -- Edit bug report at http://bugs.php.net/?id=28317&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28317&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28317&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28317&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28317&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28317&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28317&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28317&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28317&r=support Expected behavior: http://bugs.php.net/fix.php?id=28317&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28317&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28317&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28317&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28317&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28317&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28317&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28317&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28317&r=float
#27037 [Fbk->Opn]: readfile() segfaults on certain files
ID: 27037 User updated by: novicky at aarongroup dot cz Reported By: novicky at aarongroup dot cz -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: linux PHP Version: 4.3.4 New Comment: Exactly the same behavior using last CVS snapshot, see backtrace. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 8192 (LWP 22165)] 0x4207c46c in memcpy () from /lib/i686/libc.so.6 (gdb) bt #0 0x4207c46c in memcpy () from /lib/i686/libc.so.6 #1 0x403bbc58 in apr_pmemdup (a=0x40896000, m=0x4000, n=136452109) at apr_strings.c:157 #2 0x405c9280 in php_apache_sapi_ub_write (str=0x40896000 'x' ..., str_length=16384) at /tmp/php/php4-STABLE-200401271430/sapi/apache2handler/sapi_apache2.c:84 #3 0x405a0df0 in php_ub_body_write_no_header (str=0x40896000 'x' ..., str_length=16384) at /tmp/php/php4-STABLE-200401271430/main/output.c:689 #4 0x405a0e77 in php_ub_body_write (str=0x40896000 'x' ..., str_length=16384) at /tmp/php/php4-STABLE-200401271430/main/output.c:719 #5 0x4059fe51 in php_body_write (str=0x40896000 'x' ..., str_length=16384) at /tmp/php/php4-STABLE-200401271430/main/output.c:121 #6 0x4059c57a in _php_stream_passthru (stream=0x821ce4c) at /tmp/php/php4-STABLE-200401271430/main/streams.c:1092 #7 0x4053f3e9 in zif_readfile (ht=16385, return_value=0x821ce2c, this_ptr=0x0, return_value_used=0) at /tmp/php/php4-STABLE-200401271430/ext/standard/file.c:1829 #8 0x405c5636 in execute (op_array=0x8218414) at /tmp/php/php4-STABLE-200401271430/Zend/zend_execute.c:1616 #9 0x405b8d35 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /tmp/php/php4-STABLE-200401271430/Zend/zend.c:884 #10 0x40592edf in php_execute_script (primary_file=0xb690) at /tmp/php/php4-STABLE-200401271430/main/main.c:1727 #11 0x405c9e27 in php_handler (r=0x820a118) at /tmp/php/php4-STABLE-200401271430/sapi/apache2handler/sapi_apache2.c:536 #12 0x08098c1e in ap_run_handler (r=0x820a118) at config.c:195 #13 0x08099136 in ap_invoke_handler (r=0x820a118) at config.c:401 #14 0x080829d7 in ap_process_request (r=0x820a118) at http_request.c:288 #15 0x0807ebc1 in ap_process_http_connection (c=0x8203a28) at http_core.c:293 #16 0x080a1daa in ap_run_process_connection (c=0x8203a28) at connection.c:85 #17 0x080977c3 in child_main (child_num_arg=16385) at prefork.c:694 #18 0x0809796e in make_child (s=0x810bca0, slot=0) at prefork.c:734 #19 0x080979c7 in startup_children (number_to_start=5) at prefork.c:806 #20 0x080980b9 in ap_mpm_run (_pconf=0x80970ac, plog=0x81183f8, s=0x810bca0) at prefork.c:1022 #21 0x0809cf56 in main (argc=2, argv=0xb9e4) at main.c:660 #22 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 Previous Comments: [2004-01-26 19:54:03] [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 I think this was fixed already? -------- [2004-01-26 07:10:59] novicky at aarongroup dot cz Works fine with Apache1. I reported this problem as Apache2 related. [2004-01-25 15:25:57] [EMAIL PROTECTED] Please try with apache 1. Apache 2 itself is not stable. -------- [2004-01-25 10:59:22] novicky at aarongroup dot cz Description: Still the same problem as described in suspended bugs #26846 and #24301. Segmentation fault occures when sending files of length 4k*n (where n can be 4-6,8-30) via readfile(). System: linux RH 8.0 apache 2.0.48 php 4.3.4 Backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 8192 (LWP 8803)] 0x4207c46c in memcpy () from /lib/i686/libc.so.6 (gdb) bt #0 0x4207c46c in memcpy () from /lib/i686/libc.so.6 #1 0x403bbc58 in apr_pmemdup (a=0x40895000, m=0x4000, n=136459925) at apr_strings.c:157 #2 0x405c8170 in php_apache_sapi_ub_write (str=0x40895000 'x' ..., str_length=16384) at /home/linux/php/php-4.3.4/sapi/apache2handler/sapi_apache2.c:84 #3 0x4059fdf0 in php_ub_body_write_no_header (str=0x40895000 'x' ..., str_length=16384) at /home/linux/php/php-4.3.4/main/output.c:689 #4 0x4059fe77 in php_ub_body_write (str=0x40895000 'x' ..., str_length=16384) at /home/linux/php/php-4.3.4/main/output.c:719 #5 0x4059ee51 in php_body_write (str=0x40895000 'x' ..., str_length=16384) at /home/linux/php/php-4.3.4/main/output.c:121 #6 0x4059b612 in _php_stream_passthru (stream=0x821ecd4) at /home/linux/php/php-4.3.4/main/streams.c:1088 #7 0x4053ea5d in zif_readfile (ht=16385, return_value=0x821ecb4, this_ptr=0x0, return_value_used=0) at /home/
#27037 [Fbk->Opn]: readfile() segfaults on certain files
ID: 27037 User updated by: novicky at aarongroup dot cz Reported By: novicky at aarongroup dot cz -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: linux PHP Version: 4.3.4 New Comment: Works fine with Apache1. I reported this problem as Apache2 related. Previous Comments: [2004-01-25 15:25:57] [EMAIL PROTECTED] Please try with apache 1. Apache 2 itself is not stable. [2004-01-25 10:59:22] novicky at aarongroup dot cz Description: Still the same problem as described in suspended bugs #26846 and #24301. Segmentation fault occures when sending files of length 4k*n (where n can be 4-6,8-30) via readfile(). System: linux RH 8.0 apache 2.0.48 php 4.3.4 Backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 8192 (LWP 8803)] 0x4207c46c in memcpy () from /lib/i686/libc.so.6 (gdb) bt #0 0x4207c46c in memcpy () from /lib/i686/libc.so.6 #1 0x403bbc58 in apr_pmemdup (a=0x40895000, m=0x4000, n=136459925) at apr_strings.c:157 #2 0x405c8170 in php_apache_sapi_ub_write (str=0x40895000 'x' ..., str_length=16384) at /home/linux/php/php-4.3.4/sapi/apache2handler/sapi_apache2.c:84 #3 0x4059fdf0 in php_ub_body_write_no_header (str=0x40895000 'x' ..., str_length=16384) at /home/linux/php/php-4.3.4/main/output.c:689 #4 0x4059fe77 in php_ub_body_write (str=0x40895000 'x' ..., str_length=16384) at /home/linux/php/php-4.3.4/main/output.c:719 #5 0x4059ee51 in php_body_write (str=0x40895000 'x' ..., str_length=16384) at /home/linux/php/php-4.3.4/main/output.c:121 #6 0x4059b612 in _php_stream_passthru (stream=0x821ecd4) at /home/linux/php/php-4.3.4/main/streams.c:1088 #7 0x4053ea5d in zif_readfile (ht=16385, return_value=0x821ecb4, this_ptr=0x0, return_value_used=0) at /home/linux/php/php-4.3.4/ext/standard/file.c:1817 #8 0x405c4542 in execute (op_array=0x821a2ac) at /home/linux/php/php-4.3.4/Zend/zend_execute.c:1616 #9 0x405b7c41 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/linux/php/php-4.3.4/Zend/zend.c:884 #10 0x40592253 in php_execute_script (primary_file=0xb6a0) at /home/linux/php/php-4.3.4/main/main.c:1729 #11 0x405c8d2b in php_handler (r=0x820bfb8) at /home/linux/php/php-4.3.4/sapi/apache2handler/sapi_apache2.c:537 #12 0x08098c1e in ap_run_handler (r=0x820bfb8) at config.c:195 #13 0x08099136 in ap_invoke_handler (r=0x820bfb8) at config.c:401 #14 0x080829d7 in ap_process_request (r=0x820bfb8) at http_request.c:288 #15 0x0807ebc1 in ap_process_http_connection (c=0x8205860) at http_core.c:293 #16 0x080a1daa in ap_run_process_connection (c=0x8205860) at connection.c:85 #17 0x080977c3 in child_main (child_num_arg=16385) at prefork.c:694 #18 0x0809796e in make_child (s=0x810bca0, slot=0) at prefork.c:734 #19 0x080979c7 in startup_children (number_to_start=5) at prefork.c:806 #20 0x080980b9 in ap_mpm_run (_pconf=0x80970ac, plog=0x81183f8, s=0x810bca0) at prefork.c:1022 #21 0x0809cf56 in main (argc=2, argv=0xb9f4) at main.c:660 #22 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 Reproduce code: --- -- Edit this bug report at http://bugs.php.net/?id=27037&edit=1
#27037 [NEW]: readfile() segfaults on certain files
From: novicky at aarongroup dot cz Operating system: linux PHP version: 4.3.4 PHP Bug Type: Apache2 related Bug description: readfile() segfaults on certain files Description: Still the same problem as described in suspended bugs #26846 and #24301. Segmentation fault occures when sending files of length 4k*n (where n can be 4-6,8-30) via readfile(). System: linux RH 8.0 apache 2.0.48 php 4.3.4 Backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 8192 (LWP 8803)] 0x4207c46c in memcpy () from /lib/i686/libc.so.6 (gdb) bt #0 0x4207c46c in memcpy () from /lib/i686/libc.so.6 #1 0x403bbc58 in apr_pmemdup (a=0x40895000, m=0x4000, n=136459925) at apr_strings.c:157 #2 0x405c8170 in php_apache_sapi_ub_write (str=0x40895000 'x' ..., str_length=16384) at /home/linux/php/php-4.3.4/sapi/apache2handler/sapi_apache2.c:84 #3 0x4059fdf0 in php_ub_body_write_no_header (str=0x40895000 'x' ..., str_length=16384) at /home/linux/php/php-4.3.4/main/output.c:689 #4 0x4059fe77 in php_ub_body_write (str=0x40895000 'x' ..., str_length=16384) at /home/linux/php/php-4.3.4/main/output.c:719 #5 0x4059ee51 in php_body_write (str=0x40895000 'x' ..., str_length=16384) at /home/linux/php/php-4.3.4/main/output.c:121 #6 0x4059b612 in _php_stream_passthru (stream=0x821ecd4) at /home/linux/php/php-4.3.4/main/streams.c:1088 #7 0x4053ea5d in zif_readfile (ht=16385, return_value=0x821ecb4, this_ptr=0x0, return_value_used=0) at /home/linux/php/php-4.3.4/ext/standard/file.c:1817 #8 0x405c4542 in execute (op_array=0x821a2ac) at /home/linux/php/php-4.3.4/Zend/zend_execute.c:1616 #9 0x405b7c41 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/linux/php/php-4.3.4/Zend/zend.c:884 #10 0x40592253 in php_execute_script (primary_file=0xb6a0) at /home/linux/php/php-4.3.4/main/main.c:1729 #11 0x405c8d2b in php_handler (r=0x820bfb8) at /home/linux/php/php-4.3.4/sapi/apache2handler/sapi_apache2.c:537 #12 0x08098c1e in ap_run_handler (r=0x820bfb8) at config.c:195 #13 0x08099136 in ap_invoke_handler (r=0x820bfb8) at config.c:401 #14 0x080829d7 in ap_process_request (r=0x820bfb8) at http_request.c:288 #15 0x0807ebc1 in ap_process_http_connection (c=0x8205860) at http_core.c:293 #16 0x080a1daa in ap_run_process_connection (c=0x8205860) at connection.c:85 #17 0x080977c3 in child_main (child_num_arg=16385) at prefork.c:694 #18 0x0809796e in make_child (s=0x810bca0, slot=0) at prefork.c:734 #19 0x080979c7 in startup_children (number_to_start=5) at prefork.c:806 #20 0x080980b9 in ap_mpm_run (_pconf=0x80970ac, plog=0x81183f8, s=0x810bca0) at prefork.c:1022 #21 0x0809cf56 in main (argc=2, argv=0xb9f4) at main.c:660 #22 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 Reproduce code: --- -- Edit bug report at http://bugs.php.net/?id=27037&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27037&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27037&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27037&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27037&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27037&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27037&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27037&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27037&r=support Expected behavior: http://bugs.php.net/fix.php?id=27037&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27037&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27037&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27037&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27037&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27037&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27037&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27037&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27037&r=float
#24047 [NEW]: xmlrpc_decode() does not decode NULL values in SOAP 1.1
From: novicky at aarongroup dot cz Operating system: any PHP version: 4.3.2 PHP Bug Type: XMLRPC-EPI related Bug description: xmlrpc_decode() does not decode NULL values in SOAP 1.1 The function xmlrpc_decode() does not decode properly NULL values in SOAP 1.1 at the first level. The following example var_dump(xmlrpc_decode(xmlrpc_encode_request('method', array(array(NULL)), array('version'=>'soap 1.1'; will produce array(1) { [0]=> array(1) { [0]=> NULL } } which is correct, but when NULL value is used at the first level of array like in the following example, the answer is incorrect var_dump(xmlrpc_decode(xmlrpc_encode_request('method', array(NULL), array('version'=>'soap 1.1'; will produce array(1) { ["xsi:null"]=> string(0) "" } -- Edit bug report at http://bugs.php.net/?id=24047&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24047&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24047&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24047&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24047&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24047&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24047&r=support Expected behavior: http://bugs.php.net/fix.php?id=24047&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24047&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24047&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24047&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24047&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24047&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24047&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24047&r=gnused