#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
