I'm releasing an extended PHP logging extension that we currently use at facebook with much success. I currently use a small patch to determine if a memory overflow has occurred as there's currently no direct access into the allocator structures. You can get more information on the project at http://tekrat.com/php/xlog/.
It would be useful if this patch (and perhaps more accessors into the memory allocator) where added. Although I understand there should be some careful choices and limitations here, and this case is a pretty specific use case, but I thought I'd share it in case there are others who happen to find this useful as well or perhaps someone can propose a more general alternative.
Patches for different branches are here (I've pasted php53 below):
http://tekrat.com/downloads/bits/zend_mm_heap_overflow.php6.patch
http://tekrat.com/downloads/bits/zend_mm_heap_overflow.php53.patch
http://tekrat.com/downloads/bits/zend_mm_heap_overflow.php52.patch
diff --git a/ZendEngine2/zend_alloc.c b/ZendEngine2/zend_alloc.c
index 8853d06..b8884a0 100644
--- a/ZendEngine2/zend_alloc.c
+++ b/ZendEngine2/zend_alloc.c
@@ -2537,6 +2537,13 @@ ZEND_API void start_memory_manager(TSRMLS_D)
#endif
}
+/*** BEGIN Patch: zend_mm_heap_overflow ***/
+ZEND_API int zend_mm_heap_overflow(TSRMLS_D)
+{
-
return AG(mm_heap)->overflow;
+}
+/*** END Patch: zend_mm_heap_overflow ***/ -
ZEND_API zend_mm_heap *zend_mm_set_heap(zend_mm_heap *new_heap TSRMLS_DC)
{
zend_mm_heap *old_heap;
diff --git a/ZendEngine2/zend_alloc.h b/ZendEngine2/zend_alloc.h
index d92df4b..3610931 100644
--- a/ZendEngine2/zend_alloc.h
+++ b/ZendEngine2/zend_alloc.h
@@ -231,6 +231,7 @@ struct _zend_mm_storage {
};ZEND_API zend_mm_heap *zend_mm_startup_ex(const zend_mm_mem_handlers *handlers, size_t block_size, size_t reserve_size, int internal, void params);
+ZEND_API int zend_mm_heap_overflow(TSRMLS_D); / Patch: zend_mm_heap_overflow */
ZEND_API zend_mm_heap *zend_mm_set_heap(zend_mm_heap *new_heap TSRMLS_DC);
ZEND_API zend_mm_storage *zend_mm_get_storage(zend_mm_heap *heap);
-shire
Shire,
Xlog looks really useful. Does it also help with "exception thrown
without a stack trace"?
Thanks,
John.
-----Original Message-----
From: shire [mailto:shire@tekrat.com]
Sent: 19 January 2009 01:45
To: PHP Internals List
Subject: [PHP-DEV] PATCH: zend_mm_heap_overflow()
I'm releasing an extended PHP logging extension that we currently use at
facebook with much success. I currently use a small patch to determine
if a memory overflow has occurred as there's currently no direct access
into the allocator structures. You can get more information on the
project at http://tekrat.com/php/xlog/.
It would be useful if this patch (and perhaps more accessors into the
memory allocator) where added. Although I understand there should be
some careful choices and limitations here, and this case is a pretty
specific use case, but I thought I'd share it in case there are others
who happen to find this useful as well or perhaps someone can propose a
more general alternative.
Patches for different branches are here (I've pasted php53 below):
http://tekrat.com/downloads/bits/zend_mm_heap_overflow.php6.patch
http://tekrat.com/downloads/bits/zend_mm_heap_overflow.php53.patch
http://tekrat.com/downloads/bits/zend_mm_heap_overflow.php52.patch
diff --git a/ZendEngine2/zend_alloc.c b/ZendEngine2/zend_alloc.c index
8853d06..b8884a0 100644
--- a/ZendEngine2/zend_alloc.c
+++ b/ZendEngine2/zend_alloc.c
@@ -2537,6 +2537,13 @@ ZEND_API void start_memory_manager(TSRMLS_D)
#endif
}
+/*** BEGIN Patch: zend_mm_heap_overflow ***/ ZEND_API int
+zend_mm_heap_overflow(TSRMLS_D) {
-
return AG(mm_heap)->overflow;
+}
+/*** END Patch: zend_mm_heap_overflow ***/ -
ZEND_API zend_mm_heap *zend_mm_set_heap(zend_mm_heap *new_heap
TSRMLS_DC)
{
zend_mm_heap *old_heap;
diff --git a/ZendEngine2/zend_alloc.h b/ZendEngine2/zend_alloc.h index
d92df4b..3610931 100644
--- a/ZendEngine2/zend_alloc.h
+++ b/ZendEngine2/zend_alloc.h
@@ -231,6 +231,7 @@ struct _zend_mm_storage {
};ZEND_API zend_mm_heap *zend_mm_startup_ex(const zend_mm_mem_handlers
*handlers, size_t block_size, size_t reserve_size, int internal, void
params);
+ZEND_API int zend_mm_heap_overflow(TSRMLS_D); / Patch:
+zend_mm_heap_overflow */
ZEND_API zend_mm_heap *zend_mm_set_heap(zend_mm_heap *new_heap
TSRMLS_DC);
ZEND_API zend_mm_storage *zend_mm_get_storage(zend_mm_heap *heap);
-shire
--
To unsubscribe,
visit: http://www.php.net/unsub.php
John Carter -X (johncart - PolicyApp Ltd at Cisco) wrote:
Shire,
Xlog looks really useful. Does it also help with "exception thrown
without a stack trace"?
Thanks John,
I was just made aware that xdebug has similar functionality with a little bit different approach, config, etc so do check it out as well to see which meets your needs best. I'm sorry that I wasn't aware of it's fatal catching capabilities before.
It depends on what you want to get from "Exception thrown without a stack frame" (I assume this is the error you meant not, stack trace). There is no backtrace information available when this error occurs so nothing is going to get you a backtrace that i know of, however if there's some specific piece of data you'd like to have in the logs perhaps I can check to see if that's a possibility. However in some states of the engine, getting anything useful can often be diffucult or unstable.
-shire
Hi!
I'm releasing an extended PHP logging extension that we currently use at
facebook with much success. I currently use a small patch to determine
if a memory overflow has occurred as there's currently no direct access
into the allocator structures. You can get more information on the
project at http://tekrat.com/php/xlog/.
Maybe just make AG() exported?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev wrote:
Hi!
I'm releasing an extended PHP logging extension that we currently use
at facebook with much success. I currently use a small patch to
determine if a memory overflow has occurred as there's currently no
direct access into the allocator structures. You can get more
information on the project at http://tekrat.com/php/xlog/.Maybe just make AG() exported?
Yes, I like this idea better as it's more flexible but I wasn't sure if we wanted that much visibility into the global variables of the allocator. I suppose though, as with other things of this nature, if you're mucking with this data then you should be doing so at your own risk etc. ;-)
-shire
Hi!
Yes, I like this idea better as it's more flexible but I wasn't sure if
we wanted that much visibility into the global variables of the
allocator. I suppose though, as with other things of this nature, if
you're mucking with this data then you should be doing so at your own
risk etc. ;-)
Well, messing up AG is not worse than messing up EG or CG - you'll end
up crashing pretty soon anyway :) Only problem might be that it may
introduce binary dependencies that will limit what we can do in memory
manager between versions, so we need to consider this carefully.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev wrote:
Hi!
Yes, I like this idea better as it's more flexible but I wasn't sure
if we wanted that much visibility into the global variables of the
allocator. I suppose though, as with other things of this nature, if
you're mucking with this data then you should be doing so at your own
risk etc. ;-)Well, messing up AG is not worse than messing up EG or CG - you'll end
up crashing pretty soon anyway :) Only problem might be that it may
introduce binary dependencies that will limit what we can do in memory
manager between versions, so we need to consider this carefully.
Yeah, definitely makes sense. I'm also going on the assumption that this might be useful at some point later on, rather than my single use case. Of course if it isn't then we don't have to worry about binary compatibility either lol.
I hadn't considered creating a hybrid approach to this, perhaps that might be a good alternative. Rather than exposing the entire structure or creating one-off access functions (which has it's own BC issues), perhaps we should expose a new structure that is just a portion of the existing heap structure so we can expose only those items that we're willing to support. This won't fix everything, but at least it might mitigate problems associated with opening up the entire existing heap structure and allow some flexibility with BC if it does change.
If it's interesting to everyone and saves you some time I can work up a patch so we can see what that might look like too.
Thanks!
-shire