System.Data.SQLite

Login
This project makes use of Eagle, provided by Mistachkin Systems.
Eagle: Secure Software Automation
Ticket Hash: 07273156c20aa91e9d321c9d3367cb932f3348b2
Title: Memory leak on mono using sql params
Status: Closed Type: Incident
Severity: Important Priority: Medium
Subsystem: LINQ Resolution: Unable_To_Reproduce
Last Modified: 2019-06-08 16:18:22
Version Found In: 1.0.110
User Comments:
anonymous added on 2019-03-22 13:35:30: (text/html)
I'm facing memory leak when using Sqlite and EF into a Mono project.
If I do a query like below everything is ok.
>>context.IgnoredAlarms.Where(x => x.UserId == 1);
But if I do a query that will create query params, like code below, then program memory was growing up.
>>int userId = 1;
>>context.IgnoredAlarms.Where(x => x.UserId == userId);

I had tested from Mono 4.14 to 4.18 (and 4.20 preview too). And from System.Data.Sqlite 1.0.108 to 1.0.110.
Tested into one RaspberryPi 3 (with Raspbian) and Ubuntu 32 bits.
Tested using sqlite3 native library from apt-get and libSQLite.Interop.so created from System.Data.Sqlite source code.

Demo project can be found at www.sitrad.com.br/sitradpro103/MonoMemoryTest.zip.
It has libs\SQLite_Mono\libSQLite.Interop.so library that was built to RaspberryPi. If testing in other systems it's possible that it will need to be recompiled to the target system.

anonymous added on 2019-03-22 13:42:35: (text/x-fossil-plain)
I'm facing memory leak when using Sqlite and EF into a Mono project.

If I do a query like below everything is ok.
    context.IgnoredAlarms.Where(x => x.UserId == 1);

But if I do a query that will create query params, like code below, then program memory is growing up.
    int userId = 1;
    context.IgnoredAlarms.Where(x => x.UserId == userId);

I tested from Mono 4.14 up to 4.18 (and 4.20 preview too). And System.Data.Sqlite 1.0.108 and 1.0.110.
Tested into one RaspberryPi 3 (with Raspbian) and Ubuntu 32 bits.
Tested using sqlite3 native library from apt-get and libSQLite.Interop.so created from System.Data.Sqlite source code.

A demo project can be found at www.sitrad.com.br/sitradpro103/MonoMemoryTest.zip.
It has the libs\SQLite_Mono\libSQLite.Interop.so library that was built to RaspberryPi. If testing in other systems it's possible that it will need to be recompiled to the target system.

anonymous added on 2019-03-22 13:51:21: (text/x-fossil-plain)
I forgot to say that need to use configuration "Debug_Embedded" to build demo project to run with Mono.

mistachkin added on 2019-03-24 01:21:10: (text/x-fossil-plain)
Does this same code leak when run under the .NET Framework and/or .NET Core?

mistachkin added on 2019-03-24 01:33:29: (text/x-fossil-plain)
Testing locally here, the leak does NOT appear to reproduce using the .NET
Framework on Windows (via Visual Studio 2013).

mistachkin added on 2019-03-24 02:02:01: (text/x-fossil-plain)
It's possible that the leak you are seeing is a bug in the Mono runtime.  The
SQLiteParameter objects are purely managed, do not use or refer to any expensive
resources, and should be automatically garbage collected when no longer used.

It's also possible that this is some kind of bad interaction between EF6 and the
Mono runtime.  Perhaps EF6 is not properly disposing of SQLiteCommand and/or
SQLiteDataReader objects when running on Mono?  That could cause memory usage to
climb.

anonymous added on 2019-03-25 11:51:09: (text/x-fossil-plain)
The memory leak is not so big. But over time it ends up consuming the entire 1GB of raspberry pi RAM.
In the demo project I created 5 tasks in constant loop to speed up the process of memory consumption.
Using the Mono profiler I couldn't identify any object increasing over time.

The code below, for example, doesn't consume memory.
     int userId = 0;
     context.IgnoredAlarms.SqlQuery ("select * from IgnoredAlarm where UserId = @ p0", userId);

anonymous added on 2019-03-27 21:14:53: (text/x-fossil-plain)
This leak do not occurs in the .Net Framework on Windows. Just at Linux.
As the Mono profiler do not find any memory leak, could this be a Sqlite leak? I don't think so, but!

mistachkin added on 2019-03-27 22:27:50: (text/x-fossil-plain)
Given how thoroughly SQLite is tested for memory leaks (see
"https://www.sqlite.org/testing.html"), it seems unlikely to
be a leak there.

I think it is some kind of bad interaction between what EF6
expects (from ADO.NET) in terms of resource management and
what Mono is providing.

That being said, in my testing of System.Data.SQLite via Mono
on macOS and Linux, I have not personally seen a memory leak.

anonymous added on 2019-03-28 14:36:14: (text/x-fossil-plain)
What version of Mono and System.Data.Sqlite do you tested? In which linux distribution?

Do you have some suggestions of what can I test in RaspberryPi to find what is happening?

mistachkin added on 2019-03-29 17:48:15: (text/x-fossil-plain)
Generally, I tested with the most recently released stable version (e.g. 5.18) on
both macOS and Ubuntu 16.04 LTS.

anonymous added on 2019-04-12 18:51:50: (text/x-fossil-plain)
I tested with your Ubuntu version too. And to me there is memory leak.
Now I was testing to reduce the project complexity to identify where is the problem. And I see some curious happening.
The demo project was running all day long and increasing memory consumption. It takes hours to increase from from 102 KB to 106 KB. Then in just one moment it drops from 106 KB back to 102 KB.
It seems to be a Mono error?
Any one else has tested this project to see if there is a memory leak?