|
From: <sv...@va...> - 2005-10-06 02:31:52
|
Author: sewardj Date: 2005-10-06 03:31:49 +0100 (Thu, 06 Oct 2005) New Revision: 4871 Log: Update. Modified: trunk/docs/internals/3_0_BUGSTATUS.txt Modified: trunk/docs/internals/3_0_BUGSTATUS.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/internals/3_0_BUGSTATUS.txt 2005-10-05 18:05:01 UTC (rev 4= 870) +++ trunk/docs/internals/3_0_BUGSTATUS.txt 2005-10-06 02:31:49 UTC (rev 4= 871) @@ -13,6 +13,9 @@ 111901 cross-platform run of cachegrind fails on opteron 113468 (vgPlain_mprotect_range): Assertion 'r !=3D -1' failed. 92071 Reading debugging info uses too much memory +109744 memcheck loses track of mmap from direct ld-linux.so.2 +110183 tail of page with _end + 82301 FV memory layout too rigid =20 Will fix in 3.1. Long delay seems to be caused by amd64-Gentoo kernel not liking large mmap/munmap requests. Other bugs also look like @@ -31,13 +34,6 @@ FIXED-TRUNK: TODO =20 ---------------------------------------------------------------- -110183 tail of page with _end - -Could be a problem for glibc developers. Consider fixing. - -FIXED-TRUNK: TODO? - ----------------------------------------------------------------- 110204 fmemopen false +ve =20 Seems low priority. |