Re: Question regarding zend's _efree implementation

At 16:22 19/07/2001, Holger Zimmermann wrote:

Hi, I don't understand the purpose of the following code in zend_alloc.c: 8< snip ZEND_API void _efree(void *ptr ZEND_FILE_LINE_DC ZEND_FILE_LINE_ORIG_DC) {

        zend_mem_header *p = (zend_mem_header *) ((char *)ptr - sizeof(zend_mem_header) - PLATFORM_PADDING);
        DECLARE_CACHE_VARS
        ALS_FETCH();

#if defined(ZTS) && ZEND_DEBUG

        if (p->thread_id != tsrm_thread_id()) {
                printf("efree!!!!\n");
                tsrm_error(TSRM_ERROR_LEVEL_ERROR, "Memory block allocated at %s:(%d) on thread %x freed at %s:(%d) on thread %x,

ignoring",

                        p->filename, p->lineno, p->thread_id,
                        __zend_filename, __zend_lineno, tsrm_thread_id());
                return;
        }

#endif 8 snap I'm a bit confused about the difference between debug and release builds, if the thread calling _efree is different from the thread which allocated the resource. The real free stuff follows after the above code snippet, thus in debug mode nothing is freed but in release builds everything is going its normal way, regardless of this thread issue. I looked for a reproducable Win32 crash in php4ts.dll (4.04, 4.05, 4.06) on shutdown with Pi3Web server, which appears only in release builds. The reason for the differen behaviour is the above code, because in Pi3Web the thread, which cleans up a module is not the same as the startup thread. Ok, I patched the code a bit and can now reproduce the crash in debug build too. So I was finally able to find the reason in the shutdown code of the bcmath module, but this is subject of another discussion. Any ideas regarding the above issue? I would recommend a consitent behaviour regardless of the ZEND_DEBUG setting.

Release build assumes no bugs, and thus doesn't try to help you to solve bugs, and favours performance. In release builds, we don't perform slow checking of every memory block. If an invalid block was passed - it'd cause a crash (most probably). In debug builds, which can be slower, we favour stronger debugging capabilities to performance, so we do perform these checks. Zeev