# remove or fix zend_object_proxies - Thread: https://externals.io/message/49560 - Original archive: https://news-web.php.net/php.internals/49560 - Started by Michael Wallner on 2010-09-03T09:35:37+00:00 - Messages: 9 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #49560 — Michael Wallner — 2010-09-03T09:35:37+00:00 URL: https://externals.io/message/49560#49560 At the current state zend_object_proxies are pretty broken. - They'd need an explicit zend_objects_store_dtor otherwise zend_objects_destroy_object causes a SEGV. - Any op other than set/get or cast to bool/int/double on the object cause a fatal error because no class_entry can be retrieved, or a SEGV because calling object handlers without prior checking for existence. Mike --- ## #49561 — Michael Wallner — 2010-09-03T11:04:46+00:00 URL: https://externals.io/message/49560#49561 · In reply to: #49560 > At the current state zend_object_proxies are pretty broken. Pierre told me that the tone of this mail may be interpreted offensive. That was not my intention, maybe I'd better have written "I'd suggest to remove or fix zend_object_proxies". Sorry for any confusion, Mike --- ## #49562 — Pierre Joye — 2010-09-03T11:20:41+00:00 URL: https://externals.io/message/49560#49562 · In reply to: #49561 > > > […] > > Pierre told me that the tone of this mail may be interpreted offensive. > That was not my intention, maybe I'd better have written "I'd suggest > to remove or fix zend_object_proxies". > > Sorry for any confusion, hehe, I did not mean that this mail was offensive. Only that this stuff is the best way to get mad at php internals. A more verbose post would help to, what's your actual proposal/wish or an example case :) Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #49563 — Michael Wallner — 2010-09-03T11:37:58+00:00 URL: https://externals.io/message/49560#49563 · In reply to: #49562 > hehe, I did not mean that this mail was offensive. Only that this > stuff is the best way to get mad at php internals. A more verbose post > would help to, what's your actual proposal/wish or an example case :) Alright then. OBJECTS2_HOWTO--okay maybe a tiny bit out of date, but nevertheless--states that for the get_property_ptr_ptr object handler, which is supposed to return zval** of the property, one can use zend_proxy_objects for properties not really existing as zvals. This objects overload the get and set object handlers (note: not __get/__set) to enable something along the lines: class user_class extends internal_class { function method() { $ref = &$this->internal_property; /* $ref now actually is a zend_proxy_object */ $ref = 1; } } ... but no other object handler that add_ref, del_ref, clone_obj, get and set are defined, which causes everything from fatal errors to SEGVs on simple statements like var_dump, echo, (string)-cast etc... Additionally on object destruction, at the latest on shutdown, (the default) zend_objects_destroy_object causes a SEGV because zend_proxy_objects actually are not zend_objects and don't have a class entry. Hrm.. after re-reading this mail, I don't think it's more comprehensive than the first one... ;) Mike --- ## #49564 — Gustavo Lopes — 2010-09-03T19:07:02+00:00 URL: https://externals.io/message/49560#49564 · In reply to: #49563 > OBJECTS2_HOWTO--okay maybe a tiny bit out of date, but > nevertheless--states > that for the get_property_ptr_ptr object handler, which is supposed to > return zval** of the property, one can use zend_proxy_objects for > properties not really existing as zvals. OBJECTS2_HOWTO is indeed out of date. For instance it refers to the handlers get_property_zval_ptr and get_property_ptr, which don't exist anymore. If I'm not mistaken, the current way to return proxy objects is to return `NULL` from get_property_ptr_ptr, forcing a fallback to read_property and return a proxy object from there (with refcount 0 if it's not referenced anywhere). > > This objects overload the get and set object handlers (note: not > __get/__set) > to enable something along the lines: > > class user_class extends internal_class { > function method() { > $ref = &$this->internal_property; > /* $ref now actually is a zend_proxy_object */ > $ref = 1; > } > } > > ... but no other object handler that add_ref, del_ref, clone_obj, get > and set are defined, which causes everything from fatal errors to SEGVs > on simple statements like var_dump, echo, (string)-cast etc... Yes, I've also noticed this breakage when writing the wiki page for objects ( http://wiki.php.net/internals/engine/objects ). Most from the code I've seen (I haven't actually programmed anything with proxy objects except for making some tests while writing that page), the problem is not so much the engine. Although the Zend engine also has some parts with poor proxy objects supports (e.g. I don't think you can use proxy objects as array indexes, even if the get handler would return an int/string), the problem is mostly the extensions, which frequently assume the handlers exist. The engine sometimes tries to protect against this -- Z_OBJCE/zend_get_class_entry check if get_class_entry exists before calling it, for instance --, but there are a lot of extensions that inadequately assume some handlers exist. Even var_dump assumes get_class_name exists... Those bugs should be fixed and extension writes should be aware they can be given proxy objects, but if you're worried about those segfaults, you can define dummy implementations for those handlers. zend_parse_parameters is also broken because it does not attempt to call the get handler when you pass a proxy object, except if you request a string (and even then, it prefers the cast_object handler). > Additionally on object destruction, at the latest on shutdown, > (the default) zend_objects_destroy_object causes a SEGV because > zend_proxy_objects actually are not zend_objects and don't have > a class entry. > I don't see the issue here. You should define an appropriate callback. If they're not zend standard objects, don't use zend_objects_destroy_object in your zend_objects_store_put call (or NULL, which defaults to zend_objects_destroy_object). The store accepts anything and even has a clone callback specifically to make easier the cloning of non-standard Zend objects. -- Gustavo Lopes --- ## #49565 — Michael Wallner — 2010-09-03T21:25:00+00:00 URL: https://externals.io/message/49560#49565 · In reply to: #49564 Am 03.09.2010 21:07, schrieb Gustavo Lopes: [...] > Although the Zend engine also has some parts with poor proxy objects supports (e.g. I don't think you can use proxy [...] IMO one cannot even name it "support". [...] > > […] > > I don't see the issue here. You should define an appropriate callback. If they're not zend standard objects, don't > use zend_objects_destroy_object in your zend_objects_store_put call (or NULL, which defaults to > zend_objects_destroy_object). The store accepts anything and even has a clone callback specifically to make easier > the cloning of non-standard Zend objects. I didn't do anything. I tried to use the API like zend_object_create_proxy. I wonder what you're trying to tell me? Mike --- ## #49566 — Gustavo Lopes — 2010-09-03T21:40:35+00:00 URL: https://externals.io/message/49560#49566 · In reply to: #49565 > > […] > > I didn't do anything. I tried to use the API like > zend_object_create_proxy. > I wonder what you're trying to tell me? > Well... zend_object_create_proxy is broken. I'd say Dmitry broke it in revision 200527: http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_objects_API.c?r1=200526&r2=200527& zend_object_create_proxy should be changed to pass a no-op implementation to zend_objects_store_put for the dtor callback or Dmitry's change should be reverted. -- Gustavo Lopes --- ## #49567 — Pierre Joye — 2010-09-03T21:50:50+00:00 URL: https://externals.io/message/49560#49567 · In reply to: #49566 > > > > […] > > Well... zend_object_create_proxy is broken. > > I'd say Dmitry broke it in revision 200527: > > http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_objects_API.c?r1=200526&r2=200527& > > zend_object_create_proxy should be changed to pass a no-op implementation to > zend_objects_store_put for the dtor callback or Dmitry's change should be > reverted. Is there any bug report about this breakage? Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #49568 — Gustavo Lopes — 2010-09-04T01:44:45+00:00 URL: https://externals.io/message/49560#49568 · In reply to: #49567 On Fri, 03 Sep 2010 22:50:50 +0100, Pierre Joye wrote: > Is there any bug report about this breakage? > OK, here are three in the hope they're not left rotting: http://bugs.php.net/bug.php?id=52772 http://bugs.php.net/bug.php?id=52773 http://bugs.php.net/bug.php?id=52774 -- Gustavo Lopes