-
Notifications
You must be signed in to change notification settings - Fork 7.8k
Typed property DOMDocument::$documentElement must not be accessed before initialization #12215
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
Comments
… ext/dom When we try to load an extension multiple times, we still overwrite the type, module number, and handle. If the module number is used to indicate module boundaries (e.g. in reflection and in dom, see e.g. dom_objects_set_class_ex), then all sorts of error can happen. In the case of ext/dom, OP's error happens because the following happens: - The property handler is set up incorrectly in dom_objects_set_class_ex() because the wrong module number is specified. The class highest in the hierarchy is DOMNode, so the property handler is incorrectly set to that of DOMNode instead of DOMDocument. - The documentElement property doesn't exist on DOMNode, it only exists on DOMDocument, so it tries to read using zend_std_read_property(). As there is no user property called documentElement, that read operation returns an undef value. However, the type is still checked, resulting in the strange exception.
… ext/dom When we try to load an extension multiple times, we still overwrite the type, module number, and handle. If the module number is used to indicate module boundaries (e.g. in reflection and in dom, see e.g. dom_objects_set_class_ex), then all sorts of errors can happen. In the case of ext/dom, OP's error happens because the following happens: - The property handler is set up incorrectly in dom_objects_set_class_ex() because the wrong module number is specified. The class highest in the hierarchy is DOMNode, so the property handler is incorrectly set to that of DOMNode instead of DOMDocument. - The documentElement property doesn't exist on DOMNode, it only exists on DOMDocument, so it tries to read using zend_std_read_property(). As there is no user property called documentElement, that read operation returns an undef value. However, the type is still checked, resulting in the strange exception. Solve this by changing the API such that the data is only overwritten if it's owned data.
* PHP-8.1: Fix GH-12215: Module entry being overwritten causes type errors in ext/dom (<= PHP 8.3) Fix bug #55098: SimpleXML iteration produces infinite loop
* PHP-8.2: Fix GH-12215: Module entry being overwritten causes type errors in ext/dom (<= PHP 8.3) Fix bug #55098: SimpleXML iteration produces infinite loop
* PHP-8.3: Fix GH-12215: Module entry being overwritten causes type errors in ext/dom (<= PHP 8.3) Fix bug #55098: SimpleXML iteration produces infinite loop
…t/dom (PHP 8.4) When we try to load an extension multiple times, we still overwrite the type, module number, and handle. If the module number is used to indicate module boundaries (e.g. in reflection and in dom, see e.g. dom_objects_set_class_ex), then all sorts of errors can happen. In the case of ext/dom, OP's error happens because the following happens: - The property handler is set up incorrectly in dom_objects_set_class_ex() because the wrong module number is specified. The class highest in the hierarchy is DOMNode, so the property handler is incorrectly set to that of DOMNode instead of DOMDocument. - The documentElement property doesn't exist on DOMNode, it only exists on DOMDocument, so it tries to read using zend_std_read_property(). As there is no user property called documentElement, that read operation returns an undef value. However, the type is still checked, resulting in the strange exception. Solve this by changing the API such that the data is only overwritten if it's owned data. Closes GH-12246.
OK, I have no run into this error as well on my VM with Ubnutu 22.04.
Code that triggers this error. I am not a php developer, just a user that is stuck with a presumably functioning plugin that fails to function on my brand new VM. This is a short code snippet that is designed to generate the error that crashes the plugin:
Error:
DOM section of the php.ini
I have no option to use a higher version of php because one is not available in the official lunar channel, and I cannot install ondrej/ppa because no repo is available for my version of ubuntu. Attempting to add the ppa fails with a 404. Help? |
@vmajor you are somehow loading the DOM extension twice, causing it to get confused. I have no experience with ppa. |
Oh... thank you for the extremely fast, and correct reply. I had only one instance of DOM in php.ini, but I commented it out and now the test script works. Next, testing the presumably functional plugin. Thank you so much. |
Description
The following code:
Resulted in this output:
But I expected this output instead:
Exact reproduction steps on a fresh Ubuntu 22.04 VM:
apt install php8.1 php-xml
sed -i '/Dynamic Extensions/a extension=dom.so' /etc/php/8.1/apache2/php.ini
(i.e. addingextension=dom.so
to the dynamic extensions section of php.ini).systemctl restart apache2
Note: The cause of the issue is a configuration error on the users end, but the error message is very non-descript and thus hard to debug. This issue is intended to ask for an improvement in error reporting (e.g. emitting an error because the extension is laoded twice or because a necessary dependency is not loaded in the right order).
PHP Version
PHP 8.1.2
Operating System
Ubuntu 22.04
The text was updated successfully, but these errors were encountered: