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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
