So that means that all the zval * I store in my map simply point to
invalid memory once the request is completed? Well, that would explain
some of the strange behaviour I have observed (such as string changing
content between requests).
Yep.
The solution to this would be to allocate the
zval struct using pemalloc and allocate memory for the data the zval
(whatever type it is) uses with pemalloc as well?
When you get the zval* in your strore_var_in_map() function it's non-persistent. You need to copy all of its data (and dependent data) into persistent storage when you store it in your map. Then when you take it out of map to return it back to userspace (possibly in another request), you need to copy it again to place it in non-persistent storage.
As far as I can tell, the APC extension doesn't use pemalloc but rather
malloc. Furthermore, pemalloc simply seems to be a macro which uses
malloc to allocate memory. This means that my memory allocations using
c++ new should allocate persistent memory chunks.
That's correct. It's not allocating the persistent memory chunks that's hard, it's duplicating a generic zval (in all the various forms that a zval can take) that's tricky (particularly in the case of IS_OBJECT and IS_RESOURCE).
S the persistent/non-persistent memory issue doesn't explain why my std::map
simply is empty. The fact that it contain zval pointers pointing to
invalid memory I understand but I don't get why it gets emptied. Any ideas?
Post the code you have so far. I'm working with a pretty limited pinhole view here....