Re: The Control-C Problem

On Thu, 15 Jul 2004, Omar Kilani wrote:

> Panu Matilainen wrote:
> 
> >>Hi,
> >>
> >>I was wondering whether anyone had come up with a proper solution to the 
> >>"Segfault on Control-C" problem, or if it had been decided that the 
> >>safest way to solve the problem was to segfault? :)
> > 
> > 
> > If we'd found a proper solution it WOULD have been implemented already :)
> > It's not at all impossible that the segfault on ctrl-c problem is a bug in 
> > rpmlib, that's where it crashes afterall. Or then it's some strange 
> > interaction between apt and rpmlib which just doesn't happen with rpm 
> > itself. One thing I've been pondering is whether there's some kind of 
> > conflict between apt and rpmlib signal handling but there aren't that many 
> > places doing signal handling in apt and disabling those didn't change 
> > anything so that reason is probably out.
> 
> I looked at the signal handling code and it seemed fine to me. But I'll 
> take another look soon. Would like to ship a non-segfaulting APT...
> 
> > There is a partial (and ugly) workaround to it (patches attached):
> > 1) make apt always take a readonly lock on rpmdb initially (this is what 
> > fedora.us apt does anyway, for other reasons)
> 
> What are those reasons? :)

Most importantly to allow rpmbuild and rpm -q while apt is starting 
(reading package lists, calculating dependencies etc) and .. well, just to 
see if it hurts anything to do so, compared to taking RW-lock like 
upstream apt does. So far I haven't gotten any complaints of strange 
results because of that (you can mess the transaction later on anyway with 
at least some versions of rpm, even while RW-lock is held)

> 
> > 2) cause a deliberate memory leak by not freeing an rpm transaction set 
> 
> A memory leak is fine if you're about to quit... and it's a lot nicer 
> than a segfault. :)

Memory leak with apt-get doesn't hurt since it's "single shot" program but 
with Synaptic and apt-shell those do matter.

> 
> > With both those done, ctrl-c during download doesn't segfault and doesn't
> > cause stale rpmdb locks. For some reason that still occasionally leaves
> > stale locks behind if you do ctrl-c during apt-cache search :( 
> 
> Are the code paths taken by apt-get and apt-cache the same in this 
> situation, though?

More or less - the traceback is practically identical IIRC and crashes in 
the very same spot but obviously the initial code path is different.

> 
> > Conectiva ships with a patched rpm to work around this outside apt but 
> > that patch isn't exactly a proper fix to the problem either.
> 
> I had a look at the Conectiva SRPM for rpm, and the Control-C patch is 
> #if 0'ed out. So I was wondering... which patch is it? :)

At least in Conectiva 10 SRPM it certainly is applied:
Patch26: rpm4.2.2-aptctrlc.patch
...
%patch26 -p1 -b .aptctrlc

The patch just causes another (but smaller, compared to doing the
workaround in apt itself) deliberate memory leak to prevent the segfault.

	- Panu -