37395 2019-10-29 17:58:38 +0300 Игнорирует XML_PARSE_NOERROR и XML_PARSE_NOWARNING в парсере html 2019-11-01 19:58:05 +0300 1 1 4 Development Sisyphus libxml2 unstable all Linux CLOSED FIXED https://bugzilla.gnome.org/show_bug.cgi?id=638618 P3 normal --- 1 rider ldv maks1ms rider qa-sisyphus oldest_to_newest 185170 0 rider 2019-10-29 17:58:38 +0300 Игнорирует LIBXML_NOWARNING и LIBXML_NOERROR в парсере html для случаев, когда используется xmlGenericError handler. Коммит 4b023ad2a90ca89e8dec7dd8f4558ff4c94f771a приводит к тому, что не проходит тест ошибки 74004 в PHP. А именно - установка LIBXML_NOERROR должна глушить вывод ошибок libxml. в других дистрибутивах тест проходит. тест выглядит так: $doc=new DOMDocument(); $doc->loadHTML("<tag-throw></tag-throw>",LIBXML_NOERROR); В результате теста у нас вывод: Warning: DOMDocument::loadHTML(): Tag tag-throw invalid in /usr/src/RPM/BUILD/php7-source/ext/dom/tests/bug74004.php on line 4 ===DONE=== в других дистрибутивах Warning глушится. 185176 1 ldv 2019-10-29 19:28:22 +0300 libxml2$ git grep -Fw LIBXML_NOERROR |wc -l 0 libxml2$ git grep -Fw LIBXML_NOWARNING |wc -l 0 Уточните, пожалуйста, о каких именно NOERROR и NOWARNING идёт речь. 185179 2 rider 2019-10-29 20:08:12 +0300 Да, прошу прощения. Названия из php, в libxml2 это XML_PARSE_NOERROR и XML_PARSE_NOWARNING 185187 3 rider 2019-10-30 08:23:25 +0300 Т.е. - у нас приложен патч: https://bug638618.bugzilla-attachments.gnome.org/attachment.cgi?id=181851 Но при этом поведение по умолчанию всё-таки изменилось и привело к тому, что вылез этот баг в php, когда вызывается callback на xmlGenericError (который и приводит к выводу Warning там, где его не ждут). В апстриме resolved fixed, но у нас в этом месте код другой. 185190 4 ldv 2019-10-30 11:30:40 +0300 (In reply to comment #3) > Т.е. - у нас приложен патч: > https://bug638618.bugzilla-attachments.gnome.org/attachment.cgi?id=181851 Это в точности дополнительный коммит 4b023ad2a90ca89e8dec7dd8f4558ff4c94f771a, который не попал в апстримный git. > Но при этом поведение по умолчанию всё-таки изменилось и привело к тому, что > вылез этот баг в php, когда вызывается callback на xmlGenericError (который и > приводит к выводу Warning там, где его не ждут). Да, это очень похоже на "If sax context is set but sax context callback channel is not set, fall back to use xmlGenericError, otherwise the error will be lost." 185191 5 rider 2019-10-30 11:47:00 +0300 Ещё в разнице в выводе ошибок между нами и версией в debian (такой же) замечена ошибка про структуру XML Reference not found, которая у нас появляется, а у Debian нет Выглядит это так (у нас): $ /usr/src/RPM/BUILD/php7-source/sapi/cli/php -n -c '/usr/src/RPM/BUILD/php7-source/tmp-php.ini' -d "output_handler=" -d "open_basedir=" -d "disable_functions=" -d "output_buffering=Off" -d "error_reporting=32767" -d "display_errors=1" -d "display_startup_errors=1" -d "log_errors=0" -d "html_errors=0" -d "track_errors=0" -d "report_memleaks=1" -d "report_zend_debug=0" -d "docref_root=" -d "docref_ext=.html" -d "error_prepend_string=" -d "error_append_string=" -d "auto_prepend_file=" -d "auto_append_file=" -d "ignore_repeated_errors=0" -d "precision=14" -d "memory_limit=128M" -d "log_errors_max_len=0" -d "opcache.fast_shutdown=0" -d "opcache.file_update_protection=0" -d "zend.assertions=1" -d "extension_dir=/usr/src/RPM/BUILD/php7-source/modules/" -d "extension=mysqlnd.so" -d "session.auto_start=0" -d "zlib.output_compression=Off" -f "/usr/src/RPM/BUILD/php7-source/ext/xml/tests/xml004.php" Warning: xml_parse(): PEReference: %incent; not found in /usr/src/RPM/BUILD/php7-source/ext/xml/tests/xml004.php on line 8 <root id="elem1"> <elem1> <elem2> <elem3> Warning: xml_parse(): Entity 'included-entity' not defined in /usr/src/RPM/BUILD/php7-source/ext/xml/tests/xml004.php on line 8 <elem4> </elem4> </elem3> </elem2> </elem1> </root> Warning: xml_parse(): PEReference: %incent; not found in /usr/src/RPM/BUILD/php7-source/ext/xml/tests/xml004.php on line 16 <ROOT ID="elem1"> <ELEM1> <ELEM2> <ELEM3> Warning: xml_parse(): Entity 'included-entity' not defined in /usr/src/RPM/BUILD/php7-source/ext/xml/tests/xml004.php on line 16 <ELEM4> </ELEM4> </ELEM3> </ELEM2> </ELEM1> </ROOT> В Debian: test@debian:~$ cat xmltest.xml <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE phptest SYSTEM "notfound.dtd" [ <!ENTITY % incent SYSTEM "inc.ent"> %incent; ]> <root id="elem1"> Plain text. <elem1> <!-- comment --> <elem2> <![CDATA[CDATA block]]> <elem3> &included-entity; <elem4> <?test processing instruction ?> </elem4> </elem3> </elem2> </elem1> </root> код: $ php <?php chdir(dirname(__FILE__)); $xp = xml_parser_create(); xml_parser_set_option($xp, XML_OPTION_CASE_FOLDING, false); xml_set_element_handler($xp, "start_element", "end_element"); $fp = fopen("xmltest.xml", "r"); while ($data = fread($fp, 4096)) { xml_parse($xp, $data, feof($fp)); } xml_parser_free($xp); $xp = xml_parser_create(); xml_parser_set_option($xp, XML_OPTION_CASE_FOLDING, true); xml_set_element_handler($xp, "start_element", "end_element"); $fp = fopen("xmltest.xml", "r"); while ($data = fread($fp, 4096)) { xml_parse($xp, $data, feof($fp)); } xml_parser_free($xp); function start_element($xp, $elem, $attribs) { print "<$elem"; if (sizeof($attribs)) { foreach ($attribs as $k => $v) { print " $k=\"$v\""; } } print ">\n"; } function end_element($xp, $elem) { print "</$elem>\n"; } ?> Вывод: <root id="elem1"> <elem1> <elem2> <elem3> <elem4> </elem4> </elem3> </elem2> </elem1> </root> <ROOT ID="elem1"> <ELEM1> <ELEM2> <ELEM3> <ELEM4> </ELEM4> </ELEM3> </ELEM2> </ELEM1> </ROOT> 185192 6 rider 2019-10-30 11:57:14 +0300 (В ответ на комментарий №4) > (In reply to comment #3) > > > Но при этом поведение по умолчанию всё-таки изменилось и привело к тому, что > > вылез этот баг в php, когда вызывается callback на xmlGenericError (который и > > приводит к выводу Warning там, где его не ждут). > > Да, это очень похоже на "If sax context is set but sax context callback channel > is not set, fall back to use xmlGenericError, otherwise the error will be > lost." Мне кажется, что его надо доработать так, что бы он учитывал флаги XML_PARSE_NOERROR и XML_PARSE_NOWARNING. Т.е. - если контекст sax есть, но при этом у него handler'ов на warning и error нету - то не переключаться на xmlGenericError. 185194 7 ldv 2019-10-30 12:40:47 +0300 (In reply to comment #6) > (В ответ на комментарий №4) > > (In reply to comment #3) > > > > > > Но при этом поведение по умолчанию всё-таки изменилось и привело к тому, что > > > вылез этот баг в php, когда вызывается callback на xmlGenericError (который и > > > приводит к выводу Warning там, где его не ждут). > > > > Да, это очень похоже на "If sax context is set but sax context callback channel > > is not set, fall back to use xmlGenericError, otherwise the error will be > > lost." > > Мне кажется, что его надо доработать так, что бы он учитывал флаги > XML_PARSE_NOERROR и XML_PARSE_NOWARNING. Т.е. - если контекст sax есть, но при > этом у него handler'ов на warning и error нету - то не переключаться на > xmlGenericError. Другими словами, ты предлагаешь откатить ту часть коммита, описание которой я процитировал, потому что она вызывает регрессию. 185196 8 rider 2019-10-30 13:55:26 +0300 (В ответ на комментарий №7) > (In reply to comment #6) > > (В ответ на комментарий №4) > > > (In reply to comment #3) > > > > > > > > > Но при этом поведение по умолчанию всё-таки изменилось и привело к тому, что > > > > вылез этот баг в php, когда вызывается callback на xmlGenericError (который и > > > > приводит к выводу Warning там, где его не ждут). > > > > > > Да, это очень похоже на "If sax context is set but sax context callback channel > > > is not set, fall back to use xmlGenericError, otherwise the error will be > > > lost." > > > > Мне кажется, что его надо доработать так, что бы он учитывал флаги > > XML_PARSE_NOERROR и XML_PARSE_NOWARNING. Т.е. - если контекст sax есть, но при > > этом у него handler'ов на warning и error нету - то не переключаться на > > xmlGenericError. > > Другими словами, ты предлагаешь откатить ту часть коммита, описание которой я > процитировал, потому что она вызывает регрессию. Да, всё верно. Надо бы ещё понять каким образом этот коммит влияет на дополнительно вылезший вывод ошибок с разбором структуры XML документа. 185197 9 rider 2019-10-30 14:29:27 +0300 На самом деле в php из-за таких ошибок, которые отсутствуют в других системах а есть только у нас и касаются качества подаваемого на вход XML - не проходит не один, а 5 тестов на libxml. 185211 10 rider 2019-10-31 11:56:15 +0300 после отката error.c в libxml2 к текущему апстримному виду - все тесты, связанные с libxml в php стали проходить без дополнительных исправлений. testStructuredErrorFunc тоже не падает. 185212 11 ldv 2019-10-31 12:29:48 +0300 (In reply to comment #10) > после отката error.c в libxml2 к текущему апстримному виду - все тесты, > связанные с libxml в php стали проходить без дополнительных исправлений. > testStructuredErrorFunc тоже не падает. В error.c никаких других изменений, помимо того дополнительного коммита 4b023ad2a90ca89e8dec7dd8f4558ff4c94f771a, уже давно нет. Если реверт этого коммита не вызывает регрессий в testStructuredErrorFunc, предлагаю отревертить. 185214 12 rider 2019-10-31 14:27:08 +0300 Ну ок. Я не против. Ментейнера попросим ? 185270 13 shaba 2019-11-01 19:57:30 +0300 Исправлено в libxml2-2.9.10-alt1 185271 14 rider 2019-11-01 19:58:05 +0300 спасибо.