Thread: [HACKERS] Regressions failures with libxml2 on ArchLinux
Hi all, It's been one month since I have done some serious development with Archlinux (I was abroad and away from the laptop dedicated to that), and surprise, I can see failures in the PG regression tests, like the following short extract (result compared to expected/xml.out): SELECT xmlparse(document ' '); ERROR: invalid XML document ! DETAIL: line 1: Start tag expected, '<' not found ---- SELECT xmlparse(document ' '); ERROR: invalid XML document ! DETAIL: line 1: switching encoding : no input ! ! ^ ! line 1: Start tag expected, '<' not found Attached is the full diff of the thing. On Archlinux the following package is being used, for something that is rather up to date with upstream: https://www.archlinux.org/packages/extra/x86_64/libxml2/ The last update of this package is dated of the 9th of July, which corresponds more or less at the moment I have not been able to touch my Linux laptop. So I would tend to think that something got broken upstream because of this package update, and because the last thing close enough to this code has been 0de791ed, but I have run the regression tests on my Linux laptop as well. I can notice as well that no buildfarm machines are running ArchLinux now, so that's one reason why this got undetected until now. My own machines running Archlinux ARM have been unplugged for a full month, and I can see the failure there. They are not able to report back to the buildfarm, but that's a separate issue, visibly that's an access permission. I have not investigated much this problem yet, but has somebody else seen those diffs? Thanks, -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
On Sat, Aug 12, 2017 at 8:46 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > I have not investigated much this problem yet, but has somebody else > seen those diffs? Coming back to that... Downgrading down to 2.9.4+4+g3169602-1 is proving to put things back the way they should. Even downgrading to 2.9.4+91+g872fea94-1 did not help much, and 2.9.4+96+gfb56f80e-1 is the newest version. I have logged an issue to archlinux website to let them know about the regression, because they are shipping a broken package: https://bugs.archlinux.org/task/55134 Using this information I have done as well some bisecting of libxml2, to finish with the following commit as culprit: commit 46dc989080d5d6b7854de8fb3cb3de55ecbf0621 Author: Nick Wellnhofer <wellnhofer@aevum.de> Date: Thu Jun 8 02:24:56 2017 +0200 Don't switch encoding for internal parameter entities This is only needed for external entities. Trying to switch the encoding for internal entities could also cause a memoryleak in recovery mode. So I have logged as well a bug for the upstream folks: https://bugzilla.gnome.org/show_bug.cgi?id=786267 Please note that I have not concluded yet if PostgreSQL is to blame or not in this case with its use of the libxml2 APIs... -- Michael
Hello, On Sat, Aug 12, 2017 at 08:46:38PM +0900, Michael Paquier wrote: > I can notice as well that no buildfarm machines are running ArchLinux > now, so that's one reason why this got undetected until now. My own > machines running Archlinux ARM have been unplugged for a full month, > and I can see the failure there. They are not able to report back to > the buildfarm, but that's a separate issue, visibly that's an access > permission. > > I have not investigated much this problem yet, but has somebody else > seen those diffs? > I have libxml2 2.9.4+96+gfb56f80e-1 on my Archlinux. All regression tests passed without any fails. I ran check and installcheck commands. Of course my environment is not completely match to your environment. It could be a reason why we have different results. -- Arthur Zakirov Postgres Professional: http://www.postgrespro.com Russian Postgres Company
Hi Michael, > It's been one month since I have done some serious development with > Archlinux (I was abroad and away from the laptop dedicated to that), > and surprise, I can see failures in the PG regression tests, like the > following short extract (result compared to expected/xml.out): I can confirm that I see the same errors on Arch Linux with latest updates when PostgreSQL is compiled with --with-libxml and/or --with-libxslt. I submitted a few details on bugs.archlinux.org [1] since probably not all Arch Linux maintainers know how to reproduce an issue. [1]: https://bugs.archlinux.org/task/55134 -- Best regards, Aleksander Alekseev
Hi Michael, > I can confirm that I see the same errors on Arch Linux with latest > updates when PostgreSQL is compiled with --with-libxml and/or > --with-libxslt. I submitted a few details on bugs.archlinux.org [1] > since probably not all Arch Linux maintainers know how to reproduce an > issue. > > [1]: https://bugs.archlinux.org/task/55134 TWIMC I've also described a workaround there. -- Best regards, Aleksander Alekseev
On Mon, Aug 14, 2017 at 6:46 PM, Aleksander Alekseev <a.alekseev@postgrespro.ru> wrote: > Hi Michael, > >> It's been one month since I have done some serious development with >> Archlinux (I was abroad and away from the laptop dedicated to that), >> and surprise, I can see failures in the PG regression tests, like the >> following short extract (result compared to expected/xml.out): > > I can confirm that I see the same errors on Arch Linux with latest > updates when PostgreSQL is compiled with --with-libxml and/or > --with-libxslt. I submitted a few details on bugs.archlinux.org [1] > since probably not all Arch Linux maintainers know how to reproduce an > issue. > > [1]: https://bugs.archlinux.org/task/55134 Thanks for adding the details directly, downgrading the hard way is what I am doing now using the past packages of libxml2 in Arch's archives [1]. ArchLinux is a bit wrong in the fact of shipping a package with a behavior change. Let's wait also for libxml2 folks to see what they have to provide on the matter... The next release of libxml2 would hurt Postgres if it were to be released today. [1]: https://archive.archlinux.org/packages/l/libxml2/ -- Michael
On Mon, Aug 14, 2017 at 7:36 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > Thanks for adding the details directly, downgrading the hard way is > what I am doing now using the past packages of libxml2 in Arch's > archives [1]. ArchLinux is a bit wrong in the fact of shipping a > package with a behavior change. Let's wait also for libxml2 folks to > see what they have to provide on the matter... The next release of > libxml2 would hurt Postgres if it were to be released today. This story has finished with a fix in libxml2 itself: https://git.gnome.org/browse/libxml2/commit/?id=3aca7f31cb9901dc3af449e08dda647898bfc1fe And Archlinux has released a new package of libxml2 with a fix two days back: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/libxml2&id=06ece61e13f760ee5c4c1df19849807b887b744d -- Michael