Home

LINQPad 4.55.03 main process consumes > 1GB RAM over 72 hour period

I'm using LINQPad 4.55.03 Premium, and I leave LINQPad open as it's running on a virtual machine. I started LINQPad on 11-MAY-2015 and according to Task Manager the main process was consuming < 175MB private working set memory. Right now, 13-MAY-2015, it's using > 1.2GB private working set memory. There are four UserQuery processes that are using 10MB, 30MB, 52MB, and 280MB each. As a side note this Windows computer has 12GB RAM, and is currently using 6.4GB.

With the main process over 1GB memory, the LINQPad interface is very sluggish, to the point that it gets in the way of keystrokes. My only remedy is to close LINQPad and start it again thereby releasing the 1GB of memory. I don't remember when this behaviour started, perhaps about two months ago. Regrettably, I agreed to update LINQPad to a recent version at its prompting and I regret having done so.

Should I downgrade to an earlier version, or is there a new setting that I'm not aware of that will stop the runaway memory consumption?

Comments

  • Almost 24 hours later and the LINQPad main process is over 420MB for working set memory. A user query process was at 400MB but I recycled it with Shift-Ctrl-F5 and then Windows spawned a message box stating an error in LINQPad and that it had to be closed. I acknowledged the prompts, but the main LINQPad program is still running, and usable.
  • LINQPad has been running since 13-MAY, and today 19-MAY the main process has a memory footprint of 3.1GB (private working set). Time to kill it.
  • The main change since the older versions is process isolation for queries. In case this is factor, you could try disabling it in Edit | Preferences | Advanced. Let me know the result.

    Thanks
  • Disabling process isolation has eliminated the endless consumption of memory. A LINQPad process has been running since 19-MAY and as of this moment it is consuming <200MB. Thanks!
  • I can confirm that turning of process isolation have solved the same kind of problem for me. For me the problem was also that rendering of the results of queries was running slower and slower over time even before the memory usage was very high.

    So both these things fixed by turning it off.
  • Note sure whether this is related, but I noticed yesterday what looked like a zombie 'Your LINQPad Query' process which was taking over 1Gb of memory. The process id on this task did not appear in any of the Linqpad windows and it remained the same even after I closed all queries and tried the 'Cancel all threads and reset' and 'Cancel and reset all queries'.

    This routine was deleting/truncating some data from a database and my original attempt was attempting to delete a master table before child table and so I cancelled the routine.

    When I fixed my code and re-ran it, the routine stalled and timed out on a truncate table command. The only reason this could happen is if the table was locked and the only other process that could be doing so the supposed cancelled query.

    When I killed this process id using task manager, the script ran immediately.

    Hence it looks like the cancel button made it look like the query had stopped, whereas it was still running and taking up memory in the background causing a memory leak.

  • I came across this problem again today. I was running an routine which uses recursion and it threw an 'Out of memory' exception. I changed the code to limit the recursion level and re-ran the report and it still ran out of memory. I then lowered the recursion level again and this time it ran successfully.

    I didn't notice at the time, but I later discovered that there were two 'Your LINQPad Query' processes which were each using 1.6GB of memory and also around 25% CPU time.

    This was on a machine using LinqPad 4.57.02
  • Are you sure those processes were related to the queries that ran out of memory? LINQPad normally kills the process when there's an OOM exception. For instance, try running the following:

    static List<object> _objects = new List<object>(); void Main() { for (int i = 0; i < 10 ; i++) _objects.Add (Enumerable.Range (0, 10000000).Select (x => x).ToArray()); }

    After the first run, you'll see a LINQPad.UserQuery process using 400MB of memory. Run it twice more, and you'll get an OOM error - and you'll notice that the LINQPad.UserQuery process will disappear.
  • Firstly, your example behaves exactly as you said it should.

    So, you are correct that I don't know for sure that the processes were related to those two queries. Because the processes where still running even when all queries were closed, I assumed they belonged to some zombie process that and that was the only unusual thing that happened in LinqPad.


Sign In or Register to comment.