[ESS] Random ESS Freezes

Bill Denney bill at denney.ws
Wed May 1 13:31:07 CEST 2013

Hi Vitalie,

No, C-g doesn't work.

emacs becomes totally non-responsive and I have to kill the process via task manager.  After killing emacs, Rterm spikes to 100% CPU usage (or if I kill Rterm first, emacs takes 100%).  Typically, both are not taking any CPU while in the frozen state I'm describing.



On May 1, 2013, at 6:40 AM, Vitalie Spinu <spinuvit at gmail.com> wrote:

> So if I understand it correctly, C-g doesn't' help?
> The SVN branch hopefully fixes all these issues, I will merge them to
> git today after a couple of more tests. 
> It is difficult for me to debug these problems because, for whatever
> magical reason, I never experience them.
>    Vitalie
>>> Bill Denney <bill at denney.ws>
>>> on Tue, 30 Apr 2013 17:12:26 -0400 wrote:
>> On 4/30/2013 12:09 PM, Vitalie Spinu wrote:
>>>>> Bill Denney <bill at denney.ws>
>>>>> on Tue, 30 Apr 2013 11:34:12 -0400 wrote:
>>>> I am having random freezes with ESS that I have not been able to
>>>> identify the pattern of.  I am using R 2.15.2 with ESS 12.09-2 (I
>>>> also tried with the git head).
>>> In such cases you should go to *ess-command-output* buffer and see if
>>> there is anything unexpected that waits for user input.
>>> Do you have options(error=recover)?
>> When I got this error, I didn't have options(error=recover) activated.
>> Typically, when I have the issue, I can't interact with emacs anymore
>> and the window view of emacs doesn't refresh.  In other words, if there
>> is another window open on top of the emacs window, then whatever was
>> visible is gone.  Is it possible to redirect a the *ess-command-output*
>> buffer to a file?
>> Also FYI, this is in Windows XP if that changes anything.
>> Have a good day,
>> Bill

More information about the ESS-help mailing list