R crashes when performing a 'clear all' operation with lots of graph devices

[marQIsoft]

Hi,

Since I have installed both the latest version of Tinn-R (4.2.4.0) and that of Microsoft R Open (3.3.0), R crashes every time I run a 'clear all' command (default shortcut F12 in Tinn-R). This is a problem within Tinn-R, I think, because R does not crash if I copy and run the very same command myself in the R console: "rm(list=ls()); graphics.off()". Therefore, I suspect the bug is related to the dynamic interaction/connection betwenn Tinn-R and R. Maybe that issue does not occur with standard R directly from CRAN, but even if it is so, that would be nice if you could resolve this bug (systematic fatal R APPCRASH'es) for MRO&TinnR users, which are to become increasingly numerous I think.

More specifically, I've just found a workaround, which may guide you toward a cleaner way to fix this issue for good. As I suspected the problem to be due to the R object Explorer within Tinn-R Tools panels (CTRL+F8), I've simply changed the focused panel to 'Misc' instead of 'R', and from that moment, R would not crash anymore! So that's it: R Explorer causes the issue, when closing lots of 'windows' devices. And I think I know why. When a device is closed, focus is returned to the previous window, which may be Tinn-R, in which case R Explorer may try to refresh/update its list, which is not a good thing to perform during a 'clear all' task...

Here is a code to generate many variables and devices, a prequisite for the APPCRASH bug to occur:

#Creation of dummy variables and basic plot devices:
for(i in 1:100) assign(sprintf("var%d", i), rnorm(n=i))
for(j in 1:30) {
  dev.new()
  plot(1:5)
}
if(F) {
  #to test manually:
  rm(list=ls()); graphics.off()
  graphics.off(); rm(list=ls())
  #Curiously, both work without any R crash...
}
#BUT IF I USE THE F12 shortcut: ouch! R crashes! :-(

(Also, in case it matters, my Computational synchronization (delay) [in Tinn-R general settings] is set to 100 ms.)

Could you check it out and find a robust fix for this bug, please?

Thanks a lot.

Cheers.

   Marc (alias marQIsoft)

[José Cláudio Faria]

Hello Marco,

I appreciate the attention to report these bugs.

I confess I did not know this flavor (MRO) of R made by Microsoft.

I studied a little about it, installed and tested here without any change in Tinn-R project.

I found some bugs (Rgui the Rterm) especially when I try to send selections marked blocks and contiguous line.

I believe it will not be very difficult to reconcile this flavor of R with Tinn-R, however,

we can not promise anything in the short term.

If you really need to use this flavor of R due to gain speed in some operations,

I suggest using rstudio, from what I read, it mainly seemed that was prepared some time for this new flavor of R.

All the best,

J.C.Faria

[José Cláudio Faria]

Hello,

Studying the pointed out a little more I could see that the source

of all bugs seems to be associated only to svSocket package. So, just disable the

automatic connection of the package that you can work well with this flavor of R.

You will lose only the resources to complete the function arguments (call tip) and completion of data.frames names.

So, it will be necessary to communicate P. Grosjean (the maintainer of svSocket package) to fix the bugs.

All the best,

J.C.Faria

Em terça-feira, 2 de agosto de 2016 12:26:02 UTC-3, marQIsoft escreveu:

[marQIsoft]

Thanks for your investigation into the problem I'd described.

Actually, I've made similar tests with standard R 3.3.1, and the same APPCRASH occurs.

As you said, it's likely related to the svSocket package. But my last test has shown that it's not related to some difference within Microsoft R Open, which works as well as the standard R concerning this bug.

The simplest workaround I've found, which is fast enough for being satisfying, is to combine (sequentially) the two following shortcuts: F10 (to close all graph. devices, then F11 or F12 to clear the rest (i.e. variables and console). Indeed, when devices are closed separately from clearing all variables, no such bug occurs.

If my workaround gives you some idea to solve this issue without having to wake up svSocket's maintainer, so much the better! :-)

Thanks for your time!

Ciao.

   Marc (alias marQIsoft)

[José Cláudio Faria]

Hello Marc,

Your suggestion

unlockBinding("last.warning", baseenv())

works nice here to MRO version. After it, I did not find any problem using this new flavor of R and Tinn-R.

The maintainer of the Socket package (P. Grosjean) was notified of the problem and promised to release a new version of the package (compatible with MRO) soon.

I would like to inform you that I can not reproduce here the bug (both MRO and plain R) you spoke with the code below:

#Creation of dummy variables and basic plot devices:
for(i in 1:100) assign(sprintf("var%d", i), rnorm(n=i))
for(j in 1:30) {
  dev.new()
  plot(1:5)
}
if(F) {
  #to test manually:
  rm(list=ls()); graphics.off()
  graphics.off(); rm(list=ls())
  #Curiously, both work without any R crash...
}
#BUT IF I USE THE F12 shortcut: ouch! R crashes! :-(

everything works fine here on my computer without bugs.

I am using the PRE-RELEASE (aug/07/2016): Tinn-R_04.02.10.00_setup.exe

(http://nbcgib.uesc.br/lec/software/editores/tinn-r/en#h10-download)

All the best,

J.C.Faria

[marQIsoft]

Good news, that upcoming release of an updated svSocket package! Thanks for having contacted P. Grosjean for that purpose.

Actually, I had not the most recent pre-release version of Tinn-R, which may explain some differences in the behavior of the bug I've described.

Now I have Tinn-R 04.02.10.00 installed.

And as you say, no APPCRASH occurs when running my example code. BUT it's only because it was a bad example.

I've increased the amount of data in the plots, and then the bug occurs systematically. I've attached the new code, for testing this bug, to this post.

My conclusion: Tinn-R "Clear All" command troubles R when graph devices contain lots of data: there is probably confusion somewhere in memory or else in interactions between R and Tinn-R. But since executing a "Close all graph devices)"(F10) then "Remove all objects"(F11) does NOT cause any AppCrash, that's more likely a Tinn-R / svSocket / TinnRcom interaction problem...

So, if you want to reproduce the bug, I suggest you to generate tens of graph devices each containing tons of points or any other features. Then try F12, you'll see. ;-)

Thanks, and ciao!

   Marc.

[Jose Claudio Faria]

Hello Marc,

I can not reproduce the "bug" here in my computer, everything works perfectly!

What may be happening is you're bypassing your computer's memory limit.

Here (in I my computer) the limit of graphics devices opened is 63.
More than that I get the following message:

if(T) {

for(i in 1:100) assign(sprintf("var%d", i), rnorm(n=i))

for(j in 1:70) {
dev.new()
plot(rnorm(2500))
}
}

Error in (function (width, height, pointsize, record, rescale, xpinch,:
many open devices

But the shortcut F12 always works nice.

It takes a bit to close all graphics devices, but closes all smoothly
and remains functional.

All the best,
///\\\///\\\///\\\///\\\///\\\///\\\///\\\///\\\
Jose Claudio Faria
Estatistica
UESC/DCET/Brasil
joseclaudio.faria at gmail.com
Telefones:
55(73)3680.5545 - UESC
55(73)99966.9100 - VIVO
55(73)99100.7351 - TIM
55(73)98817.6159 - OI
55(73)98129.9942 - CLARO
///\\\///\\\///\\\///\\\///\\\///\\\///\\\///\\\

[Marc Laurencelle]

Ok. Thanks for having verified that on your computer.

Still, the bug remains very frequent on my computers.

However, if there aren't any other user experimenting the same APPCRASH problem, you may indeed consider this issue as unimportant, especially given that I found a workaround which avoid APPCRASH in every case: using the F10 shortcut prior to F12, to close all graphics only, first, then clear all contents from the .GlobalEnv.

Let say, then, this issue is standby (or ~solved), as long as there won't be other users reporting similar crashes of R due to the F12 shortcut.

Bye!

   Marc. 

[Jose Claudio Faria]

OK.
One doubt, are you using the Rterm or Rgui with Tinn-R?

///\\\///\\\///\\\///\\\///\\\///\\\///\\\///\\\
Jose Claudio Faria
Estatistica
UESC/DCET/Brasil
joseclaudio.faria at gmail.com
Telefones:
55(73)3680.5545 - UESC
55(73)99966.9100 - VIVO
55(73)99100.7351 - TIM
55(73)98817.6159 - OI
55(73)98129.9942 - CLARO
///\\\///\\\///\\\///\\\///\\\///\\\///\\\///\\\

[Jose Claudio Faria]

On Tue, Aug 16, 2016 at 7:06 PM, Marc Laurencelle
<marc.lau...@gmail.com> wrote:
> I'm using Rgui with Tinn-R... but the MRO (Microsoft R Open) version.
> But in my previous tests, the standard R produced the same APPCRASHes, if I
> remember well.
>
> Marc

Hummm...
I only use the Rterm interface, rarely Rgui.
All the tests were done with the Rterm interface, this is the reason I
have not noticed before, sorry.

Using Rgui.exe (in both plain R and MRO) really is possible to
reproduce the bug on my machine.
We will see if you can get around.

Best,

[Jose Claudio Faria]

Dear Marc,

The bug was fixed: thanks for pointig it out!

The closure of many graphics devices for R is time consuming. So,
Tinn-R was trying to send the virtual key "CTRL + L" (after a default
and internal delay) to clear the R console after "rm(list=ls());
graphics.off()". This was the source of the bug under Rgui (it does
not occur under Rterm).

You will see the fix in the next pre-release version 4.02.12.00 to be released.

All the best,

///\\\///\\\///\\\///\\\///\\\///\\\///\\\///\\\
Jose Claudio Faria
Estatistica
UESC/DCET/Brasil
joseclaudio.faria at gmail.com
Telefones:
55(73)3680.5545 - UESC
55(73)99966.9100 - VIVO
55(73)99100.7351 - TIM
55(73)98817.6159 - OI
55(73)98129.9942 - CLARO
///\\\///\\\///\\\///\\\///\\\///\\\///\\\///\\\

[Marc Laurencelle]

Oh yeah! Even if there were workarounds for this bug, I'm so glad you found a solution!... and quite impressed by how quick you found it!

I'll download this new version gladly, as soon as it'll be available.

Thanks again!

Marc.