bug#16995: 24.3; CPU usage spikes to 100% for minutes at a time

[Andrew Beekhof]

On 13 Mar 2014, at 3:17 am, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Andrew Beekhof <andrew@beekhof.net>
>> Date: Wed, 12 Mar 2014 18:08:27 +1100
>> 
>> I've been editing lots of python files in the last few days and noticed
>> that Emacs has begun locking up for minutes at a time, for no apparent
>> reason.
>> 
>> Example actions that can trigger the problem C-s (isearch-forward),
>> pressing 'y' in response to query-replace prompts, typing, etc.
>> Whether the buffer is saved or not makes no difference.
>> 
>> The only thing that really seems to help is switching back to a .c file.
>> 
>> Is this a known problem?
>> 
>> Example top output:
>> 
>> top - 17:44:11 up 29 days, 22:26,  3 users,  load average: 0.44, 0.50, 0.42
>> Tasks: 236 total,   2 running, 233 sleeping,   0 stopped,   1 zombie
>> %Cpu(s): 12.6 us,  0.1 sy,  0.0 ni, 87.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 
>> st
>> KiB Mem:   7871472 total,  7538448 used,   333024 free,   305676 buffers
>> KiB Swap:  6029308 total,   731032 used,  5298276 free,  2390156 cached
>> 
>>  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
>> 22971 beekhof   20   0  644976  49236  16308 R 100.1  0.6  19:33.79 emacs    
>>                                                                              
>>                                                                              
>>                                                                            
>> 26689 root      20   0   53020    272    176 S   0.7  0.0 308:17.91 
>> plymouthd                                                                    
>>                                                                              
>>                                                                              
>>        
>> 
>> A random blog suggested the following command might show something of
>> interest. All I can tell is that thread 1 is quite deep.
>> 
>> # echo 't a a where' > gdb.cmd; gdb /usr/bin/emacs -p 22971 -x gdb.cmd 2>&1 
>> </dev/null | tee /tmp/emacs.crash.backtrace
>> GNU gdb (GDB) Fedora 7.6.50.20130731-19.fc20
> 
> The backtrace you posted indicates that Emacs is in garbage
> collection.  To see if this is indeed the cause of those "lockups",
> could you please customize garbage-collection-messages to a non-nil
> value, and then see if every time Emacs locks up there's a message in
> the echo area announcing GC?

It took about 2 hours of solid editing to hit it again this morning, but 
eventually I did.

For the first while I saw 'Garbage collecting...done', with the 'done' part 
flashing.

Then it switched to 'Garbage collecting...'

At some point I must have hit C-l (goto-line) because after I came back from 
making breakfast (I wasn't exaggerating when I said 'minutes') it was prompting 
for a line number.
Pressing C-g (cancel) at this point resulted in the buffer flashing between 
displaying 'Quit' and 'Garbage collecting...'

After it stopped doing this, I used the pointer to move the cursor which got me 
back to the 'Garbage collecting...' phase followed by 'Garbage 
collecting...done', with the 'done' part flashing again.

Top says:

22971 beekhof   20   0  658092  61636  15584 R  99.1  0.8  37:03.28 emacs       
                                                                                
                                                                                
                                                                  

(note that its still the same process from yesterday)


If I now switch to a .c file, things appear normal.
Switching back to the .py file and doing anything results in more garbage 
collection.

signature.asc
Description: Message signed with OpenPGP using GPGMail