Bug#604902: apt-cacher: random segfaults in libperl when clients are accessing cache

[Niko Tyni]

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.)

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?

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,
-- 
Niko Tyni   ntyni at debian.org