Bug#356167: reproducible with vim 7?

Justin Pryzby justinpryzby at users.sourceforge.net
Thu May 18 20:00:06 UTC 2006


found 356167 1:7.0-017+2
thanks

On Thu, May 18, 2006 at 12:49:11PM -0500, Stefano Zacchiroli wrote:
> Hi, in case you are able to routinely reproduce the signal accumulation
> bug, could you please test if it is still reproducible with vim 7,
> uploaded a few days ago into unstable?
> 
> It would be really appreciated!
> 
> Many thanks in advance,
Hi,

This bug is only reproducible when the machine is thrashing under
extremely high load eg. with a runaway firefox process suddenly
requiring an extra 100+MB ram.

I was thinking about this bug recently when reading glibc-doc section
on signal handling, and I wonder what kind of solution exists, or if
any *can* exist..  ^Z sends SIGTSTP, which can apparently be blocked,
but it would eventually have to be unblocked (because not doing so
would be "unfriendly").  But unblocking it would just cause the
process to immediately suspend itself.  Sending SIGCONT to the process
(group?) probably can't work (and would be ugly, inefficient, and
scary looking anyway), since vim would immediately try to read from
the terminal while not the foreground process, and so it would just get
suspended again.

I'll wrote a program to allocate and zero 130MB memory, which is all
this machine has for physical ram.  I started vim, compiled my memory
sucker program, ran I, waiting a bit until the machine was thrashing,
then held down ^Z.  When it took a minute to respond, I spent some time
while switching to the memsucker xterm, killed it, then switched back to
the vim xterm.  I 'fg' the vim process, and it immediately suspended
itself.  I had to 'fg' it over 30 times before it remained active.

Justin




More information about the pkg-vim-maintainers mailing list