Fix life time of FFI CData and FFI CType with FFI\CDef

[nielsdos]

For GH-8556 the return type is stored in the CDef and doesn't outlive the CData. In that case it happened because temporaries were used, but it's also possible to get this with compiled variables when the variable holding the CDef leaves the scope.

For GH-12910 the exception trace is built after the compiled variables are destroyed, so that means the FFI CDef instance got destroyed but the CData argument still remained. When the trace building code tries to get the class string for the exception, the CData instance tries to access the already-freed CDef.

Fix all of this by storing a reference to the CDef object inside of CData and CType.

Closes GH-8556.
Closes GH-12910.

This is an alternative for #10574 that fixes the issue more efficiently and more generally.

[dstogov]

I don't like this new FFI\CDef dependency especially for CData.
This looks like an attempt to manage, unmanaged C data.
And FFI anyway provides another hundred ways to short into the lag.

I'll need to think about this. I'll return to the PR a bit later.

Any arguments are welcome.

[nielsdos]

Thanks for taking a look.

I agree that FFI provides many ways to crash PHP, but those usually involve pointers or library calls. And I agree we can't do anything about that as it's the users' responsibility. That is indeed unmanaged data.

The cases that this PR tries to solve are different: they are for problems with types being freed.
These types look and behave like PHP objects, so it causing a use-after-free is surprising because it seems like managed data. This is especially confusing when the CDef is used as a temporary: it is difficult to explain to the user why the behaviour is different than from using a CV. Even if we don't end up fixing this, we should at least in my opinion fix #12910 because otherwise debugging becomes more difficult for users (crash instead of exception).

I think we should avoid use-after-frees for types: users will have a hard time figuring out what goes wrong because use-after-frees often lead to random crashes later.

I think this approach is simpler and more efficient than remembering the types like I did in my previous attempt.

[dstogov]

I think this approach is simpler and more efficient than remembering the types like I did in my previous attempt.

I agree, that we should try to solve this, especially for types and may be your approach is good enough, but I remember, FFI already had some mechanism for dallying type destruction. I should find time, to look into the problem more careful.

The main thing that I didn't like from the first look, was the FFI\CDef dependency for CData, but this also needs a more careful review.

[dstogov]

I didn't completely get the reason for CData->ffi and all the related code.
Do you maintain it just to pass the proper ffi value to zend_ffi_ctype_new_ex()?

I think this should be fixed in a different way.
ZEND_METHOD(FFI, cdef) should remember CDef related types at first place and keep them until the end of request.

In #10574 you tried to do this delaying store, by resetting ZEND_FFI_ATTR_STORED.
I think, we don't need this delay and should remember types immediately.
What do you think?
Can you try this?