severity 260767 minor tags 260767 + wontfix thanks On Wed, Jul 21, 2004 at 11:16:04PM -0500, Jeff Licquia wrote: > The severity deserves an explanation. I found this bug as part of my > work on getting Debian in shape for LSB 2.0. It appears that test > /tset/LSB.os/genuts/glob/T.glob 29 does a double-free which tweaks this > bug. That test ends up succeeding, but the next test (test 30) hangs at > the very first attempt to allocate memory through no fault of its own. > This causes bogus test failures, which will have an impact on Debian's > ability to certify under at least LSB 2.0. I suspect that the LSB 1.3 > version of this test will experience similar problems. > > One might argue that the LSB's double-free is the real problem, and I > will indeed be working with the LSB people to get this problem solved. > Unfortunately, it's very possible that the LSB will not be in a position > to fix this bug in a timely manner, and thus it would be better to fix > the underlying incorrect behavior in glibc. > > I won't argue with a severity adjustment, though. > > I will have to write a workaround patch to fix this problem, and will > attach it to this bug report when it is ready.
As a courtesy to the tracking of LSB problems, I will not close this bug. However, I do not believe it should be "fixed". Under absolutely no circumstances would a "fix" be accepted upstream. Affecting the performance or maintainability of a non-debugging malloc implementation to handle invalid input is not worthwhile. The LSB tests are not such special software as to penalize the fast-path allocation of every other piece of software on a Debian system. If the LSB people do not have an adequate process for handling bugs in their tests, that's not glibc's problem. Even SPEC can manage this... -- Daniel Jacobowitz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
