On Fri, 2011-01-28 at 22:26, Niko Tyni wrote: > On Thu, Jan 27, 2011 at 07:04:32PM +0100, Milan P. Stanic wrote: > > On Tue, 2010-12-21 at 09:10, Niko Tyni wrote: > > > On Mon, Dec 20, 2010 at 10:26:18AM +0100, Schoepflin, Markus wrote: > > > > > No further segmentation faults of apt-cacher have been observed up to > > > > now. Looks like the suggested patch does indeed solve the observed > > > > problem. > > > > > > Great, thanks for the testing! It's too late to get this in the upcoming > > > Squeeze release. It's possible that it can make it into the first point > > > release (r1) - I'll talk to the release team about that. > > > > I have written application which started to segfault when I upgraded to > > 5.10.1-17 (maybe earlier but I didn't noticed it). > > > > Application uses threads (it can have bugs) and it segfaults when call > > my own module which uses SOAP::Lite. The same application worked without > > (at least visible bugs) before I upgraded perl. > > Why do you think your segfault has the same cause as the one discussed > in this bug? Is the backtrace similar? AFAIK the 'crash when receiving > a signal after perl_destruct()' issue is not a regression from 5.10.0 > (the lenny version.)
I am not sure. I have no idea if the bugs are same. Just thought that they are related because the bugs looks similar to me. > In case you are seeing a separate issue, please file a new bug, preferably > with a minimal recipe for reproduction and a backtrace. > > > It is not problem for me, I can build perl with mentioned patch but I'm > > not sure is it ok to release squeeze with such bug. Perl should not > > segfault because unexperienced programmer made mistakes in > > script/programs. > > Have you tried if the patch actually fixes your problem? Yes. But even with the patched Perl the segfault occurs. And this is the first time I have seen Perl segfault so I mistakenly concluded that must be the same bug. Sorry. > Traditionally Perl bugs that make the interpreter crash in limited > circumstances have been treated as severity:important, not at a release > critical severity. That doesn't mean they don't get fixed - for example, > #596105 did make it into squeeze even though we had frozen already. > > Obviously the severity will still vary with the circumstances, so a > hypothetical bug that made sort() mostly nonfunctional would certainly > be RC. Such issues would probably get mostly caught by the extensive > test suite, though. > > The release team has only been accepting RC bug fixes for a while now, > and with the information currently available I don't think the 'crash > when receiving a signal after perl_destruct()' issue makes the package > unsuitable for release. > > Hope this clarifies, Yes, thank you. -- Kind regards, Milan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
