To reproduce:
sql>select count() from sys.bbp() where kind='transient';
+------+
| L4 |
+======+
| 161 |
+------+
1 tuple (11.032ms)
sql>select count() from sys.bbp() where kind='transient';
+------+
| L4 |
+======+
| 163 |
+------+
1 tuple (9.218ms)
sql>select count() from sys.bbp() where kind='transient';
+------+
| L4 |
+======+
| 165 |
+------+
1 tuple (9.192ms)
sql>select count() from sys.bbp() where kind='transient';
+------+
| L4 |
+======+
| 167 |
+------+
1 tuple (9.083ms)
sql>select count(*) from sys.bbp() where kind='transient';
+------+
| L4 |
+======+
| 169 |
+------+
1 tuple (8.975ms)
Expected: that number should not be increasing
The issue can be reproduced with any query which is guaranteed to return one row, e.g. "select 1;". I used the example above because it both reproduces and demonstrates the issue in a single query.
Each run of the query leaks 1+<number_of_result_columns> BATs.
The issue appears to be in mvc_scalar_value_wrap(), which is calling mvc_result_table() and then discarding the result so it can never call res_tables_remove(res_tables_find()) on it. The equivalent code in mvc_row_result_wrap() (i.e. for multi-row results, which don't leak) is rather different so I'm not sure what's the neatest patch.
Date: 2017-08-22 14:42:40 +0200
From: Richard Hughes <<richard.monetdb>>
To: SQL devs <>
Version: 11.27.5 (Jul2017-SP1)
Last updated: 2017-10-26 14:01:34 +0200
Comment 25590
Date: 2017-08-22 14:42:40 +0200
From: Richard Hughes <<richard.monetdb>>
Build is Jul2017 a55ec984eb42
To reproduce:
sql>select count() from sys.bbp() where kind='transient';
+------+
| L4 |
+======+
| 161 |
+------+
1 tuple (11.032ms)
sql>select count() from sys.bbp() where kind='transient';
+------+
| L4 |
+======+
| 163 |
+------+
1 tuple (9.218ms)
sql>select count() from sys.bbp() where kind='transient';
+------+
| L4 |
+======+
| 165 |
+------+
1 tuple (9.192ms)
sql>select count() from sys.bbp() where kind='transient';
+------+
| L4 |
+======+
| 167 |
+------+
1 tuple (9.083ms)
sql>select count(*) from sys.bbp() where kind='transient';
+------+
| L4 |
+======+
| 169 |
+------+
1 tuple (8.975ms)
Expected: that number should not be increasing
The issue can be reproduced with any query which is guaranteed to return one row, e.g. "select 1;". I used the example above because it both reproduces and demonstrates the issue in a single query.
Each run of the query leaks 1+<number_of_result_columns> BATs.
The issue appears to be in mvc_scalar_value_wrap(), which is calling mvc_result_table() and then discarding the result so it can never call res_tables_remove(res_tables_find()) on it. The equivalent code in mvc_row_result_wrap() (i.e. for multi-row results, which don't leak) is rather different so I'm not sure what's the neatest patch.
Comment 25591
Date: 2017-08-22 17:45:39 +0200
From: MonetDB Mercurial Repository <>
Changeset 2167d80ea078 made by Sjoerd Mullender sjoerd@acm.org in the MonetDB repo, refers to this bug.
For complete details, see https//devmonetdborg/hg/MonetDB?cmd=changeset;node=2167d80ea078
Changeset description:
Comment 25593
Date: 2017-08-23 12:03:08 +0200
From: Richard Hughes <<richard.monetdb>>
Confirmed.
Sorry for the misleading commentary above - I did most of my debugging on Jun2016 then only tested its existence on Jul2017.
Comment 25595
Date: 2017-08-23 13:34:06 +0200
From: @sjoerdmullender
Your comments did help in locating the problem.
I'm glad the fix is confirmed.
The text was updated successfully, but these errors were encountered: