C stack usage is too close to the limit while loading data.image for shiny-server app




I am trying to run shiny app on shiny server deployed via ubuntu vm using Azure services.
My UI file begins with loading data.image (~100mb).
While app is working fine on my local pc and via r-studio server, when I am trying to acces it from shiny-server it crashes with this errors:

C stack usage 814747143012 is too close to the limit
R --no-save --slave -f /opt/shiny-server/R/SockJSAdapter.R

Have anybody ever tried to solve this problem? If so, what are potential solutions here? I have tried to find the answer, but I haven't seen any related to both - error and loading data image.

PS: I kept default settings, except I changed the path for applications, (examples and index. are working just fine).

Many thanks in advance for any help!


Hi, have you found a solution to your error? This post might be useful.


Hi. Thanks for your answer. I saw post that you shared, but I didn't find it helpfull. Even with seting stuck to unlimited amount I am continuing to expirience the same problem.


okay, too bad that didn't help.
Can you share the code that is causing the issue?


I'm also curious to see the code, and particularly to know if your code contains any recursive functions. A recursive function can consume a lot of stack, but the problem can be solved by converting the recursive function to an iterative one.


I am sorry for not responding so long.

Regarding code. Well, before sharing, let me highlight something.
The app runs perfectly on my laptop, (Windows 8.1), using desktop r-studio. It also opens via the r-studio server, established on Azure Droplet, (Ubuntu). Described error occurs only when I am trying to run an app using shiny-server, established on the same VM.

I am pretty sure that recursion is not an issue. I checked shiny-server logs. The application fails when trying to load a large r-data object into the global environment.

So, taking into account everything that I mentioned, the line of code that causing the issue is following:



Have you tried using a VM with more memory? If that makes the problem go away, you could stop there, or you could work on optimizing your data and/or code so that it works in the original-sized VM.