Re: The Control-C Problem

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? :)

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

> 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?

> 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? :)

> 	- Panu -

Regards,
Omar