Date: 2017-01-23 14:52:23 +0100
From: @yzchang
To: GDK devs <>
Version: 11.25.3 (Dec2016)

Last updated: 2017-03-03 10:24:29 +0100

Comment 24902

Date: 2017-01-23 14:52:23 +0100
From: @yzchang

With the following queries:

create table bug1 (hit uuid, has_contributed boolean, parent_hit uuid);
insert into bug1 (hit, has_contributed, parent_hit) values ('16caf284-7fa2-4402-8e8a-5e89c644d23a', true, '16caf284-7fa2-4402-8e8a-5e89c644d23a');
insert into bug1 (hit, has_contributed, parent_hit) select * from bug1;

If one repeats the last INSERT INTO query several times to insert more tuples into "bug1", at some moment (after ~8K tuples have been inserted), mserver5 will report:

!ERROR: MT_msync: msync failed
!OS: Cannot allocate memory

after the transaction has succeeded.

The error seems to have been caused by that a point, which is not memory-mapped, was past to MY_msync.
The msync() call returns ENOMEM.

Comment 24903

Date: 2017-01-23 15:26:38 +0100
From: MonetDB Mercurial Repository <>

Changeset 6e108baf7828 made by Sjoerd Mullender sjoerd@acm.org in the MonetDB repo, refers to this bug.

For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=6e108baf7828

Changeset description:

Don't call msync with a length argument that is too long.
In fact, don't do all this complicated stuff to calculate start
address and length, just pass the unaltered heap base as start
address, and the occupied size of the heap as the length.
This should fix bug #6191.

Comment 24904

Date: 2017-01-23 15:30:18 +0100
From: @sjoerdmullender

This was a fairly benign bug. The msync was sometimes called with a "length" parameter which was too large. This resulted in the system call returning an error (ENOMEM) after it had done the work for the valid area. The fix was to not try to round the values for the arguments but to just pass the actual values for the start and size of heap.

Comment 25118

Date: 2017-03-03 10:24:29 +0100
From: @sjoerdmullender

Dec2016-SP2 has been released, incorporating the fix.