FAQ
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

Search Discussions

  • John Carter -X (johncart - PolicyApp Ltd at Cisco) at Jan 19, 2009 at 9:33 am
    Shire,

    Xlog looks really useful. Does it also help with "exception thrown
    without a stack trace"?

    Thanks,

    John.

    -----Original Message-----
    From: shire
    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

    --
    PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
    visit: http://www.php.net/unsub.php
  • Shire at Jan 19, 2009 at 9:05 pm

    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
  • Stanislav Malyshev at Jan 19, 2009 at 6:22 pm
    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
  • Shire at Jan 19, 2009 at 9:07 pm

    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
  • Stanislav Malyshev at Jan 19, 2009 at 9:43 pm
    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
  • Shire at Jan 19, 2009 at 11:07 pm

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedJan 19, '09 at 1:45a
activeJan 19, '09 at 11:07p
posts7
users3
websitephp.net

People

Translate

site design / logo © 2022 Grokbase