And if you disable DeepTrace can you reproduce this? The memory management is 
obviously not completely buggy as it works fine for a whole lot of people and as 
your Valgrind shows right at the top:

==3187== Invalid read of size 1
==3187==    at 0x8E25081: zif_dt_remove_constant (DeepTrace_constants.c:74)

there are memory issues in the DeepTrace extension, so I suspect that DeepTrace 
has not been updated to support 5.4 properly.

These problems also occured with DeepTrace 1.2, which was completely free of any 
leaks or memory issues. 1.3 is a complete recode which mainly adds some features 
to remove interfaces. I know the developer of DeepTrace and I was working with him 
to track down and fix all memory issues. Pancake will also run with DeepTrace 1.2 
but typo3 probably won't work because it uses interfaces, which were not supported 
in 1.2. Also, it is quite impossible to run Pancake without DeepTrace as it is 
really necessary to replace some PHP-functions in order to be able to directly run 
PHP-source under Pancake.

Ok, so you can't test without DeepTrace, I understand that. But that doesn't make 
it any less likely that the problem is in that extension. It does a lot of low-
level stuff and there were a lot of changes related to memory management in 5.4 
that would affect an extension like DeepTrace. I see no evidence here that there 
is a PHP bug.

I'm the developer of this extension and I tested 
already many different things. Every function 
runs through without any problem and I can't 
see any issues so far.  I already tried different 
things like repairing all the internal functions, 
setting the opcode handlers to NULL (eq. default 
handler) or destroying some hashtables by 
myself.  Actually it is impossible to reproduce 
this "bug", it happens randomly and I can't see 
any kind of critical memory leak. Because of 
that and the fact that these simple changes in 
code (see above) will fix the crash, I think it is 
Zend related

Well, without a concrete example that doesn't involve DeepTrace messing around in 
the internals I don't see how we could possibly track this down. Nothing remotely 
like it has been reported so far.

A quick check of the DeepTrace code that deletes constants shows a pretty 
obvious bug. In DeepTrace_constants.c you have:

        // Get constant
        if(zend_hash_find(EG(zend_constants), constName, len + 1, (void**) 
&constant) == FAILURE) {

Ok, so *constant now points to the constant named constName. Then later on:

        // Delete constant
        if(zend_hash_del(EG(zend_constants), constName, len + 1) == FAILURE) {
                php_error_docref(NULL TSRMLS_CC, E_WARNING, "Could not remove 
constant %s.", constName);
                if((constant->flags & CONST_CS) == 0) efree(constName);
                RETURN_FALSE;
        }

Ok, you have deleted the constant from the hash table which means constant now 
points to free'ed memory. But on the next line you do:

        // Free memory
        if((constant->flags & CONST_CS) == 0) efree(constName);

You can't look at constant->flags there, it has been free'ed.

Probably not related to these particular issues, although it did show up in your 
Valgrind output there, but a sign to me that this code needs a bit more 
attention.