Bug#972510: glibc: Please ignore misc/tst-sbrk and/or misc/tst-sbrk-pie on all archs
* Aurelien Jarno: > brk/sbrk is definitely something deprecated. But it is still part of the > API (especially for old architectures) and still used by software like > jemalloc, gcl or libgc. This is therefore important to keep this feature > in a good shape. > > It's also used by many less important packages, often just to print a > backtrace. > > If someone has spoons it might be worth opening bugs again those > package, so that they stop using brk/sbrk. glibc malloc also uses sbrk, and has some glitches in corner cases when it has to switch from sbrk to mmap for the main arena. I think it is worth investigating *why* sbrk fails. Usually that is due to an obstructing mapping caused by problematic address space layouts. With ASLR, such failures can essentially appear to be random.
Bug#972510: glibc: Please ignore misc/tst-sbrk and/or misc/tst-sbrk-pie on all archs
Hi, On 2020-10-21 11:55, John Paul Adrian Glaubitz wrote: > Hi! > > On 10/19/20 9:12 PM, Aurelien Jarno wrote: > >> jrtc27 | misc/tst-sbrk and/or misc/tst-sbrk-pie seem to be failing on a > >> *lot* of architectures > >> jrtc27 | if it were up to me the problem would be solved by just > >> deleting sbrk... > >> jrtc27 | FreeBSD just took the stance of not implementing them for new > >> ports > >> jrtc27 | so it's arm64 and riscv64 ports just have no sbrk > >> jrtc27 | cbmuser: looks like the tests are Debian-specific > >> jrtc27 | added as part of Hurd sbrk reworking to test it didn't break > > > > This is a bit exaggerated, this test actually passes on more > > architectures than it fails. Also this doesn't mean the test is useless, > > it means those architectures behaves differently, and that something has > > to be fixed. It could be some architecture specific code or the test > > itself. > > Well, but if it's in the end a feature that no one is using and a test that > isn't even part > of the upstream tests I don't see the point in testing it. brk/sbrk is definitely something deprecated. But it is still part of the API (especially for old architectures) and still used by software like jemalloc, gcl or libgc. This is therefore important to keep this feature in a good shape. It's also used by many less important packages, often just to print a backtrace. If someone has spoons it might be worth opening bugs again those package, so that they stop using brk/sbrk. > >> Can we disable them? With the tests disabled, glibc should pass its > >> testsuite on at least alpha and > >> sparc64. Not sure what the problem with hppa is at the moment. > > > > We can definitely ignore it on the affected architectures, do you please > > give more details why the test is so wrong that it should be ignored on > > *all* architectures? > > I'm just quoting jrtc27 from IRC. I'm not really an expert on that matter. > > > Ignoring it on the affected architectures, will indeed fix alpha. Not > > sure about hppa, ia64 and sparc64 that have other issues. And there is > > no build log for m68k and sh4 to judge. > > It seems that these two tests are currently the only tests that are not being > ignored > that are failing unless I'm missing something (I just looked at the build > log). I guess you mean for sparc64. This is indeed the case when building the sparc64 flavour, but we know that the sparc flavour will fail later. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#972510: glibc: Please ignore misc/tst-sbrk and/or misc/tst-sbrk-pie on all archs
Hi! On 10/19/20 9:12 PM, Aurelien Jarno wrote: >> jrtc27 | misc/tst-sbrk and/or misc/tst-sbrk-pie seem to be failing on a >> *lot* of architectures >> jrtc27 | if it were up to me the problem would be solved by just deleting >> sbrk... >> jrtc27 | FreeBSD just took the stance of not implementing them for new >> ports >> jrtc27 | so it's arm64 and riscv64 ports just have no sbrk >> jrtc27 | cbmuser: looks like the tests are Debian-specific >> jrtc27 | added as part of Hurd sbrk reworking to test it didn't break > > This is a bit exaggerated, this test actually passes on more > architectures than it fails. Also this doesn't mean the test is useless, > it means those architectures behaves differently, and that something has > to be fixed. It could be some architecture specific code or the test > itself. Well, but if it's in the end a feature that no one is using and a test that isn't even part of the upstream tests I don't see the point in testing it. >> Can we disable them? With the tests disabled, glibc should pass its >> testsuite on at least alpha and >> sparc64. Not sure what the problem with hppa is at the moment. > > We can definitely ignore it on the affected architectures, do you please > give more details why the test is so wrong that it should be ignored on > *all* architectures? I'm just quoting jrtc27 from IRC. I'm not really an expert on that matter. > Ignoring it on the affected architectures, will indeed fix alpha. Not > sure about hppa, ia64 and sparc64 that have other issues. And there is > no build log for m68k and sh4 to judge. It seems that these two tests are currently the only tests that are not being ignored that are failing unless I'm missing something (I just looked at the build log). As for m68k and sh4, I currently can't enable the builds there as the fixes by Adhemerval Zanella to unbreak glibc >= 2.28 on qemu-user have not been merged yet anywhere (neither in Debian nor upstream). I know that Adhemerval is testing glibc on my SH-7785LCR board regularly and I know that Andreas Schwab is testing internally at SUSE on m68k (his openSUSE port for m68k is unfortunately not public). Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916276 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
