-
Notifications
You must be signed in to change notification settings - Fork 15.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PHP Extension - Segmentation fault if message constructor is not called. #19978
Comments
Can you clarify in your In practice if the C But it seems more likely that |
It is triggered by the getter / setter. when the I believe with the proxy extending the I think in the PHP implementation the behaviour is different BC that never triggers any code relies on the descriptor / descriptor pool. But Perhaps the issue here is how the But that is not the case any time the message is extended. Perhaps it needs a fallback.. something like this : zval* Message_write_property(zend_object* obj, zend_string* member, zval* val, void** cache_slot) {
const upb_FieldDef* f = try_lookup_field(obj, member);
// If the field belongs to the message, set it.
if (f) {
if (Message_set(obj, f, val)) {
return val;
}
return &EG(error_zval);
}
// If not delegate to the standard write_property handler.
return zend_std_write_property(obj, member, val, cache_slot);
} |
Ah, I understand now. We definitely would not want it to be designed to silently fallback to PHP properties if it can't be stored properly; the point of protobuf is to create objects that will be serialized, and any time that path would be reached outside of exactly this weird mocking case it would likely imply a severe production-impacting bug where the user tried to set something and it silently didn't actually affecting the content that will go over the wire. I think we'd view that as a path where we intentionally made data corruption/data loss be a silently and hard-to-observe behavior. I would have to think about this a bit, but I think realistically the resolution from our side for this is less likely to actually support the behavior and instead be more like having it consistently throw a PHP exception rather than segfault. Do you feel like this pattern (subclassing and preventing ctor) is actually so common in PHP frameworks that use it would expect it to consistently work, versus have arbitrary behavior? |
Yes, I think so.. Likely why other extensions support. I don't think proxy is a particularly good pattern to apply on protobuf message but is is definitely used and (unintentionally?) possible with the php protobuf implementation. If you guys decide no to support extending the messages I'd argue that the generated classes should probably be made final. |
Thanks for the clarifications. We're discussing what to do about this internally, will get back to this thread with updates when I have it. |
We are trying to migrate an application from the PHP Protobuf implementation to the C extension.
A few tests are using the prophecy to mock objects during tests.
and prophecy ends up creating a proxy that looks something like this :
Since the parent constructor is not always called it seems the message never properly initialized and the field lookup fails when get_field is called.
What version of protobuf and what language are you using?
Version: main
Language: php
OS: Linux
What did you do?
What did you expect to see
What did you see instead?
gdb
The text was updated successfully, but these errors were encountered: