Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values - Mailing list pgsql-bugs
From | Daniel Verite |
---|---|
Subject | Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE andwork_mem values |
Date | |
Msg-id | b9379009-61d6-4fec-b7e9-786f3da7b2d3@manitou-mail.org Whole thread Raw |
In response to | Re: [BUGS] Crash report for some ICU-52 (debian8) COLLATE and work_mem values (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-bugs |
Tom Lane wrote: > I went to http://www.icu-project.org/ and downloaded icu4c-52_1-src.tgz. > All the file dates therein seem to be 2013-10-04. > > Debian, for one, is evidently not trying very hard in that direction, > since not only are the bugs still there but the line numbers I saw in > my backtraces agreed with Daniel's, indicating they've not changed > much of anything at all in ucol.cpp. They have 2 small patches in ucol.cpp (diff attached), but the last backtraces I've sent were against upstream, not Debian, got from the same source as you, so they wouldn't differ in the line numbers. Anyway the behavior with segfaulting was identical to Debian's. Speaking of upstream vs Debian, for the library as a whole there are quite a few security patches that are not in upstream: $ apt-get source libicu-dev [...] dpkg-source: info: extracting icu in icu-52.1 dpkg-source: info: unpacking icu_52.1.orig.tar.gz dpkg-source: info: unpacking icu_52.1-8+deb8u5.debian.tar.xz dpkg-source: info: applying icudata-stdlibs.patch dpkg-source: info: applying gennorm2-man.patch dpkg-source: info: applying icuinfo-man.patch dpkg-source: info: applying malayalam-rendering.patch dpkg-source: info: applying indic-ccmp.patch dpkg-source: info: applying mlym-crash.patch dpkg-source: info: applying two-digit-year-test.patch dpkg-source: info: applying icu-config.patch dpkg-source: info: applying CVE-2014-6585.patch dpkg-source: info: applying CVE-2014-6591.patch dpkg-source: info: applying CVE-2014-7923+7926.patch dpkg-source: info: applying CVE-2014-7940.patch dpkg-source: info: applying CVE-2014-9654.patch dpkg-source: info: applying CVE-2014-8146.patch dpkg-source: info: applying CVE-2014-8147.patch dpkg-source: info: applying CVE-2015-4760.patch dpkg-source: info: applying CVE-2014-6585+.patch dpkg-source: info: applying CVE-2015-1270.patch dpkg-source: info: applying CVE-2014-9911.patch dpkg-source: info: applying CVE-2015-2632.patch dpkg-source: info: applying CVE-2015-4844.patch dpkg-source: info: applying CVE-2016-0494.patch dpkg-source: info: applying CVE-2016-6293.patch dpkg-source: info: applying CVE-2016-7415.patch dpkg-source: info: applying CVE-2017-7867_CVE-2017-7868.patch Independantly of the bug discussed in this thread, what is puzzling to me is why upstream does not integrate any of these fixes. Here's their policy about maintenance releases: http://site.icu-project.org/processes/maintenance-releases "When a critical problem is found in ICU libraries, we try to fix the problem in the latest development stream first. If there is a demand for the fix in a past release, an ICU project developer may escalate the fix to be integrated in the release to the ICU project management committee. Once the committee approved to merge the fix into back level stream, the developer can merge the bug fix back to the past release suggested by the committee. This merge activity must be tracked by maintenance release place holder tickets and the developer should provide original ticket number and description as the response in each maintenance ticket. These fixes are automatically included in a future ICU maintenance release." Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Attachment
pgsql-bugs by date: