Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[statet-users] Fehler: protect(): protection stack overflow

Hello,

 

I got “Fehler: protect(): protection stack overflow” messages when reading a semi-large data set (an ESRI shape file) with rgdal::readOGR or when loading the same data set after conversion to a sp::SpatialPolygonsDataFrame. The size of the object is 139 Mb (so it is not to big).

 

The message is printed in countless replicates, so that the complete Console Window is full:

 

Fehler: protect(): protection stack overflow

Fehler: protect(): protection stack overflow

Fehler: protect(): protection stack overflow

Fehler: protect(): protection stack overflow

...(countless replicates)...

Fehler: protect(): protection stack overflow

Fehler: protect(): protection stack overflow

Fehler: protect(): protection stack overflow

Fehler: protect(): protection stack overflow

> 

 

 

The loaded object is listed normally in the Object Browser after loading, despite of the error messages.

 

After that, each command is executed as normal, but also the countless replicated error messages appear after (less then a half second) each execution of a command.

 

This problem does not occur in a normal Rgui (R 4.2.2) and also not in older Eclipse/StatET installations like StatET 4.5.0, Eclipse IDE for Java Developers 4.23 with R 4.1.3.

 

It does also not occur with StatET 4.6, Eclipse 2022-06, R-4.2.1 (or R-4.2.2), when starting a R Console, where in the “Run configurations” nothing has changed in the “R Console” Tab.  If something is added to the “R snippet run after startup” or the “Enable integrated R Help...” is unchecked, the problem appears. And still appear if the settings where set back to the initial values...

The error messages do also not appear, when the launch type is set to “Rterm”.

 

I can not provide a reproducable example, I have no problems with subsets of the data set (90 Mb) or with self constructed large data vectors.

 

Maybe this behaviour is somehow related to Windows, because of the use of the “system memory” allocator since R-4.2.0.., but this is far behind my knowledge.

 

 

Kind regards

Marco

 

 

 

 


Back to the top